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

[kirk_hall at trendmicro.com]

Robin – on one of your points below, I don’t think we are requiring “tokens” per say when we use the email confirmation method – just “a value that unpredictable and previously unknown to the applicant  included in the email” in the latest draft.  That could be a Request Token or Random Value, but does not have to be, right?
From: Robin Alden [mailto:robin at comodo.com]
Sent: Monday, June 08, 2015 10:08 AM
To: 'Wayne Thayer'; Kirk Hall (RD-US); 'Rick Andrews'; validation at cabforum.org
Subject: RE: [cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers

Hi Wayne,
                Addressing your last point:

Ø  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.
If it’s a practical demonstration of control, then I think it is probably reasonable to use the same token for every FQDN in a multi-domain certificate.
For those methods you send the token to the applicant and he has to put it everywhere you ask him to.
If the token is being used in an email challenge response (e.g. to an admin email address from a WHOIS lookup) then you need a token per email address being used.
If all the FQDNs are being validated by a single email to a single email address then a single token may be used, but if the FQDNs in a certificate are to be validated by sending a token to more than one email address (e.g. because the WHOIS entries do not all share a single email address) then a new token must be used for each destination email address.
E.g.  If I apply for a cert for
adam.com
2.bob.com
1.bob.com
And if the WHOIS admin email address for bob.com is admin at bob.com<mailto:admin at bob.com> and the WHIOS admin email address for adam.com is admin at adam.com<mailto:admin at adam.com> then the CA has to send one token to admin at bob.com<mailto:admin at bob.com> and a different one to admin at adam.com<mailto:admin at adam.com> because if you use the same token to both one could (perhaps) construct a spoofed ‘click-thru’ link using the token has received to pretend to be the other.
Regards
Robin


From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Wayne Thayer
Sent: 06 June 2015 18:09
To: kirk_hall at trendmicro.com; Rick Andrews; validation at cabforum.org
Subject: Re: [cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers

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.




<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/validation/attachments/20150608/78e647ff/attachment-0001.html