[cabfpub] For discussion: Restricting the use of file-based demonstrations of control
rob.stradling at comodo.com
Mon Jun 2 13:11:56 UTC 2014
On 02/06/14 10:40, Ryan Sleevi wrote:
> On Jun 2, 2014 2:13 AM, Rob Stradling wrote:
> > 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 (à
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
(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.
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public