Ben, I like these proposals. I think they will do a good job of preventing the kinds of delayed revocation incidents we have seen lately.
However, there is one other kind of delayed revocation incident we've seen in the past that I think these policies don't address: https://bugzilla.mozilla.org/show_bug.cgi?id=1715455. That incident three years ago affected 185 million certificates; if a similar incident were to happen today it would affect over 400 million. While I completely agree that the impact on any individual website would be negligible, and that delayed revocation should not happen at the behest of site operators, I do worry about the impact on end-users when certificates are revoked at such a large scale. In particular, I worry about accidentally training people to believe that clicking through their browser's SSL warnings is OK. Thankfully technologies like ARI are improving things here: it's deployed by several CAs, implemented in several clients, and is ready for Working Group Last Call at the IETF. But ARI hasn't yet become ubiquitous enough to significantly mitigate the aggregate effect of revoking 400M certificates with (in the worst case) less than 24 hours of warning. So if possible I'd like there to be some thinking about this other mass-revocation case. Thanks, Aaron On Thu, Sep 19, 2024 at 2:53 PM 'Ben Wilson' via [email protected] <[email protected]> wrote: > Hi folks, > > We have discussed delayed revocation a bit internally and wanted to come > back to the community with some thoughts. > > We agree that expanding beyond the existing revocation timelines (24 hours > / 5 days) is undesirable. While we think some exceptional delayed > revocations are necessary as a current practicality, we do want to > eventually sunset this policy. To that end, we’d like to refine our > existing policy so that it is more effective and equitable during the > interim. > > We’re skeptical about proposals to pre-identify domains that will require > delayed revocation. We expect that many sites might ask for such > exceptions, and an extensive amount of deliberation would be required in > order to process these requests. Worse, in practice, doubtless some sites > impacted in a revocation event would not have followed the procedure, and > CAs would still be left with a last-minute decision about whether a > revocation will inflict substantial harm. > > Instead, we would like to seek the community's feedback on the following > two proposals: > > 1. > > Clarification of existing requirements > We would be more explicit about what would be required for delayed > revocation. Some ideas include: > 1. > > Explicitly clarifying that CAs must revoke certificates by default, > that any delayed revocation must be the result of an explicit request by > the subscriber, containing the necessary information, and meeting the > requirements under such interim policy; > 2. > > That subscriber requests contain a clear claim or explanation about > the critical nature of the system and why timely revocation is not > possible > (more detailed requirements to be discussed); > 3. > > That the requests are signed by a company officer, or similar legal > representative, stating that the information in the request is accurate > to > the best of their knowledge; > 4. > > That the information contained in the subscriber’s request be > accurate to the CA’s understanding (e.g. not materially contradicted by > other facts known to the CA); > 5. > > That each granted request be published for the community (and > Mozilla) to scrutinize (allowing CAs to redact PII prior to > publication); > and > 6. > > That CAs be required to produce summary statistics in their reports > (alongside the individual granted requests) detailing how many requests > were received, how many were well-formed, how many were granted, etc. > > 2. > > Consequences of Delayed Revocation > We believe that if a domain hosts critical infrastructure that cannot > tolerate timely revocation, then it is deeply damaging to the web PKI. In > order to help these domains transition to effective certificate management > practices and automated tooling, we propose that domains that are granted > delayed revocation must then be limited to shorter-lifetime certificates as > a consequence of such decision. This also ensures that future revocations > impacting such domains have much less impact. > > Concretely, the domains accepted for delayed revocation by a CA are > already public. If this proposal were to be adopted, root programs would > manage a shared list of such domains (e.g. via the CCADB) and require CAs > to limit the lifetimes of certificates issued to these domains (e.g. to 90 > days). > > We stress that both of these proposals are presented for early feedback, > and we look forward to the community’s thoughts on whether they are likely > to be suitable and effective, and how they might be improved. We would also > look to align these policies across the root programs in order to provide > clarity for the entire community. > > Thanks and best wishes, > > Ben > > -- > 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/CA%2B1gtaYZWhgfs23hB-Z%3DgEQCybugPrP8W4MSdnX9Y-dyoMoarA%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYZWhgfs23hB-Z%3DgEQCybugPrP8W4MSdnX9Y-dyoMoarA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEmnEreVrVU6%3D%3DdMBksFRT1YcOWWH-X7G9fR6JUpO_ekq%2BAUqQ%40mail.gmail.com.
