Are you suggesting _pki.shop.example.com CNAME <rnd>.cnameauth.digicert.com would be used to validate shop.example.com?
From: Kane York [mailto:[email protected]] Sent: Thursday, September 8, 2016 8:32 AM To: Jeremy Rowley <[email protected]>; Peter Bowen <[email protected]> Cc: [email protected]; Ryan Sleevi <[email protected]> Subject: Re: [cabfpub] CNAME-based validation I think it would be more secure, but without compromising functionality, to point _pki.shop.example.com <http://pki.shop.example.com> CNAME <Random Value>.cnameauth.digicert.com <http://cnameauth.digicert.com> ... , just like how a TXT record validation sets the text to a Random Value. (Using the BR's definition of Random Value here.) On Wed, Sep 7, 2016, 10:20 PM Jeremy Rowley <[email protected] <mailto:[email protected]> > wrote: Not really. No one wants to point their site to a different domain. I'm hoping we can do something where there's a set process for showing control over the domain (such as by creating sub-domains) to validate certificate issuance. Pointing <rnd>.shop.example.com <http://shop.example.com> to digicert.com <http://digicert.com> is a whole lot better for customers than pointing shop.example.com <http://shop.example.com> . -----Original Message----- From: Peter Bowen [mailto:[email protected] <mailto:[email protected]> ] Sent: Wednesday, September 7, 2016 12:51 PM To: Jeremy Rowley <[email protected] <mailto:[email protected]> > Cc: Ryan Sleevi <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: Re: [cabfpub] CNAME-based validation Jeremy, It seems that there are two different discussions here that are getting conflated. The first is allowing someone to confirm control of a standard domain by using a CNAME record instead of a TXT record. The process would be very similar: prepend a defined string to the domain and set the canonical name to something containing a random value. The second is authentication with one level of indirection. I think that is already mostly covered as the Authorization Domain Name can be the result of dereferencing a CNAME pointer. So if you have: shop.example.com <http://shop.example.com> IN CNAME webstorehosting.webpki.com <http://webstorehosting.webpki.com> . You can run the validation for webstorehosting.webpki.com <http://webstorehosting.webpki.com> using constructed email to domain contact, agreed-upon change to a website, DNS change, test certificate or TLS using random number. If this passes, then shop.example.com <http://shop.example.com> is validated. Does that not solve your issue? Thansk, Peter > On Sep 6, 2016, at 5:07 PM, Jeremy Rowley <[email protected] > <mailto:[email protected]> > wrote: > > Hi Ryan, > > Pardon my DNS ignorance, but how does the server know which CNAME record to > use in this case? If shop.domain.comCNAMEs to digicert.com > <http://digicert.com> and *.domain.com <http://domain.com> CNAMEs to > google.com <http://google.com> , then how do you know which will resolve? > There isn’t a weight/ordering preference for CNAME like there is TXT records. > > As for how to resolve this, what if the CA generated two random numbers, > holding one of the numbers in reserve. Immediately after verifying that > <rnd1>.domain.com <http://domain.com> CNAME points to a validated domain, > the CA can then check <rnd2>.domain.com <http://domain.com> to see if it > resolves. If it resolves successfully, a wildcard DNS is in place and the > domain is not validated. If the domain does not resolve, a wildcard DNS is > not present and the domain is considered validated. Does this resolve your > concern? > > Jeremy > > From: Ryan Sleevi [mailto:[email protected] <mailto:[email protected]> ] > Sent: Friday, September 2, 2016 7:40 PM > To: Jeremy Rowley <[email protected] > <mailto:[email protected]> > > Cc: Peter Bowen <[email protected] <mailto:[email protected]> >; [email protected] > <mailto:[email protected]> > Subject: Re: [cabfpub] CNAME-based validation > > Hi Jeremy, > > I'm afraid you may have misread my example. > > shop.example.com <http://shop.example.com> is a CNAME to > paymentprovider.example.org <http://paymentprovider.example.org> (curse our > lack of distinct TLDs). It does not resolve to example.net > <http://example.net> > > On Fri, Sep 2, 2016 at 6:29 PM, Jeremy Rowley <[email protected] > <mailto:[email protected]> > wrote: > Here’s the steps: > 1) CA verifies example.net <http://example.net> using any one of the > methods permitted > > 2) CA receives request for shop.example.com <http://shop.example.com> > > 3) CA retrieves CNAME for shop.example.com <http://shop.example.com> > (permitted under Authorization Domain Name definition: “The CA may use the > FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain > validation”) > > 4) CNAME causes resolution to example.net <http://example.net> . > > 5) Example.net is verified under step 1, permitting issuance of the > certificate > > > > > > > From: Ryan Sleevi [mailto:[email protected] <mailto:[email protected]> ] > Sent: Friday, September 2, 2016 5:12 PM > To: Jeremy Rowley <[email protected] > <mailto:[email protected]> > > Cc: Peter Bowen <[email protected] <mailto:[email protected]> >; [email protected] > <mailto:[email protected]> > > Subject: Re: [cabfpub] CNAME-based validation > > Right, and I'm not sure that (2) sufficiently establishes that example.com > <http://example.com> is authorizing the request, given wildcards. > > I think this would be a similar concern with, say, following HTTP open > redirects and saying a "200 OK" code authorizes the request - wellllll, not > really. > > I'm curious if you could expand more why you believe other methods would > permit a cert to be issued in the presence of this Wildcard DNS. > > As a concrete example: > example.com <http://example.com> A [my host] > *.example.com <http://example.com> CNAME example.net <http://example.net> > shop.example.com <http://shop.example.com> CNAME paymentprovider.example.org > <http://paymentprovider.example.org> > > Under this scenario, could you explain what ways that the [<rnd>.example.com > <http://example.com> ] would be able to issue a cert for either example.com > <http://example.com> or shop.example.com <http://shop.example.com> ? > Perhaps I'm just missing the implications of the existing validation methods. > > > > > On Fri, Sep 2, 2016 at 3:33 PM, Jeremy Rowley <[email protected] > <mailto:[email protected]> > wrote: > Yes. Those are the two steps I am proposing. > > -----Original Message----- > From: Peter Bowen [mailto:[email protected] <mailto:[email protected]> ] > Sent: Friday, September 2, 2016 4:31 PM > To: Jeremy Rowley <[email protected] > <mailto:[email protected]> > > Cc: Ryan Sleevi <[email protected] <mailto:[email protected]> >; > [email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] CNAME-based validation > > I think you are talking about two different things. > > Ryan is concerned that a customer has an existing record that is > “*.example.com <http://example.com> CNAME vanityblogs.example.net > <http://vanityblogs.example.net> ”. If you say “if you can make a record > show up at _309654fddb59444d8efd6d2cc98881d5.example.com > <http://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 > <http://vanityblogs.example.net> . > 2) Make _309654fddb59444d8efd6d2cc98881d5.example.com > <http://309654fddb59444d8efd6d2cc98881d5.example.com> point to > vanityblogs.example.net <http://vanityblogs.example.net> . > > You are proposing that passing these both would confirm control of > example.com <http://example.com> , right? And this would allow getting a > certificate for shop.example.com <http://shop.example.com> , correct? > > Thanks, > Peter > > > On Sep 2, 2016, at 3:25 PM, Jeremy Rowley <[email protected] > > <mailto:[email protected]> > wrote: > > > > We are talking about the same thing (wildcard DNS records). > > > > Examples: > > > > sleevi.example.com <http://sleevi.example.com> CNAME vdomain.com > > <http://vdomain.com> *.example.com <http://example.com> CNAME vdomain.com > > <http://vdomain.com> > > <rnd>.example.com <http://example.com> CNAME vdomain.com > > <http://vdomain.com> > > > > The BRs permit verification of each of these by establishing control over > > vdomain.com <http://vdomain.com> (under the definition of authorization > > domain name). > > > > If *.example.com <http://example.com> can be verified this way, what is > > different between verifying *.example.com <http://example.com> and > > <rnd>.example.com <http://example.com> to verify all sub domains of > > example.com <http://example.com> ? All the RND does is make it so the > > website doesn’t have to point to vdomain.com <http://vdomain.com> . > > > > Jeremy > > > > From: [email protected] <mailto:[email protected]> > > [mailto:[email protected] <mailto:[email protected]> ] > > On Behalf Of Ryan Sleevi > > Sent: Friday, September 2, 2016 4:05 PM > > To: Jeremy Rowley <[email protected] > > <mailto:[email protected]> > > > Cc: [email protected] <mailto:[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 <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 <[email protected] > > <mailto:[email protected]> > wrote: > > Wildcard domains are already allowed. We can verify Wildcard DNS because a > > CNAME for *.domain.com <http://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 > > <http://domain.com> isn’t necessarily distinguishable from *.domain.com > > <http://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 <http://domain.com> -> dcv.example.com > > <http://dcv.example.com> (validated under the Authorized > > Domain Name section) <rnd>.domain.com <http://domain.com> > > ->validation.example.com <http://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] <mailto:[email protected]> ] > > Sent: Friday, September 2, 2016 3:28 PM > > To: Jeremy Rowley <[email protected] > > <mailto:[email protected]> > > > Cc: [email protected] <mailto:[email protected]> > > Subject: Re: [cabfpub] CNAME-based validation > > > > > > _______________________________________________ > > Public mailing list > > [email protected] <mailto:[email protected]> > > https://cabforum.org/mailman/listinfo/public > _______________________________________________ Public mailing list [email protected] <mailto:[email protected]> https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
