I think broadly this is a good decision. As Matt mentioned, I really *really* hope there are no CAs that think they shouldn't revoke by default, given the events of the past few months.
I'd go a step further than that proposal however and suggest that *each and every* delayed revocation request requires a separate action to be made. For example, if I had: - acme.example.com - example.com - *.example.com as three separate certificates that I needed delayed revocation on, I as the officer of Acme would need to submit three separate signed requests as Ben mentioned on the critical nature of the system etc. The goal here is to avoid a process where a company just goes "critical services, don't revoke" on a certificate set that is hundreds or thousands of certs. There's a potentially separate conversation to be had about subscribers not understanding the meaning of "CA can revoke within 24/120h" in the subscription agreement they're all agreeing to (at least I hope), but that's somewhat out of scope for this discussion. Maybe a bit of a stretch goal here (especially since this would generally run counter to the incentives of the average CA [in that profit is more or less the priority by virtue of them being a for profit business) is that not only do any of these limited domains only allow a 90 day certificate, but a CA can only issue them using ACME or other fully automated protocols for x amount of time. Since this also has downstream impact in terms of EV/DV certs, this is a much harder sell, but as a counter point on why this may not be necessary if the 90 day max lifespan is implemented, a 90 day long certificate is rotating frequently enough that just from pure hassle alone it may make sense to switch to automating the certificates, whether or not enforcing ACME or similar is a mandated part of that list. On Thursday, September 19, 2024 at 5:44:15 PM UTC-7 Matt Palmer wrote: > On Thu, Sep 19, 2024 at 03:53:16PM -0600, 'Ben Wilson' via > [email protected] wrote: > > 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; > > If there are any CAs that currently think that they *shouldn't* revoke > certificates by default, I would be very deeply concerned. > > > 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 > > Requiring publication of the detailed reasons for delayed revocation as > part of a delayed revocation report would be a great benefit to the > WebPKI, I believe. > > > 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. > > This, too, would be valuable information to improve the visibility and > resilience of the WebPKI. > > > 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. > > I believe this would be an admirable improvement, because as you say, a > shorter lifetime for such certificates reduces the period of time in > which a known-flawed certificate could be misused, if revocation were > significantly delayed for some reason. > > Taking this thought to its logical conclusion, if a certificate is so > important that revocation is too dangerous to execute within the > strictures of the WebPKI, it should be moved to a seven-day lifetime, > which as I understand it means that the CA is no longer required to > revoke. > > > 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). > > By "domain", are you referring to FQDN (ie sAN values) or the associated > eTLD+1? I would expect it to be FQDN, based on my understanding of the > intent, but it's worth clarifying, IMO, to ensure everyone's on the same > page. > > - 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/7325aa62-c3b0-41b0-962d-5d44e0847c9an%40mozilla.org.
