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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
