Thanks for putting that together, Steve. Reading through the doc it appears that some of my concerns are addressed but I do have a few questions yet:
1) I saw that tucked away in section 10.3.2 item #3 is "key reuse" but all it says is "you have to promise not to do it". Is there any solid enforcement for this, above and beyond the "we found out about it" clause in section 13.1.5 item #4 or #6? 2) Is there a particular reason to not mention the prohibition on key reuse in section 9.5? 3) All of the EKU sections in Appendix B have a loophole for companies that have some sort of platform specific need to include other CA values, but I don't know what those use cases look like. From my standpoint it's more secure for everyone to have hard and fast rules for rigorous enforcement of security policies. As written, such rigor goes out the window. Do you know of any good examples why the loophole is necessary? Bringing this discussion back to TurkTrust's request: 4) When might CABF approve the requirements and when might cert issuers be expected to comply? 5) What is reasonable to ask of TurkTrust to spell out in CP/CPS documents in conjunction with this current request? I think it's reasonable to ask for them to just say what policies they plan to enforce. If they have no plans to impose limits on EKU's then just say it--give me a chance as an end user to make an informed decision when I come across certs chained to their root. -------- Original Message -------- From: Steve Roylance Sent: Saturday, February 21, 2015 2:59 PM Hi Peter. I double checked, and everything looks good for the future (Please see the attached proposed Code Signing Requirements which has been publically released by the CABForum) Specifically see Appendix B section F which covers MUST requirements for CAs and as such alleviates your concerns in that 'Server Auth' is not allowed to coexist with code signing so it's not necessary to segregate by Root CA as it's going to be mandatory to segregate by issuing CA.. F. extkeyUsage (EKU) The id-kp-codeSigning [RFC5280] value MUST be present. The following EKUs MAY be present: documentSigning and emailProtection. The value anyExtendedKeyUsage (2.5.29.37.0) MUST NOT be present. Other values SHOULD NOT be present. If any other value is present, the CA MUST have a business agreement with a Platform vendor requiring that EKU in order to issue a Platform-specific code signing certificate with that EKU. This extension SHOULD be marked non-critical. The CA MUST set all other fields and extensions in accordance to RFC 5280. Steve > -----Original Message----- > From: Peter Kurrasch [mailto:fhw...@gmail.com] > Sent: 19 February 2015 13:49 > To: Steve Roylance > Cc: Kathleen Wilson; mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: TurkTrust Root Renewal Request > > My preference is to have key separation explicitly addressed by Mozilla and > CABForum. From strictly a security perspective sharing keys is an all risk, no > reward proposition. The only advantage I can see is in terms of convenience > in > different ways. > > I offer the following options for consideration: > > Bare minimum: for any root cert which intends to be used for both SSL and > code, > the CA shall provide a statement in the CP/CPS regarding any plans they have > to > limit end/leaf certs from having both EKU's. If it's just a policy thing or > if an > intermediate will provide a technical enforcement mechanism, just write it > down. > If there is no plan/policy, just state that too. > > Minimum: enact a policy to disallow both EKU's from being used in a single > end- > entity cert. > > Better: separate intermediates are utilized for SSL and code. > > Ideal: separate roots for both SSL and code. > > The reason I favor something more than just policy statements are because > people can make mistakes and should that happen it would be good to have the > technical backstop. > > > Kathleen--Would you feel comfortable asking TurkTrust to provide a statement > clarifying their plans or intentions regarding these EKU's? > > Original Message > From: Steve Roylance > Sent: Wednesday, February 18, 2015 4:36 PM > To: Peter Kurrasch > Cc: Kathleen Wilson; mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: TurkTrust Root Renewal Request > > > > On 18 Feb 2015, at 22:01, Peter Kurrasch <fhw...@gmail.com> 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; mozilla-dev-security-pol...@lists.mozilla.org > > 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- > >> bounces+steve.roylance=globalsign....@lists.mozilla.org] On Behalf Of > >> bounces+Peter > >> Kurrasch > >> Sent: 18 February 2015 14:31 > >> To: Kathleen Wilson; mozilla-dev-security-pol...@lists.mozilla.org > >> 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: mozilla-dev-security-pol...@lists.mozilla.org > >> 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 > >> dev-security-policy@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
