Hi Ben, First, thanks for this proposal. It is excellent leadership on the part of Mozilla and yourself to address the underlying cause of chronic delayed revocation: incentives that are mismatched with the goals and needs of the Web PKI. I think it represents tremendous progress towards a healthier and more secure Web PKI, which is to say one for which relying parties can be more confident that certificates they encounter are properly issued and trustworthy. Backtesting this against the last year’s incidents paint the future you describe in a much more pleasant colour than the recent past we endured as a community.
Some more specific comments: On Thu, Sep 19, 2024 at 5:53 PM 'Ben Wilson' via [email protected] <[email protected]> wrote: > We’re skeptical about proposals to pre-identify domains that will require > delayed revocation. > Agree. > 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. > One notable issue we’ve seen in the past is differing understanding of what constitutes “substantial harm” or “critical infrastructure”. I recognize that it will require a fair bit of deliberation and debate to settle on one even for the scope of Mozilla’s root program, let alone the broader CA/BF community, but I think it is important to nail that down more crisply and to avoid skew between CAs. > 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; > > I think we need a template or similar to show what the necessary information is, and to reinforce the criteria for “critical infrastructure” or similar. I volunteer to draft one in October, drawing hopefully on the wisdom of this community, if that would be helpful. > 1. 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); > > We should expect that there will be push-back on this via security or other such angles, but I agree that it’s important. “Not possible” isn’t really appropriate here, IMO, since it’s very rarely physically prohibited given sufficient investment and assumption of risk. Goes back to the “substantial harm” definition, sort of. > 1. 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; > > Extremely good. > 1. > > 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); > > What might the consequence be if this were found to not be honoured? One challenge of the current policy around delayed revocation is that there isn’t a clear “or else”. > 1. That each granted request be published for the community (and > Mozilla) to scrutinize (allowing CAs to redact PII prior to > publication); > and > > Should this be limited to granted requests, or others that the CA might themselves have declined? I think the additional visibility would help CAs and others refine their communication with subscribers in order to improve alignment on the criteria. It might also disincentivize subscribers from trying “just in case it works” and creating additional work for CAs and others evaluating these requests in good faith. > 1. > > 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). > > I like the idea of the centralized list, but I’m concerned that it puts CCADB infrastructure in the critical path of certificate issuance. That’s a big operational responsibility and a type of centralized dependency that AFAIK doesn’t currently exist in the ecosystem. Could we find a way to piggyback on CT or similar infrastructure, which is already maintained to the standards required? > 1. We would also look to align these policies across the root programs > in order to provide clarity for the entire community. > > I agree that cross-program alignment would be valuable, but I would hope that it wouldn’t be a prerequisite for Mozilla adopting a policy. Some root programs are more engaged than others in these matters, and letting them delay the implementation of an improvement like this one would be unfortunate. Mike Apologies for this Gmail nonsense: > 1. > > -- 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/CADQzZqu2-_ByLaOFf3fadH_b7AiqGeOe3OKb7ZGZkvLiRrNOAw%40mail.gmail.com.
