when do things really need to be revoked? who decides?

[Mike Shaver]

DELAYED REVOCATION IS TOO COMMON

This is long enough, so I’ll spare readers dozens of links to delayed-revocation incidents collected in Bugzilla; we all know that pretty much any other incident that involves misissuance will come with a delayed-revocation chaser these days.

In *many* of those delrev (?)incidents, we see a phrase like “we requested that our subscribers revoke and reissue”. They are not informing their subscribers as to a fixed revocation timeline, but rather simply asking if those subscribers if they would please do the revocation process when they’re able. In one case, I heard of a revocation request from a major CA that didn’t even have a timeline *suggested*. Of course, the subscriber gets no value out of replacing their certs: it’s pure overhead, and if WebPKI were operated perfectly, it would never be necessary. This is an externality of, most often, a CA’s failure to sufficiently invest in understanding, implementing, and verifying the processes that they use to twirl the keys to the entire web’s security.

Indeed in a number of cases the CAs didn’t even stop issuing once they realized that they were misissuing certs! Intentionally issuing certs that are known to be bad, what a world.

While CAs generally claim that they would be able to handle a mass revocation incident (such as due to leaked key material), the evidence we have for CAs aggressively revoking as called for by the BRs and the root programs is…scant. We’ve seen “it was a long weekend” as a reason for delaying revocation for certs—including some used by a different part of the CA’s company! One CA has proposed a “global fire drill” to stress-test revocation procedures, but we’re seeing revocation timelines reaching multiple months right now, so…a lot of stuff would end up burning in that fire.

CAs also tell us that they advocate and recommend for their subscribers to implement automation for cert management, but we never see any concrete targets or success criteria for those efforts, so they certainly seem to me to just be more “asking nicely”. (I’m not sure that all of the CAs claiming to be pushing for subscriber automation actually have robust ACME or similar support yet, in fact.)

(Some of the CAs made explicit promises years ago to not delay revocation, some of them issued even though they knew that zlint showed an error—there are lots of additional twists on simply “issuing bad certs and not cleaning them up as agreed”.)

Now, in the wake of these *many* delrev incidents, over years of history, the root programs have responded with pretty much no consequences whatsoever as far as I can tell. There’s one case open about Entrust’s overall behaviour, who are certainly over-achieving when it comes to ways to get location fields wrong, but they are definitely not the only ones who treat the BRs’ 1/5-day revocation instruction as instead meaning “when it’s convenient for the customer”.

THE QUESTION

So: what should be done to make revocations of misissued certificates—sometimes *intentionally* misissued certificates—as prompt as the BRs require?

The cost equation for CAs is obviously skewed against the health the web PKI, if we are to believe that the BRs are important. Once a CA has violated the BRs and misissued, it is *in their commercial interest* to not revoke promptly: it causes embarrassment and subscriber frustration, or even disruption to subscriber services. At the limit it might even lead a subscriber to change CAs if the reissuance events are frequent and disruptive enough.

On the other hand, the more bad certs there are floating around, even if it’s “only” a matter of a case mismatch, the less interoperable the web PKI is, and the harder it is for a relying party to make effective use of WebPKI’s guarantees. Let’s please not end up with a “quirks mode” for TLS certificate handling!

SOME OPTIONS

One option: decide that there really are some BR violations that “don’t matter”, such that revocation can happen on a more relaxed, accommodating timeline—or perhaps not at all, just letting them expire as has been seen in some delrev incidents already. This would mean that we would still see incident reports that in theory help other CAs learn to put the postal code in the right field or similar, but subscribers and CAs and root programs would have to do less work.

Another option: have affected certificates added to OneCRL after 72 hours. It would benefit from some automation, but it’s probably feasible to make relatively smooth. It is sometimes the case, worryingly, that it takes CAs a fair bit of time and multiple attempts to find all the affected certificates, so this might require some linter running off CT logs or similar as a watchdog.

Another another option: forbid CAs from selling WebPKI certificates into environments where a) revocation within a 5-day limit is operationally infeasible, and b) disruption of the related services would cause risk to human health and safety or similar. There are apparently many organizations out there which are critical to national economies or whatever, but need literal Earth months to replace a certificate. These are clearly cases where the requirements of WebPKI are incompatible with the operational constraints of the subscriber, so it’s not a good idea to mix them. (I’m sure some CAs could offer help with private PKI systems, probably with compelling margins.)

Yet another, this time somewhat more preventative: if a CA repeatedly demonstrates that they are unable or (always the case?) unwilling to honour their commitments to the BRs, impose validity length restrictions on certs that they issue. At least in that case future misissued certificates would be in the wild for longer, and it would also show nicely that CAs’ advocacy for certificate automation was fruitful. Ignoring Entrust’s diatribe against 90-day validity periods in that weird blog post, I don’t think that any CA has made a credible case that their customers would not be able to handle rotating certificates every 90 days, even if they have to carve the new fingerprint into a mountain using a toothbrush or whatever. They’d even know it’s coming.

One more: make delayed revocation incidents, specifically, more visible to subscribers and potential subscribers, and see if business pressure does what merely “agreeing legally to follow the BRs” (and optionally making empty “it’ll never happen again” promises) has been unable to do in too many cases.

THANKS FOR READING

I think the WebPKI is being poorly served by the *realities* of certificate integrity and misissuance responses. If nothing else, it’s causing a ton of delrev incidents for Ben to have to shepherd, without even module peers to assist him.

Something needs to change.

[Suchan Seo]

I wonder what makes certficiate replacement slow and not wanted to do so - is it validation step or deploy new certficiate everywhere old certificate was?

OV/EV related valiations are valid for 398 days as 3.2.2.14.3 so most of revalidation should be about validating domains:

for simplyfying later part there could be an ocsp extension that points to another certificate (that signs same skid/publikey) that tell while this certificate itself is revoked, but this is replacement that likely to be valid: this makes in effect skips certificate deployment process, make replacement single email to webmaster to authroize replacement certificate.

2024년 5월 21일 화요일 오전 9시 46분 0초 UTC+9에 Mike Shaver님이 작성:

[Wayne]

In the delayed revocation incidents recently, the main barrier for replacing a certificate has been deployment. I've not heard of validation being an issue as-of-yet, but it may just not have been mentioned.

[Jeremy Rowley]

From my perspective, it’s the third-party approval process some of these companies are required  to go through to replace certs. Failure to go through that process can result in government fines. Financial and medical companies operating outside of the US seem especially handicapped by policy restrictions when replacing certificates.

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Wayne <rdau...@gmail.com>
Sent: Thursday, May 30, 2024 8:34:16 AM
To: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: when do things really need to be revoked? who decides?

 

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/79c8a805-c043-45d4-8a06-8946425a3cb5n%40mozilla.org.

[Mike Shaver]

Have we actually seen any evidence that this is the barrier, and not just the Subscribers’ historic processes? It seems like the sort of thing that one would expect to be outlined in the per-subscriber detail expected by the BRs, but those tend to be extremely sparse on actually *why* the Subscriber cannot rotate more promptly. In my casual survey of delayed revocation incidents, virtually every case is “the Subscriber’s internal processes and tooling doesn’t permit it”, which the CA assures us they will advocate to remedy, and not “there is a regulatory barrier for this Subscriber which will always exist”. If there were a piece of bright-line regulation that prevented rotation within 120 hours, I would have expected it to have been brought up by now in one of the many delayed revocation incidents.

Could you point the community to an example of such a regulation that would prevent a certificate from being validated and deployed within the timelines, given sufficiently motivated Subscribers? They might have to pay overtime or rush fees, of course, but choosing not to do so is not the same as being unable.

But then, I wonder, what are these companies expected to do if there is a key compromise? (If they had a validated backup certificate from a different vendor—like they probably do for all their other essential operating elements—then they could just drop it in without having to run a validation process in the moment. This seems like such an obviously necessary SPOF to address that I’m amazed that it’s not the norm in regulated industries like the ones you describe.)

It also seems unusual to me that so many of these regulated-industry Subscribers would have made a legally binding commitment to 9.6.3(8) of the BRs, which requires them to “accept” immediate revocation, if they had these opposing regulatory constraints in place.

Mike

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/BYAPR14MB2600DF510017199D80A2F5888EF32%40BYAPR14MB2600.namprd14.prod.outlook.com.

[Jeremy Rowley]

Here’s one example provided during our revocation: Hong Kong Monetary Authority - Technology Risk Management (hkma.gov.hk)

 

I haven’t read it all, but according to several of the Chinese banks, there’s monetary damages if they replace a certificate without government permission. We had the same issue in South America, but those subscribers haven’t sent over the corresponding regulations yet.

 

I don’t think it’s a bright line rule. What I’ve consistently heard is they need government approval, which is easily obtained in security incidents but hard to obtain when the regulator does not understand why the certificate is being replaced. One question I always ask is “What would you do in key compromise?”. The answer I get back is that key compromised would be better because the regulator’s understand that. They don’t understand why a capitalization issue is requiring a cert rotation. The worse the issue, the faster and easier to get permission.

[Mike Shaver]

“The certificate is being replaced because it will be revoked by the CA, as we agreed to legally when we were issued the certificate” seems like it would need to be sufficient, unless the regulatory body also has some way to compel the CA to forestall revocation itself, in violation of its root program agreements. Historically, have the regulatory bodies preferred that these services go offline while waiting for approval? (Or do they ask “why don’t you have a fallback option here?”, perhaps?)

But this would require the CA to actually set and credibly enforce a revocation timeline within the parameters of the BRs, and it seems that some CAs are, worryingly, unwilling to do so.

Mike

[Watson Ladd]

On Thu, May 30, 2024 at 8:28 AM 'Jeremy Rowley' via
dev-secur...@mozilla.org <dev-secur...@mozilla.org>
wrote:
>

> Here’s one example provided during our revocation: Hong Kong Monetary Authority - Technology Risk Management (hkma.gov.hk)
>
>
>
> I haven’t read it all, but according to several of the Chinese banks, there’s monetary damages if they replace a certificate without government permission. We had the same issue in South America, but those subscribers haven’t sent over the corresponding regulations yet.
>
>
>
> I don’t think it’s a bright line rule. What I’ve consistently heard is they need government approval, which is easily obtained in security incidents but hard to obtain when the regulator does not understand why the certificate is being replaced. One question I always ask is “What would you do in key compromise?”. The answer I get back is that key compromised would be better because the regulator’s understand that. They don’t understand why a capitalization issue is requiring a cert rotation. The worse the issue, the faster and easier to get permission.

The answer should be "because it will stop working in 5 days since the
CA will revoke it, and if they don't the CA will be distrusted". Your
subscribers signed an acknowledgement this would happen: did they do
so knowing that the regulators don't understand the issue?

Sincerely,
Watson

--
Astra mortemque praestare gradatim

[Jeremy Rowley]

Yes – sites have gone down while waiting for approval. We have caused outages by revoking if we didn’t think the revocation would meet the bar required for a delayed revocation report or if there is a key compromise (requiring 24 hour revocation).

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqvoy0T5s-BKuQc-GBvxmb-JM%3D-FARyamXr9vcP9AQ7Aew%40mail.gmail.com.

[Mike Shaver]

OK, then I guess that’s how that industry and subscriber want things to go, given that they prefer this to the alternatives of hot-spare certificates or non-public PKI or such.

It may be that the subscribers in these industries need to lobby for a better understanding of WebPKI operations and principles on the part of their regulatory body, but that’s outside the scope and concerns of the BRs and root programs.

Thank you for your help understanding these issues!

Mike

[Amir Omidi (aaomidi)]

In my experience (and through what I've heard from others), at least in large enterprises, the work for automating cert issuance and replacement is simply not important.

I've asked a few folks who would be in the place to do that automation work and in nearly all cases they tell me they know what they need to do, they know the task is not necessarily a fast one to complete, but it will forever be de-prioritized because it just doesn't matter. If something happens, they can ask their CA of choice to delay revocation - they seem to  believe that certain CAs would be fine delaying revocation even in the case of key compromise.

This really brings it back down to incentives and priorities. Changing how you do certificates in an enterprise is definitely not easy. This is exacerbated by the fact that DNS-01 does not allow DNS validation delegation to more than one entity (CNAMEs are unique records, so you can't have _acme-challenge.example.com pointing at two different DNS names, something I'm trying to solve through https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/). To be clear, I don't think that the barrier for adopting automation is genuinely on the technology level, but rather the lack of enforcement by the RPs and the lack of "care" for the rules by the CAs.

Ryan Sleevi also pointed this out a while back, that if one CA is allowed to delay revocations, then that will effectively cause a regression to the mean: https://lists.cabforum.org/pipermail/servercert-wg/2018-September/000170.html

Quote:

However, let's further expand this thought experiment, and think about what the consequences are of having the CA make such a determination (Availability > Competent and Correct operation). A CA is naturally incentivized to optimize for Availability - the CA who never revokes their Subscriber certs is the CA to pick, the same as the CA that always picks the maximum validity period rather than the minimum. This is something we've seen time and time again - the worse a CA is, for the ecosystem, the more popular it becomes relative to its competitors. But equally, a CA that issues such invalid certificates, but encourages non-revocation, equally encourages the rest of the ecosystem to do so, such that it becomes the norm - a de facto standard of incompatibility.

If the client does not aggressively police this - at verification time - then the ecosystem falters, because the existing players accept such certs, and thus any new Relying Parties must also accept such certs.

I really do think that a lot of these "difficulties" are baseless excuses. They are stemmed from avoidance of what seems like unnecessary work (we can just ask the CA to delay revocation).

The state that WebPKI is in right now is not a healthy one. We have a list of rules, that we're treating mostly as "guidelines". This means that when a CA feels like it can ignore one part of the BRs, and the RPs simply don't care when a CA does that, then CAs are going to feel a lot more adventurous to ignore other parts of the BRs. If left alone, we're just going to see more and more CAs that don't even know what the BRs are.

So if we're talking about the options laid out in this post, I'd like to add one more option: If the RPs are finding the existing rules impossible to enforce then trash the existing rules and write a new ones that are  watered down enough to the point where the RPs can actually enforce them. Don't treat these rules as guidelines.

[Matt Palmer]

On Thu, May 30, 2024 at 09:14:52AM -0700, 'Amir Omidi (aaomidi)' via dev-secur...@mozilla.org wrote:
> In my experience (and through what I've heard from others), at least in
> large enterprises, the work for automating cert issuance and replacement is

> simply *not important*.

>
> I've asked a few folks who would be in the place to do that automation work
> and in nearly all cases they tell me they know what they need to do, they
> know the task is not necessarily a fast one to complete, but it will

> forever be de-prioritized because it *just doesn't matter*. If something

> happens, they can ask their CA of choice to delay revocation - they seem
> to believe that certain CAs would be fine delaying revocation even in the
> case of key compromise.

If subscribers don't think that certificate automation isn't important,
lets make a new revocation reason, "because a Root Program told us to".
Mozilla, et al then randomly choose issued certificates and require them
to be revoked within 24 hours (if I'm going to make up
never-gonna-happen things, I may as well shoot for the moon...)

- Matt

[Matt Palmer]

On Thu, May 30, 2024 at 11:23:03AM -0400, Mike Shaver wrote:
> But then, I wonder, what are these companies expected to do if there is a
> key compromise?

I can't tell you what they *expected* to do, but I can tell you exactly
what they *actually* do:

1. they contact the person who publicised the key compromise, very
strongly suggesting that the blog post describing the compromise be
taken down.

2. they contact the places where the blog post was publicised, and
pressure them into removing / editing the publication.

3. they replace the certificate on the live site about 10 days later.

4. they never contact the issuing CA to request revocation of the
compromised certificate, leaving everyone exactly as exposed to
interception as if they'd never bothered to replace the certificate in
the first place.

- Matt

[Matt Palmer]

On Thu, May 30, 2024 at 02:52:33PM +0000, 'Jeremy Rowley' via dev-secur...@mozilla.org wrote:
> From my perspective, it’s the third-party approval process some of
> these companies are required to go through to replace certs. Failure
> to go through that process can result in government fines. Financial
> and medical companies operating outside of the US seem especially
> handicapped by policy restrictions when replacing certificates.

Sounds like they bought something that wasn't fit for purpose. If the
customer isn't able to comply with the requirements of the WebPKI, they
shouldn't be using it. Whether that mistaken purchase is the fault of
the subscriber (through a lack of due diligence) or the CA (through
misrepresentation) is something for those parties to work out between
themselves, but is *absolutely* not something that is relevant to
considerations of trustworthiness.

(I know *you* know this, Jeremy; this one's for the wider community)

- Matt

[Tyrel]

I think the question posed is a good one, and, as a relying party, that the answer should be "whatever it takes."

More specifically, I think CAs are often misinterpreting what responses should be in case of a delayed revocation event. Rather than generalities or abstract strategies ("we will encourage adoption of automation!" or "we will discourage certificate pinning" or...), the actions should be specific and concrete, and tied to each subscriber for whom there was a delay. Some examples, inspired by recent delayed revocation events, of the kinds of actions I would expect from CAs:

"We didn't know subscriber X was using certificates to manage their fleet of nuclear reactors. Since that is against our terms of service, subscriber X is no longer a customer of ours."

OR

"We didn't know that subscriber Y was contractually required to notify others 90 days in advance of a certificate change. Since they cannot possibly abide by the 1 day/5 day revocation timelines, we have moved them to be on a privatePKI [or they are no longer our customer]."

OR

"Subscriber Z needed a delay because they had one person responsible for manually requesting and replacing 5000 certificates. We have worked with that subscriber so that certificate replacement is now automated, and can be completed in the timelines required by the BR.s"

OR

"We did not grant a revocation delay to subscriber Q because they said we cannot communicate the reason for the delay to the root programs and the community."

The fact that we are not seeing responses like these I think speaks volumes about the current priorities within a majority of CAs. The question of course is, what do to so that these kinds of responses become the norm?

Personally, I think the idea of having 1 day / 5 day revocation technically enforced by the root programs (rather than by the CAs) has a lot of merit. In particular, it would change the conversation that CAs have with subscribers from "maybe we will delay, maybe not, convince us" to "these certificates are being revoked in 5 days. What can we do to help it not be an interruption to your line of business?". I think this is actually a really strong benefit of the approach. The biggest weakness I can see is that it might promote "intentional ignorance," within CAs, at least for a period of time, where "oops, our first list didn't have all the mis-issued certificates, sorry about that." becomes a refrain. This could be nipped in the bud if the root store policy were "if we find that is happening, then at the next revocation event  we will add all affected issuing intermediates as revoked." Which is a strong incentive to do it right the first time [and, also, to encourage use of more intermediates to limit blast radius's, which is also a good thing in my opinion].

I am less sold on the idea of capping the validity time of certificates of CAs with more than their share of problems. While this does push towards greater agility, I doubt it will have the intended effect, instead pushing most subscribers to other CAs who still issue yearly.

Whether or not a technical solution like these are adopted, it is clear to me that something must be done here. Perhaps root programs should also be much more willing to revoke roots over delay events ("three times in a year and you're out."?). But I think the intermediate technical solutions have a better chance of driving the ecosystem to where it needs to go.

[Tyrel]

Since it has come up in multiple delayed revocation events across multiple CAs, I want to push back on the idea that regulators are a valid reason for revocation delays in most cases. 

There is no question some countries have regulators that expect to be notified before certificate changes, and that a fraction of those also disallow replacement until the regulating body approves the change (which is my opinion is crazy, but to each their own). But in most of these cases, the reason for this is that they are deployed on, e.g., communication systems between banks, payment terminals, etc. There is no technical reason why almost all of these spaces cannot have their own privatePKI (with different rules than the webPKI). Especially if the reason for the rule is incorporation of the new certificate into other systems -- that means there is pinning or something equivalent going on, in which case you could just as well trust explicitly the self-signed certificate (or whatever suits your fancy).

I know that in some cases, the certificates are deployed at endpoints that may be access by payment terminals or other "covered devices" (which means the regulations cover it) while also being web browser accessible, and thus while not directly required to followed the same rules, it has to, and be compatible with the webPKI. But there are technical solutions here too -- the easiest being of course, "make the endpoints for covered devices and the web different!" But there are others, e.g. many CDNs and web proxy software will let you send different certificates depending on the originating device, so you can use a privatePKI certificate (that requires approval and cannot change "fast") for covered devices and a webPKI certificate (that needs agility) all on one endpoint.

I think the webPKI should take actions commensurate with encouraging these applications to move to their own PKI hierarch(y/ies), which is to say, view "regulators did not approve it in time," is not a valid reason to delay revocation.

In writing this, I have a question: does anyone know if most of the regulations are tied to the certificates, or to the cryptographic keys? My limited perusal seems to suggest that in many cases it is the latter that is tied to notification/approval requirements, in which case a certificate change (but keeping the same keypair) should not impose the regulator requirements at all. But I'd love for people who actually know this space to chime in.

Tyrel

On Monday, May 20, 2024 at 8:46:00 PM UTC-4 Mike Shaver wrote:

[Amir Omidi (aaomidi)]

I want to very explicitly say that I am against doing a `CA Fire Drill` for the time being. There is probably a time and place for that, but I do not think this is it. This idea of a CA fire drill being proposed by CAs that are consistently not revoking according to the BRs is, at best, an attempt at deflection and blaming the rules of the BRs that they have agreed to in the past.

I would actually recommend that root programs, and CAs (even though, I don't think what I'm about to propose is going to be popular with a lot of these misbehaving CAs), move towards a unified 24 hour revocation requirement.

My justification for this is:

1. We keep hearing from CAs that their subscribers don't take the 5 day revocation reasons seriously. 
2. Short lived certificates remove the need for revocation.
3. Most enterprise subscribers will not take certificate agility seriously.
4. We're sacrificing the security of most of the users with the current model, because of the inability for a very few users not wanting to spend the resources to achieve certificate agility.
5. It is impossible, and irresponsible, to due a security analysis of a mis-issuanece with the due-diligence necessary to make the claim of 24 vs 120 hours for revocation. We're having CAs fail to follow basic instructions, I don't think we're at the point where we can expect them to fully, and thoroughly analyze an incident and understand the full security implications of it.
   

All of these reasons are completely understandable, so let's work with these subscribers and CAs by removing that second tier of 120 hour revocation requirements, and state that all misissuances must be revoked within 24 hours with the exception of short lived certificates.

As my proposal, I recommend that we do a graduated move towards the 24 hour number. For example, by the end of 2024 - we hit 96 hours for the second tier. By the end of 2025 we hit 72 hours. And finally by the end of 2026, we put all misissuances in a 24 hour revocation requirement.

[Amir Omidi (aaomidi)]

I should add one more point to this. I don't actually think most CAs would be able to properly handle a mass revocation in 24 hours effectively (finding impacted certificates, oncall preparedness, HSM capacity to even do the revocation).

This is scary if we actually face a major issue (e.g. DVC was done incorrectly for millions of certificates.) The move to a 24 hour unified revocation requirement means that the muscles for doing a revocation in 24 hours actually gets tested and can be improved when non-serious incidents happen. The graduated move towards this number softens the impact and allows for both subscriber, and CA preparedness.

This also means that CAs can consider different strategies for revocation such as revoking a whole intermediate instead of the individual leaf certs.

[Mike Shaver]

On Mon, Jun 10, 2024 at 11:06 AM Tyrel <tmcque...@gmail.com> wrote:

Since it has come up in multiple delayed revocation events across multiple CAs, I want to push back on the idea that regulators are a valid reason for revocation delays in most cases.

What do you mean by valid?

- seen as an acceptable reason by regulators?

- seen as an acceptable reason by subscribers?

- seen as an acceptable reason by CAs?

- seen as an acceptable reason by relying parties?

- compatible with the rules laid out in the BRs?

- seen as an acceptable reason by root programs?

the first 3 seem to often be the case, from the evidence available to me

I’m guessing but I don’t think the vast majority of relying parties care, but would probably accede to “the government said we can’t do this thing (and we won’t bring up any of the things we could have done to avoid this situation)”

the BRs don’t admit to any option for delaying revocation beyond 120hr but they also don’t indicate what an appropriate response should be, and it is clear that “distrust” is not viewed as a proportionate response even to a large number of delayed revocation incidents (in the absence of other problems)

and it’s sort of hard to see how often it’s bought up in delrev incidents without specific opposition by root program representatives, let alone subsequent consequences, and *not* feel that the root programs actually feel that it’s a valid reason

I think that the practice of delaying revocation due to (entirely predictable, and plausible to mitigate, if also generally undetailed) regulatory contexts is harmful for the web PKI, but as long as the CAs are able to push the risk onto the web PKI rather than turning away a customer that is inappropriate for the web PKI, or telling them to get a backup certificate pre-approved from a different CA, or whatever…why would CAs *not* let Subscribers use that as an excuse?

Mike