<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Kelvin. </div><div><br></div><div>We tried this but unfortunately the ballot failed to gain support (ballot 100) so we had to take the advice given and try again.</div><div><br></div><div>If you are saying that you wanted to allow more time for non Name constrained CAs then I'm confused as to why there was no feedback to Ballot 100?</div><div><br></div><div>Am I missing something?</div><div><br>Sent from my iPhone</div><div><br>On 19 Jul 2013, at 02:32, Kelvin Yiu <<a href="mailto:kelviny@exchange.microsoft.com">kelviny@exchange.microsoft.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<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;}
@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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
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.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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle32
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle33
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle34
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle35
{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]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">[I am filling in for Tom while he is enjoying some well-deserved time off.]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">It is unfortunate that ballot 105 combined the OCSP issue with the clarification of audit requirements for subCAs. If one of the goals of ballot 105 is to provide some “breathing space” to the August deadline
on the OCSP issue, then it must address the OCSP problem for all CAs, not just those who are able to take advantage of name constraints.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I think it is great that the CAB Forum is driving the use of name constraints to reduce the burden for many customers who manages a stable set of domains and reduce the risks for the entire PKI eco-system. It
is even more important for the CAB Forum to produce guidelines that can be fairly applied to all CAs, even when there is an arbitrary self-imposed deadline looming over us. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Kelvin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="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>
<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 2:39 PM<br>
<b>To:</b> Stephen Davidson<br>
<b>Cc:</b> Rick Andrews; <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>
<p class="MsoNormal">Hi Tom. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I agree with Stephen that we need to let 105 run its course and amend the wording now, as a number of enterprise CAs will immediately fail to deliver on the BR requirements (fully) come August 1st, yet they've been willing to limit their
domain exposure through name constraints. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm fully behind additional language tweaks above and beyond this ballot to help, and as you recall I was an advocate of reaching out to CA platform and OCSP providers, 18 months ago as all these companies have a vested interest to be
members of the CABForum.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Lets get this Ballot implemented and then discuss at length what makes sense for the industry at large. There are so many moving parts with CRLs, OSCP stapling etc that we need to consider all but we need to consider in a timely fashion
and the ballot was written to allow us some breathing space...... as August is here now.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
Sent from my iPhone<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On 18 Jul 2013, at 22:01, Stephen Davidson <<a href="mailto:S.Davidson@quovadisglobal.com">S.Davidson@quovadisglobal.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I agree that section 13.2.6 is a problem and am happy to focus attention on that. The top CAs can readily adapt their own inhouse software – but this section
created a significant cost and obstacle for CAs that use commercial software, and we may find in Q4 there are a lot of SSL small players that don’t meet the requirement.</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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">However, the intent of this ballot is to clarify the Mozilla options for technical constraints in the context of the BR, and to fill in some of the gaps on
how to use them. The link in with OCSP is a simply rattle-on from that, and I would hope not to derail the overall ballot.</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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The fact is that today all Enterprise CAs that are root signed must comply with 13.2.6. With this ballot, if they are audited, they will still need to comply
with 13.2.6. If they are constrained, they will not. </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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I understand that the same conditions would also apply with Certificate Transparency …</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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","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>Rick Andrews<br>
<b>Sent:</b> Thursday, July 18, 2013 3:53 PM<br>
<b>To:</b> Tom Albertson; <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.</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<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.</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>
<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.</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>
<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.</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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Rick</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 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">
<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>Tom Albertson<br>
<b>Sent:</b> Thursday, July 18, 2013 11:24 AM<br>
<b>To:</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.</span><o:p></o:p></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><o:p></o:p></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.
</span><o:p></o:p></p>
<p class="Default" style="margin-left:.5in"><span style="font-family:"Calibri","sans-serif""> </span><o:p></o:p></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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt"> </span><o:p></o:p></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><o:p></o:p></p>
<p class="MsoNormal"><span style="color:windowtext"> </span><o:p></o:p></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. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:windowtext"> </span><o:p></o:p></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. </span><o:p></o:p></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"> </span><o:p></o:p></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. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:windowtext"> </span><o:p></o:p></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. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:windowtext"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:windowtext">All the best, </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:windowtext"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:windowtext">Tom</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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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.</span><o:p></o:p></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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif""> </span><o:p></o:p></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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif""> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif"">Steve</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif""> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif""> </span><o:p></o:p></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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial","sans-serif""> </span><o:p></o:p></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">
<tbody>
<tr>
<td style="background:white;padding:.75pt .75pt .75pt .75pt">
<table class="MsoNormalTable" border="0" cellpadding="0">
<tbody>
<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>
</tbody>
</table>
</td>
</tr>
</tbody>
</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> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="color:windowtext">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div></blockquote></body></html>