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.
