<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>It seems clear to me that the Applicant doesn't receive a request token from the CA, but the CA specifies a derivation method, and both Applicant and CA independently use the same method on the same public key to derive the same Request Token. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">But the definition of Request Token says the method is irreversible, so it must be a cryptographic hash. Kirk has pointed out several places where the language isn't so clear. A careful reader should be able to understand what needs to be done, but I think we would be better served by making the language more explicit. Remember, many people working with this document are not native English speakers. <br><br>-Rick</div><div><br>On Nov 12, 2015, at 8:07 PM, "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>> wrote:<br><br></div><blockquote type="cite"><div>

<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin-top:0in;
        margin-right:0in;
        margin-bottom:8.0pt;
        margin-left:0in;
        line-height:106%;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
p.Default, li.Default, div.Default
        {mso-style-name:Default;
        margin:0in;
        margin-bottom:.0001pt;
        text-autospace:none;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;
        color:black;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@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" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<b>Question 1 – Domain Validation pre-ballot<o:p></o:p></b></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
On the CA-Browser Forum teleconference today, we discussed the five remaining open questions for the pending Domain Validation method pre-ballot (current draft is attached).  I will summarize the open question and discussion in five emails.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<u>We invite further discussion on this list</u> so the Validation Working Group can make progress on its call next Thursday, November 19 – others are welcome to join the call.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<b><u>Question 1 - Richard Barnes Comments<span style="color:#002060"><o:p></o:p></span></u></b></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<u><o:p><span style="text-decoration:none"> </span></o:p></u></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
Richard Barnes of Mozilla suggested we make the following change to new validation method No. 9:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="Default" style="margin-left:.5in"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Proposal 1: In
<u>line L</u> of draft<o:p></o:p></span></b></p>
<p class="Default" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="Default" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">CURRENT DRAFT:
<o:p></o:p></span></p>
<p class="Default" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="Default" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">"9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the
 FQDN which is accessed and then validated via https by the CA over an Authorized Port.”<o:p></o:p></span></p>
<p class="Default" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="Default"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Richard proposes to add: "*** or installing a Test Certificate containing a Random Value or Request Token" as shown:<o:p></o:p></span></p>
<p class="Default" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="Default" style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the
 FQDN </span><b><u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:red">or installing a Test Certificate containing a Random Value or Request Token</span></u></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> which is
 accessed and then validated via https by the CA over an Authorized Port. <o:p></o:p></span></p>
<p class="Default" style="margin-left:1.5in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="Default"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Richard’s reasoning: “This liberalization would cover the DVSNI proposal being considered in ACME, and seems to offer equivalent protection to the other option. (Either way the
 cert contains something specified by the CA.)“<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
Richard’s added language does not specifically say who issues the Test Certificate – the CA or the Applicant – but it implies the Applicant generates the Test Certificate. 
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
As a separate question, we discussed whether the Random Value or Request Token must come from the CA – Richard’s language does not specify that.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
The defined term Random Value says the value must come from the CA.  The defined term Request Token says only that the Request Token is a “value derived in a method specified by the CA from the public key to be certified” – here is the current definition:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;line-height:normal;text-autospace:none">
<b><span style="color:black">Request Token</span></b><span style="color:black">: A value derived in a method specified by the CA from the public key to be certified. The uniqueness of the Request Token and the irreversibility of the derivation to be at least
 as strong as those of the cryptographic signature algorithm to be used to sign the certificate.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
It is unclear exactly how an Applicant receives a Request Token from a CA – does the CA calculate the value and transmit it to the Applicant to be used in a practical demonstration?  Or does the CA send the Applicant the “method” to be used to calculate the
 Random Value?  There is general agreement that all “practical demonstration” methods like this one should be unpredictable and not able to be copied or used by a hacker. 
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<b><u>Questions</u></b>:  (1) Should Richard Barnes’ suggested edit be accepted?  (2) Do we need to edit or clarify either Richard’s language or the definition of Request Token?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>



<table><tbody><tr><td bgcolor="#ffffff"><font color="#000000"><pre><table class="TM_EMAIL_NOTICE"><tbody><tr><td><pre>TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></tbody></table></pre></font></td></tr></tbody></table>
</div></blockquote><blockquote type="cite"><div><New Domain Validation Draft 9-10-2015 (for CABF consideration).pdf></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Public mailing list</span><br><span><a href="mailto:Public@cabforum.org">Public@cabforum.org</a></span><br><span><a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a></span><br></div></blockquote></body></html>