Ryan beat me to the punch. so I'll reinforce his message with my own: The overall potential impact from revocations in the current scenario feels quite similar to the potential for disruption from revoking certificates containing underscores a few months ago. Mozilla's guidance for revocation [1] was updated based on the "underscores" discussion, and it is generally applicable here. (I will give it another review in light of the current situation.)
In my opinion, Mozilla should not get in to the business of granting one-off exceptions to the BR revocation requirements. In this case, doing so would certainly not be fair to Google, and in the future would only result in constant pleas for mercy that would be near impossible to refuse. Revocation decisions should ultimately be made by CAs and followed up with disclosure and preventative action. Mozilla should highlight situations where delaying revocation will be viewed as an egregious failure by a CA to respond to an imminent threat. I believe that Google's response here sets a good, if imperfect, example of the agility we desire for the entire web PKI. I hope that the current event serves to illustrate the need for agility and encourages CAs to develop more solutions that move us in that direction. - Wayne [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation On Fri, Mar 8, 2019 at 3:40 PM Ryan Sleevi via dev-security-policy < [email protected]> wrote: > On Fri, Mar 8, 2019 at 4:35 PM Jeremy Rowley via dev-security-policy < > [email protected]> wrote: > > > does Mozilla want to require a complete revocation and replacement? Seems > > like a lot of effort and disruption for little value to the Mozilla > > community. > > > I'm surprised, given the length of the discussion in [1], to see such an > unhelpful framing of the issue, as it sounds remarkably like asking for an > "exception". I had hoped that the changes [2] to the policy [3] had > provided greater clarity about what the expectations are for CAs. It does > seem that CAs are following that process, which is something another CA > recently did in the case of underscores, so perhaps its best to not try and > re-open that discussion? :) > > I think a particular piece of guidance and clarification, expected of such > incident reports, and captured in [3], is > "That you will perform an analysis to determine the factors that prevented > timely revocation of the certificates, and include a set of remediation > actions in the final incident report that aim to prevent future revocation > delays." > > It does seem that this is an essential and valuable piece for the > community, regardless of the CA affected and regardless of the nature of > the incident. After all, it doesn't seem to dissimilar to the discussion > regarding Heartbleed, and the challenges the ecosystem faced then. > > [1] > > https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/pnywuWbmBwAJ > [2] > > https://groups.google.com/d/msg/mozilla.dev.security.policy/HdirGOy6TJI/oIHKXeSuCAAJ > [3] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
