[cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers
Rick_Andrews at symantec.com
Fri Jun 5 14:18:59 MST 2015
I like these changes, but I wonder if we have a crisp definition of “revetting”. If a customer attempts to get a cert, receives the random number/token/cert and attempts to use it but something goes wrong (let’s say the site is temporarily down), the CA won’t be able to verify the presence of the random number/token/cert. If the customer calls back and says “ok, the site is back up now, try it again” I think I’d feel better if we insist that the CA choose and deliver a new number/token/cert and repeat the entire process. Would you consider this “revetting”? I think some folks wouldn’t.
From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, June 04, 2015 3:02 PM
To: validation at cabforum.org
Subject: [cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers
I have some suggested edits that I think should be simple.
In this draft we are tightening the “practical demonstration” methods for domain confirmation, which is a good thing. We do this by defining a Random Value, Request Token, and Test Certificate, and specify how they are to be used in subsections 5, 6, and 9.
Chris and I were talking, and there is the risk that a CA could complete one of these practical demonstration methods under 5, 6, and 9 in Year 1, and then go back again in 13 months (for EV) or 39 months (for DV or OV) to see if the SAME Random Value, Request Token, and Test Certificate is still there. In other words, a CA might take the liberty of doing the practical demonstration only once, and then relying on the same marker (under 5, 6, and 9) upon revetting without repeating the practical demonstration process with a new marker. I don’t think that’s a good practice.
To make sure this doesn’t happen, I’d suggest we amend the three definitions by adding a sentence to each, as follows. (I recognize this may not be necessary for Request Token and Test Certificate for practical reasons, but it would be good to make all three methods subject to the same limitations.)
Any objections? Here are the suggested edits:
Random Value: A value specified by a CA to the Applicant that exhibits at least 112 bits of entropy. A Random Value may not be reused, but instead a new Random Value must be generated and used by the CA each time a domain is revetted.
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. A Request Token may not be reused, but instead a new Request Token must be generated and used by the CA each time a domain is revetted.
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. A Test Certificate may not be reused, but instead a new Test Certificate must be generated and used by the CA each time a domain is revetted.
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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5749 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20150605/674a631a/attachment.bin
More information about the Validation