[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Wayne Thayer]

On Mon, Mar 19, 2018 at 6:25 PM, Peter Bowen <pzb at amzn.com> wrote:

>
>
> On Mar 19, 2018, at 4:44 PM, Wayne Thayer <wthayer at mozilla.com> wrote:
>
> On Mon, Mar 19, 2018 at 9:16 AM, Peter Bowen via Validation <
> validation at cabforum.org> wrote:
>
>> On Mar 17, 2018, at 7:43 AM, Ryan Sleevi <sleevi at google.com> wrote:
>>
>>>
>>> Consider the use of .7, in which we already permit (by virtue of CNAME)
>> an expression of delegation to a separate entity via DNS.
>>
>> From my understanding of the problem, this may be a solution that works
> for everyone. Is it correct that under the existing .7, a CA could instruct
> their customer to create a DNS CNAME in the 'example.com' zone for '_www'
> that points to a DNS record controlled by the CA (e.g. '
> account1234.validation.megaca.com'), then perform .7 domain validation in
> perpetuity for 'www.example.com' without any interaction from the DN
> Registrant?
>
>
> I think that would be allowed, but haven’t thought through all the
> implications of it being the CA itself.  I’ve only seen it used with CDNs
> and other delegation.
>
> If the entire concern is that the respondant in WHOIS is not the PKI
>> approver (preventing .2 and .3), and that the domain operator "for reasons"
>> cannot configure one of the mailboxes (.4), would the expression of a
>> domain record that allowed for a designated approver suffice? This could be
>> established for all new/additional domains, can be verified technically,
>> can be checked, and is "no worse" than setting a mailbox under .2/.4 or a
>> CNAME under .7 to delegate to a PKI approver. Does this meet the needs?
>>
>> My example above doesn't work for the Base Domain, so this makes sense.
> What would this special domain record contain?
>
>
> Your example above does work for a registered domain.  For example, given
> two records:
>
> _pki-validation.example.com. IN CNAME a852f14a-1bb5-4ab4-90
> 50-7929605844ee.domainvalidation.acmecorpcdn.com.
>
> a852f14a-1bb5-4ab4-9050-7929605844ee.domainvalidation.acmecorpcdn.com. IN
> TXT 9b3d28ae4a6a4410bab518acc6cbbe21
>
> That could be used to validate the whole example.com namespace.  The
> characters between “_” and “.” can be any valid DNS label and do not matter.
>
> Ah, yes. I missed that an **entire label** beginning with underscore could
prefix the Authorization Domain Name. So now I really wonder if CAs could
use this today to replace method #1?

Or consider during the F2F, there was a discussion of expanding .12 in a
>> way that the DNS Owner could put in a "challenge token" (of sorts) into
>> WHOIS, which allowed them to uniquely and unambiguously link back to the
>> notion of a CA account. Would such a link - in which the CA validated the
>> existence (under the proposed ".13" rules, to be fleshed out) of this
>> random token - suitably replace the need to do an organization-identity
>> link? I think so.
>>
>> However, if the proposal of the .1 supporters is that they should not
>> have to consult DNS to verify an explicit authorization to delegate - such
>> as a DNS record or (additional) WHOIS configuration - and instead rely on
>> the mere existence of information that ICANN requires of domain holders -
>> then that will remain unacceptable, as it's a fundamentally weak
>> proposition.
>>
>> I agree that an explicit authorization (similar to the approach proposed
> to "fix" .9 and .10) is much better, and I also question how useful an
> implicit but unambiguous WHOIS record match is outside of specific ccTLDs
> like the .no example we keep tossing around.
>
> These are both things worth introducing to the BRs and seeing if they meet
>> needs.
>>
>> If my understanding of the proposal above is in the ballpark, then the
> combination of these two with the new .12 seem to cover most of what was
> lost with #1. What do CAs who've been using .1 think?
>
> We should be biased towards including more validation methods in the BRs
>> if they meet the bar for security, rather than trying to limit the number
>> of options.  The BRs are very different from IETF RFCs as they are
>> mandatory and validation methods are a closed set, so we cannot reasonably
>> say “at least two independent interoperable implementations” as we likely
>> won’t even have the first implementation of a method until well after a
>> method is approved.
>>
>> I put text forward for the .13 method in another email.  I hope that we
>> can get it to a ballot soon so we can start to try it i the real world.  I
>> also think DNS discovery of delegation of approval that you propose seems
>> like a good path; it has the potential to allow delegation via multiple
>> protocols via URI, which could offer a number of opportunities to improve
>> the system.
>>
>> Thanks,
>> Peter
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180319/e38f3e96/attachment.html>