[cabfpub] [cabfquest] Comments on BR for code signing certs

[Jeremy Rowley]

Thank you for your comments Peter. They are greatly appreciated.  We’re incorporating several into the next draft as explained below.

From: questions-bounces at cabforum.org<mailto:questions-bounces at cabforum.org> [mailto:questions-bounces at cabforum.org] On Behalf Of Peter Kurrasch
Sent: Thursday, February 26, 2015 9:13 AM
To: questions at cabforum.org<mailto:questions at cabforum.org>
Subject: [cabfquest] Comments on BR for code signing certs

‎I'd like to offer the following comments on the public draft of this requirements document.

1) One of the key benefits of putting together this BR has to be formalizing the separation of keys used for signing code and those used for other purposes, SSL in particular.‎ As such I'd like to see this idea of separation featured more prominently than it currently is. The first mention of it that I noticed was deep in section 10.3.2 item 3 "key reuse". Why not bring this up in section 9.5? Or, better yet, put a bullet list of goals in the Purpose section and include this as one of them?

[JR] The reason for putting it in the subscriber obligation section is because there isn’t a good way for CAs to monitor whether a key is being reused. There isn’t a repository of keys that we can check to see if the subscriber has used the submitted key previously for SSL.

2) ‎In reading the EKU sections in Appendix B, I was disappointed that strong separation of keys was being compromised in the name of what I'll call "special cases". I don't actually know what a special case looks like or how valid I would personally consider it to be, but I'm willing to allow there are cases where the need for a single key to be used for code signing and something else is unavoidable. If that truly is the case, the loophole being granted in these sections is far too broad and should be reconsidered.

I'll offer an alternate approach‎, starting with the assumption that special cases are rare and, therefore, not every CA or cert issuer will be doing it. I'd like to keep it rare, hence the following:

A) As a first layer of defense, place a restriction on which intermediate certs are even allowed to be used in a code signing cert chain and a "other" chain. The restriction is based on those intermediates which have an existing, documented need. Intermediate cert holders will have to provide that documentation to an auditor.

[JR] Thanks.  We are clarifying that an intermediate certificate cannot include the serverAuth EKU.

B) As a best practice, encourage the segregation of code signing and other keys at a root level. Doing so provides the greatest level of protection to the general public.‎ I would expect that most CA's are doing this already, but it doesn't hurt to encourage others to do this too.

[JR] This would require CAs to embed a lot more roots. We require separation at the intermediate level, but not at the root level.

C) At every step where offering the capability for key reuse is being considered, require that the decision making be based on pre-existing, rare cases with documented (and then audited) evidence. I define pre-existing as "a business relationship and documented need that exists prior to the date of this BR publication".

The bottom line is that the need to protect the general public should outweigh a theoretical business need. To put it another way, "key reuse puts the public at risk" must outweigh "I'd like to have the option of offering key reuse as a service in the future".

[JR] I don’t disagree with your assessment, but there isn’t a practical way to enforce this other than through a contractual obligation. Requiring CAs to search their own data records will simply encourage end users to switch CAs, not prevent key resuse.

My preference is still to disallow key reuse in all cases but perhaps ‎these rare, special cases really are unavoidable.

[JR] I don’t disagree.  In fact, we should encourage people to change keys frequently.  However, I’m not sure this is possible yet.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150327/47cc9e1a/attachment-0002.html>