[cabf_validation] Using 3.2.2.4.2/.3 for future domains

Thu Mar 15 13:28:29 MST 2018

Consider the actual case that I shared in conversation with a couple people at our F2F meeting last week (domain name changed to protect the guilty):

I was testing our high risk system on our QA server, so ordered a certificate for well-known-credit-card-company.com.  In placing this order I intended, but neglected, to set the Domain Control Verification method preference to NONE so that no email or other communication to the actual domain registrant would be generated, as I just wanted to see if the order itself would trigger the high risk check properly (it didn’t, and a bug fix was in order, but I digress).  Instead a DCV email was sent out to the domain registrant WHOIS email contact and some knuckle-head on the other end approved it and the cert was issued (from a non-publicly trusted QA_Crippled_CA thank goodness).  Under this proposal an attacker could be granted issuance rights to any domain this company owns or will own for the next 25 months for which they register the same email address as contact.

No.  Just no.  Enterprises ask for a lot of things that aren’t good for them or anyone else.  That’s why we’re the CAs.

Rich Smith

Senior Compliance Manager

ComodoCA.com

From: Rich Smith [mailto:rich at comodoca.com] 
Sent: Thursday, March 15, 2018 3:11 PM
To: 'Peter Bowen' <pzb at amzn.com>; 'CA/Browser Forum Validation WG List' <validation at cabforum.org>; 'Ryan Sleevi' <sleevi at google.com>
Subject: RE: [cabf_validation] Using 3.2.2.4.2/.3 for future domains

I completely agree with Ryan on this.  If someone is proposing that a liberal reading of the current wording implies that this is acceptable then it needs to be tightened up.  If this is a proposal to add wording to allow this, I’m very much against it.

Peter said:

“What we have heard from domain registrants is that there are domain registrants/contacts who actively do want this level of authorization scope.” 

That doesn’t particularly surprise me.  There are a lot of domain registrants, particularly in the enterprise space, who actively want things that are on the whole bad for the ecosystem so that they don’t have to be bothered with properly managing their domains.  I consider this just one more of those.

Rich Smith

Senior Compliance Manager

ComodoCA.com

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Peter Bowen via Validation
Sent: Thursday, March 15, 2018 11:52 AM
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.

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/8a38c459/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5725 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180315/8a38c459/attachment-0001.p7s>