As I mentioned last week [1], the "serial number entropy" issue has identified some improvements that could be made to Mozilla's guidance for CAs on revocation when responding to an incident. These are relatively minor clarifications and in no way do they represent a fundamental change in our guidance. I have updated a portion of the Revocation section on the wiki page [2] as follows:
> Mozilla recognizes that in some exceptional circumstances, revoking > misissued certificates within the prescribed deadline may cause significant > harm, such as when the certificate is used in critical infrastructure and > cannot be safely replaced prior to the revocation deadline, or when a > defect affects a massive number of Subscribers and certificates. However, > Mozilla does not grant exceptions to the BR revocation requirements. It is > our position that your CA is ultimately responsible for deciding if the > harm caused by following the requirements of BR section 4.9.1 outweighs the > risks that are passed on to individuals who rely on the web PKI by choosing > not to meet this requirement. > > If your CA will not be revoking the certificates within the time period > required by the BRs, our expectations are that: > > - The decision and rationale for delaying revocation will be disclosed > to Mozilla in the form of a preliminary incident report immediately; > preferably before the BR mandated revocation deadline. The rationale must > include an explanation for why the situation is exceptional. Responses > similar to “we deem this misissuance not to be a security risk” are > generally not acceptable, and must be discussed on the > mozilla.dev.security.policy list. When revocation is delayed at the request > of specific Subscribers, the rationale should be provided on a > per-Subscriber basis. > - Any decision to not comply with the timeline specified in the > Baseline Requirements must also be accompanied by a clear timeline > describing if and when the problematic certificates will be revoked and > supported by the rationale to delay revocation. > - The issue will need to be listed as a finding in your CA’s next BR > audit statement. > - Your CA will work with your auditor (and supervisory body, as > appropriate) and the Root Store(s) that your CA participates in to ensure > your analysis of the risk and plan of remediation is acceptable. > - 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. > > If your CA will not be revoking the problematic certificates as required > by the BRs, then we recommend that you also contact the other root programs > that your CA participates in to acknowledge this non-compliance and discuss > what expectations their Root Programs have with respect to these > certificates. > I will once again appreciate everyone's constructive feedback on these changes. - Wayne [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/HNDX5LaZCAAJ [2] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation On Tue, Feb 12, 2019 at 4:42 PM Wayne Thayer <wtha...@mozilla.com> wrote: > Mozilla's guidance for incident response lives at > https://wiki.mozilla.org/CA/Responding_To_An_Incident > > I just made some significant changes to the Revocation section that > reflect the approach we took with the recent underscore sunset. > > Most notably, the following paragraph: > > However, it is not our intent to introduce additional problems by forcing >> the immediate revocation of certificates that are not BR-compliant when >> they do not pose an urgent security concern. Therefore, we request that >> your CA perform careful analysis of the situation. If there is >> justification to not revoke the problematic certificates, then your report >> will need to explain those reasons and provide a timeline for when the bulk >> of the certificates will expire or be revoked/replaced. >> > > Has been replaced with: > > Mozilla recognizes that in some exceptional circumstances, revoking >> misissued certificates within the prescribed deadline may cause significant >> harm, such as when the certificate is used in critical infrastructure and >> cannot be safely replaced prior to the revocation deadline. However, >> Mozilla does not grant exceptions to the BR revocation requirements. It is >> our position that your CA is ultimately responsible for deciding if the >> harm caused by following the requirements of BR section 4.9.1.1 outweighs >> the risks created by choosing not to meet this requirement. >> > > Additions have also been made to our expectations when a CA doesn't revoke > on time, along with a number of minor updates. > > You can view a comparison of all the changes at > https://wiki.mozilla.org/index.php?title=CA%2FResponding_To_An_Incident&type=revision&diff=1207675&oldid=1185707 > > I will greatly appreciate everyone's feedback on these changes. > > - Wayne > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
