I'll save you the trouble on #4. Jeremy Rowley and I chair the Code Signing working group. The Baseline Requirements are out for public comment and the comment period closes on March 6th. Once we finalize the document from the comments it will be put to a vote and hopefully ratified by the forum. CAs will have a year to comply (March 2016).
If you have technical comments, please send them to the questions list. Thanks Dean > On Feb 25, 2015, at 11:10 AM, Steve Roylance <[email protected]> > wrote: > > 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- >> [email protected]] On Behalf Of Peter >> Bowen >> Sent: 26 February 2015 00:00 >> To: Steve Roylance >> Cc: [email protected]; [email protected]; 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" <[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 >>>>>>> bounces+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 >> _______________________________________________ >> 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
