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

[Ryan Sleevi]

On Tue, Jan 23, 2018 at 2:36 PM, Bruce Morton via Public <
public at cabforum.org> wrote:
>
> 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.


To be clear: From your own description, you use information provided by the
Applicant - which is unquestionably self-validation. That is, in your
described flow, Step 1 very clearly states that the "Applicant Technical
Contact" and "Applicant Authorization Contact" were provided by the
Applicant themselves.

This is unacceptably insecure.


> 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.
>

To be clear: This is the fundamental problem with 3.2.2.4.1 as you've
described, as it does not adequately determine authorization of the domain
name, and fundamentally and inherently cannot when examining a validation
in isolation.

Your use of Applicant Provided Data (in Step 5) demonstrates a fundamental
security weakness that has been highlighted.


> 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.


Given the difficulty that Entrust has stated it has with determining the
validation methods used, I am surprised to hear how quickly you were able
to determine that 3.2.2.4.1 has not be used in validation. It's encouraging
to hear that you analyze every certificate you revoke for the validation
method used, and that you're able to so quickly compute these statistics.
In order to assist the Forum in making decisions based on objective data,
rather than speculation, could you please share how many certificates
Entrust CA has revoked over the past 13 years, along with the distributions
of validation methods used for each revocation? Given Entrust's commitment
to improving the validation methods, such information could dramatically
inform prioritization of possible improvements.

Many CAs also believed SHA-1 was secure (it was not), MD5 was secure (it
was not), RSA-1024 was secure (it was not), that playing IP addresses in
dNSNames was valid (it is not), and a host of other mistakes over the past
20 years. We work best as an industry when we look forward on how to
improve, rather than trying to look to the past and remain comfortable.

I hope you can see, with the above example, it's clear that you're relying
on Applicant-provided data to authorize issuance, and the risk this poses
to the ecosystem is unacceptably large.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180123/18cfbe45/attachment-0003.html>