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

Mon Jun 8 15:03:58 MST 2015

Kirk – Yes, that was what we came to previously. – But do we need to split out the automated case from the manual case if we are setting a low bar?

If a human validator is sending an email to validate domain control then I can see that a short email of this form is enough:
“Hi Bob, this is Pete at Wonder CA Inc.  We spoke earlier about your certificate.  Please reply to this email so we can see you receive emails as the domain admin.  Include the words ‘HungarianBanjoSpasm’ in your reply.  Thanks.”

But if it’s an automated system, as many are, and especially if the unique token/value/certificate gets fed into a URL that the recipient clicks on then it is no more effort to include a pretty good unique token than it would be to choose a sequence that looks like its picked by a person with a weak imagination.

Robin

From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] 
Sent: 08 June 2015 18:29
To: Robin Alden; 'Wayne Thayer'; 'Rick Andrews'; validation at cabforum.org
Subject: RE: [cabf_validation] Suggested edits to Domain Validation ballot - reuse of practical demonstration markers

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 and the WHIOS admin email address for adam.com is admin at adam.com then the CA has to send one token to admin at bob.com and a different one to 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"
Date: Friday, June 5, 2015 at 6:39 PM
To: Rick Andrews, "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
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] 
Sent: Friday, June 05, 2015 4:11 PM
To: Rick Andrews; 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
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] 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...
URL: https://cabforum.org/pipermail/validation/attachments/20150608/4800a762/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5776 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20150608/4800a762/attachment-0001.bin 