[cabfpub] CNAME-based validation

[Jeremy Rowley]

We are talking about the same thing (wildcard DNS records). 

 

Examples:

 

sleevi.example.com CNAME vdomain.com

*.example.com CNAME vdomain.com

<rnd>.example.com CNAME vdomain.com

 

The BRs permit verification of each of these by establishing control over vdomain.com (under the definition of authorization domain name). 

 

If *.example.com can be verified this way, what is different between verifying *.example.com and <rnd>.example.com to verify all sub domains of example.com? All the RND does is make it so the website doesn’t have to point to vdomain.com.

 

Jeremy

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Friday, September 2, 2016 4:05 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: public at cabforum.org
Subject: Re: [cabfpub] CNAME-based validation

 

Jeremy,

 

Perhaps it wasn't clear, I wasn't speaking of wildcard certificates, but wildcard DNS rules, in which all requests for a given subdomain return a preconfigured record type. While for TXT and CAA records this is quite uncommon, it's exceedingly common to have CNAME records.

 

That is, both <rnd>.example.com <http://example.com>  and sleevi.example.com <http://sleevi.example.com>  may both CNAME to example.com <http://example.com> , by virtue of of the host putting a rule of "*.example.com <http://example.com>  3600 CNAME example.com <http://example.com> "

 

I am attempting to assert that placing the <rnd> in the subdomain is insufficient proof of authorization, and is meaningfully and tangibly different than the proof of control demonstrated in 3.2.2.4.7.

 

As I read your wording, it suggests the following:

CA looks up <rnd>.example.com <http://example.com> 

<rnd>.example.com <http://example.com>  points to example.com <http://example.com> 

CA sees it previously issued a certificate for example.com <http://example.com>  using one of the other methods

CA issues certificate for <rnd>.example.com <http://example.com> 

 

That concerns me.

 

Peter's rewording suggests the inverse:

CA looks up _certvalidation.example.com <http://certvalidation.example.com> 

_certvalidation.example.com <http://certvalidation.example.com>  points (CNAMEs) to <rnd>.validation.[nameofca].com

CA issues certificate for example.com <http://example.com> 

 

This is much less concerning.

 

Could you help clarify which you intend, and for what names/purposes?

 

 

On Fri, Sep 2, 2016 at 2:52 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

Wildcard domains are already allowed. We can verify Wildcard DNS because a CNAME for *. <http://domain.com> domain.com is pointing to a record previously verified. This verification method is permitted under the definition of Authorization Domain Name (where the FQDN returned by a CNAME lookup can be used to verify the requested FQDN). Although <rnd>. <http://domain.com> domain.com isn’t necessarily distinguishable from *. <http://domain.com> domain.com, the validation ends up being the same because either its considered an Authorized Domain Name (under the definition) or it was validated as a random value in this new method. 

 

For example:

 

*. <http://domain.com> domain.com ->  <http://dcv.example.com> dcv.example.com (validated under the Authorized Domain Name section)

<rnd>. <http://domain.com> domain.com -> <http://validation.example.com> validation.example.com (validated under this new section)

 

Because each is validated properly, tracking which exact section was used in the validation isn’t necessary.

 

Jeremy

 

From: Ryan Sleevi [mailto: <mailto:sleevi at google.com> sleevi at google.com] 
Sent: Friday, September 2, 2016 3:28 PM
To: Jeremy Rowley < <mailto:jeremy.rowley at digicert.com> jeremy.rowley at digicert.com>
Cc:  <mailto:public at cabforum.org> public at cabforum.org
Subject: Re: [cabfpub] CNAME-based validation

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160902/bf94763a/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160902/bf94763a/attachment-0001.p7s>