<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
/* 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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1401293801;
mso-list-type:hybrid;
mso-list-template-ids:367578058 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1915358809;
mso-list-type:hybrid;
mso-list-template-ids:1581411224 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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">I agree with Ryan that the hard fail per item number 3 is the sticking point. My concern is that in many organizations, the certificate requesters are not the
DNS administrators and there could be some disconnect.<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">I think that Peter asked the question, “how does the CA currently know that they are allowed to issue certificates for a specific domain?”
<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">I think we did a good job with the BR and EV documents. We have defined certificate approvers with the Enterprise RA and the Certificate Approver. We have also
defined access controls and limits on certificate requesters.<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 answer is that we know we are allowed to issue certificates for a specific domain as we have a subscriber agreement which allows us to honor the requests
of verified Enterprise RAs and Certificate Approvers.<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">Per the BRs, an Enterprise RA is defined and has the following privileges:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">BR 1.6.1 – Definition: An employee or agent of an organization unaffiliated with the CA who authorizes issuance of Certificates to that organization.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">BR 1.3.2 - The CA MAY designate an Enterprise RA to verify certificate requests from the Enterprise RA’s own organization.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Note that if the Enterprise RA has the ability to issue a certificate then they must meet the multi-factor requirement of BR 6.5.1, “The CA SHALL enforce
multi‐factor authentication for all accounts capable of directly causing certificate issuance.”<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Also note that per BR 3.2.5, “the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates.” This
generally limits requests which have not been approved by an Enterprise RA or a Certificate Approver.<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">For EV certificates, there is a Certificate Approver:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">EV 4 – Definition: A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent
the Applicant to (i) act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and (ii) to approve EV Certificate Requests submitted by other Certificate Requesters.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Note if the Subscriber had established the BR 3.2.5 restriction, then a new Certificate Approver would not be verified unless they could be added to
the approved list.<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">In both cases the roles have the privilege to verify/approve certificate requests. As such, I do not think that we need a hard fail on CAA if the request has
been approved by an Enterprise RA or a Certificate Approver.<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">I think that the CA can limit risk by checking CAA records where there has been no verified Enterprise RA or a Certificate Approver established. In this condition,
I think that the CAA record check should be a hard fail. <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">Bruce.<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:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Ryan Sleevi<br>
<b>Sent:</b> Thursday, September 8, 2016 6:35 PM<br>
<b>To:</b> Rick Andrews <Rick_Andrews@symantec.com><br>
<b>Cc:</b> public@cabforum.org<br>
<b>Subject:</b> Re: [cabfpub] Continuing the discussion on CAA<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Sep 8, 2016 at 2:40 PM, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Additionally, I'd like to address this point: 'Ryan pointed out that, at<br>
present, nothing would prevent Neil from stating in his CP/CPS that his CA<br>
will issue certificates if he sees a CAA record for "<a href="http://symantec.com" target="_blank">symantec.com</a>" '. If<br>
Neil adopted that policy, wouldn't it violate RFC 6844, which says "The<br>
issue property entry authorizes the holder of the domain name <Issuer Domain<br>
Name> or a party acting under the explicit authority of the holder of that<br>
domain name to issue certificates for the domain in which the property is<br>
published."?<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Rick,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As you know, the IETF historically shies away from discussions of policy, and instead focuses on the technological side. We can see that certainly with PKIX (RFC 5280 & friends), and it was actually a frequently reiterated point during
the discussion of CAA through its standardization.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As such, we should imagine that CAA defines the structural representation, but it's up to the CA/B Forum to specify the policy that applies here. You can see that the document intentionally shies away from this discussion in Sections 6.1
and 6.2, and that's arguably the right thing.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The extent of my comments was to make sure that, in developing a policy for CAA (which I'm strongly supportive of, so appreciate you continuing the discussion), we make it clear what is and is not acceptable. If we were to accept that Neil
doing so would violate RFC 6844, then we must also accept that the only RFC 6844-compliant method of a CA running into the situation you propose is to Not Issue At All. That is, not even Option 1 is acceptable (since you included the parenthetical escape clause).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My "ideal" outcome for CAA within the CA/B Forum would be:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1) A requirement in the CPS to state that the CA respects CAA<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) A requirement that the CPS documents which domains the CA recognizes in CAA records. As a consequence, if a CA wishes to recognize additional domains in CAA records, this requires a CPS update.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3) A requirement that the CA honor the CAA record exactly as presented, with no overriding allowed, short of changing the DNS record.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4) A requirement that the CA maintain audit records regarding their CAA evaluation, such as:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - The order and sequence of DNS records they attempted to resolve<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - The results of those DNS records and the source of the information.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Each of these I suspect is controversial in some way, and will no doubt require more discussion, but to briefly justify this:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">#1, without #2-4, is largely toothless. However, my goal is to ensure that auditors have a consistent framework to evaluate a CA's compliance, and for the public at large as well to evaluate. If a CA says it supports CAA, and a misissuance
event occurs that contravenes that, it's natural that both auditors and the public should want to understand why and how, and setting this up within the CPS makes it clear that the CA is committed to explaining that.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">#2 is about making it clear for Subscribers and Applicants the "Right Way" to configure things. Each CA naturally is free to manage their customer relations as they wish, but it can be hard to find consistent information (such as where
to report misissuance events), and the CPS is the one universal aspect that all CAs must have and abide by, so it naturally makes sense to ensure it's in a consistent and discoverable place.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">#3 is clearly a sticking point. I think we're all pretty aware of CAs' objections to this, but I do feel strongly that, without this, CAA is not an effective security mitigation. As you know, Google holds a variety of domains, and we routinely
receive requests from other CAs attempting to confirm that an applicant was duly authorized to make a request, and we routinely have to contact CAs and request revocation for certificates that were not authorized according to our company policy. Allowing escape
clauses, even at the EVGL level, significantly weaken our ability to proactively prevent this, which we believe would reduce both ours and CAs' administrative burdens.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">#4 is less obvious. During Bilbao, we discussed how DNS resolution can be unreliable for CAs; for example, network hiccups due to peering interconnects can manifest as a DNS timeout, rather than a successful (negative) response. We also
know that CAA policies are only applicable at time of issuance, and may change, so we can't examine post-facto the CAA record of a domain and make a declarative judgement of misissuance. However, unfortunate as it is, CAA is a "fail open" rather than "fail
closed" model - any misconfiguration on the CA's part (such as forgetting to configure their DNS clients or firewalls correctly) can result in issuance, even when a domain holder explicitly requests that the CA not issue (via CAA). So we need to have some
sort of way to audit this, so that, in the event of claimed conflict, we can better ascertain what happened, and why. This is a rough sketch of an attempt to do so, but the point in particular being to ensure there's enough record to know if the CA had a bug
in their system, and to ensure enough information is preserved to understand that bug.<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">We know CAA isn't the system we'd hope for - while it presents itself as a whitelist mechanism (listing only authorized CAs) - because it's built atop the unreliable DNS, it's effectively a blacklist mechanism (any failure is interpreted
as the status quo - any CA is authorized - rather than the desired state - no CA is authorized). In an ideal world, I would wish for CAA to be required, and present, in order for a CA to issue a certificate, but I know that world is unlikely to ever come about,
and so I'd at least be willing to settle on #1 - #4 as an improvement to the status quo.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>