As suggested by others, I submitted comments to CABF questions email address regarding the code signing cert requirements.
I'm including them below in the event there is any interest in the wider Mozilla community in discussing the issues further in a public forum. Thanks. ====== Submitted Comments ====== 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? 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. 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. 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". My preference is still to disallow key reuse in all cases but perhaps these rare, special cases really are unavoidable. Thank you for your consideration. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
