<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Thank you for your comments Peter. They are greatly appreciated. We’re incorporating several into the next draft as explained below.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">
<a href="mailto:questions-bounces@cabforum.org">questions-bounces@cabforum.org</a> [<a href="mailto:questions-bounces@cabforum.org">mailto:questions-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Peter Kurrasch<br>
<b>Sent:</b> Thursday, February 26, 2015 9:13 AM<br>
<b>To:</b> <a href="mailto:questions@cabforum.org">questions@cabforum.org</a><br>
<b>Subject:</b> [cabfquest] Comments on BR for code signing certs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626">I'd like to offer the following comments on the public draft of this requirements document.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626">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?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">[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.
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626">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:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">[JR] Thanks. We are clarifying that an intermediate certificate cannot include the serverAuth EKU.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">[JR] This would require CAs to embed a lot more roots. We require separation at the intermediate level, but not at the root level.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626">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".<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626">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".<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">[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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626">My preference is still to disallow key reuse in all cases but perhaps these rare, special cases really are unavoidable.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">[JR] I don’t disagree. In fact, we should encourage people to change keys frequently. However, I’m not sure this is possible yet.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:#262626"><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>