The proposals are very interesting. Regarding limiting lifetimes, would you consider allowing per-CA lists instead of a shared list? I think that would have some advantages: - Faster to implement because CAs don't have to wait for CCADB to develop such a shared list. - Faster/easier for CAs to implement because they can use whatever internal format and process that suits them instead of having to build a new integration to CCADB. - CAs could be required to add a FQDN to the list as soon as they decided to delay a revocation instead of allowing them to wait until Mozilla updates CCADB. - If a CA and a subscriber disagrees afterwards about who requested the delay, then that dispute would only impact the CA in question and not other CAs which were not involved. - CAs with never-delay revocation policies might not have to implement such a list. - Incentivises CAs to revoke on time to avoid having their customer on their internal list but not on their competitor's list.
The Chrome root program has previously described an intent to reduce lifetime for all certificates to 90 days in the future. It would be great if Mozilla could do the same and then use this proposal as a first step towards that goal. And similar to what Aaron said, these proposed policies should be scoped to when a CA delays revocation because subscribers requested it or because the CA is worried about the potential impact to its subscribers. This will still cover almost all delayed revocation incidents we have seen lately. If CAs then start to blame themselves instead of subscribers to avoid the new requirements, they would then have to add action items to their incident reports to reflect that. Den tors. 19. sep. 2024 kl. 23.53 skrev 'Ben Wilson' via [email protected] <[email protected]>: > 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/CACAF_Wj%3DAv9am5%2B3hfzKd%2BSGRqUietK28hd_%3DAFDzGx%2B6exEMg%40mail.gmail.com.
