<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 23, 2018 at 2:36 PM, Bruce Morton via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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. </blockquote><div><br></div><div>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.</div><div><br></div><div>This is unacceptably insecure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Your use of Applicant Provided Data (in Step 5) demonstrates a fundamental security weakness that has been highlighted.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>