Mike, While the existence of the delayed revocation protocol might make delayed revocation seem more acceptable, I think that it currently serves a useful purpose (or could, if complied with in good faith) in helping other CAs identify scenarios that they should prepare for themselves, and can shine light on cases where the CA is misaligned with the purpose and requirements of the Mozilla root program. Imagine how much harder people would have to fight to get useful information about a failure to revoke on time, if there wasn’t that set of Mozilla expectations to start from…
I'm not sure I fully agree. I absolutely agree most delayed revocation reports are not up to how I interpret Mozilla's current expectations, and certainly fully see the merits with respect to it being useful in shining a light on which CAs are not aligned with the purpose and spirit of being a webPKI CA before it gets to the point of malicious misissuance (as we have seen in spades in a recent example). Yet I think the large number of delayed revocation events that explicitly cite the Mozilla policy first and foremost for why there is a delay is evidence that this policy is having a detrimental effect on the webPKI. If this language did not exist, the pressure on CA's is to "not delay revocation at all, or, if we do, risk being distrusted [or have our certificate lifetimes capped]." And if they decide that it truly is an exceptional case, then to avoid that distrust action (or lifetime capping or whatever) they are strongly incentivized to provide as much detail as possible for why these specific certificates were not revoked on time. Instead of having a policy, that due to the wide definition of "critical infrastructure" is taken as carte blanche permission to delay, which clearly seems to be the opinion of some CAs. Put another way: as you so eloquently described above, ultimately it is up to each subscriber -- not the CA -- to weigh the risks and benefits of how they are acquiring and deploying certificates, and to act accordingly. That only works if the subscriber is exposed to the actual "risks" associated with webPKI certificates, which in turn comes from CAs, as custodians of public trust, actually enforcing the rules. The current Mozilla delayed revocation policy, based on the evidence in the many delayed revocation reports, is providing way too much leeway to CAs who are, in turn, not applying appropriate back pressure on subscribers to assess risks and plan accordingly. If the objective is to make sure other CAs and the community is learning as much as possible from events when they happen, it might instead be worth incorporating language that incident reports [of any variety] must include per-certificate and per-subscriber breakdowns of root causes / effects. This would be beneficial not just in revocation cases, but in others as well. -- 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/e15fd673-9273-49fe-9fd0-6afa9d250c96n%40mozilla.org.
