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: [email protected] [mailto:[email protected]] On Behalf Of Ryan Sleevi
Sent: Thursday, September 8, 2016 4:48 PM
To: Jeremy Rowley <[email protected]>
Cc: [email protected]; Peter Bowen <[email protected]>; [email protected]
Subject: [MmmSPAM] Re: [cabfpub] CNAME-based validation

 

 

 

On Thu, Sep 8, 2016 at 3:25 PM, Jeremy Rowley <[email protected] 
<mailto:[email protected]> > 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)

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to