[cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

[Bruce Morton]

Hi Jonathan, 

Please note that the domain validation methods under BR 3.2.2.4 are introduced as follows:  "This section defines the permitted processes and procedures for validating the Applicant's ownership *or* control of the domain."  There is no requirement of proving both domain ownership and control, and proving only domain control has its own security vulnerabilities.

Searching for "Apple, Inc." is a BR 3.2.2.1 Identity verification. This needs to be done for all OV certificates and would be done regardless of which type of domain verification was performed. Nevertheless, when "Apple, Inc." was searched in D&B/Hoover's we found only one matching record - the correct one.  When we search on the term “Apple” and “Cupertino, California”, we get 22 entries - but these include companies like Apple Green Bistro or Apple Tree Library Association, so there’s no danger of confusion with Apple, Inc. of Cupertino, CA. 

Next 3.2.2.4.1 is performed to verify the domain Registrant is the Applicant. In our example there was an exact match. In other cases the Registrant may be a Parent/Subsidiary. These are defined terms in the BRs and CAs have much experience in performing this type of verification. Our proposed process also requires that the WHOIS also has some other type of unique information to verify that we have a match. We were able to use the address.

Finally we do 3.2.5, the authorization to issue check. We do not use the information from WHOIS to perform this check. The reason is most information is provided by the Registrant, so using it would be considered allowing self-validation. This information may be OK to use to show domain control, but should not be used for authorization to issue. As such, we call the Applicant, which also owns the domain to confirm authorization to issue. You say that the Applicant Authorization Contact does not control the domain and you are probably right. Actually, we think that the Applicant Technical Contact controls the domain. We don't want to contact the Applicant Technical Contact as again, this would be self-verification. Also, in many cases, the Applicant Technical Contact is a contractor or hoster and should not verify authorization to issue. We use a phone number found in a QIIS to contact the Applicant. This verifies that the Applicant Authorization Contact is employed by the Applicant and the CA relies on their authority.

Every method of domain validation has its own potential vulnerabilities, and we have to be practical in deciding which validation methods are secure enough to use.  BR 3.2.2.4.1 (proving domain ownership) has been used for about 20 years for OV and was primarily required in the EV Guidelines from 2007 where the it stated "To verify Applicant’s registration, or exclusive control, of the domain name(s)."  Many CAs believe that it’s at least as secure as the domain control methods and should continue to be available as an alternative to domain control.  In fact, in my 13 years working with the Entrust CA, we have never been asked to revoke a certificate which was issued using BR 3.2.2.4.1 to verify the domain. Please note that BR 3.2.2.4.1  will only be successful if BR 3.2.2.1 and 3.2.5 are also performed adequately. 

For this reason, we believe BR 3.2.2.4.1 should continue, and we are working with other CAs in the Forum’s Validation Working Group to clarify how 3.2.2.4.1 should be applied, and thereby make it stronger.  

In the meantime, we will not be supporting Ballot 218.

Thanks, Bruce.

-----Original Message-----
From: Jonathan Rudenberg [mailto:jonathan at titanous.com] 
Sent: January 22, 2018 1:38 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Geoff Keating <geoffk at apple.com>
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document


> On Jan 22, 2018, at 13:05, Bruce Morton via Public <public at cabforum.org> wrote:
> 
> Geoff,
>  
> We put together an example of using method 1. Please see attached.


Thanks for posting this. I was initially unclear on how 3.2.2.4.1 worked in practice, and this walkthrough made the pieces fit together for me.

Unfortunately, the implementation described does nothing to verify domain control, and so should obviously be removed from the BRs immediately. Additionally, given the level of weakness I think it would make a lot of sense to revalidate or revoke all certificates that are currently valid and have been issued using this method.

The phone number in a D&B record that matches the Registrant Organization and address from the WHOIS does not indicate domain control, all it indicates is that someone put a record into the D&B database. There are >25 results matching ‘Apple’ with an address in California in the D&B database, so clearly they don’t do any duplicate prevention, which makes sense because business entity names are not unique. This means that anyone who can either a) create a new D&B entry that would match your search or b) edit an existing D&B entry matching your search has the ability to receive certificates using this method. Obviously neither a) or b) indicate domain control, so this method is completely inadequate.

Additionally, even without any changes to the D&B database, there is no link between the Applicant Authorization Contact and domain control. This means that anyone accessible via the phone number in D&B can authorize the issuance of a certificate. So if the phone number is a corporate switchboard, anyone in the phone directory, including janitorial staff, interns, and temporary contractors would be capable of authorizing certificate issuance if their name was specified as the Applicant Authorization Contact.

There are a bunch of other potential issues that come to mind, but this method is already so hopelessly broken that I don’t think it makes sense to continue.

Jonathan