Apologies, I realize that Mozilla’s policy is that revocation is up to the CA and there is no such thing as an exception. A more careful way to state what I meant is that I’m surprised that there is not more discussion around the revocation of all of these certificates and the impact to the ecosystem compared to an assumption that they will all be revoked. There has been some discussion of course, but 1.8 million certificates is a lot of certificates to replace. I’d think to see more discussion here from GoDaddy about ether they are replacing the certificates or not and the pros and cons of doing so.
From: Wayne Thayer <wtha...@mozilla.com> Sent: Friday, March 8, 2019 3:46 PM To: Ryan Sleevi <r...@sleevi.com> Cc: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Pre-Incident Report - GoDaddy Serial Number Entropy 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 <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: On Fri, Mar 8, 2019 at 4:35 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > 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 dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
