<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Some CAs are domain registrars some,
others are not. What if some of those registrars offer also "free
CAA service"?<br>
<br>
Thanks,<br>
M.D. <br>
<br>
On 5/3/2014 7:28 PM, <a class="moz-txt-link-abbreviated" href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> wrote:<br>
</div>
<blockquote
cite="mid:EF70381B2D29784EA4FC66042BE81EAF2274AEC7@SJDCEXMBX03.us.trendnet.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Well
put, Ryan – but I would point out that the “variety of
requests for confirmation from CAs that we [Google] do not
do business with about the legitimacy of certain requests”
you mention below sound like the results of the vetting
process itself – and the vetting process appears to be
working well at filtering out illegitimate requests. Why
add yet another step?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">No
one can identify any mis-issued certs from the past decade
that would, in fact, have been prevented by CAA. Current
vetting practices are working. They can be strengthened if
needed, but until we find cases of CA mis-issuance after
vetting, the current practices seem to be working well.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">CAA
clearly is an impediment to competition among CAs, and
imposes another administrative and engineering burden on
cert issuance. And yet there are no real business rules
around what to do with a contrary CAA result after
completion of all vetting for a cert request (using a third
party confirmed phone number to call “Google, Inc.,”
checking WhoIs, etc. I can predict with confidence that
many large organizations will lose track of who is
maintaining the CAA records in various hosting locations,
and how to make a change. The CAA record will then become
inaccurate and out of date. Someone who is authorized to
buy certs for a company then signs a deal with a new CA (at
a better price and service level), but the contrary CAA
record is found. Either the parties ignore the record as
“something we’ll clean up later” or the deal is delayed or
prevented because no one can get the CAA record updated.
Either way, after proper vetting of a cert request by an
organization the CAA record is not very useful.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">CAA
strongly favors incumbent CAs, for little or no demonstrated
value to the security structure (especially as each CA gets
to craft its own response or non-response to a CAA record).
It also lacks DNS support. To me, it has more potential
negative aspects than positive.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Ryan Sleevi [<a class="moz-txt-link-freetext" href="mailto:sleevi@google.com">mailto:sleevi@google.com</a>]
<br>
<b>Sent:</b> Friday, May 02, 2014 6:15 PM<br>
<b>To:</b> Kirk Hall (RD-US)<br>
<b>Cc:</b> Gervase Markham; <a class="moz-txt-link-abbreviated" href="mailto:public@cabforum.org">public@cabforum.org</a><br>
<b>Subject:</b> Re: [cabfpub] Revisiting CAA<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Kirk,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Your parenthetical comment leaves me
believing you still do not see the significant value of
CAA. Allow me to attempt to explain.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, May 2, 2014 at 5:54 PM, <a
moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">
kirk_hall@trendmicro.com</a> <<a
moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>>
wrote:<o:p></o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
-----Original Message-----<br>
From: Phillip Hallam-Baker [mailto:<a
moz-do-not-send="true"
href="mailto:philliph@comodo.com">philliph@comodo.com</a>]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Sent:
Friday, May 02, 2014 10:54 AM<br>
To: Gervase Markham; Kirk Hall (RD-US); Rick Andrews; <a
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>
; Rick Andrews ;
<a moz-do-not-send="true"
href="mailto:public@cabforum.org">public@cabforum.org</a><br>
Subject: Re: [cabfpub] Revisiting CAA<br>
<br>
On 02/05/14 16:40, <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true"
href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<table>
<tbody>
<tr>
<td bgcolor="#ffffff"><font color="#000000">
<pre><table class="TM_EMAIL_NOTICE"><tbody><tr><td><pre>TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></tbody></table></pre>
</font></td>
</tr>
</tbody>
</table>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>