[cabfpub] VWG Question 5 – Domain Validation pre-ballot

Gervase Markham gerv at mozilla.org
Wed Nov 25 07:45:29 MST 2015

On 24/11/15 02:31, kirk_hall at trendmicro.com wrote:
> *Yes, I was referring to the situations where the Random Value is
> visible in a public place.  There was also concern on the last call that
> a Random Value in an email was not really secure enough to be used more
> than once.*

Then perhaps we need to distinguish between Random Values posted as
known locations, and those posted at random locations?

> *Perhaps not realistic, but some on the call said a single Random Value
> sent to an applicant could be used to validate 100 domains contained in
> the SANs field of a single certificate request.  As this could happen by
> posting the same Random Value in the DNS record of the 100 domains over
> and over again, I was thinking about a case where the Applicant posted
> to 55 or 72 domains over three or four days, and then didn’t continue. 
> At some point, a hacker might figure out that this Random Value could be
> reused with this CA, and..   not sure how the hacker would use it, but
> it would no longer be unknown and unpredictable.*

If you aren't sure how the hacker would use it, there's not yet any
threat :-) We should base security decisions on actual threat modelling.

The purpose of the Random Value is for the applicant to prove they have
control of the domain. What can a hacker do if they know it? They can
add that random value to other domains - but that's not useful, as the
CA will never look at them, and they aren't in the CSR.

> You are right that if a CA used the same test certificate for all
> validations, that would be dumb.
> *Yes, the current definition for Test Certificate does not require any
> unique or random information, so it will be modified.  Also, because a
> Test Certificate is likely to be posted in a public place, in my opinion
> it should be one use only and not reused for other domains or for
> re-vetting 13 or 39 months later.*

The certificate will be in a public place, but the private key
corresponding to it will not. Saying having a certificate posted
publicly makes it insecure is saying that all certificates on the web
are insecure.

> *Not necessarily – a Test Certificate does not have to be tied to a
> public key.*
> *Test Certificate*: A Certificate which includes data that renders the
> Certificate unusable for use by an application software vendor or
> publicly trusted TLS server such as the inclusion of a critical
> extension that is not recognized by any known application software
> vendor or a certificate issued under a root certificate not subject to
> these Requirements.

How can you have a certificate without a public key? A certificate binds
some identity information to a public key - that's what it _does_.

> 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?
> *If the domain validation is limited to one certificate request with one
> public key, it may not be useful to a hacker.  But if the CA treats the
> Request Token as a credential that a customer can reused to validate
> _other_ domains (and then come back to get additional certs for the
> validated domains using a different public key – many CAs allow repeated
> certificate requests once a domain has been validated) then perhaps a
> hacker can observe and copy the Request Token from the DNS record and
> use it somehow to imitate the real customer using a different key pair. 

If the CA is also using the Request Token as a password, then they are
dumb. I guess we could forbid this, but we can't enumerate all possible


More information about the Public mailing list