[cabf_validation] Open Issues for Validation Working Group call on Thurs. Dec. 3

[kirk_hall at trendmicro.com]

I attached an updated draft Domain Validation ballot dated Nov. 21 which includes changes approved on our last call of Nov. 21.  (See my email “Results of Validation Working Group call on Thurs. Nov. 19” dated Nov. 21 for a summary of those changes.)
Here are pending issues from the last call, which we can discuss on Thursday.

Issue 1: Robin was going to bring back a revised definition of Request Token for discussion.  Under the current definition, once an Applicant’s public key is known (and the CAs requested hash algorithm is also known), a hacker could create a duplicate Request Token.  Robin said he planned to amend the definition of Request Token, perhaps by requiring the insertion of a Random Value from the CA for uniqueness, and bring a revised definition back to a future VWG meeting for review.

The term Request Token is currently only used in Method 7.

7. Having the Applicant demonstrate control over the requested FQDN by the Applicant making a change to information in a DNS record for an Authorization Domain Name where the change is to insert a Random Value or Request Token

Current definition:

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.

Issue 2: Similar issue relating to the definition of Test Certificate.  Or, because a Test Certificate is created from a specific public key, is it sufficient to state that a particular Test Certificate can only be used in connection with a pending certificate request for that public key, and for no subsequent certificate requests with different public keys or for other domain validation requests not connected with a certificate order?  (So even if a hacker has the public key and the Request Token, the hacker can’t do anything with them because the related certificate request has been satisfied and expired.)

This relates to some degree to the question of re-use - could an Applicant install a Test Certificate and leave it on the FQDN for 13 or 39 months or 10 years, and the CA can simply look for the same Test Certificate upon domain revetting each time (even though the Applicant is now using a different public key for the certificate securing that FQDN)?

Test Certificates are only used for Method 9:

9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the FQDN or installing a Test Certificate containing a Random Value which is accessed and then validated via https by the CA over an Authorized Port.

Current definition:

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.

Issue 3: In connection with the change we made to Method 8 regarding verification of IP addresses, Wayne Thayer also noted that we should make conforming changes to BR 3.2.2.5 which covers authentication for an IP address.  Tim Shirley agreed and offered the following amendments to BR 3.2.2.5 for discussion:


  1.  Change preamble for consistency with new 3.2.2.4 preamble.
  2.  Replace 3.2.2.5.1 with text from new 3.2.2.4.6, substituting "IP Address" for "FQDN" and "Authorized Domain Name".

     *   We'll need to update the ".well-known/validation" path here too once we settle on what it should be [note: we settled on ".well-known/pki-validation"]
     *   I also added "or Request Token" here as I believe this is inadvertently missing from section 3.2.2.4.6 currently as Robin identified. [Note: Did Robin propose to add “or Request Token” to method 6?  To be discussed.]

  1.  Delete section 3.2.2.5.4.

With these changes, BR 3.2.2.5 would read as follows:

3.2.2.5. Authentication for an IP Address
This section defines the permitted processes and procedures for validating IP Address ownership or control.  The CA SHALL confirm that the IP Address has been validated by at least one of the methods below for each IP Address listed in a Certificate.  For purposes of IP Address validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.
For each IP Address listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant has control over the IP Address by:

1. Having the Applicant demonstrate practical control over the requested IP Address by installing a Random Value or Request Token (contained in the name of the file, the content of a file, on a web page in the form of a meta tag, or any other format as determined by the CA) under "/.well-known/pki-validation" directory on the requested IP Address that can be validated over an Authorized Port; or making an agreed‐upon change to information found on an online Web page identified by a uniform resource identifier containing the IP Address;

2. Obtaining documentation of IP address assignment from the Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC); or
3. Performing a reverse‐IP address lookup and then verifying control over the resulting Domain Name under Section 3.2.2.4.; or

4. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant has control over the IP Address to at least the same level of assurance as the methods previously described.

Note: IPAddresses may be listed in Subscriber Certificates using IPAddress in the subjectAltName extension or in Subordinate CA Certificates via IPAddress in permittedSubtrees within the Name Constraints extension.

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.

Revetting of Domains:  My biggest concern is that I don’t think Random Values / Request Tokens / Test Certificates should be treated as “evergreen” credentials by an Applicant that they can leave on their website, in a DNS record, etc. for years and be used by the CA for revetting every 13 months (for EV) or 39 months (for DV or OV) - at each new revetting of the domain name, I think a CA should have to issue a new Random Value / Request Token / Test Certificate to be used by the Applicant.

Using the same credential to authenticate multiple domains: As a separate matter, I’m uneasy with letting an Applicant use the same Random Value / Request Token / Test Certificate to authenticate multiple domains, although I may be more comfortable if re-use for multiple domains is limited to certificate request/single public key validation methods (where all the domains to be validated using the one credential are contained in the SANs field of a single CSR).  I think it would be a mistake to let a customer re-use a single credential for multiple certificate requests with multiple public keys, as that means the credential is no longer “unknown and unpredictable” to the Applicant (or a hacker).

Time limit for use of a credential:  Finally, I’m uncomfortable with the idea that a credential (Random Value / Request Token / Test Certificate), once issued or authorized by the CA, can be used by the Applicant at any time over months or years - the longer the credential is out there, the greater chance it can be discovered and potentially used by a hacker.  I can’t come up with simple use cases where this would be a problem, but perhaps we should impose a time limit after which the Applicant must receive and use a new Random Value / Request Token / Test Certificate to complete a pending order (for Request Tokens and Test Certificates, this might require generation of a new key pair).

Issue 5 - Applicant/Subscriber versus domain Registrant:

I believe Peter Bowen of Amazon will be participating on our VWG calls from now on, so I will let him cover this issue.  I have included my summary of the issue as of Nov. 21, but Peter offered more comments after that.  I don’t fully understand what this issue is, so I’ll let Peter explain himself on the call.

In connection with Question 3 emails, Peter Bowen suggested extensive changes to the introductory language for many of the domain validation methods replacing "Confirming the Applicant’s domain ownership or control by [method]" with "Confirming the Applicant’s authorization to obtain and manage certificates for the Domain Namespace by [method]”.   Kirk was confirmed that this change could add confusion as who was the Applicant for legal purposes, such as the various warranties the Applicant must make under the BRs.  Peter acknowledged this point and provided examples that raised his concerns.  The issue was discussed in multiple email exchanges, and Peter’s proposal is still a work in progress.

Subsequently, Ryan Sleevi posted a message on Nov. 20 putting this question in the larger context of certificates for third level domains and higher - which company should be in the O field of the cert, and how is the company verified by the CA.  Kirk posted some thought in an email the same day.



<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/20151201/3ddb0b59/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: New Domain Validation Draft 11-21-2015 (for VWG consideration).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 35466 bytes
Desc: New Domain Validation Draft 11-21-2015 (for VWG
 consideration).docx
Url : https://cabforum.org/pipermail/validation/attachments/20151201/3ddb0b59/attachment-0001.bin