[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

On Fri, Mar 16, 2018 at 2:43 PM, Peter Bowen <pzb at amzn.com> wrote:

>
>
> 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> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/115aa9f8/attachment-0001.html>