> I think that this process in its current form has not served to minimize or eliminate delayed revocation.
Unlike literally every other rule, one root program had an explicit exception for just this rule. And unsurprisingly, the exception was leveraged a lot. > Do you feel that the frequency and magnitude of delayed revocation over the last year, across many CAs, should be acceptable to root programs and the community? Delayed revocation incidents should be exceptional, not routine. There is a solution to "there is a pattern of incidents" available to root programs already. I do not understand why, given a pattern of incidents, the solution Mozilla is proposing is "add an exception", not either trust actions, or actually changing the rule. Either strike the rule, or don't. We have a process for making mistakes and exceptional circumstances already, it's called Filing An Incident. It is expected that incidents themselves are routine, and evaluated by root programs holistically and with discretion. There should be no expectation that an single delayed revocation would result in immediate trust actions. > Do you feel that the proposals are harmful in some way? Yes. Any proposal to add an exception to the rules, rather than actually changing the rules, is harmful to the ecosystem, and in particular, harmful to any root program that expects the rules and incident process to be followed. The recent Digicert delayed revocation incident would have been much easier to handle if there had been no expectation of an "exception", especially given that Digicert sought an exception from multiple root programs _that did not have exception processes_. Ironically, I am not even sure Digicert considered Mozilla important enough to ask. Mozilla's existing process is harmful, and doing anything other than getting rid of it exacerbates the problem. On Sat, Sep 28, 2024 at 2:59 PM Mike Shaver <[email protected]> wrote: > I think that this process in its current form has not served to minimize > or eliminate delayed revocation. The requirement to file an incident, and > the kinds of remediation that have historically been promised or provided > in the context of those incidents, have not materially improved the > trustworthiness of certificates on the web, and in my opinion something has > to. I think that the view that the process for delaying revocation is > simply to “file an incident”, and that it is merely an administrative > burden rather than a signal that material change must occur between CA and > subscriber, is a major contributor to the issues we have had over the past > year(s). > > Do you feel that the frequency and magnitude of delayed revocation over > the last year, across many CAs, should be acceptable to root programs and > the community? Do you feel that the proposals are harmful in some way? > > Mike > > On Sat, Sep 28, 2024 at 2:46 PM David Adrian <[email protected]> wrote: > >> 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/CACf5n78rokc9_NjkQbfhkyp%3DvfNPAU8i2O-e2wa2kUNgu%2BLMoQ%40mail.gmail.com.
