[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Peter Bowen]

> On Mar 16, 2018, at 11:34 AM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Fri, Mar 16, 2018 at 2:27 PM, Peter Bowen <pzb at amzn.com <mailto: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.

Why not?  Given I can have a limited power of attorney that allows me to delegate certain functions to a representative, why can I not say “I want to allow Bob to approve certificates for all domains which I control?”

If Example Marketing Technology, Inc. (EMTI) is the controller of 10,000 domains, then there is already at least one person who is delegated to act on behalf of EMTI (as EMTI is a legal entity so there must be a natural person who is the agent).  Why can EMTI not delegate only the function of certificate approval to someone?

>  
> 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/08391bdd/attachment.html>