<div dir="ltr">I stand by the assertion and can happily demonstrate it. While it may be that your position is that such commercial CAs exercise their fiduciary duty by considering the long-term impact of such 'short-term' hacks, I do not believe it can or should be disputed that the incentive structure is as I described, and it is constantly such a balancing act. You took it as a pejorative remark, clearly, but I am highlighting that is is a struggle between the CA's fiduciary duty to maximize shareholder value and the common resource that is the security ecosystem.<div><br></div><div>In any event, it seems that an argument that rests on "CA's can be trusted to do the right thing" is both unreasonable and unsustainable, and the ample evidence suggests that - more often from ignorance than malice - ambiguity in requirements, or broad strokes, do not output the desired results. Further, we should assess the practical impact - that is, is 3.2.2.4.1 being used, by who, and by how - if we are to mount a defense that it should not be removed. We have evidence of its abuse, we know that less than half of the trusted CA's participate in the CA/Browser Forum, and we know that auditors are even more liberal in their interpretation given _their_ fiduciary duty to their clients and financial incentives, so it's not at all unreasonable to remove (given the ample alternatives) and then later revisit if there is something equivalently secure.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 4, 2018 at 9:59 AM, Tim Hollebeek <span dir="ltr"><<a href="mailto:tim.hollebeek@digicert.com" target="_blank">tim.hollebeek@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-6442474759600517209WordSection1"><p class="MsoNormal">This characterization of CAs in general is simply not true and I wish you would stop making it.  It’s a bunch of overly broad statements and mischaracterizations.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">There are some bad actors out there, and some bad practices out there that need to be eliminated, but using that to tar the entire industry with a broad brush is misleading in the extreme.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">-Tim<u></u><u></u></p><p class="MsoNormal"><a name="m_-6442474759600517209__MailEndCompose"><u></u> <u></u></a></p><span></span><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@<wbr>cabforum.org</a>] <b>On Behalf Of </b>Ryan Sleevi via Public<br><b>Sent:</b> Wednesday, January 3, 2018 10:03 PM<br><b>To:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.<wbr>com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> Re: [cabfpub] [EXTERNAL]Re: Verification of Domain Contact and Domain Authorization Document<u></u><u></u></p></div></div><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Given that CAs have competing interests - namely, to sell certificates first and foremost, while at the same time not doing anything too egregious to get noticed and thus distrusted - I don't think it's reasonable, particularly given the economic incentives and industrial behaviour, to suggest that CAs would find this as something to reject.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Most CAs, at the end of the day, mint certs for money. CAs particularly concerned about appearances such as market share are further incentivized to make minting certs easier. It is thus unsurprising that this sort of incentive structure results in what we might term 'exploitative' (in a security mindset), while the CA might call it 'innovative' or 'customer friendly'.<u></u><u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Jan 3, 2018 at 5:41 PM, Bruce Morton via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"><span style="color:#1f497d">The requirement may mean a LOT of things, but it is also qualified by language such as “This method may only be used if: 1. The CA authenticates the Applicant's identity under BR Section 3.2.2.1 and the authority of the Applicant Representative under BR Section 3.2.5.”</span><u></u><u></u></p><p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="color:#1f497d">I assume it will be stated that the language in 3.2.2.1 and 3.2.5 also mean a LOT of things, but this is the job of the CA to create a policy which is effective. Per BR 5, the CA should also do risk assessments and security plans. Using this methodology will help the CA close the loopholes in its processes. Of course, if the CA still finds the risk too high, then they can stop using the method.</span><u></u><u></u></p><p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="color:#1f497d">Bruce.</span><u></u><u></u></p><p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@<wbr>cabforum.org</a>] <b>On Behalf Of </b>Jeremy Rowley via Public<br><b>Sent:</b> January 3, 2018 5:25 PM<br><b>To:</b> <a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.com</a><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document<u></u><u></u></p></div></div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">The ambiguity is exactly why we need to remove method 1. I’ve seen all of the following:<u></u><u></u></p><p class="MsoNormal" style="margin-left:.5in">1)<span style="font-size:7.0pt;font-family:"Times New Roman",serif">      </span>Approval based on a name match<u></u><u></u></p><p class="MsoNormal" style="margin-left:.5in">2)<span style="font-size:7.0pt;font-family:"Times New Roman",serif">      </span>Approval based on an email match (same email as requester or the email is a corporate email) – note that this is a Domain Contact match<u></u><u></u></p><p class="MsoNormal" style="margin-left:.5in">3)<span style="font-size:7.0pt;font-family:"Times New Roman",serif">      </span>Approval based on address and name match<u></u><u></u></p><p class="MsoNormal" style="margin-left:.5in">4)<span style="font-size:7.0pt;font-family:"Times New Roman",serif">      </span>Approval based on a letter from the registrar<u></u><u></u></p><p class="MsoNormal" style="margin-left:.5in">5)<span style="font-size:7.0pt;font-family:"Times New Roman",serif">      </span>Approval based on a call to the registrar<u></u><u></u></p><p class="MsoNormal" style="margin-left:.5in">6)<span style="font-size:7.0pt;font-family:"Times New Roman",serif">      </span>Approval based on a validation email to the registrar<u></u><u></u></p><div><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">All of these are equally permitted by the language, IMO, because “by validating the Applicant has the same name as the Domain Contact directly with the Domain Name Registrar” can mean a LOT of things.<u></u><u></u></p><p class="MsoNormal"><a name="m_-6442474759600517209_m_-1878068654978953830__MailEndCompose"> </a><u></u><u></u></p><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> <a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.com</a> [<a href="mailto:geoffk@apple.com" target="_blank">mailto:geoffk@apple.com</a>] <br><b>Sent:</b> Wednesday, January 3, 2018 2:54 PM<br><b>To:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>>; Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>; Adriano Santoni <<a href="mailto:adriano.santoni@staff.aruba.it" target="_blank">adriano.santoni@staff.aruba.<wbr>it</a>><br><b>Subject:</b> Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document<u></u><u></u></p></div></div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">It looks like we’re going to be removing 3.2.2.4.1, so this will be moot, but just to explain the interpretation, 3.2.2.4.1 says that what you are doing (this sentence is the entire description of the method, the rest of the section just limits its application) is "Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.”<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">This is not a name match.  If the BRs wanted to say “by validating the Applicant has the same name as the Domain Contact”, they would say so.  This is a one-and-the-same match, it uses the word “is”.  In the example below, the CA must ensure that “Google Inc., the Utah corporation” is the same one as shown in the WHOIS information, and all the WHOIS information is relevant in confirming this.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">Another important clarification is that if you use 3.2.2.1, it doesn’t just verify “the name of the applicant”; it says that "the CA SHALL verify the identity and address of the organization”, not just the name.  (Um… actually, if you read it closely, you might not verify the name at all, if you identify the organization in another way, maybe with some kind of ID number.  That’s probably a bug.)<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal">On 2 Jan 2018, at 8:47 pm, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<u></u><u></u></p></div><p class="MsoNormal"> <u></u><u></u></p><div><div><p class="MsoNormal">I disagree. The requirements do not specify that.  All that is required is the name of the applicant was verified under 3.2.2.1 and that the register specify the domain contact is the applicant. If Google, Inc. is specified as the domain contact, no address matching is required.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><div><p class="MsoNormal"><b>From:</b><span class="m_-6442474759600517209m-1878068654978953830apple-converted-space"> </span><a href="mailto:geoffk@apple.com" target="_blank">geoffk@apple.com</a> [<a href="mailto:geoffk@apple.com" target="_blank">mailto:geoffk@apple.com</a>]<span class="m_-6442474759600517209m-1878068654978953830apple-converted-space"> </span><br><b>Sent:</b><span class="m_-6442474759600517209m-1878068654978953830apple-converted-space"> </span>Tuesday, January 2, 2018 4:34 PM<br><b>To:</b><span class="m_-6442474759600517209m-1878068654978953830apple-converted-space"> </span>Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Cc:</b><span class="m_-6442474759600517209m-1878068654978953830apple-converted-space"> </span>Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>; Adriano Santoni <<a href="mailto:adriano.santoni@staff.aruba.it" target="_blank">adriano.santoni@staff.aruba.<wbr>it</a>><br><b>Subject:</b><span class="m_-6442474759600517209m-1878068654978953830apple-converted-space"> </span>Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document<u></u><u></u></p></div></div></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><div><p class="MsoNormal">On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public <<a href="mailto:public@cabforum.org" target="_blank"><span style="color:purple">public@cabforum.org</span></a>> wrote:<u></u><u></u></p></div></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><div><div><p class="MsoNormal">The attack vector is easier than that.<span class="m_-6442474759600517209m-1878068654978953830apple-converted-space"> </span><u></u><u></u></p></div></div><ol start="1" type="1"><li class="MsoNormal">I use very stringent processes to verify that Google, Inc. is a legit company in Utah.<u></u><u></u></li><li class="MsoNormal">I verify that Jeremy did indeed incorporate Google, Inc.<span class="m_-6442474759600517209m-1878068654978953830apple-converted-space"> </span><u></u><u></u></li><li class="MsoNormal">I call Jeremy at the phone listed for Google, Inc., the Utah corporation<u></u><u></u></li><li class="MsoNormal">The domain information shows Google, Inc. as owning<span class="m_-6442474759600517209m-1878068654978953830apple-converted-space"> </span><a href="http://google.com/" target="_blank"><span style="color:purple">google.com</span></a><u></u><u></u></li><li class="MsoNormal">Certificate issues.<u></u><u></u></li></ol><div><div><p class="MsoNormal"> <u></u><u></u></p></div></div><div><div><p class="MsoNormal">Obviously this would be caught in every CA’s high risk checks, but the point remains valid. Regardless of the expertise and thoroughness of the org check, the specs lack any time between the verified org and the actual domain because orgs are not unique on a global basis.<u></u><u></u></p></div></div><div><div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></blockquote><div><p class="MsoNormal"> <u></u><u></u></p></div></div><div><div><p class="MsoNormal">For item 4, you have to verify that “the Applicant is the Domain Contact”.  Obviously it’s insufficient to just compare names—you must verify every element of the WHOIS contact matches the Applicant, that’s typically name, postal address, phone number, and e-mail.<u></u><u></u></p></div></div></div></blockquote></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>______________________________<wbr>_________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></div></blockquote></div><br></div>