Changes

Jump to: navigation, search

CA/Symantec Issues

767 bytes added, 08:44, 31 March 2017
And yet more
==Issue D: Test Certificate Misissuance (April 2009 - September 2015)==
Between 2009 and 2015, Symantec issued a large number of test certificates in their publicly trusted hierarchies. These contained domains that Symantec did not own or control, and for which domain validation was not performed. Some of these domains were unregistered, and others were owned by other organizations. Issuing test certificates for unregistered domains was not a BR violation before April 2014, but Symantec continued the practice after it had been forbidden. The registered domains used included those belonging to Google and Opera Software. Given the numbers involved, this sort of test certificate issuance appears to have been common practice at Symantec. Some of the test certificates (including one for www.google.com) left Symantec's network because they were logged in CT; Symantec claims no others did. However, Symantec personnel would have had access to the public and private keys of the certs.
Some details of this incident are recorded in {{bug|1214321}}.
# Failure to review application and system logs
The nost most recent available WebTrust for CAs audits for Symantec's [https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTCA-2015.pdf Verisign and own-brand roots], their [https://www.symantec.com/content/en/us/about/media/repository/Thawte-WTCA-2015.pdf Thawte roots] and their [https://www.symantec.com/content/en/us/about/media/repository/GeoTrust-WTCA-2015.pdf GeoTrust roots] run from December 1st, 2014 to November 30th, 2015. In those audits, the management assertions (and thereby the auditors) call out the following violations:
# Background checks not renewed for trusted personnel
===Further Comments and Conclusion===
Mozilla did not object to these qualifications in Symantec's audits at the time the audit documentation was submitted to us. Because of this, it is not reasonable for us to take action based on the mere existence of these qualifications. They are listed here because they are one part of the general picture of Symantec's compliance or otherwise with the BRs. An audit with any qualifications at all is not particularly common among CAs.
==Issue H: SHA-1 Issuance After Deadline (January 2016)==
The US Government has an extremely complicated PKI called the Federal PKI. It has [https://bugzilla.mozilla.org/show_bug.cgi?id=478418 applied for inclusion] in the Mozilla root store but that application seemed unlikely ever to be successful due to the difficulty of bringing the entire FPKI in line with Mozilla's policies. At the time of this incident, it had a number of non-audited subordinate CAs.
Presumably in November or December of 2015, Symantec [https://groupscrt.google.comsh/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/PGhVbV-UBQAJ ?id=12638543 cross-signed] one of the root CAs in the FPKI ("Federal Bridge CA 2013"), thereby making certificates below that root in the chain of trust be publicly trusted, and technically making Symantec responsible to Mozilla for all certificates issued in the covered part of the FPKI, including any BR violations. The [https://crt.sh/?id=12638543 intermediate CA certificate concerned] was not disclosed in the CCADB, as Mozilla practice at the time required. This was [https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0wSUJKnH5MY/PGhVbV-UBQAJ reported in m.d.s.policy]. Symantec is not the only CA to have done this; IdenTrust [https://crt.sh/?id=9114292 also did it]. Their cross-sign's notBefore is in January 2015 and they revoked it on 17th February 2016, two years before it was due to expire.
===Symantec Response===
The Baseline Requirements, in section 4.9.1.1 item 9, state that the CA SHALL revoke a certificate if "The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Poliy or Certification Practice Statement". However, Symantec did not revoke all the certificates.
Instead, Symantec decided to shut down the RA program entirely and re-assess every certificate issued under it. Symantec committed to revalidating all of the CrossCert-issued certificates (10,000+) and any of the 20,000+ certificates issued by their other RAs if deficient validation was discovered. However, the determination of deficient validation was made based on the RAs own logs of activity, which may themselves be suspect given some of the audit deficiencies found at these RAs. Furthermore, this revalidation process, which presumably is continuing beyond the end of March deadline Mozilla has set for using only the ten defined domain methods in version 1.4.1 of the Baseline Requirements, is not one of those ten.
===Further Comments and Conclusion===
[https://cert.webtrust.org/SealFile?seal=2168&file=pdf CrossCert's audit] does not list or cover the full number of Symantec roots under which they had issuance capability. Symantec's investigation discovered that CrossCert had the scope of the audit reduced for cost reasons.
[https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929 Certisign's audit] and [https://cert.webtrust.org/SealFile?seal=2067&file=pdf Certisur's audit] are only WebTrust for CAs audits - neither CA appears to have a Baseline Requirements audit. The WebTrust audit criteria require that such a CA has a BR audit. In addition, Mozilla policy requires "CA operations and issuance of certificates to be used for SSL-enabled servers" to conform to the Baseline Requirements. As Symantec has stated that audit was their only mechanism for monitoring their RAs, they can have had no assurance that RAs without a BR audit were actually following the BRs.
===Symantec Response===
==Issue X: Incomplete RA Program Remediation (February - March 2017)==
At the time Symantec shut down their RA program, they had four RAs - CrossCert, Certisign, Certsuperior, and Certisur. Symantec committed to revalidating all certificates issued by those RAs. Independent of the rightness or otherwise of this course of action, it should have been applied consistently. However, the program seems to have previously had additional RAs, and Symantec has as yet taken no action to revalidate the certificates that they issued, despite some still being valid.  Those RAs include at least E-Sign (, for which we have found audits from [https://cert.webtrust.org/SealFile?seal=1873&file=pdf at least March 1st - June 2014] to , [https://cert.webtrust.org/SealFile?seal=1931&file=pdf at least April - July 31st 2015]) and may include others[https://cert.webtrust.org/SealFile?seal=2180&file=pdf July - September 2016]. This party does not appear to have an unbroken series of audits; it is unclear what that means. Another possible RA is MSC TrustGate, which appears to have been operating as a sub-CA based on the scope of [https://cert.webtrust.org/SealFile?seal=2127&file=pdf their audit]. However this audit, like those for some other Symantec RAs, is only to the WebTrust for CAs criteria and does not cover the Baseline Requirements. The WebTrust audit criteria require that such a CA has a BR audit.
===Symantec Response===
Symantec has not yet been officially requested to respond to this issue.
Accountapprovers, antispam, confirm, emeritus
4,925
edits

Navigation menu