[cabfpub] VWG Question 5 – Domain Validation pre-ballot
kirk_hall at trendmicro.com
kirk_hall at trendmicro.com
Thu Nov 19 01:28:55 UTC 2015
There have been a number of comments in response to this question, and it seems the best idea is to discuss separately the question of whether or not each kind of “marker” used in a practical demonstration (Random Value, Test Certificate, and Request Token) should be limited as follows:
(1) should be limited to validation of a single domain,
(2) should be limited to one-time use, and/or
(3) there should be a time limit on how long the Value, Certificate, or Token could be used for validation purposes.
One preliminary caveat: We should be careful during our discussion of domain validation methods to avoid conflating the act of submitting a CSR to request a certificate, versus the act of validating a domain for future certificate requests from an Applicant/Subscriber (the domain validation only needs to occur once every 13 months for EV, once every 39 months for DV and OV, and can then be relied upon for the entire validation period to issue multiple certificates that include the validated domain). Any domain method that STARTS with a CSR has to be evaluated very carefully so we pull the domain validation process for the customer’s future use apart from any specific certificate request.
So I suggest we discuss each method separately to decide on the three questions above concerning re-use and time limits.
1. Random Values
Here is the current ballot language on Random Values:
6. Having the Applicant demonstrate control over the requested FQDN by installing a Random Value (contained in the name of the file, the content of a file, on a web page in the form of a meta tag, or any other format as determined by the CA) under "/.well-known/validation" directory on an Authorized Domain Name that can be validated over an Authorized Port; or
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; or ***
Random Value: (1) For domain validation methods that are totally automated or involve making a change specified by the CA to the Applicant’s DNS record, a value specified by a CA to the Applicant that exhibits at least 112 bits of entropy; (2) for all other domain validation methods, a value specified by the CA that is unknown to the Applicant.
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 believe Random Values should be one-time use, a new Random Value per domain, a new Random Value per domain re-validation, and a time limit on the use of a Random Value - it should have to be used successfully by the Applicant during a limited period (24 hours?) or be regenerated by the CA.
This is true even if the same Applicant applies for 10 domains to be validated at the same time (e.g., by submitting a CSR with 10 new domains needing validation), because once the Applicant starts posting the Random Value provided by the CA in a public place for the first domain being validated, a hacker could observe it and try to use it for other domains.
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. A given Random Value should go stale in a limited period and have to be regenerated and reissued.
Finally, why specify 112 bits of entropy if a Random Value can be re-used again and again over time once it has been exposed to the public – what’s the point?
*What limits should we add for re-use/time limits on use for Random Values?
2. Test Certificate
As our ballot now stands, a Test Certificate is generated by the CA and provided to the Applicant. Presumably it contains something random and unique (like a Random Value is random and unique). Here is the current ballot language:
9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the FQDN which is accessed and then validated via https by the CA over an Authorized Port.
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.
Richard Barnes has proposed that Method 9 be expanded so the Test Certificate can be generated by the Applicant, so long as it contains a Random Value created and issued by the CA to the Applicant.
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.
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. So I think a Test Certificate should be one-time use, a new Test Certificate per domain, a new Test Certificate per domain re-validation, and a time limit on the use of a Test Certificate.
*What limits should we add for re-use/time limits on use for Test Certificates?
3. Request Token
I posted some questions to Robin Alden (who proposed the existing language about use of Request Tokens for domain validation), and I know I need to understand the Request Token process better to evaluate whether it can be re-used for validating multiple domains, or re-used over an extended period of time. Here is the current ballot 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.
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, which suggests we may need special limitations on the re-use of Request Tokens, and the time period for which they are valid (perhaps they can no longer be valid after a certificate has been issued to the Applicant for the public key in question?).
How can this method be used where a CSR includes 10 domains needing validation – can the same Request Token be used for validating all 10 domains? Again, a hacker can create a duplicate Request Token, can (falsely) validate to the 10 domains, and then can discard the Request Token and order new certificates from a new key pair – because the CA has validated the domain ownership to the hacker, the CA may issue additional certs to the hacker based on a new CSR.
This is one domain validation method where the request for a certificate and the process of validating the domain (which can be relied on for 39 months for DV and OV) need to be carefully pulled apart for analysis.
*What limits should we add for re-use/time limits on use for Request Tokens?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public