Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
Improvements suggested by Jakob
The page gives guidance to CAs as to how Mozilla expects them to react to reported incidents such as misissuances, and what the best practices are. For the purposes of this page, a "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. Researchers who report CA incidents such as misissuances are welcome to include a link to this page in their report to the CA, reminding the CA that Mozilla has the following expectations. This document is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained therein.
For the purposes of this page, a "misissuance" is defined as any certificate issued in contravention of any applicable standard, process or document - so it could be RFC non-compliant, BR non-compliant, issued contrary to the CA's CP/CPS, or have some other flaw or problem. Researchers who report CA incidents such as misissuances are welcome to include a link to this page in their report to the CA, reminding the CA that Mozilla has the following expectations. This document is framed in terms of misissuance of certificates; it will need to be adapted as necessary for incidents of a different nature, respecting the spirit of the information requests contained therein. Other examples of incidents include misconfigured OCSP responders, un-revocations, and any other event affecting trust in the WebPKI which does not involve the actual contents of certificates. While some forms of misissuance incident may be seen as less serious than others, opinions vary on which these are. Mozilla sees all misissuances incidents as good opportunities for the CA to test that their incident response processes are working well, and so we expect a similar level of timeliness of response and quality of reporting for all incidents, whatever their adjudged severity.
To be clear on the status of this document: this is a best practices document, not an official policy, and does not use normative language. Therefore, failure to follow one or more of the recommendations here is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response.
* Work out how the bug or problem was introduced. For a code bug, were the code review processes sufficient? Does your code have automated tests, and if so, why did they not catch this case?
* Work out why the problem was not detected earlier. Were these certificates missed by your self-audits? Or is the code or process you use for such audits insufficiently frequent or rigorous?
* If the problem is lack of compliance to an RFC, Baseline Requirement or Mozilla Policy requirement: were you aware of this requirement? If not, why not? If so, was an attempt made to meet it? If not, why not? If so, why was that attempt flawed? Do any processes need updating for making sure your CA complies with the latest version of the various requirements placed upon it?
The incident report should cover at least the following topics:
# How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug, or internal self-audit), and the time and date.
# A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
# Whether your CA has stopped, or has not yet stopped, issuing TLS/SSL certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
# A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
# 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.
