<div dir="ltr">Bruce,<div><br></div><div>I'm not sure your threat model is well-considered, or at least, ignores much of the discussion about CAA to date.</div><div><br></div><div>Your threat description is "There will be CAs that won't follow the Baseline Requirements", but that's no more an argument against CAA than it is against having the BRs to begin with. Root stores will take appropriate action to ensure that CAs participating in their root stores adhere to the root store requirements - such as following the BRs. If your line of arguing was acceptable against CAA, then it would also be acceptable against Ballot 169, or against the SHA-1 deprecation, or against any and every change to the BRs, so I hope you can understand why it doesn't fly.</div><div><br></div><div>The second half of your argument presumes that the sole purpose of CAA is to prevent "attackers" or "dishonest Subscribers". However, that's not the purpose of CAA either. CAA is designed to prevent misissuance by people who, under the existing BRs, would be seen as 'authorized', but by the express intent of the domain holder, are not authorized. Much of your argument is related to "CAs already have systems to describe who is authorized," and my point is that these systems are non-standard, fragile, and not reflective of the real world, precisely because the BRs provide for a number of ways for a CA to determine someone is 'authorized'. CAA returns the balance of control back to the domain holder, rather than the argument you're making, which is "Trust us, we know who is authorized".</div><div><br></div><div>So to recap:</div><div>Those who obtain certificates from non-compliant CAs are not proof of CAA's fraility, but of the existential purpose of the BRs, and have no relationship nor impact on CAA.</div><div>Those who attempt to obtain certificates from compliant CAs, who are otherwise authorized pursuant to the terms of the BRs, but are blocked because of the compliant CA's CAA checking, is CAA working expressly as intended, and thus is not a 'bug' needing to be fixed.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 25, 2017 at 10:58 AM, Bruce Morton <span dir="ltr"><<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.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_699413333007479176WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Ryan, thanks I appreciate the feedback.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">My thinking was that compliant implementations would check CAA and issue/not issue or get permission to issue. The non-compliant implementations would not check
(or ignore the response) and just issue.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">However, the good news is that the CAs which issue the most SSL certificates and the CAs which issue certificates for domains with the highest risk will prepare
compliant implementations. The result will be that most SSL certificate issuance will either respect the CAA record or would have gotten permission from the Applicant/Subscriber to issue. The CAs with the non-compliant implementations will be found out by
the Subscriber or through CT investigation and can then be dealt with.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The ballot proposed with hard-fail will only impact the CAs (and their Subscribers) which plan to perform a compliant implementation. The industry will be better
as the attackers which request a certificate from a compliant CAA implementation will be rejected, but will receive a certificate from a non-compliant implementation.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The solution which I propose will improve the industry as it will mitigate most attacks, but will also allow the honest Subscribers to get their certificates.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Bruce.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>]
<br>
<b>Sent:</b> Wednesday, January 25, 2017 12:41 PM<br>
<b>To:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.<wbr>com</a>><br>
<b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>>; Gervase Markham <<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>>; Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>><span class=""><br>
<b>Subject:</b> Re: [cabfpub] Draft CAA motion (4)<u></u><u></u></span></span></p><span class="">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Bruce,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The problem is that the method we've permitted in the EV Guidelines for 10 years and the BRs for 5 years is not secure nor reliable. And we've concretely seen - even this year - that such methods are inadequate about preventing misissuance.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We can't keep pretending that everything is OK and that CAs aren't misissuing or that these systems work. We need to adapt and improve our methods and controls if we expect people to be able to continue to trust CAs as competent entities
working to help promote a secure Internet.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm sorry that it means that there will be work, and I'm sorry that it means things can't keep on going the same as they have. But that's progress. We need to make some, rather than keep pretending that these systems have worked for the
past 10 years or will work for the next 5 years.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Jan 25, 2017 at 9:38 AM, Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.<wbr>com</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="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I am not trying to find a loop hole, provide uncertainty or be misleading. I am trying to respect both
the CAA record and the means to authenticate the issuance of a certificate which the CA/Browser Forum have permitted in the EV Guidelines for 10 years and the BRs for 5 years. A mistaken or incomplete CAA record may not support Subscribers and may be an issue
for an enterprise Subscriber. </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I am hoping we can work together to find a solution.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thanks, Bruce.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>]
<br>
<b>Sent:</b> Wednesday, January 25, 2017 12:15 PM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br>
<b>Cc:</b> Gervase Markham <<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>>; Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>>; Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.<wbr>com</a>><br>
<b>Subject:</b> Re: [cabfpub] Draft CAA motion (4)</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Wed, Jan 25, 2017 at 9:04 AM, Bruce Morton via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<u></u><u></u></p>
<div>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">Current contractual obligations may be a prepaid service to perform certificate management services and license a Subscriber to issue X number of certificates (say 5, 10, 100, 500,
1000, ...) over a specific period of time (say 1, 2, 3 years ...). Creation or a change to the CAA record with a hard-fail could stop the CA from fulfilling their obligation.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Using this line of argument, so could changes to Ballot 169 with validation. Or is the point being that y'all don't revalidate domain ownership, so you're already not concerned
about potential misissuance?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">Anti-competitive behavior is an error case which I think should be planned for in the policy design. I am not sure how we can provide evidence to strongly prove a future error case.
I don't believe that we are allowed to discuss possible incentives or benefits which a Subscriber could be provided by restricting the CAA record to a specific CA.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">This again sounds like "Uncertainty" part of FUD. In the four+ years we've been discussing CAA, not a single CA member has been able to advance this argument to any meaningful scenario
beyond what you've described, other than the possible "CA may request that their customer put a CAA record in". And that's not anti-competitive - that's helping customers be more secure. If HTTP Public Key Pinning had been subject to the CA/Browser Forum,
I have no doubt CAs would have equally been opposed to helping their customers prevent misissuance for the same grounds, but the reality is that HPKP is a thing, it exists, and CAA is functionally no different in this regard, other than preventing the certificates
from being issued in the first place. Which is by design.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">I am not looking for CA processes to decide whether to check a CAA record. I am looking to use the current methods which we have defined in the BRs and EV guidelines to permit a
CA to issue a certificate. I am also looking for escalation processes using defined terms and requirements from the BRs and EV guidelines to allow an Applicant or Subscriber to request and authenticate the issuance of a certificate.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">That is a misleading statement. The "defined terms" refer to CA-specific processes. You're not using objective policies and practices - you're again resorting to undefined and underspecified
aspects of the BRs that allow a CA to do whatever it wants, which the entire point of CAA is to say that if we're going to allow the BRs to have these undefined practices, we need some way to limit their risk.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The alternative to CAA that accomplishes browsers' goals is removing those allowances - things like allowing the reuse of previously validated information, and of Enterprise RA
contracts, and of methods of validation other than DNS validation - and since I have no doubt that would be far more impactful and objectionable to CAs such as yourself, CAA offers a more measured path to get the damage prevention from insecure CA practices
- such as those seen recently. It's a question about one or the other - either CAA to indicate which CA's discretion is acceptable from a business risk perspective, or the removal of any ability for CA discretion or contractual agreements.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</span></div>
</div>
</blockquote></div><br></div></div></div>