On Tue, Apr 25, 2017 at 12:14 AM, Ryan Sleevi <r...@sleevi.com> wrote:
> Gerv, > > Is there any update on https://wiki.mozilla.org/ > CA:Symantec_Issues#STRUCK:_Issue_Y:_Unaudited_ > Unconstrained_Intermediates_.28December_2015_-_April_2017.29 ? > > I'm just wanting to understand how this relates to Mozilla's PKI policy > and expectations, and better understand why you struck it. > > - The CP/CPS does not state adherence to the Baseline Requirements. > - The audit was only to "WebTrust Principles and Criteria for CAs v2.0" - > e.g. not BRs > - Seemingly excluded from scope of the audits are the following, for > https://crt.sh/?Identity=%25&iCAID=1384&exclude=expired , on the basis of > Footnote 1 in https://www.symantec.com/content/en/us/about/media/ > repository/Symantec-NFSSP-WTCA_11-30-2016.pdf > - https://crt.sh/?id=19602740 > - https://crt.sh/?id=19602709 > - https://crt.sh/?id=19602733 > - https://crt.sh/?id=19602720 > - https://crt.sh/?id=19602670 > - https://crt.sh/?id=19602679 > - https://crt.sh/?id=19602705 > - https://crt.sh/?id=19602730 > > Of critical relevance: > - If you examine the CPS that was audited, https://www.symantec. > com/content/en/us/about/media/repository/nf-ssp-pki-cps.pdf, it notes in > Appendix A.5 that the profile includes issuing certificates with dNSName > and iPAddress SANs, with the anyExtendedKeyUsage (or the presence of more > specific EKUs) > > - If you examine Symantec's statements on this matter in > https://bugzilla.mozilla.org/attachment.cgi?id=8860216 , they stated > "Under the Non-Federal SSP program, they are used to issue certificates for > Microsoft Windows domain controllers and IPSec endpoints." . A Windows > Domain controller requires that it have id-kp-serverAuth, with a dNSName > SAN ( https://support.microsoft.com/en-us/help/291010/ > requirements-for-domain-controller-certificates-from-a-third-party-ca ) > I actually missed something in https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216 "With the wind-down of the SSL/TLS RA program, all authentication and issuance of certificates chaining to Class 3 CAs is done by Symantec; Google and Apple in the case of the GeoRoot sub-CAs; and customers of the Non-Federal SSP program (in this case used to issue certificates for Microsoft Windows domain controllers and IPSec endpoints). " This would imply that customers of the NF SSP program can direct and perform RA duties for the issuance of domain controller certificates, which have the full capability of TLS server certificates, as directed above. This would seem consistent with the audit findings in https://www.symantec.com/content/en/us/about/media/repository/Symantec-NFSSP-WTCA_11-30-2016.pdf which states "Symantec makes use of external registration authorities for specific subscriber registration activities for the Symantec Non-Federal SSP - Customer Specific CAs and Symantec Healthcare CA ... Our examination did not extend to the controls exercised by these external registration authorities." So the audit, the CPS, and Symantec's own statements seem to indicate that external RAs had the capability of issuing domain controller certificates, which would minimally include id-kp-serverAuth, id-kp-clientAuth, and dNSName SANs, from an intermediate that was and is enabled for TLS server authentication at the request of VeriSign ( https://bugzilla.mozilla.org/show_bug.cgi?id=515470 ) and as maintained by Symantec. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
