Confirm, administrator
5,526
edits
Changes
Updated due to MDSP migration
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 [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&version=other creating a bug in Bugzilla under the NSS:CA Certificate Compliance component], or by posting the report to the [https://groups.google.com/a/mozilla.org/g/dev.-security.-policy MDSP 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:
# How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in the [https://groups.google.com/a/mozilla.org/g/dev.-security.-policyMDSP mailing list], 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, certificate issuance or the process giving rise to the problem or 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.
