[cabfpub] [MmmSPAM] Re: CNAME-based validation

[Ryan Sleevi]

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

<rnd1>.example.net CNAME shop.example.com
<rnd2>.example.net CNAME anothershop.example.com

And assuming that because shop.example.com != 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>
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]
> *Sent:* Monday, September 12, 2016 3:53 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* 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>
> 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] *On Behalf Of *Ryan
> Sleevi
> *Sent:* Thursday, September 8, 2016 4:48 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* rsleevi at chromium.org; Peter Bowen <pzb at amzn.com>;
> 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>
> 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 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
>
>
>
>
>
> 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 CNAME shop.example.com  (Notice how I keep using
> RFC 6761 special-use domains? :P)
>
>
>
> Would be seen as authorization to issue for "example.net" if the CA
> previously issued for "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 CNAME <rnd2_CA1>.shop.example.com
>
>
>
> Be taken as authorization to issue for example.net if the CA has
> validated 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 (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
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160912/3a6f43f6/attachment.html