[cabfpub] Domain validation
doug.beattie at globalsign.com
Thu Apr 16 10:31:00 MST 2015
I have a few comments and recommendation for this ballot:
Item 1: Change the section name.
The current section name is "Authorization by Domain Name Registrant", but this section defines more than this one authorization method. I suggest naming it as "Domain Control Validation", or something similar.
Item 2: Inconsistent definition of the "FQDN, Base Domain or any other domains" that can be used to validate domain control validation.
When validating a FQDN of a.b.c.d.example.com we need to clearly identify where emails can be sent, where ".well-known" directories can be located, which CNAME records can be updated, etc.
- Is c.d.example.com allowed for some/all options?
- What about example.com, for some but not all options?
The definitions in the various options are inconsistent and we should take the opportunity to clean this up.
- If only the FQDN or the Base Domain can be used, we need to specify that
- If anything between the FQDN and the Base Domain can be used, we need to specify that.
- We should specify which domains can be used for a wildcard FQDN (strip off the "*." and treat that as the FQDN)
I recommend we define a new term and we use that throughout the list of Domain Control Validation methods.
Authorized Domains: The FQDN, the Base Domain, or any FQDN in-between these two values. For the purpose of verifying a wildcard FQDN, the CA MUST remove the leading wildcard character and period and treat the remaining as a FQDN.
Item 3: In Item 5, I suggest including the entire definition of "Domain Authorization Document" right in the list vs. referencing a short paragraph that defines Domain Authorization Document later in the section (ease of reading and to make this option clear and standalone)
Item 4: In the "Note" about FQDNs, we say :
- "FQDNs may be listed in Subscriber Certificates using dNSNames in the subjectAltName extension or..."
Even though the CommonName is depreciated and the value in the CommonName needs to be in the SAN, should we explicitly call out CommonName as a location for FQDNs?
- FQDNs may be listed in Subscriber Certificates in the Common Name field of the Subject DN, using dNSNames in the subjectAltName extension or..."
Item 5: Domain Authorization Document
The paragraph about the Domain Authorization Document section says:
- 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.
Item (i) implies you cannot get a Domain Authorization Document to validate a domain and then enter it into a managed SSL offering and allow customers to request and receive certificates against this pre-vetted domain. I might not be interpreting this correctly though. Does this document need to be dated AFTER the certificate request, and if so, what is the reason for that? One would think that this could be done once and then re-used for 39 months like the other "Certificate Data" for all subsequent Certificate Requests.
As far as item (ii), do we need to verify that the WHOIS record has not been modified since the previous certificate's request? Again, I would assume that if you collected a set of "Certificate Data" at a point in time, you should be able to use it for 39 months without going back to check WHOIS for each certificate request you process for that domain. I also assume you need a new Domain Authorization Document every 39 months (more frequently for EV)
Item 6: gTLDs
Some companies have registered their own new TLDs, like BMW. Assuming this is owned and managed by one company (vs. .email or similar generic values), can this be considered the Base Domain? We should spell out that this is allowed. Something along the lines of: Domain Control Validation of a TLD may be used to demonstrate control over all lower level domains if and only if the owner of the TLD is the only entity registering DNS entries and they they will be used exclusively for "their" FQDNs.
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Wednesday, April 15, 2015 7:29 PM
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...
More information about the Public