> On 18 Feb 2015, at 22:01, Peter Kurrasch <[email protected]> wrote: > > Thanks for the update, Steve. Is there a requirement (current or > forthcoming) for the CA to document how such segregation will be > performed--or that there even is a plan to perform it? I didn't see any such > language in the CP or CPS provided by TurkTrust so I don't know what they > plan to do. >
I don't know of any formal plans by CABForum to stipulate segregation. AFAIK it just happens naturally. Maybe if people feel strongly that can be looked at through enforced EKU usage in intermediates, however that sort of change would take far longer to enact due to the validity of intermediates being approx 10 years and the fact it's another slight against RFC5280. > The risk I have in mind is when a server gets compromised thus exposing the > private keys. If the keys can be used to sign objects I can then turn around > and use them to sign malware and so forth. What could be just a minor breach > then becomes a bigger problem. (I think we should assume that server > compromises are a "regular" occurrence even though we might not know how many > or how often or how serious they are.) > Here we are are all OK, as you are taking about end entities/leaf certificates and they always have the relevant EKU added by the CA so I don't see this as an issue. > I would argue that the best strategy is to have forced separation at the root > level, but I can appreciate that there are limits on the number of roots that > CAs are allowed to submit. > > > Original Message > From: Steve Roylance > Sent: Wednesday, February 18, 2015 9:18 AM > To: Peter Kurrasch > Cc: Kathleen Wilson; [email protected] > Subject: RE: TurkTrust Root Renewal Request > > 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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
