Changes

Once the problem is diagnosed, you may restart issuance even if a full fix is not rolled out, if you are able to put in place temporary or manual procedures to prevent the problem from re-occurring. You should not restart issuance until you are confident that the problem will not re-occur.

It is normal practice for CAs to revoke misissued certificates. But that leaves the question about '''when''' this should be done, particularly if it's not possible to contact the customer immediately, or if they are unable to replace their certificate quickly. Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements currently states (version 1.46.93):

“The CA SHALL SHOULD revoke a Certificate within 24 hours and MUST revoke a Certificate with 5 days if one or more of the following occurs: …<br>97. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;<br>108. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate or misleading; …<br>1410. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or<br>1511. The technical content CA is made aware of a demonstrated or format of proven method that exposes the Certificate presents an unacceptable risk Subscriber's Private Key to Application Software Suppliers or Relying Parties compromise, methods have been developed that can easily calculate it based on the Public Key (esuch as a Debian weak key, see http://wiki.gdebian. the CAorg/Browser Forum might determine that a deprecated cryptographic/signature algorithm SSLkeys), or key size presents an unacceptable risk and if there is clear evidence that such Certificates should be revoked and replaced by CAs within a given period of time)the specific method used to generate the Private Key was flawed.

This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 24 hours5 days.

HoweverMozilla recognizes that in some exceptional circumstances, revoking misissued certificates within the prescribed deadline may cause significant harm, it such as when the certificate is not our intent used in critical infrastructure and cannot be safely replaced prior to introduce additional problems by forcing the immediate revocation of certificates that are deadline. However, Mozilla does not grant exceptions to the BR-compliant when they do not pose an urgent security concernrevocation requirements. Therefore, we request It is our position that your CA perform careful analysis of the situation. If there is justification to not revoke ultimately responsible for deciding if the problematic certificates, then your report will need to explain those reasons and provide a timeline for when harm caused by following the bulk requirements of BR section 4.9.1.1 outweighs the certificates will expire or be revoked/replacedrisks created by choosing not to meet this requirement.

If your CA will not be revoking the certificates within 24 hours in accordance with the time period required by the BRs, then our expectations are that will need to be listed as a finding in your CA’s BR audit statement.:

We expect 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 not acceptable. This 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 for 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 report or attestation 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.

* If, as happens in a regrettably large number of cases, a problem report was sent to your CA but action in accordance with BR section 9.4.5 was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate.

Once the report is posted, you should respond promptly to questions that are asked, and in no circumstances should a question linger without a response for more than one week, even if the response is only to acknowledge the question and provide a later date when an answer will be delivered. You should also provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless Mozilla representatives agree to a different update schedule with youby setting a “Next Update” date in the “Whiteboard” field of the bug. Such updates should be posted to the m.d.s.p. thread, if there is one, and the Bugzilla bug, if there is one. The bug will be closed when remediation is completed.