[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Peter Bowen]

> On Mar 15, 2018, at 8:13 PM, Ryan Sleevi <sleevi at google.com> wrote:
> On Thu, Mar 15, 2018 at 4:28 PM, Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com>> wrote
> From: Validation [mailto:validation-bounces at cabforum.org <mailto:validation-bounces at cabforum.org>] On Behalf Of Peter Bowen via Validation
> Sent: Thursday, March 15, 2018 12:52 PM
> To: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com>>
> Cc: CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org>>
> Subject: Re: [cabf_validation] Using 3.2.2.4.2/.3 for future domains
> 
>  
> 
> On Mar 15, 2018, at 9:37 AM, Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com>> wrote:
> 
>  
> 
> On Thu, Mar 15, 2018 at 12:28 PM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> 
> From the discussions of CA use cases where they were using 3.2.2.4.1, it seems that we might be able to cover a number of these by clarifying 3.2.2.4.2/.3.
> 
> Specifically, the BRs currently say:
> 
> "Each email, fax, SMS, or postal mail MAY confirm control of multiple Authorization Domain Names. […] MUST be sent to an email address, fax/SMS number, or postal mail address identified as a Domain Contact.”
> 
> "Each phone call SHALL be made to a single number and MAY confirm control of multiple FQDNs, provided that the phone number is identified by the Domain Registrar as a valid contact method for every Base Domain Name being verified using the phone call"
> 
> What is unclear is whether an an email, fax, SMS, postal mail, or phone call MAY be used to confirm approval for an unbounded set of domains names which have that method as a contact method.  For example, can a CA email hostmaster at example.com <mailto:hostmaster at example.com> and say “Will you approve Bob to get a certificate for _any_ domain which has hostmaster at example.com <mailto:hostmaster at example.com> as a Domain Contact, including domains not yet registered but which are registered in the future with hostmaster at example.com <mailto:hostmaster at example.com> as a Domain Contact?”  This authorization is subject the aging requirements already in the BRs.
> 
>  
> 
> Yes, the intent is that if you send an email to hostmaster at example.com <mailto:hostmaster at example.com> and ask them if they approve issuance for example.com <http://example.com/>, and if they further approve issuance for future domains with a who-is contact listed as hostmaster at example.com <mailto:hostmaster at example.com>, this would be approval for issuance for domains that have not been provided to the CA yet, or perhaps for domains that are not yet registered.  Yes, this authorization is subject to the aging requirements.
> 
> 
> If this is allowed, it would seem to cover the use case of adding domains to an existing applicant/subscriber account without requiring a new communication with the domain contact for each domain.  This was the primary use case that I heard for 3.2.2.4.1 (1) & (2).
> 
>  
> 
> I suppose this yet again depends on the answer to the question of what are we trying to validate?
> 
>  
> 
> I think this would be a net-negative for security and a problematic interpretation, if authorization for 'example.com <http://example.com/>' could be interpreted as future authorization (for up to 825 days) for 'example.net <http://example.net/>'. I understand some CAs would like this. I think they're wrong and it's insecure, and not what domain holders would or should expect.
> 
> The approval to authorize issuance under example.net <http://example.net/> would only be done if they expressly said they wanted approval of new domains.  There are some domain owners that would like this model, but I also agree there are some that won’t.  They don’t need to provide this approval.
> 
> 
> The "problem" with this model is that you're effectively relying on the Applicant over the Domain Owner. As discussed in Reston, the presumption has to be the Applicant is an Attacker and the Domain Holder is the Defender. Hopefully, the alliterative association will help CAs internalize this threat model, since it's so key.
> 
> In an ideal model, the flow is that you validate the Applicant is authorized to assert Public Key X for Domain Y in Certificate A as a hermetic, wholly self-contained step. If you also want to assert Public Key X for Domain Z, that's effectively a new process. 3.2.2.4.2/.3/.4 allow you to coalesce that validation across Domains, and 4.2.1 allows you to amortize/coalesce that validation across Public Keys and Certificates - that is, reusing the Domain Authorization for multiple distinct certificates/public keys.
> 
> During the discussion of 4.2.1, it's clear that some CAs view the steps as further segmented - namely, that you validate the Applicant is authorized (for any public key) for Domain Y as a distinct step, and then later they can provide the public key. This is the "Do the validation before there's a CSR" discussion - namely, the Applicant saying "I will request a certificate for Y and Z" without providing the public key X yet in a CSR.

[ snipping discussion of the challenges of .1 as I don’t think that is in question in this thread ]
> 
> If we imagine that system, with its conditions, my understanding of the current proposal is that once we've validated the Identity I for Domain Y for Applicant-Attacker A, if we then go look up Domain Z, and see it also matches Identity I, can we allow the Applicant-Attacker to self-declare their authorization? The old 3.2.2.4.1 allowed it (insecurely), and the proposal below seems to be based on a notion of "If the Domain Y holder opts in, then they can authorize the Applicant-Attacker A for any future domains, such as Domain Z"
> 
> 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?

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

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.

Thanks,
Peter


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