[cabf_validation] Domain Validation ballot -- open discussion items

[kirk_hall at trendmicro.com]

I went through my notes of remaining issues, and here's where I think we are for our call on Thursday.  Please refer to the attached email dated Dec. 1 laying out the five issues we are discussing.  Robin and Doug - you need to send out a redraft of your methods (see below).

Issue 1 (Method 7): On the Dec. 3 call, Robin said he wants to amend the definition of Request Token so (1) it has something unique in it that the Applicant can control (more than the public key - maybe also a Random Value the CA sends directly to the Applicant, maybe independent of the Reseller), and (2) if the Request Token is coming through the Reseller, do something to be sure the Reseller is not and can't be compromised.

Robin - can you circulate your redraft before the call?

Issue 2 (Method 9): On the Dec. 3 call, Doug Beatty said the following: (1) the Test Certificates and the certs issued after domain validation using the Test Certificate must all have the same public key (i.e., the Test Certificate can't be used for vetting domains in a certificate request using a different public key); (2) The Test Certificate must "work" for all the domains in the certificate request that you are validating, meaning the Test Certificate must contain all the FQDNs in the certificate request.

Doug - can you circulate your redraft before the call?

Issue 3: Completed

Issue 4: This question related to whether Random Values, Test Certificates, and/or Request Tokens should have limits on re-use (either for authenticating more than one domain, such as multiple domains in the SANs field of a single CSR, re-used to re-authenticate the same domain when re-vetting is required, 13 or 39 months or 10 years later, or limited over what period of time it can be used after being send by the CA to the Applicant, such as 48 hours or 96 hours).  The question relates to making sure the validation method remains secure and can't be gamed by hackers.

Peter Bowen suggested an RV could only be reused if all the emails in WhoIs are all the same (meaning, you could list multiple domains for validation in an email containing a single RV); otherwise, they should be changed every time.

General rules were discussed, such as the following:


*        Random Values, Test Certificates, and Request Tokens that are tied to a certificate request can be reused for all the FQDNs in that certificate request, but only for issuing certificates for the same public key as in the certificate request

*        Random Values, Test Certificates, and Request Tokens may never be reused for revetting a domain at a later date.

*        Random Values, Test Certificates, and Request Tokens must be reissued if not used by the Applicant within [x] days, and must be reissued for any domains that have not been authenticated within [x] days (where x is what - 30 days?)

Issue 5 - Applicant/Subscriber versus domain Registrant:

We did not have time to discuss Peter Bowens suggestions.


<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/20151216/59d61be3/attachment-0001.html 
-------------- next part --------------
An embedded message was scrubbed...
From: "kirk_hall at trendmicro.com" <kirk_hall at trendmicro.com>
Subject: Open Issues for Validation Working Group call on Thurs. Dec. 3
Date: Tue, 1 Dec 2015 18:58:58 +0000
Size: 88801
Url: https://cabforum.org/pipermail/validation/attachments/20151216/59d61be3/attachment-0001.mht