I think this can get simplified to adding “, CNAME, “ to 3.2.2.4.7. Here is why:
The process you describe could be redescribed as: Confirming the Applicant’s control over the requested FQDN by confirming the presence of a A Domain Name created directly under an FQDN by appending a Random Value or Request Token as the left-most label of the FQDN in a DNS CNAME record for an Authorization Domain Name that is prefixed with Random Value or Request Token includes a pre-appended underscore character. Given this, the current 3.2.2.4.7 fully applies except that it needs to add CNAME to TXT and CAA. Thanks, Peter > On Sep 14, 2016, at 3:06 PM, Jeremy Rowley <[email protected]> wrote: > > 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:[email protected]] > Sent: Monday, September 12, 2016 4:32 PM > To: Jeremy Rowley <[email protected]> > Cc: [email protected] > 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 <[email protected]> > wrote: > Let me reword that. The intent was to do as previously described > <rnd1>.example.net CNAME shop.example.com > And <rnd2>.example.net does not CNAME to shop.example.com > > From: Ryan Sleevi [mailto:[email protected]] > Sent: Monday, September 12, 2016 4:09 PM > To: Jeremy Rowley <[email protected]> > Cc: [email protected] > 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 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 _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
