Changes

This page lists all confirmed or suspected issues involving the CA "Symantec". It may be further updated by Mozilla as more information becomes available, although the deadline for comments from Symantec has now passed. Please do not edit this page yourself; if you have proposed changes, email [mailto:gerv@mozilla.org Gerv]. Information here is correct to the best of Mozilla's knowledge and belief. Symantec has also [https://bug1334377.bmoattachments.org/attachment.cgi?id=8867735 confirmed] the accuracy of the information, although errors transcribing their statements into this page remain Mozilla's.

==Issue L: Cross-Signing the US Federal Bridge (February 2011 2009 - July 2016)==

Since February 20112009, Symantec has regularly had a valid cross-sign for one or both of "[https://crt.sh/?caid=1324 Federal Bridge CA]" and "[https://crt.sh/?caid=1410 Federal Bridge CA 2013]", which are both part of the FPKI, thereby making (as far as I can tell) all certificates in the FPKI be publicly trusted, and technically making Symantec responsible to Mozilla for all certificates issued in the FPKI, including any BR violations. The intermediate CA certificate(s) concerned were 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].

There are three possibilities hereSymantec [https:  * Symantec didn't realise //bug1334377.bmoattachments.org/attachment.cgi?id=8867735 state] that what they did had the effect were aware of making the entirety of the FPKI trusted in Mozilla browsers; or* Symantec knew issues with this cross-signing since 2014 and were investigating whether it was actually required. It would seem it took two years to figure that they had taken actions to make the entirety of the FPKI trusted in out, and at no time was Mozilla browsers and didn't realise informed about the implications; or* fact that Symantec knew that they had taken actions to make the entirety of was enabling public trust for the FPKI trusted in Mozilla browsers and did realise the implications, but didn't see fit to tell usentire Federal PKI.

None of these possibilities reflects well on Symantec. Symantec should While technical controls within the FPKI may have known that certificate policy extensions are not sufficient protection for the WebPKI (which doesn't use or recognise them). prevented it, Symantec should realise the full implications of any cross-signing they do. And Symantec should have revealed to Mozilla that they had made it possible for a massive hierarchy no way of non-BR- and non-Mozilla-policy-compliant knowing or controlling whether the FPKI was issuing EV certificates to be trusted in our browserusing Symantec's OID.

* Test certs to un-registered domains: Discovered and fixed in October 2015, but there was a "discovery of additional instance involving approved domains in a test account resulting in 6 additional issued certificates in Approximately Mar 2016." (Mozilla isn't aware that Symantec has previously made disclosure of this mis-issuance.)

The time for further discussion has passed, but it remains unclear how the Management Assertions for the 2014-2015 It is noteworthy that even if third party audits can contain information about problems [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 apparently only discovered] in January or February 2016 ("Failure to maintain physical security records for 7 years"are qualified, "Failure to review application and system logs" and "failure that does not lead to refresh background checks every 5 years") during the audit process. Is a CA allowed to rewrite its management assertions during the qualification on Symantec's main audit process so as to include as "known" any problems found? Would this make the difference between failing and passing an audit? It is also not clear whether the disclosure in the cover letters excuse the absence of qualifications related to GeoRoot and the RA program in these audits.

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 (in cases other than CrossCert) 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.

Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority(which is EV-enabled), have audit and control problems:

Symantec has say that the subCAs under these intermediates are under Symantec's control and, in all cases but one, are technically prevented from issuing for TLS server authentication. In one case, a customer does have the ability to issue TLS server auth certificates. The subCAs concerned ("CSC Device CA – G2" and "CSRA FBCA C3 Device CA"), like all the others, do not yet responded have BR audits. They say that their technical controls, which apply to all these subCAs, prevent EV issuance. Nevertheless, they plan to privatise this bit of the PKI by revoking trust in the certificates which link it to the updated allegations hereWebPKI on May 24th, 2017.

All evidence still points to it being Symantec say that these hierarchies were not BR audited based on the system controls they have in place and the intended usage. But Mozilla policy is based on capability, not intent. And in one case that these intermediates are unconstrained, unrevoked both capability and fully capable intent led to the issuance of issuing TLS server authentication certificates which are trusted by Mozilla browserscerts, and yet they have deficient or missing auditsno audit was obtained.