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/6b183f07-0cd9-49e2-bf6b-e930e8d22e81%40mtasv.net.
