<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:x="urn:schemas-microsoft-com:office:excel" 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=us-ascii"><meta name=Generator content="Microsoft Word 12 (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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 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";
color:black;}
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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
p.line867, li.line867, div.line867
{mso-style-name:line867;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.line874, li.line874, div.line874
{mso-style-name:line874;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.line891, li.line891, div.line891
{mso-style-name:line891;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.line862, li.line862, div.line862
{mso-style-name:line862;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.Default, li.Default, div.Default
{mso-style-name:Default;
mso-style-priority:99;
margin:0in;
margin-bottom:.0001pt;
text-autospace:none;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.anchor
{mso-style-name:anchor;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle29
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle30
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle31
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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";color:#1F497D'>I tend to agree with Tom that the complexity and risk might outweigh the potential benefit. And I’m not saying that because I want the status quo – Symantec has moved all its certs to our OCSP system that returns “unknown” for unknown cert serial numbers.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The intent of this ballot is to allow relying parties to detect a certificate created by an attacker which has a valid signature by virtue of hash collisions (the attacker creates a fake cert that hashes to the same value as a legitimate cert, and simply copies the good signature to the fake cert). From what I know of hash collision attacks, the attacker has some freedom in choosing the serial number of the fake cert. It should be possible, and maybe even easy, to use the serial number of a legitimate certificate and therefore avoid detection from the OCSP responder.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So I feel that OCSP responders should return “unknown” for unknown serial numbers, but we should recognize that this ballot is a very weak deterrent to attackers.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Rick<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><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";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Tom Albertson<br><b>Sent:</b> Thursday, July 18, 2013 11:24 AM<br><b>To:</b> public@cabforum.org<br><b>Subject:</b> Re: [cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I wanted to comment on the question of industry support for Section 13.2.6, which this ballot builds upon. We may want to consider amending it now instead of proceeding further with the language in 13.2.6, as this ballot does. In fact ballot 105 compounds our earlier error in dictating product design details to OCSP responder vendors without thinking very heavily<span style='color:#1F497D'> </span><span style='color:windowtext'>about the impact</span>. It’s our collective mistake – let’s not make it worse. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The section 13.2.6 amendment proposed by Ballot 105 reads as follows:<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=Default style='margin-left:.5in'><b><span style='font-family:"Calibri","sans-serif"'>13.2.6 Response for non-issued certificates </span></b><span style='font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=Default style='margin-left:.5in'><span style='font-family:"Calibri","sans-serif"'>If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. The CA SHOULD monitor the responder for such requests as part of its security response procedures. <o:p></o:p></span></p><p class=Default style='margin-left:.5in'><span style='font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri","sans-serif"'>Effective 1 August 2013, OCSP responders </span><u><span style='font-family:"Calibri","sans-serif";color:red'>for</span></u><span style='font-family:"Calibri","sans-serif";color:red'> </span><s><span style='font-family:"Calibri","sans-serif"'>MUST NOT</span></s><span style='font-family:"Calibri","sans-serif"'> </span><u><span style='font-family:"Calibri","sans-serif";color:red'>CAs which are not Technically Constrained in line with Section 9.7 MUST NOT</span></u><span style='font-family:"Calibri","sans-serif";color:red'> </span><span style='font-family:"Calibri","sans-serif"'>respond with a "good" status for such certificates.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt'><o:p> </o:p></span></p><p class=MsoNormal>The current version of Section 13.2.6 requires OCSP responders to not respond with <span style='color:windowtext'>a Good status for non-issued certificates. OCSP responder that couldn’t comply had to be modified by the 1 August 2013 deadline. The amendment in this ballot 105 provides a limitation on the earlier restriction: it says OCSP responders for CAs which are not Technically Constrained must not respond with a Good status for non-issued certificates. Let’s untwist the double negative to ensure we understand the meaning: OCSP responders with Technical Constraints applied are exempt from the requirement in Section 13.2.6. OCSP responders without Technical Constraints still must not respond with a Good status for non-issued certificates. </span><span style='font-size:11.0pt;color:windowtext'><o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>The Microsoft OCSP responder is part of Windows Server, commercial software targeting enterprises, not commercial CAs. It is deployed by and large by enterprises worldwide. To date, only a very few enterprises have embraced or adopted Technical Constraints. Many enterprises deploy a large number and variety of domains that rapidly scales beyond effective control via the Technical Constraints approach. <o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>When asked to modify the OCSP responder in Windows Server to conform to Section 13.2.6, the response was that the request adds very little value to enterprise scenarios, and added certain risks to enterprise PKI deployment. OCSP responders are generally kept outside the corporate network, and due to this requirement the OCSP responder would need to access the Certificate Server database. This means exposing the Certificate Server box outside the company’s network. We might curb this, put up firewalls etc. to reduce the risks, but still the requirement creates complexity and risk. If the Certificate Server key gets compromised, the attacker can issue certificates with serial numbers that already exist in the Certificate server database, and show as Good. And if the Certificate Server box is compromised, the attacker can issue the certificates they want to issue, and have them come out as “Good”. An attacker can engineer their way around any protection to enforce this OCSP Good requirement. <o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The current Section 13.2.6 didn’t close a very big hole in our view, and it could open another one for enterprise customers. The new language introduced in ballot 105 would have us add an advisory to our customers that they can comply with Section 13.2.6 if only they Technically Constrain their enterprise PKI. Which few enterprises have done.<o:p></o:p></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>As a group CAB Forum member CAs implement proprietary OCSP responders that they can amend at will, and by deadline. That is not the case in the commercial software world, or for many enterprise customers. We should reconsider adding new language that has such a broad impact on customers and enterprises. We didn’t anticipate very well the impact on OCSP responder vendors, and assertions that this language can have a positive effect on enterprise security should be examined. It seems to me that this language in section 13.2.6 will throw more fire on deployment of enterprise PKIs subordinated to publicly trusted CAs without doing anything to address underlying issues and conflicts. We think the majority of enterprises are more secure with a design methodology that doesn’t implement the OCSP Good proposal as currently specified. <o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Perhaps we should consider an exemption from this Section 13.2.6 requirement for enterprise CAs. Or delete the last sentence entirely. <o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>All the best, <o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Tom<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'> <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Steve Roylance<br><b>Sent:</b> Thursday, July 18, 2013 12:40 AM<br><b>To:</b> <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a><br><b>Cc:</b> <a href="mailto:public@cabforum.org">public@cabforum.org</a><br><b>Subject:</b> Re: [cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif"'>Hi Kirk.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif"'>I did update the Wiki Ballot text correctly but failed to update the example PDF. Attached is the new one.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif"'>Steve<o:p></o:p></span></p></div><div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div></div></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","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:11.0pt;font-family:"Calibri","sans-serif"'>From: </span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>"<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>><br><b>Date: </b>Wednesday, 17 July 2013 18:20<br><b>To: </b>"<a href="mailto:public@cabforum.org">public@cabforum.org</a>" <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br><b>Subject: </b>Re: [cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div><div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'>In reading Ballot 105, our technical team has a question about Section 9.7, particularly this paragraph</span><o:p></o:p></p><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'> </span><o:p></o:p></p><p class=Default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'>If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage<u>, then the Subordinate CA MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName</u> as follows:- </span><o:p></o:p></p><p class=Default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'> </span><o:p></o:p></p><p class=Default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'>(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of section 11.1 </span><o:p></o:p></p><p class=Default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'> </span><o:p></o:p></p><p class=Default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'>(b) For each iPAddress range in permittedSubtrees, the CA MUST confirm that the Applicant has been assigned the iPAddress range or has been authorized by the assigner to act on the assignee's behalf. </span><o:p></o:p></p><p class=Default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'> </span><o:p></o:p></p><p class=Default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'>(c) For each DirectoryName in permittedSubtrees the CA MUST confirm the Applicants and/or Subsidiary’s Organizational name and location such that end entity certificates issued from the subordinate CA will be in compliancy with section 9.2.4 and 9.2.5. </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'>The wording “then the Subordinate CA MUST include the Name Constraints X.509v3 extension” is not clear as to whether the constraints are applied to the sub CA certificate or to an EE certificate the sub CA is going to issue. Should it read “then the Subordinate CA *<b><i><u>certificate</u></i></b>* MUST include the Name Constraints X.509v3 extension ***” for clarity? Is that the intention?</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div></div><table class=MsoNormalTable border=0 cellpadding=0><tr><td style='background:white;padding:.75pt .75pt .75pt .75pt'><table class=MsoNormalTable border=0 cellpadding=0><tr><td style='padding:.75pt .75pt .75pt .75pt'><pre>TREND MICRO EMAIL NOTICE<o:p></o:p></pre><pre>The information contained in this email and any attachments is confidential<o:p></o:p></pre><pre>and may be subject to copyright or other intellectual property protection.<o:p></o:p></pre><pre>If you are not the intended recipient, you are not authorized to use or<o:p></o:p></pre><pre>disclose this information, and we request that you notify us by reply mail or<o:p></o:p></pre><pre>telephone and delete the original message from your mail system.<o:p></o:p></pre></td></tr></table></td></tr></table><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif"'>_______________________________________________ Public mailing list <a href="mailto:Public@cabforum.org">Public@cabforum.org</a> <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a> <o:p></o:p></span></p></div></div></body></html>