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

"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
 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

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

dev-security-policy mailing list

Reply via email to