[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Peter Bowen]

> On Mar 16, 2018, at 11:54 AM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Fri, Mar 16, 2018 at 2:43 PM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> 
> 
>> On Mar 16, 2018, at 11:34 AM, Ryan Sleevi <sleevi at google.com <mailto: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?”
> 
> Because at the time you're making that delegation, you haven't established that you control it for domains not enumerated.
>  
> 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?
> 
> I think the issue here is the proposal that this delegation acts without need to validate that delegation going forward. Without some explicit validation step, which the other methods all possess, you have no reason to believe that the validation for Domain X applies to Domain Y 
> 
> By analogy, it might help to think of it as the difference between offering a signing oracle and a key compromise. A signing oracle is compromised for the duration its exposed, but upon termination of that oracle, future messages can be relied upon, and so can messages before the compromise (that is, assuming you can distinguish 'before' and 'after' - e.g. timestamping or the like). However, a key compromise means that all messages, past and present, are compromised.
> 
> That's the net-effect here, is that such a delegation turns a temporary, bounded risk into a perpetual, unbounded risk, and the level of assurance that, at the time of issuance, things were correct, completely disappears.
> 

I wasn’t asking about validation methods, I was asking about delegation of rights.  When a corporation appoints an officer (who can sign for the company, or put another way has a delegation from the corporation), it is persistent.  If I give someone power of attorney for financial matters, it isn’t only valid for bank accounts which existed at the time the PoA was signed.   If someone has the right to sell a domain, cancel a domain, or transfer a domain (all things which can be done by delegating the right to manage any domain with a given registrant entity), why should they not have the right to approve certificates for the domain?

Thanks,
Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/0a0606c4/attachment.html>