[cabfpub] VWG Question 5 – Domain Validation pre-ballot
gerv at mozilla.org
Sat Nov 21 13:14:03 UTC 2015
On 19/11/15 01:28, kirk_hall at trendmicro.com wrote:
> Random Values
> _Kirk’s opinion_: A Random Value must be generated and specified by the
> CA to the Applicant, and must have at least 112 bits of entropy. With
> all that trouble taken to make it truly random (entropy), and given that
> the Random Value is posted in public places by the Applicant,
I don't think this is always correct - the Random Value is not
necessarily posted in a public place. I guess it partly depends on
whether the value is part of the filename or the file contents; if it's
in the filename, then the only way to find it out is by knowing it
already, so it could hardly be said to be publicly posted.
If the method is to add the value to the file contents of
.well-known/validation/foo-ca.txt, then yes, that is publicly posted, as
a hacker could poll that URL until they got content.
> I think a time limit is appropriate because if the customer uses the
> Random Value but misapplies it to a public place (so a hacker sees it),
> or just doesn’t get around to using it after it has been sent by an
> email or otherwise, it is potentially discoverable by a hacker and can
> be used.
Can you elaborate more on the sequence of events which lead to a threat
here? How can an attacker discover the person's email? And if they can,
how does a time limit help - surely the attacker will launch their
attack as soon as the email is received?
> Question: Should we beef up the definition of “Test Certificate” so it
> has some unique and random character? Otherwise, a hacker could simply
> copy MegaCA’s standard Test Certificate (which never changes) and try to
> use it, even though the hacker didn’t receive it from the CA.
You are right that if a CA used the same test certificate for all
validations, that would be dumb.
> Test Certificates
> _Kirk’s Opinion_: My opinion for Test Certificates is the same as for
> Random Values – once issued by the CA, a Test Certificate is public and
> can be seen and reused by a hacker to attempt fraudulent domain
But surely a test certificate involves both a public and a private key?
Just because the hacker can see the public key (by accessing the website
when it's using the cert) doesn't mean they have the private key. So
they can't use the cert on a spoof website.
> Request Token
> There is no requirement that the Request Token be generated by the CA
> and provided to the Applicant, and there has been speculation that the
> Request Token may be generated by the Applicant as a hash of a
> particular public key used in connection with a specific certificate
> request. If so, that raises the questions I posed in my earlier email
> to Robin about this method – does it depend on a specific CSR from the
> Applicant? If the CA’s “method” is known and the public key is known to
> everyone, then a hacker could generate and use an identical Request
Yes, and so they could perhaps get a signature issued for a public key
to which they don't hold the private key. How is that useful to them?
More information about the Public