[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Doug Beattie]

From: Validation [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>
Cc: CA/Browser Forum Validation WG List <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, 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 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.

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.

Yes, we have customers that manage a lot of domains and they don’t (yet) have the ability to programmatically implement domain validation using one of the automated methods for every domain.  It’s much easier for the Domain owner to be able to make the one “global” approval and have all new domains added to their managed account without being involved in the approval for everyone.

If were to communicate to the Registrant and they said no, they do not permit the global forward approval of all domains (as I presume large enterprises like Google and Amazon would do), then we would verify each domain as they are supplied for validation.  For those that do permit approval for all domains, we would be sure that the address/value we used to obtain the approval (email/phone/sms/postal address) is the same on any future domains.


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