[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Peter Bowen]

> On Mar 15, 2018, at 9:37 AM, Ryan Sleevi <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.
> 
> 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.
> 
> That is, it's granting retroactive authorization based on unknown facts and details when the (previous) authorization was granted, so there's no way to be confident that the site operator intended for that authorization to be that broadly scoped. Every domain should be authorized through contact with the domain holder for that domain, and the authorization should be scoped only to that domain. We allow you to batch authorizations together (such as .2, .3, .4) in some cases, but that should not be seen as a forward grant for all future authorizations. This was part of the problem with .1.

"there's no way to be confident that the site operator intended for that authorization to be that broadly scoped.”

What we have heard from domain registrants is that there are domain registrants/contacts who actively do want this level of authorization scope.  This is very common for large organizations which have a central team that manages certificates for the whole organization but is distinct from the team that manages domain registrations.  The organization wants to avoid having the registrant team approving each new domain that needs a certificate.

I was not proposing that all validation communications permit this, rather that there is an option that a domain contact can opt-in to the broad authorization model.  It might be that we would need to consider this a new method and include some recourse requirement — e.g. that the contact be able to affirmatively able to revoke the authorization.

Thanks,
Peter

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