I think you are talking about two different things. Ryan is concerned that a customer has an existing record that is “*.example.com CNAME vanityblogs.example.net”. If you say “if you can make a record show up at _309654fddb59444d8efd6d2cc98881d5.example.com you are validated” that is bad. Instead, you are proposing a two prong validation test:
1) Confirm control of vanityblogs.example.net. 2) Make _309654fddb59444d8efd6d2cc98881d5.example.com point to vanityblogs.example.net. You are proposing that passing these both would confirm control of example.com, right? And this would allow getting a certificate for shop.example.com, correct? Thanks, Peter > On Sep 2, 2016, at 3:25 PM, Jeremy Rowley <[email protected]> wrote: > > 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: [email protected] [mailto:[email protected]] On > Behalf Of Ryan Sleevi > Sent: Friday, September 2, 2016 4:05 PM > To: Jeremy Rowley <[email protected]> > Cc: [email protected] > 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 and sleevi.example.com may both CNAME to > example.com, by virtue of of the host putting a rule of "*.example.com 3600 > CNAME 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 > <rnd>.example.com points to example.com > CA sees it previously issued a certificate for example.com using one of the > other methods > CA issues certificate for <rnd>.example.com > > That concerns me. > > Peter's rewording suggests the inverse: > CA looks up _certvalidation.example.com > _certvalidation.example.com points (CNAMEs) to <rnd>.validation.[nameofca].com > CA issues certificate for 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 <[email protected]> > wrote: > Wildcard domains are already allowed. We can verify Wildcard DNS because a > CNAME for *.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>.domain.com isn’t necessarily distinguishable > from *.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: > > *.domain.com -> dcv.example.com (validated under the Authorized Domain Name > section) > <rnd>.domain.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:[email protected]] > Sent: Friday, September 2, 2016 3:28 PM > To: Jeremy Rowley <[email protected]> > Cc: [email protected] > Subject: Re: [cabfpub] CNAME-based validation > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
