[cabfpub] Domain validation proposal update

[Doug Beattie]

Hi Peter and Jeremy,

Regarding #5 and #7 and the use of Authorized Domain, FQDN or Base Domain:

Here’s an example for using Authorizeed domain:  Customer wants CA to verify us.domain.com because the US division is managed differently than their global domain.com.  Once this domain is validated and associated with the account, the CA will allow them to order <anything>.<anything>.us.domain.com.  

If we only allow FQDN, then it will not be possible to pre-validate any domains (i.e., you cannot validate ownership/control of domain.com ahead of time and allow issuance of any certificates against it)

If we allow only FQDN and Base domain (domain.com), then the above would not be supported (us.domain.com)

I recommend the continued use of Authorized Domain for these 2 methods.

Doug

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Jeremy Rowley
> Sent: Sunday, June 21, 2015 4:42 AM
> To: Peter Bowen
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Domain validation proposal update
> 
> 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.
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public