<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Ryan, you haven’t explained to your objection to my suggested edits.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">With my edits, we may find substantial support for CAA among most CAs. Right now, the support is concentrated mainly with the larger CAs who have established
customer bases that CAA would protect. With my proposed amendments, not only larger, established CAs, but also smaller and newer CAs may support CAA and this ballot. That would be a good thing, right?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">No CA has said it will only support the CAA ballot if CAs retain the right to push customers to create a CAA record in their behalf, or the right to create
a CAA record for their customer – right? So most CAs may support my proposed amendment and pass the CAA ballot with that language included.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">So my question to you is – do you yourself oppose the proposed amendment? If so, why?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If you don’t oppose the amendment, then there’s really not a problem and the ballot may pass with the added language.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><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 [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Friday, September 05, 2014 5:31 PM<br>
<b>To:</b> Kirk Hall (RD-US)<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> RE: [cabfpub] Pre-Ballot 125 - CAA Records<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p><br>
On Sep 5, 2014 5:20 PM, "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>> wrote:<br>
><br>
> Ryan, I just noticed your statement at the bottom of my proposal about a separate ballot for the amendment I proposed.<br>
><br>
> <br>
><br>
> When the Forum has discussed CAA in the past, it was noted that in many large enterprises (the most likely candidates for CAA), the people who buy certificates are not the same people who manage the company’s DNS – and in fact, they may not work on the same
continent or know each other. So it may be very difficult for CAA records to be updated – a potential competitive handicap for new CAs, or CAs trying to sell to an organization that buys its certs from others. <br>
><br>
> <br>
><br>
> Several of us tried experiments within our organizations, and found this was so (no communication between the two groups). It was also noted that many enterprises buy certs from multiple CAs, sometimes a development team needs a cert on very short notice,
etc. – CAA could greatly complicate this with no real benefit if any CA tries to get an exclusive CAA record for itself and use it as a competitive blocking tool.<br>
><o:p></o:p></p>
<p>This proposal does not concern itself with that. It is merely a requirement to document policies.<o:p></o:p></p>
<p>Your concerns - and certainly, they have been raised by other CAs - about the possibility of a CA to abuse its position in a market are only applicable when CAs are actually required to check CAA, which the Forum has shown there is significant opposition
by CAs to do.<o:p></o:p></p>
<p>> <br>
><br>
> I’ll tell you want I’ll do at my next CA, Voracious CA – Section 18(d)(ii) of my Subscriber Agreement will say “You hereby authorize us to contact your DNS operator and create a CAA record with our name in it.” Hah! I’ve just created a potential competitive
block for all my competitors, and the customer never knew. And I’ll have my sales team always say “Hey, you know how you can REALLY increase your security? Create a CAA record and put our name in it. That prevents rogue hackers from getting certs in your
valuable domain <a totally non-target domain for hackers>. I’ll email you instructions containing the name and phone number of your DNS operator – you’ll get a discount on your next cert if you do!” Hah – I just fooled the customer into creating a CAA record
that only contains my name.<br>
><br>
> Or if I also offer hosting services, I’ll bundle it all, with an automatic CAA record thrown in.<br>
><br>
> <o:p></o:p></p>
<p>And there are plenty of other ways to game the system that the BRs don't deal with.<o:p></o:p></p>
<p>Respectfully, Kirk, I would simply ask whether or not you will support a simple ballot, without your modifications, that simply requires CAs to document their policies.<o:p></o:p></p>
<p>CAs that are concerned of such abusive (and, dare I say, unrealistic) behavior have full liberty to take whatever measures you find suitable in your CPS. This simply gets your position on record.<o:p></o:p></p>
<p>I see no reason to stall this ballot, which would inevitably be another 6 months of delay (we have been talking about this since the Mozilla F2F nearly a year ago), when it makes no such requirements on any CA.<o:p></o:p></p>
<p>><br>
> For CAs to impose CAA on other CAs without protective language like what I propose presents serious competition law issues. No one yet has said “it’s a good idea for CAs to tell their customers to create CAA records, or to do it for them,” so the proposed
language is a way to make the CAA ballot palatable to many CAs (especially smaller or newer CAs).<br>
><o:p></o:p></p>
<p>Please reread the ballot. You, and the other CAs who have repeatedly raised this concern as a way to dismiss CAA, have been listened to, which is why the ballot is so narrow and focused as it is.<o:p></o:p></p>
<p>Any CA that shares your view of the unlikely situation occurring can deal with it in their CPS. If you feel it actually is a problem, or it would prohibit a ballot that required CAA enforcement (which, again, this does not), then we can spend another 6 months
working on this language and hearing the same arguments we have heard for the past year+.<o:p></o:p></p>
<p>To be clear, I'm fully sympathetic to your fear, even though I find it extremely unlikely, but I think its entirely disconnected and orthogonal to a simple ballot as this, which simply requires documentation of practices.<o:p></o:p></p>
<p>Surely you can recognize the value in both such documentation and in the Forum occasionally reaching consensus and forward progress in real and pressing issues, rather than be stalled by years of debate and uncertainty while trying to boil the ocean of CA
practices.<o:p></o:p></p>
<p>I think we have two endorsers at this point, so I would be thrilled to see this taken to a vote. If your fears prevent you from voting on such a simple change, then we can certainly revisit this and discuss how to assuage them, but I think if you and others
who may feel the same read the proposal, you will realize nothing unreasonable is being requested of you.<o:p></o:p></p>
<p>> <br>
><br>
> From: Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com">sleevi@google.com</a>]
<br>
> Sent: Friday, September 05, 2014 4:43 PM<br>
> To: Kirk Hall (RD-US)<br>
> Cc: CABFPub<br>
> Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records<br>
><br>
> <br>
><br>
><br>
> On Sep 5, 2014 4:35 PM, "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>> wrote:<br>
> ><br>
> > Ben, I have an amendment to propose, in the form of the language below (to be added at the end of your language in Sec. 8.2.2. A word of explanation: every time CAA has come up as a topic of discussion at a CAB Forum meeting or on a call, one or more
CAs and browsers<br>
><br>
> I have yet to hear a browser express this concern.<br>
><br>
> > have expressed concern that CAA could be used as a "blocking" strategy by CAs in order to add hurdles for another CA to sell certificates to the same customer. The main way this could happen is if a CA induces a customer to insert its name to a CAA record
when there is no CAA record at the time for the customer (or even worse, adds its name to a blank CAA record in the customer's name -- this could happen if the fine print of the Subscriber Agreement authorizes the CA to insert its name in a CAA record for
the customer and the customer has no idea this is happening). Another potential abuse would be if a CA got its name put in blank CAA records for other domains registered to the customer that are not even part of the pending certificate order so that other
CAs would find it more difficult to sell certificates for those domains.<br>
> ><br>
> > <br>
> ><br>
> > There seems to be strong sentiment among CAs and browsers for some language prohibiting this potential practice as anticompetitive. <br>
><br>
> I have yet to hear a browser express this concern.<br>
><br>
> > The decision of whether or not to even have a CAA record should be solely up to the customer, not the CA.<br>
> ><br>
> > <br>
> ><br>
> > With this explanation, here is my suggestion for additional language for this pre-ballot:<br>
> ><br>
> > <br>
> ><br>
> > In order to make certain that CAA is not used by CAs in an anticompetitive manner, no CA shall (1) request or suggest that a customer include the CA’s name in a CAA record for the domain in question if the customer does not already have a CAA record that
includes the name of one or more other CAs but omits the CA’s name, (2) obtain authorization from the customer to act on the customer’s behalf (directly or by request to the customer’s DNS operator) to create a CAA record for the customer that includes the
CA’s name for the domain in question if the customer does not already have a CAA record that includes the name of one or more other CAs but omits the CA’s name, or (3) request or suggest that a customer include the CA’s name in a CAA record for other domains
not the subject of the customer’s certificate order or obtain authorization from the customer to act on the customer’s behalf (directly or by request to the customer’s DNS operator) to create a CAA record for the customer for other domains not the subject
of the customer’s certificate order.<br>
> ><br>
> > <br>
> ><br>
> > What do you think? Does this meet everyone’s stated concerns?<br>
><br>
> If you feel strongly about this, I feel it is worth a separate ballot. I do not support burdening this ballot with that language.<br>
> ><br>
> > <br>
> ><br>
> > [Also – typo below – “(section 4.1 for CA’s still conforming to RFC 2527)” should be “(section 4.1 for CAs still conforming to RFC 2527)”]<br>
> ><br>
> > <br>
> ><br>
> > -----Original Message-----<br>
> > From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On Behalf Of Ben Wilson<br>
> > Sent: Friday, August 29, 2014 2:02 PM<br>
> > To: Sigbjørn Vik; Rick Andrews; Geoff Keating; Stephen Davidson; Ryan Sleevi (<a href="mailto:sleevi@google.com">sleevi@google.com</a>)<br>
> > Cc: cabfpub<br>
> > Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records<br>
> ><br>
> > <br>
> ><br>
> > Picking up where we left off .. attached is the redlined version that I think is closest to where we were on this issue:<br>
> ><br>
> > <br>
> ><br>
> > 1. In Section 4 of the Baseline Requirements, add a definition for CAA Record as follows:<br>
> ><br>
> > <br>
> ><br>
> > CAA Record: The Certification Authority Authorization (CAA) DNS Resource Record of RFC 6844<br>
> ><br>
> > (http:<a href="http://tools.ietf.org/html/rfc6844">tools.ietf.org/html/rfc6844</a>) that allows a DNS domain name holder to specify the Certification Authorities<br>
> ><br>
> > (CAs) authorized to issue certificates for that domain. Publication of a CAA Resource Record allows public Certification Authorities to implement additional controls to reduce the risk of unintended certificate mis-issue.<br>
> ><br>
> > <br>
> ><br>
> > We might want to abbreviate this definition a bit.<br>
> ><br>
> > <br>
> ><br>
> > 2. In Section 8.2.2 (instead of editing warranties in section 7.1.2 or verification practices in section 11, as some have suggested) add the following to the end of the paragraph on Disclosure:<br>
> ><br>
> > <br>
> ><br>
> > Effective as of [insert date that is six months from Ballot 125 adoption], section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement (section 4.1 for CA’s still conforming to RFC 2527) shall<br>
> ><br>
> > disclose: (1) whether the CA reviews CAA Records, and if so, (2) the CA’s policy or practice on processing CAA Records and comparing them with proposed Domain Names for the Common Name field or Subject Alternative Name fields of certificates applications,
and (3) any actions taken as result of such comparison.<br>
> ><br>
> > <br>
> ><br>
> > Any comments or suggestions are welcome. <br>
> ><br>
> > <br>
> ><br>
> > -----Original Message-----<br>
> ><br>
> > From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On Behalf Of Sigbjørn Vik<br>
> ><br>
> > Sent: Tuesday, July 22, 2014 12:47 AM<br>
> ><br>
> > To: Rick Andrews; Geoff Keating; Stephen Davidson<br>
> ><br>
> > Cc: cabfpub<br>
> ><br>
> > Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records<br>
> ><br>
> > <br>
> ><br>
> > On 21-Jul-14 20:11, Rick Andrews wrote:<br>
> ><br>
> > > Siggy, how does the addition of a CAA record make DoS or DNS<br>
> ><br>
> > > amplification<br>
> ><br>
> > attacks more problematic?<br>
> ><br>
> > <br>
> ><br>
> > I am no DNS expert, merely relaying comments from our sysadmin. If people with more knowledge in the field conclude that this is not an issue, that is fine with me, but it should be considered.<br>
> ><br>
> > <br>
> ><br>
> > > -----Original Message-----<br>
> ><br>
> > > From: Sigbjørn Vik [mailto:<a href="mailto:sigbjorn@opera.com">sigbjorn@opera.com</a>]<br>
> ><br>
> > > Sent: Monday, July 21, 2014 12:21 AM<br>
> ><br>
> > > To: Rick Andrews; Geoff Keating; Stephen Davidson<br>
> ><br>
> > > Cc: cabfpub<br>
> ><br>
> > > Subject: Re: [cabfpub] Pre-Ballot 125 - CAA Records<br>
> ><br>
> > ><br>
> ><br>
> > > On 17-Jul-14 23:51, Rick Andrews wrote:> Siggy,<br>
> ><br>
> > >> <br>
> ><br>
> > >> There are a number of Security Considerations in Section 6 of the CAA<br>
> ><br>
> > >> RFC (_<a href="http://tools.ietf.org/html/rfc6844#page-13_">http://tools.ietf.org/html/rfc6844#page-13_</a>) which detail<br>
> ><br>
> > >> possible abuse.<br>
> ><br>
> > ><br>
> ><br>
> > > I don't see DoS or DNS amplification listed there.<br>
> ><br>
> > ><br>
> ><br>
> > > --<br>
> ><br>
> > > Sigbjørn Vik<br>
> ><br>
> > > Opera Software<br>
> ><br>
> > ><br>
> ><br>
> > <br>
> ><br>
> > <br>
> ><br>
> > --<br>
> ><br>
> > Sigbjørn Vik<br>
> ><br>
> > Opera Software<br>
> ><br>
> > _______________________________________________<br>
> ><br>
> > Public mailing list<br>
> ><br>
> > <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> ><br>
> > <a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
> ><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>
> ><br>
> ><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">https://cabforum.org/mailman/listinfo/public</a><br>
> ><br>
><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.<o:p></o:p></p>
</div>
</body>
</html>
<table><tr><td bgcolor=#ffffff><font color=#000000><pre><table class="TM_EMAIL_NOTICE"><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></table></pre></font></td></tr></table>