CA/Symantec Issues: Difference between revisions

CA/Symantec Issues (view source)

Revision as of 13:29, 25 April 2017

769 bytes added , 25 April 2017

Unstrike and update Issue Y

Gerv

Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti

4,925

edits

@@ Line 370: / Line 370: @@
 In the absence of evidence that these organizations have the ability to issue SSL/TLS certificates, we must accept Symantec's assertion.
-==STRUCK: <strike>Issue Y: Unaudited Unconstrained Intermediates (December 2015 - April 2017)</strike>==
+==Issue Y: Unaudited Unconstrained Intermediates (December 2015 - April 2017)==
-Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority, appear not to be covered by any of Symantec's audits as listed in their document repository:
+Two intermediate CAs, which are subordinates of or cross-certified by VeriSign Universal Root Certification Authority, have audit and control problems:
 * [https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired VeriSign Class 3 SSP Intermediate CA - G2]
 * [https://crt.sh/?Identity=%25&iCAID=12352&exclude=expired Symantec Class 3 SSP Intermediate CA - G3]
-Both intermediates are disclosed in Salesforce, and both have 15 or so also-disclosed sub-CAs which seem to be specific to particular companies. The audit associated with both of them in Salesforce is [https://www.symantec.com/content/en/us/about/media/repository/symantec_nfssp_wtca_5_13_2016.pdf this one] from May 2016, but that audit document does not list the intermediate CAs that it covers. It's from Symantec's 2015 set of audits (i.e. the set before the current one). The most recent audit which covers the VeriSign Universal Root Certification Authority is [https://www.symantec.com/content/en/us/about/media/repository/18_Symantec_STN_WTCA_period_end_11-30-2016.pdf this one], but these certificates are not on the accompanying list of intermediates. There seems to be no 2016 version of the "Symantec Non-Federal Shared Service Provider WTCA" audit in the list for 2016 in the Symantec [https://www.symantec.com/about/legal/repository.jsp?tab=Tab3 document repository].
+Both intermediates are disclosed in Salesforce, and both have 15 or so also-disclosed sub-CAs which seem to be specific to particular companies. The audit associated with both of them in Salesforce is [https://www.symantec.com/content/en/us/about/media/repository/symantec_nfssp_wtca_5_13_2016.pdf this one] from May 2016, i.e. from Symantec's 2015 set of audits (i.e. the set before the current one), but that audit document does not list the intermediate CAs that it covers. Symantec has produced a [https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf more recent audit] but not yet updated Salesforce. This one does list the intermediate CAs covered. However, like that from the previous year, this is a WebTrust for CAs audit, and does not include a BR audit.
-As far as we can tell, these intermediates are unconstrained, unrevoked and fully capable of issuing server authentication certificates which are trusted by Mozilla browsers. They appear to be related to the US Federal Bridge PKI (see Issue L).
+These intermediates appear to be related to the US Federal Bridge PKI (see Issue L) As far as we can tell, they are unconstrained, unrevoked and fully capable of issuing server authentication certificates which are trusted by Mozilla browsers. Mozilla policy is based on capability, not intent - if a sub-CA is capable of issuing SSL certs we trust, it must be appropriately constrained or audited. These intermediates have deficient audits and, as far as we can tell, sub-CAs of them are effectively controlled by entities without any audits at all. Specifically:
+* The CP/CPS does not state adherence to the Baseline Requirements.
+* The audit is only a WebTrust for CAs audit, not a BR audit.
+* A number of sub-CAs seem excluded from even the scope of that audit, as they are not listed in it: [https://crt.sh/?id=19602740 1], [https://crt.sh/?id=19602709 2], [https://crt.sh/?id=19602733 3], [https://crt.sh/?id=19602720 4], [https://crt.sh/?id=19602670 5], [https://crt.sh/?id=19602679 6], [https://crt.sh/?id=19602705 7], [https://crt.sh/?id=19602730 8].
+* The CP/CPS has a profile which includes issuing certificates with dNSName and iPAddress SANs, and Symantec states that Windows domain controller certs are within scope for the program. Such certs are fully TLS server certificates.
+* [https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 A Symantec statement] suggests that customers of their NF SSP program can perform RA duties for the issuance of certs for Windows domain controllers and, according to the audit report, those RA activities are outside the scope of the audit entirely.
 ===Symantec Response===
-Symantec say that these intermediates "are covered under Symantec’s Non-Fed SSP audits, and the latest unqualified audits that we just received are being published." And indeed such an audit [https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf has now appeared], albeit significantly late.
+Symantec has not yet responded to the updated allegations here.
 ===Further Comments and Conclusions===
-These intermediates do appear to be covered by audits, albeit tardily-submitted ones. They are constrained by policy OID, although such constrains are not recognised by the Web PKI, and so they remain capable of issuing SSL certs trusted by Mozilla and need to continue to be under appropriate control and audit.
+All evidence still points to it being the case that these intermediates are unconstrained, unrevoked and fully capable of issuing server authentication certificates which are trusted by Mozilla browsers, yet they have deficient or missing audits.