Thanks Peter. Yes my bad..
https://cabforum.org/current-work/code-signing-working-group/ has the questions e-mail at the bottom of the page. Steve > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve.roylance=globalsign....@lists.mozilla.org] On Behalf Of Peter > Bowen > Sent: 26 February 2015 00:00 > To: Steve Roylance > Cc: fhw...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Kathleen > Wilson > Subject: RE: TurkTrust Root Renewal Request > > 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" <steve.royla...@globalsign.com> > 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:fhw...@gmail.com] > > > Sent: 25 February 2015 21:52 > > > To: Steve Roylance > > > Cc: Kathleen Wilson; mozilla-dev-security-pol...@lists.mozilla.org > > > 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: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 > > > > >> bounces+Behalf Of 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 > > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
