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

[Rich Smith]

Ryan,

We can certainly make changes should the Forum decide that's the best course, 
however, our HTTP based DCV is as follows:



HTTP-based DCV

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!

The file and it's content should be as follows:
http://yourdomain.com/<Upper case MD5 hash of CSR>.txt

Content (as a plain text file):

<SHA1 hash of CSR>
comodoca.com



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.



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.



Regards,

Rich





From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On 
Behalf Of Ryan Sleevi
Sent: Monday, June 02, 2014 5:40 AM
To: Rob Stradling
Cc: CABFPub
Subject: Re: [cabfpub] For discussion: Restricting the use of file-based 
demonstrations of control




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/473841ec/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140602/473841ec/attachment-0003.bin>