136
edits
CA/Responding To An Incident: Difference between revisions
CA/Responding To An Incident (view source)
Revision as of 22:53, 12 February 2019
, 12 February 2019Update revocation best practices
(Added paragraph to explain that purpose of incident report is not to point fingers, but to help improve the web.) |
(Update revocation best practices) |
||
| Line 13: | Line 13: | ||
In misussuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI until you have diagnosed the source of the problem, or explain why this has not been done. | In misussuance cases, a CA should almost always immediately cease issuance from the affected part of your PKI 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 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 re-occurring. You should not restart issuance until you are confident that the problem will not re-occur. | 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. | ||
= Revocation = | = Revocation = | ||
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. | 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.6.3): | ||
<blockquote> | <blockquote> | ||
“The CA | “The CA SHOULD revoke a Certificate within 24 hours and MUST revoke a Certificate with 5 days if one or more of the following occurs: …<br> | ||
7. 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> | |||
8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; …<br> | |||
10. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or<br> | |||
11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence that the specific method used to generate the Private Key was flawed. | |||
</blockquote> | </blockquote> | ||
This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within | This means that, in most cases of misissuance, the CA has an obligation under the BRs to revoke the certificates concerned within 5 days. | ||
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. | |||
If your CA will not be revoking the certificates within | 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 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. | |||
= Follow-Up Actions = | = Follow-Up Actions = | ||
| Line 47: | Line 53: | ||
* 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] to harden your issuance pipeline against further problems. | * 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] 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 was not taken within 24 hours, investigate what happened to that report and whether your report handling processes are adequate. | * 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. | ||
= Incident Report = | = Incident Report = | ||
| Line 57: | Line 63: | ||
The incident report may well repeat things which have been said previously in discussions or bug comments. This is entirely expected. The report should be a summary of previous findings. The existence of data in discussions or bug comments does not excuse a CA from the task of compiling a proper incident report. | The incident report may well repeat things which have been said previously in discussions or bug comments. This is entirely expected. The report should be a summary of previous findings. The existence of data in discussions or bug comments does not excuse a CA from the task of compiling a proper incident report. | ||
Your CA may submit an incident report by creating a bug in Bugzilla under the NSS:CA Certificate Compliance component, or by posting the report to the mozilla.dev.security.policy mailing list. If an incident report is sent to the list without a corresponding bug, a new one will be created to track the incident. | |||
The incident report should cover at least the following topics: | The incident report should cover at least the following topics: | ||
| Line 70: | Line 78: | ||
= Keeping Us Informed = | = Keeping Us Informed = | ||
Once the report is posted, you should provide updates at least every week giving your progress, and confirm when the remediation steps have been completed - unless Mozilla representatives agree a different | 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 schedule by 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. The bug will be closed when remediation is completed. | ||
= Examples of Good Practice = | = Examples of Good Practice = | ||