Changes

The This page discusses incidents, incident reporting, remediation, and communication. It gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are.  An incident arises any time a CA fails to comply with an applicable requirement found in the CA/Browser Forum’s Baseline Requirements or in the Mozilla Root Store Policy. As noted in section 2.4 of the Mozilla Root Store Policy, an incident can arise from certificate misissuance, delayed revocation, procedural or operational issues, or some other cause.

In misussuance misissuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI . In situations not involving misissuance, there also may be processes that need to be stopped until you have diagnosed the source of the problem, or explain why this has not been done.

Once the problem is diagnosed, you may restart issuance the process 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 the process until you are confident that the problem will not re-occur.

It is normal practice for CAs to revoke misissued or otherwise problematic 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.67.30):

“The CA SHOULD revoke a Certificate within 24 hours and MUST revoke a Certificate with within 5 days if one or more of the following occurs: …<br>

This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 5 days(or within 24 hours in some cases).

Mozilla recognizes that in some '''exceptional''' circumstances, revoking misissued the affected 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 the volume of revocations in a short period of time would result in a large cumulative impact to the web. 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.

* 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 do not deem this misissuance not non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis.

* That you 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.

* Examine whether there are potential related problems which you can also remediate at the same time. For example, if the problem was bad data in a particular field, consider improving the validation of all fields in the certificate prior to issuance. You should be proactively looking for [https://crt.sh/linttbscert ways] , such as pre-issuance lint testing, to harden your issuance pipeline against further problems.

* 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.

The purpose of incident reporting is to help all of us work together to build a moresecure web. Therefore, the incident report should share lessons learned that could be helpful to all CAs to build better systems. The incident report should explain how the systems failed, how was the mis-issuance or incident possible, and why the problem was not detected earlier. In addition to the timeline of responding to and resolving the incident, the incident report should explain how the CA's systems will be made more robust, and how other CAs may learn from the incident.

CAs should submit a an additional, separate incident report when:

# Whether your CA has stopped, or has not yet stopped, issuing certificates with certificate issuance or the process giving rise to the problemor incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.# A In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certscertificates, and the date the first and last certs certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.# The In a case involving certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

# List of steps your CA is taking to resolve the situation and ensure that such issuance situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these thingsremediation steps. The purpose of these incident reports is to provide transparency about the steps the CA is taking to address the immediate issue and prevent future issues, both the issue that originally lead to the report, and other potential issues that might share a similar root cause. Additionally, they exist to help the CA community as a whole learn from potential incidents, and adopt and improve practices and controls, to better protect all CAs. Mozilla expects that the incident reports provide sufficient detail about the root cause, and the remediation, that would allow other CAs or members of the public to implement an equivalent solution. For example, it’s not sufficient to say that “human error” of “lack of training” was a root cause for the incident, nor that “training has been improved” as a solution. While a lack of training may have contributed to the issue, it’s also possible that error-prone tools or practices were required, and making those tools less reliant on training is the correct solution. When training or a process is improved, the CA is expected to provide specific details about the original and corrected material, and specifically detail the changes that were made, and how they tie to the issue. Training alone should not be seen as a sufficient mitigation, and focus should be made on removing error-prone manual steps from the system entirely.