On November 22, Apple submitted an incident report: https://bugzilla.mozilla.org/show_bug.cgi?id=1598829, which is reposted below.
Incident Report 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. On 13-November-2018 at 16:00 PT, we completed a more in-depth investigation into our key control used to determine if security patches should be applied (automated vulnerability scans) and determined that while it was possible the vulnerability scanner would detect a vulnerability with EJBCA, it was not likely. We also identified that since our review of EJBCA releases and decisions about upgrading was not a key control, it was not provided to the auditors. Based on this information we committed to opening this incident report in Comment 13 of the Apple OCSP responders return responses with incorrect issuer incident report. For clarity, key controls are mapped to WebTrust control objectives, and non-key controls are performed operationally but not provided to the auditors. 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. 14-October-2019 at 15:08 PT - We internally contemplated whether running version 4.0.14 could be a potential Network and Certificate System Security Requirements (NCSSR) violation, but based on our understanding at the time, we determined it was not a violation. 17-October-2019 at 18:33 PT - We posted the Apple OCSP responders return responses with incorrect issuer incident report. 17-October-2019 at 19:20 PT - We received Comment #5 questioning the version of software we were running on our OCSP service. 21-October-2019 at 9:00 PT - As part of our ongoing investigation related to the Apple OCSP responders return responses with incorrect issuer report we took a closer look at our software management practices and the CA/Browser Forum NCSSR which requires that CAs “Apply recommended security patches to Certificate Systems within six (6) months of the security patch’s availability, unless the CA documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch.”. 24-October-2019 at 21:54 PT - As part of Comment 6 of Apple OCSP responders return responses with incorrect issuer, we committed to opening a separate bug with more details. 29-October-2019 from 11:25 - 11:58 PT - Notified the Apple Policy Authority, DigiCert and Sectigo (Root vendors), Apple, Microsoft, Mozilla, Google, and Oracle (Root programs), and Ernst & Young (WebTrust assessors) of a potential incident. 31-October-2019 at 21:36 PT - We posted Comment 10 to the Apple OCSP responders return responses with incorrect issuer incident report in which we stated that our practices and controls for both the OCSP software and CA software were compliant with the NCSSR. 31-October-2019 from 21:38 - 21:40 PT - Notified the Apple Policy Authority, DigiCert and Sectigo (Root vendors), Apple, Microsoft, Mozilla, Google, and Oracle (Root programs), and Ernst & Young (WebTrust assessors). 13-November-2018 at 16:00 PT - We completed a more in-depth investigation into our key control used to determine if security patches should be applied and determined that while it was possible the vulnerability scanner would detect a vulnerability with EJBCA, it was not likely. We also identified that since our review of EJBCA releases and decisions about upgrading was not a key control, it was not provided to the auditors. Therefore, we came to the conclusion that our key control does not go far enough to meet the requirements specified in 1l of the NCSSR. Based on this information, we committed to opening this incident report in Comment 13 with more details. 14-November-2019 from 14:51 - 14:53 PT - Notified the Apple Policy Authority, DigiCert and Sectigo (Root vendors), Apple, Microsoft, Mozilla, Google, and Oracle (Root programs), and Ernst & Young (WebTrust assessors). 14-November-2019 at 16:00 PT - We made our review of software releases and decisions about upgrading a key control. 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. No non-compliant certificates were issued. We made our review of software releases and decisions about upgrading a key control. 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. No non-compliant certificates were issued. 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. No non-compliant certificates were issued. 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. We did not have an accurate understanding of how the vulnerability scanner worked. Our understanding of its capabilities lead us to believe it was scanning and detecting vulnerabilities in EJBCA. We did not identify a need to dig deeper until the Apple OCSP responders return responses with incorrect issuer incident report. In an effort to ensure our conclusion in Comment 10 was correct, we investigated further and determined that while it’s possible the vulnerability scanner would detect a vulnerability with EJBCA, it is not likely. 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. * We no longer rely on the vulnerability scanner as a key control to detect security vulnerabilities with EJBCA. * We made our review of software releases and decisions about upgrading a key control. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
