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

[kirk_hall at trendmicro.com]

So are you suggesting that for Request Tokens, the CA must communicate something directly to the Applicant that goes into the Request Token?
From: Robin Alden [mailto:robin at comodo.com]
Sent: Thursday, December 03, 2015 7:48 AM
To: Kirk Hall (RD-US); validation at cabforum.org
Subject: RE: [cabf_validation] Open Issues for Validation Working Group call on Thurs. Dec. 3

Issue 1: Definition of Request Token
I am not trying to insist that anyone else uses this definition in the validation of their certificates, but
I (within Comodo) do want to be allowed to use a Request Token such as this in preference to a straight ‘Random Value’.

My overriding concerns here are that, for some CAs when dealing with some sales channels, the CA does not have a direct channel of communication with the certificate applicant.
In these cases, anything that the CA sends to the applicant or that the applicant sends to the CA will have passed through the reseller.
The reseller is unaudited, and his computer systems are therefore untrustworthy.
There is a threat that a compromised or inept reseller could substitute the applicant’s public key (perhaps in a CSR) with his own key or a key belonging to a different applicant.
That being the case I want to ensure that during the process of validating domain control I really am proving that the applicant to whom I will issue the certificate controls the domain.
I can achieve that by incorporating the applicant’s public key into the token that I then have the applicant place into the DNS for the domain whose control is to be validated.
Here’s one way to do it:
Request Token = Public Key (from applicant) + Random Value (from CA)
where ‘+’ might indicate concatenation, but might be something more clever.
I want the applicant to be able to construct the request Token himself, so the CA should pass the Random Value to the applicant and tell him how to produce the Request Token from the Random Value supplied by the CA and the applicant’s own public key.
Because the applicant does not pass the Request Token through the reseller before he puts it into the DNS, the reseller could not corrupt it even if he wanted to.
If the Request Token definition were just removed from the proposed rewording I would not be able to use this method to gain my additional protection against a key substitution attack during the certificate provisioning process.
Regards,
Robin

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>
Sent: 01 December 2015 18:59
To: validation at cabforum.org<mailto:validation at cabforum.org>
Subject: [cabf_validation] Open Issues for Validation Working Group call on Thurs. Dec. 3

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".
a.      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"]
b.      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.]
3.      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.





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.




<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/20151203/4b143320/attachment-0001.html