[cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers

[Wayne Thayer]

Yes, I think this is too restrictive because it prevents a CA from automatically checking for the presence of the marker. I also think that forcing a legitimate customer who made a mistake with a token to get a new one just creates more confusion without really making it more difficult for an attacker.

I’m not thrilled with the idea of placing a time limit on the token either because it just makes the process more complicated, but I prefer that approach and I think it’s easy to communicate that the token will expire in X days.

Also, is the intent to require a unique token for every FQDN contained in a certificate? I don’t have a strong opinion on this, but in the context of a single certificate request it seems reasonable to allow reuse of a token on multiple FQDNs.

From: "kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>"
Date: Friday, June 5, 2015 at 6:39 PM
To: Rick Andrews, "validation at cabforum.org<mailto:validation at cabforum.org>"
Subject: Re: [cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers

I’m good with that.
Any one object to making that change and adding to the current domain validation ballot draft (for all three markers)?
From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: Friday, June 05, 2015 4:48 PM
To: Kirk Hall (RD-US); validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: [cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers

How about: “A [Random Value | Request Token | Test Certificate] may not be reused, but a new [Random Value | Request Token | Test Certificate] must be generated every time the CA attempts to validate domain ownership. If a validation attempt fails, the CA must issue a new [Random Value | Request Token | Test Certificate] before a subsequent attempt.”
-Rick
From: kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> [mailto:kirk_hall at trendmicro.com]
Sent: Friday, June 05, 2015 4:11 PM
To: Rick Andrews; validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: [cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers

I’m open to changing “revetting.”  But I don’t know what to say.
Maybe put a time limit on use of a marker, such as:
A Random Value [Request Token / Test Certificate] may not be used for domain authentication for more than [30?] days following generation, but instead a new Random Value [Request Token / Test Certificate] must be generated and used by the CA after that period.
What do you think?
From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: Friday, June 05, 2015 2:19 PM
To: Kirk Hall (RD-US); validation at cabforum.org<mailto:validation at cabforum.org>
Subject: RE: [cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers

Kirk,
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.
-Rick
From:validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: Thursday, June 04, 2015 3:02 PM
To: validation at cabforum.org<mailto: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.






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.




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...
URL: https://cabforum.org/pipermail/validation/attachments/20150606/e27cc7e1/attachment-0001.html