[cabfpub] CNAME-based validation
Jeremy Rowley
jeremy.rowley at digicert.com
Thu Sep 8 16:37:41 UTC 2016
Are you suggesting _pki.shop.example.com CNAME <rnd>.cnameauth.digicert.com would be used to validate shop.example.com?
From: Kane York [mailto:kanepyork at gmail.com]
Sent: Thursday, September 8, 2016 8:32 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com>; Peter Bowen <pzb at amzn.com>
Cc: public at cabforum.org; Ryan Sleevi <rsleevi at chromium.org>
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 <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > 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:pzb at amzn.com <mailto:pzb at amzn.com> ]
Sent: Wednesday, September 7, 2016 12:51 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
Cc: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >; public at cabforum.org <mailto:public at cabforum.org>
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 <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > 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:sleevi at google.com <mailto:sleevi at google.com> ]
> Sent: Friday, September 2, 2016 7:40 PM
> To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
> Cc: Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com> >; public at cabforum.org <mailto:public at cabforum.org>
> 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 <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > 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:sleevi at google.com <mailto:sleevi at google.com> ]
> Sent: Friday, September 2, 2016 5:12 PM
> To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
> Cc: Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com> >; public at cabforum.org <mailto:public at cabforum.org>
>
> 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 <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:
> Yes. Those are the two steps I am proposing.
>
> -----Original Message-----
> From: Peter Bowen [mailto:pzb at amzn.com <mailto:pzb at amzn.com> ]
> Sent: Friday, September 2, 2016 4:31 PM
> To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
> Cc: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >; public at cabforum.org <mailto:public at cabforum.org>
> 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 <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > 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: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>
> > [mailto: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 <mailto:jeremy.rowley at digicert.com> >
> > Cc: public at cabforum.org <mailto: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 *.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:sleevi at google.com <mailto:sleevi at google.com> ]
> > Sent: Friday, September 2, 2016 3:28 PM
> > To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
> > Cc: public at cabforum.org <mailto:public at cabforum.org>
> > Subject: Re: [cabfpub] CNAME-based validation
> >
> >
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org <mailto:Public at cabforum.org>
> > https://cabforum.org/mailman/listinfo/public
>
_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160908/07f0ff78/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/20160908/07f0ff78/attachment-0001.p7s>
More information about the Public
mailing list