I don't understand why these proposals exist. We have a process for delayed revocation already, it's called Filing An Incident.
On Sat, Sep 28, 2024 at 8:28 AM Mike Shaver <[email protected]> wrote: > 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqu2-_ByLaOFf3fadH_b7AiqGeOe3OKb7ZGZkvLiRrNOAw%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/CACf5n7-Z11gz%2B5C1DNFLjBHtUZ-JTGRas4q46LeQQOxYWEaDQQ%40mail.gmail.com.
