[cabfpub] For discussion: Restricting the use of file-based demonstrations of control

[Ryan Sleevi]

On Jun 2, 2014 2:13 AM, "Rob Stradling" <rob.stradling at comodo.com> wrote:
>
> On 30/05/14 02:09, Ryan Sleevi wrote:
> <snip>
>
>> Proposal 1: Remove 11.1.1 (6)
>> Alternate: Provide a single, explicit path and set of steps that must be
>> done, so that there is consistency between the CAs that employ this
>> method. One path that might suffice would be one based upon RFC 5785.
>>
>> For example, /.well-known/certificate-request . Within that file, we
>> could either establish a structure (seems complex), or simply require
>> that the applicant place a random string that is generated by the CA
>> (eg: it is not influenced by the applicant, such as a value of their
>> choosing, hash of their CSR, etc).
>
>
> Ryan, why is "hash of their CSR" insufficient, in your opinion?
>
> Thanks.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140602/bea712c6/attachment-0003.html>