[cabfpub] Domain validation proposal update
jeremy.rowley at digicert.com
Sat Jun 20 20:42:09 MST 2015
Hi Peter - responses below:
> Attached is the domain validation proposal draft from the validation
> working group. We hope to discuss this with everyone in Zurich and on
> the mailing list. We look forward to your comments and finalizing this proposal.
I think that the move from "any other" to a closed set of options is good, but I think a few of them as stated are a little too constraining.
I think that the mention of "WHOIS" is out of place in #1. My understanding of the original intent of #1 is that the CA and the Registrar (or Registry) could directly communicate with each other and compare their records. For example, they could confirm that the SAML identity or OAuth/OpenID Connect login information for the domain registrant and certificate applicant is the same. Alternatively the CA/RA and Registrar/Registry could be the same company and be handling domain registration and certificate validation in one transaction; they are very sure that the applicant is the registrant in this case.
[JR] The WHOIS reference was explicitly added to make sure auditors understood that WHOIS was a permitted form of verification under that section.
#3 should have a random value requirement. It seems reasonable to require that the email contain a random value and that value be returned to the CA/RA.
[JR] This was also discussed in the working group. Although that is true for an automated DV process some CAs use a manual process where a return email is required from the email address. A random value would not be necessary in those cases. Although the goal is to tighten the language, we are trying to do so without expressly outlawing any practice currently used, excluding some versions of a practical demonstration of control.
For #5 and #7, "Authorization Domain" should be replaced with "FQDN".
Knowing the applicant can modify content accessible via a HTTP, FTP, SFTP, gopher or other URI that has a host component and path component does not mean that they can modify content on other hosts. For example changing content on "shop.example.com" does not mean one can control "payments.shop.example.com". #7 has a similar issue; a domain registrant may choose to delegate shop.example.com to one company and payments.shop.example.com to another.
[JR] This was also discussed. We ultimately decided that each level has control over the lower level. Although, I wouldn’t mind seeing control limited to either the FQDN or base domain in each case (except wildcards where it should be the Authorization Domain, where Authorization Domain is limited to one level lower than the FQDN).
In #6, it should be called out that the token inserted and verified could be derived from the Random Value provided by the CA, not just the literal Random Value.
[JR] Noted. We will discuss this further during the working group.
Additionally, for #6, there should probably be a limitation that one can only use rely open the validation for the specific name queried if the initial result of the query in a CNAME record. If I'm requesting a certificate for foo.payments.example.com, and payments.example.com returns a CNAME with a canonical name of paycorp.mybigcdn.com, MyBigCDN should not be able to get a certificate for foo.payments.example.com based on their DNS response for paycorp.mybigcdn.com.
[JR] Again, this supports the argument for only permitting verification at the FQND or base domain. We can raise it again in the working group I suppose.
On item #9, requiring that the CA issue the test certificate seems overly constrictive. It should be possible for the CA to provide a random value and the customer include the value in a certificate, potentially even a self-signed certificate.
[JR] We used to have more general language on item #9. However, we decided to limit it to this specific language unless another CA specifically requested an extension to the language based on their current practice.
It is probably also worth noting that a Wildcard name (e.g. "*." +
FQDN) does not qualify as a FQDN for #5, #7, #8, and #9, as there is no reasonable way to do a DNS lookup on a wildcard name.
[JR] True, but this is an argument for why we used the "Authorization Domain" language.
More information about the Public