<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:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
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;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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">There also appeared to be a misunderstanding on the call that the CAA spec requires bottom up checking in order to adhere to the requirements of the spec, and
this would preclude checking the top element first. This is false.<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">While it’s possible to implement the CAA spec by having bottom up checks that stop when they find a CAA record, it’s also possible to get the exact same behavior
by checking from the top down, and using the last (instead of first) CAA record you see.<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">The first algorithm is more efficient when the majority of sites have CAA records (since you can terminate the search), but they’re equivalent in the case where
the vast majority do not. And the second algorithm allows the “skipsubdomain” behavior to be added. Even better, CAA w/ skipsubdomain is the most efficient case.<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">As I noted previously, I’m actually rather fond of that option to give site administrators even more control over the policy for their site. I’d even be tempted
to put a Trustwave CAA record with skipsubdomain on the root of our site, to enforce a uniform policy without having to worry about which portions of lower level DNS are controlled by whom.<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">-Tim<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>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<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""> Public [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Jeremy Rowley via Public<br>
<b>Sent:</b> Friday, October 28, 2016 6:06 AM<br>
<b>To:</b> CA/Browser Forum Public Discussion List<br>
<b>Cc:</b> Jeremy Rowley<br>
<b>Subject:</b> Re: [cabfpub] CAA concerns (and potential solutions)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Thanks Peter – we’d support this. There is the one additional concern Microsoft raised yesterday. If a CA is issuing only for domains where it is the registrant then implementing
CAA is a substantial expense with little benefit. This is especially true where the CA has a technically constrained intermediate (as Ryan pointed out on the Mozilla list, a technically constrained intermediate is not exempt from the BRs, instead the CA is
responsible for the audit portion). Any thoughts on how to address Jody’s issue?
<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"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<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""> Public [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Peter Bowen via Public<br>
<b>Sent:</b> Thursday, October 27, 2016 9:33 PM<br>
<b>To:</b> CABFPub <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
<b>Cc:</b> Peter Bowen <<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>><br>
<b>Subject:</b> [cabfpub] CAA concerns (and potential solutions)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">From the discussion at the F2F last week and the call today, it seems there are two major concerns about CAA.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The first concern is that a large organization may have internal miscommunication or disconnects and valid authorized certificate requesters may be blocked from getting certificates. This primarily is a concern for CAs that offer contracts
for persistent issuance capability, frequently combined with the CA delegating authority to the organization to act as RA for FQDNs and Wildcard DNs falling within pre-validated domains (“Enterprise RA”).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In this case, it is very possible that there are three independent portions of the organization: one handling domain registration, one managing DNS, and one managing certificates. These different portions may have little routine interaction
and action by one (DNS) could unintentionally negatively impact another (certificates).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I propose that this be mitigated by adoption a two prong rule for CAA:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1) By default CAs must treat the presence of CAA records which do not include them as “hard fail” and not issue<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) However, if the CA has issued an Enterprise EV RA certificate containing a valid authorization domain, logged it in at least <n> public CT logs, the CA may treat CAA for those FQDNs and Wildcard DNs matching the authorization domain
as “soft fail” and issue even if the CAA record specifies otherwise.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The CA must internally log any certs that are issued after a “soft fail” and report such via any iodef in the CAA record. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Additionally, browsers may implement further reporting requirements, such as: CAs MUST send a report at least once every 90 days to <a to be designated location> that lists the number of base domains they issued for after getting a soft-fail.
Such reports shall cover a period that begins with the end of the period of the prior report and concludes not more than 7 days prior to the date of the report.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The second concern is around issuance latency. If a certificate has dozens of subject alternative names or a CA is issuing massive number of certificates the full CAA checking algorithm can be slow, especially if there are no CAA records
as each label must be checked back to the root. In order to allow for optimization, I propose the following variances and extensions to the CAA spec:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1) a new parameter tag for issue and issuewild properties: “skipsubdomaincheck" which can be “true” or “false”. The default value is “false”. If true, it indicates that a CA may skip checks for more specific subdomains.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) extending the “domain” definition to be (<span style="font-size:10.0pt">label *("." label)) / “*”; a “*” is an explicit declaration that there is no CA restriction (the opposite of an empty domain name)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">3) CAs may choose to check starting at the TLD and working their way down the tree of labels rather than starting with all labels and working towards the root. If they choose this option they must use the
most specific CAA record found unless they find a record with skipsubdomaincheck=true. If they find such a record, they may use that record and not check any further labels.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">This should allow customers who have a need for massive issuance rates of unique hostnames to enter a CAA record at the common suffix label allowing the CA to have a near 100% cache hit rate on DNS look ups.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">For example, if a customer requests ten million certificates all in the form <some label>.<a href="http://scanmail.trustwave.com/?c=4062&d=uaOT2ACDlVREXGMYuMJ5w83tOeFkqt56KmULlWlfKA&s=5&u=http%3a%2f%2fthings%2eexample%2ecom">things.example.com</a>,
they can enter a CAA record:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt"><a href="http://scanmail.trustwave.com/?c=4062&d=uaOT2ACDlVREXGMYuMJ5w83tOeFkqt56KmULlWlfKA&s=5&u=http%3a%2f%2fthings%2eexample%2ecom">things.example.com</a>. IN CAA 0 issue “*"; skipsubdomaincheck=true</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">This would indicate any CA may issue and allow the CA to only do the following checks:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">com. IN CAA</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt"><a href="http://scanmail.trustwave.com/?c=4062&d=uaOT2ACDlVREXGMYuMJ5w83tOeFkqt56KmQNljgNLg&s=5&u=http%3a%2f%2fexample%2ecom">example.com</a>.</span> IN CAA<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="http://scanmail.trustwave.com/?c=4062&d=uaOT2ACDlVREXGMYuMJ5w83tOeFkqt56KmULlWlfKA&s=5&u=http%3a%2f%2fthings%2eexample%2ecom">things.example.com</a>. IN CAA<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">I think that these proposals provide reasonable mitigations for the concerns raised while still allowing CAA to provide significant benefit.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Thanks,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Peter</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.<br>
</font>
</body>
</html>