[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

On Fri, Mar 16, 2018 at 2:27 PM, Peter Bowen <pzb at amzn.com> wrote:
>
> The argument for this goes that, since you know it's Identity I, any
> statement they make about Domain Y should logically be able to extend to
> Domain Z or Domain W, or Public Key X or Public Key F or any other sort of
> dimension, since you're assuming that this Identity I == Applicant-Attacker
> X, for any/all domains. The old model was that this presumption was given
> by default - 3.2.2.4.1. Under the today's model, it's not possible - you
> have to validate a binding of Domain Y and Domain Z and Domain W
> "separately", as they're requested. Under this new model, the argument is
> being made that the domain holder should be able to "opt-in" to skip
> validation for Domain Z and Domain W, based on a WHOIS match, once they've
> validated Domain Y. I'm sure the advocates might not call it "skipping"
> validation so much as "introducing alternative validation", but such
> alternative validation is the semantic equivalent to alternative facts - a
> problematic renaming that hides the fact that you are, in fact, skipping an
> explicit check for Domain Z and Domain W, on the basis of (at the time of
> validation for Z/W) an unrelated Domain Y.
>
>
> I disagree that it is skipping or introducing alternative validation.  A
> public TLS certificate requires that the Applicant demonstrate one of the
> following three things:
>
> 1) Control over hosts accessible at the exact FQDN in the certificate
> (test certificates, website changes, etc)
>
> 2) Control over a DNS namespace that is equal to or a superset of the FQDN
> or Wildcard Name (DNS change)
>
> 3) That an accepted controller for the DNS namespace (“owner”,
> “registrant”, “technical contact”, role, et al) has authorized the issuance
>
> It is this third option that is the root of the discussion at hand.
> Natural persons can either take an action themselves or to delegate their
> authority to another — for example, they can issue a power of attorney that
> allows a different person to act in their place.  Legal entities are
> similar, except they never directly act; they always delegate to a natural
> person.  Entities can have multiple types of addresses: a postal mail
> address, an electronic mail address, a telephone number, etc.
>
> I think there are two questions:
>
> 1) Can a namespace controller, or their delegated representative, delegate
> their authority for certificate approval to someone else?
>

Within the context of a single domain, I think we established that of
course they can - via any of the other methods we have; namely, .2 and .4
can forward to a mailbox under the delegated representatives control, and
.3 can effectively do so as well. .7 can delegate to a third-party by
granting them DNS control (or by effectively directing DNS to them).

Within the context of multiple, non-enumerated, unbounded domains, no.


> 2) If so, can any address type for the namespace controller be used to
> confirm the delegation approval?
>

This question is a bit more difficult to parse. Can you clarify what you
mean by "address type"?


>
> Once these are established, we can discuss exact procedures, but these are
> the critical things to answer to determine if there is a path forward.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/c2871680/attachment.html>