<div dir="ltr">Kirk,<div><br></div><div>Your parenthetical comment leaves me believing you still do not see the significant value of CAA. Allow me to attempt to explain.</div><div><br></div><div>Considering that, at it's most basic level, a certificate is a binding to a DNS record - which is a perfectly acceptable form of validating the legitimacy of the request (according to the BRs), there is no entity more authorized to make decisions on certificate purchases than the DNS operator.</div>
<div><br></div><div>At Google, we have received a variety of requests for confirmation from CAs that we do not do business with about the legitimacy of certain requests. It's not uncommon to see these requests generated by acquisitions, but can also be generated inhouse. There are several means for an applicant to satisfactorily demonstrate control without the involvement of the DNS operator - Options 1, 6, and 7 of Section 11.1.1 of BRs 1.1.7. While these requests are not in line with our internal policies, they are made, and CAs receive them, and with respect to the BRs, they are "valid requests".</div>
<div><br></div><div>Because Google is (fortunately?) a high-value target, such requests are (almost always, unfortunately) deemed High Risk Requests (Section 11.5), and thus either those of us involved in the CA/B Forum, or our Security team, or our DNS operations team will receive a confirmation of the request - for which we always respond "NO"</div>
<div><br></div><div>CAA - if it is actually respected - would allow us to centrally announce our issuance policies (since we centrally manage the DNS for these acquisitions), and potentially avoid this entirely. Of course, that's assuming the CA is concerned about safety and reputation and performs meaningful actions with such signals (eg: treating as a high risk request).</div>
<div><br></div><div>Now, for all the other organizations - whether they be smaller, larger, or the same size as Google - who deal with these same problems (again, Options 6 and 7 are huge enough holes that any competent social engineering/sob story could drive right through) can benefit, even if they're not already on the CA's high risk target list.</div>
<div><br></div><div>In my view - every one of those requests (... including those that were, unfortunately, satisfied) - would count as a misissuance. Unfortunately, because we lack solutions like CT in active deployment, it's hard to quantify those - and even harder, since those most affected by it neither participate nor have a voice here.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 5:54 PM, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> <span dir="ltr"><<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another concern we have with CAA (apart from the fact that it would not have avoided any known cases of certificate mis-issuance in the past) is that often in larger companies (the most typical fraud targets), the person who buys the certs is not the person who manages the DNS -- and often, the person who buys the certs doesn't even know who is managing the DNS.<br>

<br>
Gerv -- at one point, you were going to conduct a test within Mozilla on this point -- how easy/hard was it to get CAA notations put in the proper DNS records, and how easy was it to coordinate the buyer(s) of certs for Mozilla with the various people in charge of the DNS for Mozilla's websites.  As I recall, you found it somewhat difficult to discover and coordinate the two groups.  Is that correct?<br>

<div class="im HOEnZb"><br>
-----Original Message-----<br>
From: Phillip Hallam-Baker [mailto:<a href="mailto:philliph@comodo.com">philliph@comodo.com</a>]<br>
</div><div class="im HOEnZb">Sent: Friday, May 02, 2014 10:54 AM<br>
To: Gervase Markham; Kirk Hall (RD-US); Rick Andrews; <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
Subject: Re: [cabfpub] Revisiting CAA<br>
<br>
Gerv makes a good point. But I will point out that the reason the CAA spec says nothing about what the CA has to do in response to a non-compliant request is that the IETF is the wrong forum to discuss such issues.<br>
<br>
What approaches are appropriate are going to depend on takeup by the domain name holders and what attacks we see. those will change over time. So CABForum is a better place to discuss such issues.<br>
<br>
-----Original Message-----<br>
From: Gervase Markham<br>
Sent: Friday, May 02, 2014 11:54 AM<br>
To: <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> ; Rick Andrews ; <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
Subject: Re: [cabfpub] Revisiting CAA<br>
<br>
On 02/05/14 16:40, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> wrote:<br>
> Can anyone identify one case -- even one -- of mis-issuance of a<br>
> certificate by a CA that would have been prevented by CAA?  (I can't<br>
> think of one.)<br>
<br>
It depends how CAs implement CAA. If the CA implements CAA as, among other things, a separate automated sanity check on all certificates, just before they go out the door, using an isolated system - and certs which fail have to be manually approved - then I can see it catching several of the recent misissuances.<br>

<br>
If the CA implements CAA as a printed warning on the certificate issuance screen that the operator can choose to deal with or ignore, I imagine it would catch fewer misissuances.<br>
<br>
Gerv<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
</div><div class="im HOEnZb"><table class="TM_EMAIL_NOTICE"><tr><td><pre><br>
TREND MICRO EMAIL NOTICE<br>
The information contained in this email and any attachments is confidential<br>
and may be subject to copyright or other intellectual property protection.<br>
If you are not the intended recipient, you are not authorized to use or<br>
disclose this information, and we request that you notify us by reply mail or<br>
telephone and delete the original message from your mail system.<br>
</pre></td></tr></table><br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div>