<p dir="ltr"><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>
></p>
<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>