<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 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;}
/* 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;}
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";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@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'>Ryan,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>We can certainly make changes should the Forum decide that's the best course, however, our HTTP based DCV is as follows:<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><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>HTTP-based DCV</span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The CSR you submit to Comodo will be hashed. The hash values are provided to you and you must create a simple plain-text file and place this in the root of your webserver and served over HTTP-only! <br><br>The file and it's content should be as follows:<br>http://<i>yourdomain.com</i>/<Upper case MD5 hash of CSR>.txt<br><br>Content (as a plain text file): <br><br><SHA1 hash of CSR> <br>comodoca.com <o:p></o:p></span></b></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'>I don't see how having some specific sub-directory helps if the site operator is not already preventing end users/others from modifying their root directory, and as you can see, we already have a requirement for a reference to the CA to be in the contents of the text file. I can sort of see your point with respect to hash collisions, but I don't really think that it's that relevant if you are requiring the hash in a specific place that SHOULD be under the sole control of the site operator. If the site operator is allowing all and sundry to write to the root directory of their site that's monumentally stupid, and I don't see any change we can make here fixing stupid. If the site owner is already allowing writes to the root directory, what makes you think they will better secure some sub-directory? In my experience when you think you've made something idiot proof, what you have actually done is create conditions for someone to come up with an improved model of idiot.<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'>If the Forum decides we need to change, we'll change, but with the possible exception of the hash collision issue, I don't really see anything you're proposing as a big security improvement on what Comodo is already doing.<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'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Rich<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 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"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Ryan Sleevi<br><b>Sent:</b> Monday, June 02, 2014 5:40 AM<br><b>To:</b> Rob Stradling<br><b>Cc:</b> CABFPub<br><b>Subject:</b> Re: [cabfpub] For discussion: Restricting the use of file-based demonstrations of control<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p><br>On Jun 2, 2014 2:13 AM, "Rob Stradling" <<a href="mailto:rob.stradling@comodo.com">rob.stradling@comodo.com</a>> wrote:<br>><br>> On 30/05/14 02:09, Ryan Sleevi wrote:<br>> <snip><br>><br>>> Proposal 1: Remove 11.1.1 (6)<br>>> Alternate: Provide a single, explicit path and set of steps that must be<br>>> done, so that there is consistency between the CAs that employ this<br>>> method. One path that might suffice would be one based upon RFC 5785.<br>>><br>>> For example, /.well-known/certificate-request . Within that file, we<br>>> could either establish a structure (seems complex), or simply require<br>>> that the applicant place a random string that is generated by the CA<br>>> (eg: it is not influenced by the applicant, such as a value of their<br>>> choosing, hash of their CSR, etc).<br>><br>><br>> Ryan, why is "hash of their CSR" insufficient, in your opinion?<br>><br>> Thanks.<br>><br>> -- <br>> Rob Stradling<br>> Senior Research & Development Scientist<br>> COMODO - Creating Trust Online<br>><o:p></o:p></p><p>The first reason is simple - it is not unique per CA/request, thus multiple CAs could rely on expecting to see the same value. As such, it is not a practical demonstration that the applicant is authorized to request the cert.<o:p></o:p></p><p>The second is the same reason we require entropy in the serial number or portions of the issued cert that are not under the applicant's/attacker's control - weaknesses in the hash algorithm used may lead to collisions, as we saw with Flame.<o:p></o:p></p><p>Requiring a cryptographically strong random number per request/verification creates a stronger verification method than a naive implementation. Given how weak URL based verifications are to begin with, this is important.<o:p></o:p></p></div></div></body></html>