Steve, Unless Peter is a member of the forum, the public list is a black hole, as only members can post. The alternative, the questions list, is not publicly readable, so is also a bad choice for open discussion.
Therefore, while this thread is not the appropriate place, this forum is probably the best place. Thanks, Peter On Feb 25, 2015 7:04 AM, "Steve Roylance" <[email protected]> wrote: > Hi Peter. > > To better answer the issues you've raised, I'd suggest sending this topic > to the public list in the CABforum. I'm not in the codesiging working > group so I'm unable to help directly with answers to your points. I've > not forwarded this mail as I'd rather that come directly from you. Details > here:- https://cabforum.org/mailman/listinfo/public > > Not dodging the bullet, just highlighting a better target ;-) > > Steve > > > > -----Original Message----- > > From: Peter Kurrasch [mailto:[email protected]] > > Sent: 25 February 2015 21:52 > > To: Steve Roylance > > Cc: Kathleen Wilson; [email protected] > > Subject: Re: TurkTrust Root Renewal Request > > > > 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:[email protected]] > > > Sent: 19 February 2015 13:49 > > > To: Steve Roylance > > > Cc: Kathleen Wilson; [email protected] > > > 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; [email protected] > > > Subject: Re: TurkTrust Root Renewal Request > > > > > > > > > > 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 > > > >> bounces+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 > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
