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

[kirk_hall at trendmicro.com]

Hi, Gerv.  Responses in red.  I’d appreciate any suggestions you may have on limitations the new domain validation ballot should have concerning reuse and/or time limit on use, for a Random Value, Test Certificate, or Request Token.  It may be that we should make a distinction on whether the domain validation is connected to a specific certificate request and public key, or whether the domain validation is unrelated to a specific certificate request and public key but instead is to authorize the Applicant to come back later and request certificates for the authorized domain.



-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Saturday, November 21, 2015 5:14 AM
To: public at cabforum.org >> CABFPub
Subject: Re: [cabfpub] VWG Question 5 – Domain Validation pre-ballot



On 19/11/15 01:28, kirk_hall at trendmicro.com<mailto: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.



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.



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



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.



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



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.



> 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

> validations.



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.



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.





> 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

> Token,



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.  Probably too exotic to happen, but in the current language there is no explicit requirement that this domain authentication method be used only to authenticate a domain for a particular certificate request involving only the public key that was used in creating the Request Token.  Maybe that’s implied.  I know Robin is coming back with some edits to this language.



7. Having the Applicant demonstrate control over the requested FQDN by the Applicant making a change to information in a DNS record for an Authorization Domain Name where the change is to insert a Random Value or Request Token



Request Token: A value derived in a method specified by the CA from the public key to be certified. The uniqueness of the Request Token and the irreversibility of the derivation to be at least as strong as those of the cryptographic signature algorithm to be used to sign the certificate.





Gerv

_______________________________________________

Public mailing list

Public at cabforum.org<mailto:Public at cabforum.org>

https://cabforum.org/mailman/listinfo/public

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151124/558b62b5/attachment-0001.html