Hi Peter, In general this would be true if issuance of either or both types of end entity certificate were directly from the same Root, however CA's, as best practice and from a product line perspective, segregate the usage of any end entity certificate types through an intermediate CA. In fact this is now mandated by the Baseline Requirements for SSL and forthcoming CodeSIgning requirements. Whilst any intermediate CA may or may not necessarily have EKUs which provide further protection, the additional hierarchical layer and key materials used offer the necessary protection overall.
The other reason is that Root Stores generally place a limit on the number of Roots which can be entered so CA's need to be able to maximize their usage, especially where we are today with ongoing transitions in cryptography standards and key sizes. I hope that helps. Steve > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > [email protected]] On Behalf Of Peter > Kurrasch > Sent: 18 February 2015 14:31 > To: Kathleen Wilson; [email protected] > Subject: Re: TurkTrust Root Renewal Request > > Allowing a single cert to be used for both websites and code signing is a > dangerous proposition. What is the current thinking among the community? > > > Original Message > From: Kathleen Wilson > Sent: Thursday, February 12, 2015 12:31 PM > To: [email protected] > Subject: TurkTrust Root Renewal Request > > TurkTrust has applied to include the SHA-256 "TÜRKTRUST Elektronik Sertifika > Hizmet Sağlayıcısı H5" and "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı > H6" root certificates; turn on the Websites trust bit for both roots, turn on > the Code > Signing trust bit for the H5 root, and enable EV treatment for the H6 root. > TurkTrust's SHA-1 root certificates were included in NSS via Bugzilla Bug > #380635 and Bug #433845. > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
