[cabfpub] TurkTrust Root Renewal Request

Ben Wilson ben.wilson at digicert.com
Wed Feb 25 16:25:52 UTC 2015 

One practice that the CA/B Forum should consider is to forward select comments on proposed guidelines from the questions list over to the public list, but because of the IPR Policy concerns that it creates, the practice should include mitigations for third parties (not bound to the IPR Policy) injecting protected IP into the Forum's workstream. However, because I think the risk of that is small, I think it should be allowed as long as CABF members police themselves.

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert.com at lists.mozilla.org] On Behalf Of Steve Roylance
Sent: Wednesday, February 25, 2015 9:10 AM
To: Peter Bowen
Cc: fhw843 at gmail.com; mozilla-dev-security-policy at lists.mozilla.org; Kathleen Wilson
Subject: RE: TurkTrust Root Renewal Request

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.com at lists.mozilla.org] On Behalf Of 
> bounces+Peter
> Bowen
> Sent: 26 February 2015 00:00
> To: Steve Roylance
> Cc: fhw843 at gmail.com; mozilla-dev-security-policy at 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.roylance at 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:fhw843 at gmail.com]
> > > Sent: 25 February 2015 21:52
> > > To: Steve Roylance
> > > Cc: Kathleen Wilson; mozilla-dev-security-policy at 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:fhw843 at gmail.com]
> > > > Sent: 19 February 2015 13:49
> > > > To: Steve Roylance
> > > > Cc: Kathleen Wilson; 
> > > > mozilla-dev-security-policy at 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-policy at lists.mozilla.org
> > > > Subject: Re: TurkTrust Root Renewal Request
> > > >
> > > >
> > > > > On 18 Feb 2015, at 22:01, Peter Kurrasch <fhw843 at 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-policy at 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.com at lists.mozilla.org] On 
> > > > >> bounces+Behalf Of Peter
> > > > >> Kurrasch
> > > > >> Sent: 18 February 2015 14:31
> > > > >> To: Kathleen Wilson;
> > > > >> mozilla-dev-security-policy at 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-policy at 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 at lists.mozilla.org
> > > > >> https://lists.mozilla.org/listinfo/dev-security-policy
> >
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-security-policy at lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> >
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150225/8a8894ff/attachment.p7s>

More information about the Public mailing list