[cabfpub] CNAME-based validation

Wed Sep 14 15:06:44 MST 2016

Thanks Peter and Ryan, 

After discussing internally, Peter’s suggestion would work for us. The proposal is (now):

Add the following definition:

Validation Sub Domain: A Domain Name created directly under an FQDN by appending a Random Value or Request Token as the left-most label of the FQDN.

Add the following as Section 3.2.2.4.11:

Confirming the Applicant’s control over the requested FQDN by:

(1)   Verifying the existence of a Validation Sub Domain of the requested FQDN that includes a pre-appended underscore character;

(2)   Verifying the existence of a second Validation Sub Domain that is under an FQDN verified as owned or under Applicant’s control using one of the methods permitted under Section 3.2.2.4; and

(3)   Verifying that the Validation Sub Domain under (1) has a CNAME record pointing to the second Validation Sub Domain verified under (2)

Any additional comments before I start seeking endorsers?

Jeremy

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

Yes, and I'm saying that's *still* fundamentally problematic :)

+1 to Peter's suggestion - which is spiritually akin to only keeping .12 and not adding .11, which is where the heart of the objections lay.

On Mon, Sep 12, 2016 at 3:11 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

Let me reword that. The intent was to do as previously described

<rnd1>.example.net <http://example.net>  CNAME shop.example.com <http://shop.example.com> 

And <rnd2>.example.net <http://example.net>  does not CNAME to shop.example.com <http://shop.example.com> 

From: Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com> ] 
Sent: Monday, September 12, 2016 4:09 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: [MmmSPAM] Re: [cabfpub] CNAME-based validation

As worded, you're proposing (in .11) to do the thing that was objected to:

<rnd1>.example.net <http://example.net>  CNAME shop.example.com <http://shop.example.com> 

<rnd2>.example.net <http://example.net>  CNAME anothershop.example.com <http://anothershop.example.com> 

And assuming that because shop.example.com <http://shop.example.com>  != anothershop.example.com <http://anothershop.example.com> , this is a positive demonstration of control, when it's not.

This is, in effect, your "do it twice" proposal that I expressed concerns about in the follow-up.

On Mon, Sep 12, 2016 at 3:04 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

Sorry – I thought we resolved those concerns with the second random number? Which concern is still unresolved?

From: Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com> ] 
Sent: Monday, September 12, 2016 3:53 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: [MmmSPAM] Re: [cabfpub] CNAME-based validation

Jeremy,

While you seek endorsers, I will suggest that, as worded, I believe we'd need to vote against this ballot.

I do hope you give consideration to the concerns raised, and why the Random Value in the "thing to be resolved" is going to be problematic for us.

On Mon, Sep 12, 2016 at 2:11 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

Everyone - thanks for your input on this. Here’s the proposed ballot based on the discussion:

Motion Begins:

Add the following definition: 

Validation Sub Domain: A Domain Name created directly under an FQDN by appending a Random Value or Request Token as the left-most label of the FQDN.

DNS Validation Name: A Domain Name created directly under a FQDN by appending “_pki” as the left-most label of the FQDN.

Add the following as Section 3.2.2.4.11:

Confirming the Applicant’s control over the requested FQDN by:

(1)   Creating a Validation Sub Domain of the requested FQDN;

(2)   Verifying creation of a CNAME record for the created Validation Sub Domain that points the Validation Sub Domain to a FQDN verified by the CA using one of methods permitted under Section 3.2.2.4; 

(3)   Creating a second Validation Sub Domain of the Requested FQDN using a Request Token or Random Value that was not used in the first Validation Sub Domain; and

(4)   Verifying that the second Validation Sub Domain does not resolve to the FQDN verified by the CA under step 2.

Add the following as Section 3.2.2.4.12:

Confirming the Applicant’s control over the requested FQDN by:

(1)   Creating a DNS Validation Name of the requested FQDN; 

(2)   Creating a Validation Sub Domain of a Domain Name verified using one of the methods permitted under Section 3.2.2.4;

(3)   Verifying creation of a CNAME record for the DNS Validation Name that points the DNS Validation Name to the Validation Sub Domain.

Looking for comments/endorsers. Thanks!

Jeremy

From: sleevi at google.com <mailto:sleevi at google.com>  [mailto:sleevi at google.com <mailto:sleevi at google.com> ] On Behalf Of Ryan Sleevi
Sent: Thursday, September 8, 2016 4:48 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
Cc: rsleevi at chromium.org <mailto:rsleevi at chromium.org> ; Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com> >; public at cabforum.org <mailto:public at cabforum.org> 
Subject: [MmmSPAM] Re: [cabfpub] CNAME-based validation

On Thu, Sep 8, 2016 at 3:25 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

The one short-coming of this approach over using multiple random values to detect wildcard domains is that the process makes obtaining multiple certificates from different CAs difficult. If a customer wants to use both DigiCert and another CA, the customer would have to order each one in separate intervals as _pki.domain.com <http://pki.domain.com>  can only have a single CNAME record. Using two random values, the customer can have multiple CAs simultaneously issue certificates. 

CA1:

<rnd_CA1>.domain.com <http://domain.com>  CNAME <rnd2_CA1>.validation.com <http://validation.com> 

CA2:

<rnd_CA2>.domain.com <http://domain.com>  CNAME <rnd2_CA2>.validation.com <http://validation.com> 

I think this proposal is different than what I understood your previous proposal to be, and I think it probably resolves the heart of my objection - that the randomness shouldn't be "trusted" if it's in the "name to be resolved", but can be if it's in the "contents of the record" (in this case, the CNAME-pointed to domain).

My understanding is your proposal was

<rnd_CA1>.example.net <http://example.net>  CNAME shop.example.com <http://shop.example.com>   (Notice how I keep using RFC 6761 special-use domains? :P)

Would be seen as authorization to issue for "example.net <http://example.net> " if the CA previously issued for "shop.example.com <http://shop.example.com> ". I don't think that's good, because the <rnd_CA1> can't be taken as positive consent/configuration/control in the presence of Wildcard DNS.

If the proposal is that

<rnd_CA1>.example.net <http://example.net>  CNAME <rnd2_CA1>.shop.example.com <http://shop.example.com> 

Be taken as authorization to issue for example.net <http://example.net>  if the CA has validated shop.example.com <http://shop.example.com> , then I think that'd be OK, and would be curious if anyone spots any risk I'm missing. That's because the <rnd_CA1> is not a "Random Token/Value", but just a "Don't disrupt the service" variation, and the real random value/token is in the contents of the CNAME - specifically, <rnd2_CA1>.

In the case of non-Wildcard DNS, this demonstrates practical control over example.net <http://example.net>  (by creating rnd_CA1)

In the case of Wildcard DNS, this demonstrates practical control at least to the level of the Wildcard DNS rule, because it's statistically unlikely that they would have just 'happened' to chose <rnd2_CA1> as a subdomain, provided that it has sufficient randomness.

To double check my math, a given DNS label (that is, the value of <rnd_CA1 / rnd2_CA2>) is limited to 64 characters, which should be plenty sufficient for a modified Base32-encoding of a minimum 112-bit random value, which would be 24 characters (using perhaps 0/1 as the padding character, since = can't appear due to the LDH rule)

_______________________________________________
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: https://cabforum.org/pipermail/public/attachments/20160914/4a0508fa/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20160914/4a0508fa/attachment-0001.bin 