[cabf_validation] Open Issues for Validation Working Group call on Thurs. Dec. 3, Issue #2

[Doug Beattie]

Here is my input on issue #2 (test certificates).

General info:

*         The certificate issued based on the validation of the test
certificate must have the same public key.

*         The test certificate must have the FQDN values in the SANs which
will be in the final certificate (or at a minimum the associated
Authorization Domain Names)

*         The CA must validate that the test certificate is returned for
each  Authorized Domains associated with the FQDNs which will be in the
final certificate.  In other words, if globalsign.com is in the SAN and the
CA connects to globalsign.com then it can be used to issue
mail.globalsign.com, www. Etc.

Existing definition:

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.

Proposed addition to the definition:

In either case, the Test Certificate must contain SAN values of the FQDN or
the associated Authorization Domain Names and the issued certificate must
contain the same public key as the test certificate.  When using a test
certificate, the date of the "Certificate Data" is deemed to be the
certificate not-before date thus limiting the re-use of this domain
authorization to the limits specified by Age of Validated Data (sections 11.
14.3 in EVGL and 3.3.1 in BRs).



Doug



From: validation-bounces at cabforum.org
[mailto:validation-bounces at cabforum.org] On Behalf Of
kirk_hall at trendmicro.com
Sent: Tuesday, December 1, 2015 1:59 PM
To: 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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20151203/8a9219d7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4289 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20151203/8a9219d7/attachment-0001.bin