[cabfpub] Question 5 – Domain Validation pre-ballot

Tim Shirley TShirley at trustwave.com
Fri Nov 13 12:56:42 UTC 2015


If we want to make the requirements and security policies associated with the 3 “CA Marker” types equivalent, which seems to me like a good idea, then we’re going to be inherently limited by the one to one relationship between a Request Token and Public Key.  That is, the Request Token value is going to be the same for all domains in a particular certificate because they all share the same Public Key.  Furthermore, if the customer comes back a year later to renew their certificate, and uses the same Public Key, they’re going to get the same Request Token again.
In light of that, perhaps it makes sense to simply require that the CA Marker (regardless of type) is unique per Public Key?  You wouldn’t be able to put a time limit on the use of a Request Token unless you required the customer to generate a new key pair after that time limit expired.  But is a time limit really necessary if the value is tied to the key?  An attacker who gains access to an “unused CA Marker” can’t use it to obtain a certificate he/she can use without also gaining access to the private key associated with it.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, November 12, 2015 8:08 PM
To: CABFPub (public at cabforum.org)
Subject: [cabfpub] Question 5 – Domain Validation pre-ballot

Question 5 – Domain Validation pre-ballot

Richard Wang of WoSign posted the following comment on the pre-ballot:

“I think the ballot should include some sort of requirement that a Random Value, Request Token, or Test Certificate can only be used once by the CA and customer to validate one domain, and that a new Random Value, Request Token, or Test Certificate must be generated by the CA for the customer for each domain being validated, and each time a domain is validated.”

Currently, there is no limitation on how many times the same Random Value, Request Token, or Test Certificate (call them all “CA markers”) can be used, or for confirming how many domains, or for what period of time.

On the call today, there was general agreement that the CA Markers should not be reused, but that a new CA Marker should be generated by the CA for validation of each new domain.  By extension, a CA should also generate a new CA Marker each time the CA re-validates the same domain (every 13 months or earlier for EV domains, every 39 months or earlier for DV and OV domains).

There was one suggestion that maybe a CA could use a single CA Marker for validating all the domains included in a single CSR.

Gerv also suggested there should be a time limit on how long a CA Marker would be valid, as a hacker could perhaps find an unused CA Marker sent to a domain owner and then use it to get a bogus cert.   For this reason, if the customer does not use the CA Token in a fairly short period, the CA should generate and send a new CA Marker to the customer for the domain.

Eddy said that applicants are sometimes slow to complete their vetting process, and so any time limit should not be too short.  He will explain and offer suggestions in an email.

Question for Discussion:

(1) Should all “CA Markers” (Random Values, Request Tokens, Test Certificates) be prohibited from re-use?  Should the limitation be one of the following?

(a) CA Markers should only be used one time for one domain being validated for an Applicant
(b) CA Markers should only be used one time, but can be re-used for confirming control of multiple domains so long as they are all contained in one CSR from an Applicant
(c) In any case, no CA Marker may be used more than x days after it has been generated and issued by the CA to the Applicant – if the domain validation is not completed in that period, the CA must generate and give a new CA Marker to the Applicant.

What rule(s) should we set for this?




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.




________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151113/d78a37bf/attachment-0003.html>


More information about the Public mailing list