<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 said:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>"...we would at least like to be able to provide reliable guidance and security practices for the many hosting services that do allow modifications of the root."<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 that's the goal, shouldn't the first sentence of such guidance be, "Hey numbskull, secure your root"? <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'>Not saying we shouldn't tighten up the language in the BRs some, but I also don't think we should go so far as to define the exact procedure every CA MUST follow and thereby prevent future innovation and improvement.<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'>-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"'> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Monday, June 02, 2014 9:23 AM<br><b>To:</b> Rich Smith<br><b>Cc:</b> Rob Stradling; 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 6:01 AM, "Rich Smith" <<a href="mailto:richard.smith@comodo.com">richard.smith@comodo.com</a>> wrote:<br>><br>> Ryan,<br>><br>> We can certainly make changes should the Forum decide that's the best course, however, our HTTP based DCV is as follows:<br>><br>> <br>><br>> HTTP-based DCV<br>><br>> 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>> <a href="http://yourdomain.com/">http://yourdomain.com/</a><Upper case MD5 hash of CSR>.txt<br>><br>> Content (as a plain text file): <br>><br>> <SHA1 hash of CSR> <br>> <a href="http://comodoca.com">comodoca.com</a> <br>><br>> <br>><br>> 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.<br>><o:p></o:p></p><p>While you may view it as monumentally stupid, the reality is that a vast number of services already permit this. It is common enough that we here no longer view it as an affective demonstration of control. Given that CAs are often focused on security through the lens of cryptography and identity, rather than on web application security, and may thus be unaware of how common it is, this is why we are bringing the issue to the Forum to begin with.<o:p></o:p></p><p>While file based verifications are a poor substitute for *domain* validation, for all the reasons that have been enumerated as problematic with CAA (most notably, the case of site operator != domain operator), we would at least like to be able to provide reliable guidance and security practices for the many hosting services that do allow modifications of the root.<o:p></o:p></p><p>Further, even though Comodo may be using this particular scheme, the way the BRs are written permit any number of creative interpretions - including files in subdirectories, as discussed on the call - so we really are in a similar position to how email validation behaved a decade ago.<o:p></o:p></p><p>> <br>><br>> 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.<br>><br>> <br>><br>> Regards,<br>><br>> Rich<br>><br>> <br>><br>> <br>><br>> From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On Behalf Of Ryan Sleevi<br>> Sent: Monday, June 02, 2014 5:40 AM<br>> To: Rob Stradling<br>> Cc: CABFPub<br>> Subject: Re: [cabfpub] For discussion: Restricting the use of file-based demonstrations of control<br>><br>> <br>><br>><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>> ><br>><br>> 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.<br>><br>> 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.<br>><br>> 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>