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

[Rob Stradling]

On 02/06/14 10:40, Ryan Sleevi wrote:
> On Jun 2, 2014 2:13 AM, Rob Stradling wrote:
<snip>
> > Ryan, why is "hash of their CSR" insufficient, in your opinion?
>
> 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.

I agree that "hash of their CSR" alone is insufficient.

The "hash of their CSR" methods that we currently use at Comodo also 
require the applicant to state the domain name of the authorized CA (à 
la CAA).

As for "unique per...request" - well, the CSR _is_ the request (from my 
point-of-view as a CA techie at least!)

> 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.

The attacker would need to know the hash they're trying to create a 
collision for.  Why would anyone besides the CA and the applicant ever 
see the CSR or its hash?

TBH, I think it's useful to incorporate verification of the CSR's 
authenticity into the "demonstration of control" process.  Otherwise, 
isn't there a risk that an attacker might somehow (perhaps via social 
engineering, or by MITM'ing an insecure CSR upload form) interfere with 
a legitimate certificate application, substituting the real CSR for a 
fake one?
(If attack successful, then the CA uses the fake CSR to issue Cert A; 
then the legitimate customer complains that Cert A "doesn't work"; then 
the CA shrugs it shoulders and does a reissue - Cert B, which the 
legitimate customer is happy with; the CA doesn't revoke Cert A because 
the attack went undetected; meanwhile, the attacker downloads the 
unrevoked Cert A, for which they have the associated private key, from 
one of the CT Logs...)

I think adding baseline requirements for permitted (combinations of) 
hash algorithms for "hash of their CSR" methods might be a good idea though.

> 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.

IANAL, but IIRC, demonstration of control using a CA-generated random 
number is encumbered, whereas "hash of their CSR" is (hopefully) not.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online