Let's all watch https://bugzilla.mozilla.org/show_bug.cgi?id=1910322 closely.
That incident went from a 24-hour revocation timeline to 120 hours. This is exactly why I think having more than one revocation period in the BRs is a bad idea. In my opinion, we need to set the expectation that revocations will be happening in a consistent timeline across incidents. Cheers On Fri, Jul 26, 2024 at 11:33 PM Matt Palmer <[email protected]> wrote: > On Fri, Jul 26, 2024 at 10:13:31AM -0600, Ben Wilson wrote: > > In addition to the ideas stated in my previous email, I’d like to get > your > > thoughts on some of the steps we can take while we discuss the current > > 5-day revocation requirement in BR 4.9.1.1. > > > > We can, and should, develop more stringent disclosure requirements that > > compel CAs to provide advance descriptions of the circumstances under > which > > they cannot revoke a certificate within the required timeframe. My > proposal > > is that we modify Mozilla's guidance on delayed revocation > > <https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation>. We > will > > preserve that statement that “Mozilla does not grant exceptions to the BR > > revocation requirements.” The revisions would mandate full disclosure in > > advance so that the community can evaluate the CA's and subscriber's > > arguments for delayed revocation. > > I don't agree with wording it as "full disclosure in advance so that the > community can evaluate", because that could be read as suggesting that > Mozilla and/or the community are somehow "judging" reasons, and can > provide some sort of "injunctive relief" to delay revocation. Instead, > by my understanding, the intention is to gather more useful information > about why revocation is sometimes delayed, for dissemination both to > other CAs and their subscribers (so as to inform operational and > organisational practices), and to the WebPKI community, to provide input > into policy making. I don't have any specific wording suggestions, but > I think changing the wording to more accurately emphasise the > "information gathering" purpose would be an improvement. > > Also, I'd like that information be gathered not just when full-blown > incidents occur, but also in what could be considered a kind of "near > miss". Given that all of 4.9.1.1's revocation reasons are, at a > minimum, "SHOULD revoke within 24 hours", with a subset of reasons being > "MUST revoke within five days", if we want to gather information about > why revocations are delayed, why not make it a requirement of the > Mozilla root program that *any* revocation that takes more than 24 hours > requires reporting, and any revocation beyond the 5 day "MUST" of > 4.9.1.1 be a full-blown, auditor-reportable incident? > > We want information, and a representative of one CA seems to want CAs to > provide that information, and given that a "SHOULD" means "the full > implications must be understood and carefully weighed before choosing a > different course", CAs SHOULD (heh) already have the necessary > information at hand before they make the decision to delay past 24 > hours, thus there should be minimal additional imposition on CAs to > report that information to the WebPKI community. > > > Also, there have been too many instances > > where CAs have failed to include all the necessary information in > > preliminary delayed revocation incident reports. Moving forward, and for > > existing delayed revocation bugs, CAs would need to closely follow the > > updated instructions, which would require specificity when claiming > > exceptional circumstances, significant harm, critical infrastructure, and > > all would be on a per-certificate basis rather than on a per-subscriber > > basis. > > I fully support this, and would furthermore make the guidance > *extremely* specific, something like this: > > For each affected certificate, the customer's description of precisely > why the certificate cannot be replaced within the 24 hour timeframe > advised by the Baseline Requirements, and if there are external factors > involved in that decision, a reference to publicly-available normative > documentation describing those factors in detail. For internal factors > that impact on the inability to revoke, details provided must be > sufficient to allow an independent individual reasonably versed in the > administration of IT systems to fully understand the operational and > organisational failures which led to the inability to revoke in a timely > manner. > > I'm not 100% happy with the "internal factors" part of that description, > as it is still somewhat open to (creative mis)interpretation, but I > think it's a more objective standard than what is currently provided. > > Another thought has just come to mind, regarding the issue that others > have raised around encouraging a "race to the bottom", with lax CAs > gaining business over their more rigorous competitors, and relating to > the proposal put forward by Tim Hollebeek that started this thread: that > if a certificate is not revoked within the mandatory limits set forth in > the BRs, AND that certificate was not previously publicly disclosed as > being "problematic for revocation", then no further certificates may be > issued for any eTLD+1 contained within that certificate which chains to > a trusted root under the control of the same organisation which > controlled the root that the delayed-revocation certificate chained to. > > This is, I agree, a fairly drastic measure, however it is less drastic > than what is, really, the only other stick Mozilla has: total distrust. > It would give CAs a *big* talking point to push back on customers which > demand the CA carry their water, specifically "if we delay revocation, > you'll have to find a new CA to work with to get those new certs, which > is almost certainly going to be more of a pain in the arse for you than > having to scramble internally and do whatever you need to do to replace > those certs with new ones we can give you". It also aligns CA financial > interests with that of the community, because there's no longer any > reason to play fast-and-loose with the BRs to keep the customer, because > playing fast-and-loose *guarantees* you'll lose at least some revenue, > because you can't issue that customer certificates any more (for the > problematic domains, at least). > > This is also a control whose violation *can* be externally detected (via > CT logs), and even programmatically enforced if necessary, and thus it > is more effective than purely administrative-level controls. > > - Matt > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6acb5841-5f9e-4fc7-998c-6be6525ecb81%40mtasv.net > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAOG%3DJU%2B4MOUBbUJ-hGE%3DmcE8XAeehbY0iKPfqqcV%2BukG2XjGqw%40mail.gmail.com.
