[cabfpub] Domain validation

Thu Apr 16 15:58:48 UTC 2015

Hi Jeremy, all,

                My proposed amendment has two parts.

1)      An alternative to using a 'Random Value' for the practical
demonstrations of control.

2)      Specifying the use of a 'Random Value' for (at least) the email
methods.

1) Using a 'Random Value' in sub-sections 6, 7, and 10 is a good way to
ensure that the practical demonstration of control is related to this
particular certificate request.  I don't propose removing that as an option
because it is a good idea.  
We think, however, that Comodo's current technique is superior to the Random
Value for sections 6, 7, and 10 and would like to see it permitted as an
alternative.  

We generate a token from the CSR and we have the applicant put that token in
place in a file (6) or in a DNS record (7) or to be returned as part of a
TLS response (10).

The token must strongly be cryptographically related to the subscribers
public key, and we use a concatenation of the output of two different hash
algorithms to ensure that is the case.  I'm sure there are other ways to
generate the tokens which are also perfectly adequate.

The advantage of our technique in using a token derived from the
subscriber's key instead of a Random Value is that any change in the key to
be included in the certificate during the certificate application process
implicitly requires that the demonstration of practical control be repeated.

That follows because if the key to be certified is changed the token will
change and the CA would be required to verify the token before issuance (for
6, 7, and 10).

Why should we consider the repetition of a practical demonstration of
control upon a subscriber key change to be beneficial?
During the certificate application process a CA may allow the subscriber to
provide a changed key (new CSR).  
While a diligent CA may already require that an application be restarted
from scratch when a new key is provided, it is not crystal clear in the BRs
that that must be the case.  A less diligent CA might leave itself open to a
spoofed inbound email, perhaps combined with a social engineering phonecall,
to have the CA accept a replacement key from the attacker masquerading as
the applicant.  Such an attack, if successful, could cause the CA to issue a
certificate for the genuine applicant's domain but using the attacker's
public key.  That gives the attacker a window of opportunity to MITM or
otherwise impersonate the applicant until the error is discovered (which it
is likely to be since the issued certificate will not 'work' for the genuine
applicant) and revoked (which may or may not happen if the cause of the
certificate's not 'working' for the subscriber is wrongly attributed to
subscriber error instead of attack).

2) The methods described in sub-sections 2 and 4 are the common means by
which authorization for issuance may be confirmed by email.  Since these are
both simple email challenge/response methods we feel that the use of a
'Random Value' should also be required in these sub-sections.  
We'd also like to see it required for any of the confirmation relying on a
Reliable Method of Communication, but we can see that reading out 128 bits
of entropy over the phone may be burdensome.

I've attempted to include Gerv's changes too.  The Base Domain doesn't
completely cover the wording in the note at the end, since that deals with
different behaviour for CCtlds.

Should we have a visible place-holder for the now absent sub-section 3?

Regards
Robin Alden
Comodo

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Jeremy Rowley
Sent: 15 April 2015 19:29
To: public at cabforum.org
Subject: [cabfpub] Domain validation

With removal of the opinion letters, I think this is ready for a ballot. Are
there two endorsers?

Amendment to Section 11.1.1 of CA/Browser Forum Baseline Requirements to
clarify acceptable methods of validating domain control:

1)     Add the following definitions: 

Base Domain: The portion of an applied-for FQDN that is the first domain
name node left of a registry-controlled or public suffix plus the
registry-controlled or public suffix (e.g. "domain.co.uk" or "domain.com").

Random Value: A value specified by a CA to the Applicant that exhibits 128
bits of entropy.

2)     Section 11.1.1 of the CA/Browser Forum's Baseline Requirements is
amended as follows:

.

11.1.1     Authorization by Domain Name Registrant

For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL
confirm that, as of the date the Certificate was issued, the Applicant
either is the Domain Name Registrant or has control over the FQDN by: 

1.   Confirming the Applicant as the Domain Name Registrant directly with
the Domain Name Registrar through a Reliable Method of Communication, for
example using information provided through WHOIS; or

2.   Confirming authorization of the Certificate's issuance directly with
the Domain Name Registrant using  a Reliable Method of Communication that is
(i) obtained from the Domain Name Registrar or (ii) listed as the
"registrant", "technical", or "administrative" contact for the WHOIS record
of the Base Domain; or 

4.   Confirming authorization for the Certificate's issuance through an
email address created by pre-pending 'admin', 'administrator', 'webmaster',
'hostmaster', or 'postmaster' in the local part, followed by the at-sign
("@"), followed by the Domain Name, which may be formed by pruning zero or
more components from the requested FQDN; or

5.   Relying upon a Domain Authorization Document that meets the
requirements listed below; or

6.   Having the Applicant demonstrate control over the FQDN or Base Domain
by adding a file containing a Random Value to  the
"/.well-known/certificate" directory at either the FQDN or the Base Domain
in accordance with RFC 5785; or

7.   Having the Applicant demonstrate control over the FQDN or Base Domain
by the Applicant making a change to information in a DNS record for the FQDN
or Base Domain where the change is a Random Value; or

8.   Having the Applicant demonstrate control over the requested FQDN by the
CA confirming, in accordance with section 11.1.1, the Applicant's controls
the FQDN (or Base Domain of the FQDN) returned from a DNS lookup for CNAME
records for the requested FQDN; or

9.   Having the Applicant demonstrate control over the requested FQDN by the
CA confirming, in accordance with section 11.1.2, that the Applicant
controls an IP address returned from a DNS lookup for A or AAAA records for
the requested FQDN; or

10. Having the Applicant demonstrate control over the FQDN by providing a
TLS service on a host found in DNS for the FQDN and having the CA (i)
initiate a TLS connection with the host and (ii) verify a Random Value that
is a in a format recognized as a valid TLS response.

Note: For purposes of determining the appropriate domain name level or
Domain Namespace, the registerable Domain Name is the second-level domain
for generic top-level domains (gTLD) such as .com, .net, or .org, or, if the
Fully Qualified Domain Name contains a 2 letter Country Code Top-Level
Domain (ccTLD), then the domain level is whatever is allowed for
registration according to the rules of that ccTLD. If the CA relies upon a
Domain Authorization Document to confirm the Applicant's control over a
FQDN, then the Domain Authorization Document MUST substantiate that the
communication came from either the Domain Name Registrant (including any
private, anonymous, or proxy registration service) or the Domain Name
Registrar listed in the WHOIS. The CA MUST verify that the Domain
Authorization Document was either (i) dated on or after the certificate
request date or (ii) used by the CA to verify a previously issued
certificate and that the Domain Name's WHOIS record has not been modified
since the previous certificate's issuance.

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

Note: For the purpose of verifying a wildcard FQDN, the CA MUST verify
either the Base Domain of the wildcard FQDN or the entire Domain Name Label
to the right of the wildcard character. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150416/9a14e85b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Domain Validation Ballot Clean Robin 150416a.pdf
Type: application/pdf
Size: 160733 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150416/9a14e85b/attachment-0006.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Domain Validation Ballot Redline Robin 150416a.pdf
Type: application/pdf
Size: 161106 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150416/9a14e85b/attachment-0007.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5776 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150416/9a14e85b/attachment-0001.p7s>