[cabfpub] CNAME-based validation

[Jeremy Rowley]

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 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 CNAME <rnd2_CA1>.validation.com

CA2:

<rnd_CA2>.domain.com CNAME <rnd2_CA2>.validation.com



Whereas

If CA1 issues under:

_pki.domain.com CNAME <rnd2_CA1>.validation.com

CA2 cannot do the same thing at the same time:

_pki.domain.com CNAME <rnd2_CA2>.validation.com







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







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

I suppose that would work for us but wouldn't there be the same concern with 
_pki and wildcard domains.


Why not permit both validation methods?



Because a Wildcard DNS is statistically unlikely to be CNAME'd to <random 
token>.anything, while Wildcard DNS implies a significantly greater 
probability that <random>.anything will CNAME to <fixed string>



The former - using _pki.[something] to CNAME to <random>.[something] - is 
robust in the presence of Wildcard DNS, and still ensures the critical 
property desired by <random> - that it's unlikely to happen except through a 
demonstration of control.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160908/d46d76b9/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/d46d76b9/attachment-0001.p7s>