1)How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
We became aware of the problem during an internal review of the configuration change from last week at Monday December 11 2 .30 p.m. UTC. 2) 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. •2017/12/04 2 p.m. UTC: Test Setup with wrong configuration has been set up. •2017/12/06 12.10 p.m. UTC – 2017/12/08 3.40 p.m. UTC: 10 Certificates were issued using the wrong configuration. The configuration should have been using an internal not public trusted CA. •2017/12/11 2.30 p.m. UTC: Wrong setup was detected during the internal setup review process. •2017/12/11 3.00 p.m. UTC: The affected configuration has been suspended. •2017/12/11 3.30 p.m. UTC: Affected Certificates were immediately revoked after a short internal review. •2017/12/11 3.00 p.m. UTC: The affected configuration has been corrected. •2017/12/12 10:00 p.m. UTC: Incident report was submitted to Mozilla 3) Whether your CA has stopped, or has not yet stopped, issuing 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. The affected configuration has been corrected. Since then, no such certificates have been issued. 4) 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 subject information in the affected certificates were not validated correctly due to the misconfiguration. 10 certificates were issued based on this misconfiguration between 2017/12/06 12.10 p.m. UTC and 2017/12/08 3.40 p.m. UTC. 5) 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. https://crt.sh/?id=273776520 https://crt.sh/?id=273776617 https://crt.sh/?id=272950014 https://crt.sh/?id=272950007 https://crt.sh/?id=272950012 https://crt.sh/?id=272950010 https://crt.sh/?id=272166103 https://crt.sh/?id=272166102 https://crt.sh/?id=272166107 https://crt.sh/?id=272166110 6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. The employee wanted to set up a test set up for a partner and have made a mistake in choosing the wrong template for the issuing CA (productive EV CA instead of a untrusted internally used test CA). 7)List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. The implemented controls detected the misconfiguration within 24 hours. The incorrect configuration was nevertheless recorded as a security incident. The handling of the security incident by the information security management team is still underway. Further measures will be decided within this process. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
