[cabf_validation] Domain Validation ballot -- open discussion items

[Rick Andrews]

I like these proposed changes, especially stipulating that the Random Value must be unique to the Applicant.

Jeremy, there's a typo in Line L number 9: "Confirming the Applicant's demonstrate control over the FQDN by confirming the presence of a Random Value or Request Token in the TLS handshake messages sent by a servethe Applicant requesting..."

But Line Z, definition of Request Token confuses me. It currently says (with Jeremy's edits) "Request Token: A value derived in a method specified by the CA which includes a value specified by the Applicant, such as the public key. The he irreversibility of the derivation to be at least as strong as those of the cryptographic signature algorithm to be used to sign the certificate(s) containing the FQDNs validated using the Request Token.  The CA must receive proof of possession of the private key from the Applicant.  Such proof must be provided with X hours (days) of the date stamp if the Request Token inputs include a date stamp." This talks about an irreversible method, which seems to imply a hash function. What does it mean for it to "include a value specified by the Applicant, such as the public key"? One might think you feed the public key into the hash (as I had originally thought, that the Request Token might be a hash of the CSR), but then would Robin need to view the public key, or just confirm that the public key was used to make the hash? I thought Robin wanted something like Request Token = [Public Key concatenated with Random Value].

And you can see there are a couple of typos in there.

-Rick

-----Original Message-----
From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Thursday, December 17, 2015 8:57 AM
To: Bowen, Peter; kirk_hall at trendmicro.com; validation at cabforum.org
Subject: Re: [cabf_validation] Domain Validation ballot -- open discussion items

Here's some revisions that I think  keep it clear for the auditors and keep the random value tied to the Applicant rather than each communication.

-----Original Message-----
From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Bowen, Peter
Sent: Wednesday, December 16, 2015 6:46 PM
To: kirk_hall at trendmicro.com; validation at cabforum.org
Subject: Re: [cabf_validation] Domain Validation ballot -- open discussion items

Kirk,

I propose the attached edits, which address several of the issues you list.  These are independent from the Issue 5 that I previously raised.

The edits cover several items:

* In D, E, and F: clarify the random value must be unique for each communication and that the recipient must return it to the CA.  The intent here is that a single email can be sent to multiple addresses, but each unique set of addresses must have a different random value.  It also clarifies that simply sending the random value is not adequate, which might not be obvious from the existing language.

* In H, J, K, and L: flip the language to state what the CA must so. The BRs are requirements on CAs, not applicants, and auditors cannot verify what an applicant does.  They can verify what actions the CA took.  The revised language mirrors that of the existing methods.

* In H: change to FQDN.  I think the assertion that someone who controls web server content at socsci.example.edu is also the controller of sociology.socsci.example.edu is a little tenuous.  I realize that the comments suggest that the reverse of this change was made previously and I’m late to the game, but I think that new methods 6 and 9 should have the same test scope (FQDN or Authorization Domain).

* In L: move to Random Value or Request Token.  When reading the definitions, it seems that a Test Certificate would inherently either contain a Random Value (e.g. random serial number) or a Request Token (signature).  I am proposing the change to also make the method slightly more flexible to allow returning the expected valued during other parts of the handshake.

In addition to updating 3.2.2.4/5, I think it would be good to clarify the “reuse” of validations.  

I think that it would be appropriate to flag the date the CA received the confirmation of Random Value or Request Token as the the date that the CA obtained the validation for the purposes of section 3.3.1 or the similar section in the EVG. For example, if the CA received a public key from a customer on January 1, 2016 and found a Request Token based on that key in DNS (for example, a TXT record for example.com. included the token) on January 2, 2016, then the validation for the example.com namespace would be good for non-EV certificate issuance until April 2, 2019 

Similarly, if a CA sent an email to hostmaster at example.com on January 1, 2016 and received the confirmation on January 15, 2016, then the validation for the example.com namespace would be good for non-EV certificate issuance until April 15, 2019.

Thanks,
Peter

On 12/16/15, 1:26 PM, "validation-bounces at cabforum.org on behalf of kirk_hall at trendmicro.com" <validation-bounces at cabforum.org on behalf of kirk_hall at trendmicro.com> wrote:


>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.
> 
>
>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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5749 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20151217/3988c384/attachment-0001.bin