Symantec's report on the incident is here: https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Update.pdf Discussion about this incident was held in the mozilla.dev.security.policy forum. https://groups.google.com/d/msg/mozilla.dev.security.policy/Hkyg_09EDYE/kzQAK3mqAwAJ The resulting action items for Symantec that we need to track are as follows: 1) Finish helping us update OneCRL with the appropriate records https://bugzilla.mozilla.org/show_bug.cgi?id=1214321#c20 2) Provide a set of steps Symantec will take (or has taken) to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. 3) The third-party security audit (may be part of the annual audits) must assess: - The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool. - That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key. - That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS. 4) As of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency and be published in CT.
Maybe I am missing something... The audit is supposed to occur according to policy. The re-audit step already occurred when Trustwave failed. Is there any point in doing it again? What goal will it accomplish? What has changed to warrant yet another re-audit for an audit that's already supposed to be occurring? (For completeness, the last one was well documented: https://bugzilla.mozilla.org/show_bug.cgi?id=724929 and https://blog.mozilla.org/security/2012/02/17/message-to-certificate-authorities-about-subordinate-cas/). Out of morbid curiosity, has Symantec produced any evidence or proof that the audits *actually* occurred in the past? ***** As a matter of policy and procedure, how many times do included CAs get to fail? Is there a set number, or is it kind of a perpetual thing? As a matter of policy and procedure, how is this any different than CNNIC and MSC Holdings? Why are different enforcement actions being taken? Different policies for different CAs is a slippery slope. The existence of different enforcement policies and actions may subject Mozilla to increased legal exposure and increased risk. I've never known it to be wise for a company to increase their legal risk because that's the one that usually hurts the most. ***** The message Mozilla is sending is very bad for users. The system is built upon trust. If the CAs can't be bothered, then users (like me and you) and sites (like Apple, Google and Microsoft) should not have to endure the failures. It also appears Mozilla has lost objectivity, perhaps due to its participation CA/Browser forums. Maybe one of the high level engineering changes needed is a separation of concerns.
Jeffrey, I appreciate your input, but ask that you participate in such discussion in the mozilla.dev.security.policy forum. https://groups.google.com/forum/#!forum/mozilla.dev.security.policy You can review the previous discussions about these things, and ask your questions there. I believe that most of your questions are answered in the following references: https://wiki.mozilla.org/CA:MaintenanceAndEnforcement https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ https://wiki.mozilla.org/CA:IncludedCAs Also, Symantec's previous audit statements are here: https://cert.webtrust.org/SealFile?seal=1565&file=pdf https://cert.webtrust.org/SealFile?seal=1566&file=pdf https://cert.webtrust.org/SealFile?seal=1567&file=pdf
Here's a status update... > 1) Finish helping us update OneCRL with the appropriate records Completed April 29: https://bugzilla.mozilla.org/show_bug.cgi?id=1214321#c28 > 2) Provide a set of steps Symantec will take (or has taken) to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. Completed April 21: http://www.symantec.com/connect/blogs/results-our-investigation_0 https://www.symantec.com/page.jsp?id=test-certs-update https://vs.symantec.com/assets/csv/test-certificate-incident-report-owned-domain-summary_april-2016.csv https://vs.symantec.com/assets/csv/test-certificate-incident-report-unregistered-domain-summary_april-2016.csv You might notice that there were a few recently issued test certs, e.g. https://crt.sh/?id=13871207 Symantec's explanation about those test certs was that the code to check the domain names of the test certs had unfortunately been put in to do the checks *after* the cert had been signed. Symantec's test systems in their production environment have since been updated to do the checks *before* the cert and precert are signed. > 3) The third-party security audit (may be part of the annual audits) must assess: > - The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool. > - That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key. > - That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS. Update: I received email from Symantec on April 21 saying: "Symantec engaged Deloitte Financial Advisory Services LLP to help us identify any additional mis-issued active test certificates and to help us search for any mis-issued active certificates that were issued for purposes other than internal testing." The public results of the report are here: https://www.symantec.com/page.jsp?id=test-certs-update "Deloitte analyzed the approximately 2.18 million digital certificates issued by Symantec that were active as of November 3, 2015. Deloitte used a recommended risk-scoring approach approved by Symantec that was designed to isolate certificates that were at higher risk for being mis-issued, and then manually reviewed documentation provided by Symantec for those certificates. Deloitte subjected the remainder of the active certificates to statistical sampling and manually reviewed the certificate documentation for the sample selection." ... "We have also worked with KPMG during our annual Web Trust audit, where Symantec’s certificate management practices and internal controls are extensively reviewed. In addition, KPMG will soon be conducting a separate Point in Time readiness assessment." > 4) As of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency and be published in CT. Update: https://www.symantec.com/page.jsp?id=test-certs-update "We have also now expanded CT support to our Organization Validated (OV) and Domain Validated (DV) products under each of these brands."
I believe that the action items have been completed.