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 <[email protected]> wrote: > Sorry – I thought we resolved those concerns with the second random > number? Which concern is still unresolved? > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Monday, September 12, 2016 3:53 PM > *To:* Jeremy Rowley <[email protected]> > *Cc:* [email protected] > > *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 <[email protected]> > 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:* [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]> > 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 > [email protected] > https://cabforum.org/mailman/listinfo/public > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
