I have no concerns with the proposal as-written, and would like to thank Mozilla for taking feedback on the prior proposal.
- Wayne On Thursday, September 19, 2024 at 10:53:30 PM UTC+1 Ben Wilson 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/ffcb798f-193e-412b-b0a0-fbf643a23d0en%40mozilla.org.
