[cabf_validation] Results of Validation Working Group call on Thurs. Nov. 19

[kirk_hall at trendmicro.com]

Here are results from the VWG call on Thursday, and remaining open questions for further discussion on the next call Dec. 3.  These notes are based on discussion of the prior emails I sent for the topics as listed.

COMPLETED MATTERS

Question 1: The consensus is to amend new Method 9 as follows (Richard Barnes’ suggestion):

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.

Question 2:  The consensus is to amend new Method 9 as follows to distinguish PKI validation purposes from other types of validation (Richard Barnes’ suggestion):

6. Having the Applicant demonstrate control over the requested FQDN by installing a Random Value (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 an Authorized Domain Name, that can be validated over an Authorized Port; ***

Question 3:  Peter Bowen’s original comment about Method 7 has been satisfied, and so there are no amendments to Method 7.


OPEN MATTERS FOR FURTHER DISCUSSION

Question 4: Peter Bowen thought the current language for Method 8 was too broad and said “just because I control the IP address of corp.example.com doesn’t mean I have control over payments.corp.example.com”.  Wayne Thayer agreed, and proposed Method 8 be amended to read as follows:


8. Having the Applicant demonstrate control over the requested FQDN by the CA confirming that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records for the Authorization Domain Name FQDN in accordance with section 3.2.2.5



Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance for a given FQDN.  The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation.  If the FQDN starts with a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN.  The CA may prune zero or more labels from left to right until encountering a Base Domain Name and may use any one of the intermediate values for the purpose of domain validation.

This was accepted by consensus.

Wayne also noted that we should make confirming 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 (which has not yet been discussed by the VWG):


  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.
     *   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.

  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.

These changes will be discussed on the Dec. 3 VWG call.

Question 5: This question related to whether Random Values, Test Certificates, and 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, or limited over what period of time it can be used, 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.

The VWG discussed the question first for Random Values, and then for Test Certificates and for Request Tokens.  A number of ideas and themes emerged (but there is no consensus yet on any of these points):


*        Some validation methods are tied to the SLDN domain itself (such as authentication for enterprise accounts where the customer can come back later and request multiple certificates for FQDNs containing the same validated domains over time) and not to a specific certificate request or CSR - validation of SLDN domains by these methods are good for 13 months for EV and 39 months for DV and OV under current rules.  Other validation methods are tied to a specific certificate request or CSR and perhaps the Applicant’s related public key (such as one-off retail orders), and so the validation method may have to be repeated again even for the same FQDN for every subsequent certificate request and/or new public key.  The VWG may have to specify different re-use rules for each method.

*        For Random Values (RVs), it may be ok to use one RV to validate multiple domains in a single certificate request tied to a single public key, but then require the CA to issue a new RV for a subsequent certificate request.  (We did not discuss if a new RV would be needed by a subsequent certificate request using the same public key as in the first request - but allowing this could incentivize Applicants to keep reusing the same key pair for multiple certificates and servers, which is not the best security)

*        For validation methods 2, 3, and 4, the CA should probably be required to issue a new Random Value every time the method is used - for example, in a mail, email, or telephone communication with the domain Registrant, or when included using the automatic email response method.  Once the RV is in an email, it could be picked up and used by a hacker.

*        Some thought a different Random Value should be used for each domain validated, while at least one call participant thought it would be appropriate to use a single Random Value to validate 100 domains submitted at the same time.  (For example, If the email method is used for the 100 domains, and if all the 100 domains have the same Technical Contact listed, kirk@[domain], then it would be acceptable to send a single verification email with a single Random Value to kirk@[domain] listing all 100 domains to be verified, and accept a single response back.)

*        In some circumstances, the CA may not have a strong enough confirmed channel to the ultimate customer to allow subsequent ordering of new certificates for previously validated domains, so re-validation with each order may be necessary.

*        Test Certificates - many of the conclusions above may also apply to Test Certificates.  Test Certificates appear be one of the methods that are related to a specific certificate request, and would need to be repeated for later certificate requests even for the same domains.  The current definition of Test Certificate may need to be amended to require that the Test Certificate include every FQDN in the SANs field being validated to ensure that the Test Certificate will be unique and will be limited to a particular order for particular domains (and so it can’t be reused for validation of different domains at a later time).  Not discussed: should the Test Certificate also contain data from the related public key for the specific order, or a hash of the public key, etc., and not just a list of the domains to be verified.

*        Request Tokens - these are generally a hash of the certificate request’s public key, to be used by the Applicant using one of the “practical demonstration” methods.  Under the current definition, a Request Token is not necessarily sent from the CA to the Applicant, but may simply be generated and used by the Applicant using instructions from the CA.  Request Tokens appear also be one of the methods that are related to a specific certificate request and related public key, and would need to be repeated for later certificate requests.  There was discussion that once the public key is known (and the 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.

*        One person commented that for methods using Test Certificates or Request Tokens (or any other method that is certificate request-based), the methods should be designed so that “if all else fails” then the CA will fall back on the specific public key associated with the order (to prevent imitation or reuse by a hacker).  Perhaps these validation methods need to require explicitly linkage to a specific public key and/or single CSR.  There is still an open question of whether revetting should be required if the same public key is associated with a later certificate request (which may or may not come from the same Applicant) - how should this be handled from a best practices / security engineering standpoint?  Also, if domain verification is token based, we need to make certain it is cryptographically strong.

*        There was discussion of whether a Random Value, Test Certificate, or Request Token should also have an outside time limit for use in case the Applicant is slow to respond or complete authentication (for example, if a Random Value is in an email sent to the Applicant and the Applicant still has not used the Random Value and responded after a week, or if the Applicant submits a certificate request with 100 domains in the SANs field but only uses the Test Certificate or Request Token successfully on 92 domains - how long should a CA wait for the Applicant to complete authentication before the CA must issue a new Random Value, Test Certificate, or Request Token?)  And can a CA rely on the same Random Value, Test Certificate, or Request Token to revalidate the same domain after 13 months (EV) or 39 months (DV or OV)?  (Preliminary comments indicated a new Random Value, Test Certificate, or Request Token should be used for that.)

Question 6 (New) - Applicant/Subscriber versus domain Registrant:

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.

This topic needs further discussion, including an attempt to define if there is a current problem and what the problem is, so we can focus on potential solutions.

I think there is one other pending issue, but I can’t remember it right now.  Anyone?


<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/20151122/3f073789/attachment-0001.html