<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:"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.m-6768152368494706811msolistparagraph, li.m-6768152368494706811msolistparagraph, div.m-6768152368494706811msolistparagraph
{mso-style-name:m_-6768152368494706811msolistparagraph;
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">I think the “blocked by a change to a CAA record” is important to the discussion and does not need evidence to be supported. I’m looking at this as error handling
for an improper CAA record. Experience tells me that since CAA is new there will be errors. I assume that errors have also happened with other controls such as HPKP. I think our policy should consider errors.<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 also assume that a person signing a Subscriber agreement is more authorized to accept the agreement than a DNS administrator is at declining an agreement. I
do not see agreement, contract, etc. in the RFC.<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 would prefer if we started CAA with minimum requirements and then make these requirements more strict over time, rather than creating a policy which is very
strict with no back-out clause, when there has not been enough CAA records to gain any new experience.<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"> Ryan Sleevi [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Wednesday, November 9, 2016 1:58 PM<br>
<b>To:</b> Bruce Morton <Bruce.Morton@entrustdatacard.com><br>
<b>Cc:</b> CA/Browser Forum Public Discussion List <public@cabforum.org>; Doug Beattie <doug.beattie@globalsign.com><br>
<b>Subject:</b> Re: [cabfpub] Draft CAA motion<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 Wed, Nov 9, 2016 at 10:48 AM, Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.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">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I do think that the random person executing a contract with a CA is out of scope of the CAA discussion.
This issue can potentially already happen with or without a CAA policy. I do not think this is an issue with OV and EV certificates.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think you're missing that it's somewhat core to the discussion.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If I place a CAA record that says "Only Entrust shall issue", then presumably, I have a contract with you (or will soon have one). If I have a contract with you, then per 3.2.5 of the BRs, I can further limit that scope of issuance to just
named parties.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If we take CAA out of the equation, then I have no way of notifying you who the authorized parties are - you could end up signing a contract with anyone. With CAA, I gain the ability to combine with the existing BRs to sufficiently prevent
against internal misissuance - in *addition* to preventing external misissuance (as previously discussed with the Amazon/Microsoft/Google hosting scenarios)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think the primary CAA goal is to assure that a random unidentified person does not receive a certificate
where the CAA record does not authorize the CA for issuing. </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That is a goal, but I think it's unnecessarily crippling to suggest that's the only goal. As has been discussed in several calls and the F2F, the flexibility to limit which CAs can issue opens up for a host of new opportunities for domain
holders to specify their policies, and reduce the risk of a CA being lax, compelled, or fooled into issuing a certificate to a person not authorized - internally or externally.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">This could also be extended to stopping an random person from creating an account where the data is
pre-verified if the verification fails the CAA check. I also hope the goal is to allow a company to contract a CA to issue tens, hundreds or thousands of certificates per year without suddenly being blocked by a change to a CAA record.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think the preponderance of evidence on this thread have shown that this claim - "blocked by a change to a CAA record" - is not supported. If you have any data or experience to show it is, I think that'd be very useful - and indeed, I
appreciate Gerv's clause that tries to move us beyond the circular discussions claiming (without evidence or experience) that it will be a problem.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">There are minimum requirements for an enterprise to open a certificate management service, such as:</span><o:p></o:p></p>
<p class="m-6768152368494706811msolistparagraph" style="margin-left:38.4pt"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Accept the Subscriber agreement</span><o:p></o:p></p>
<p class="m-6768152368494706811msolistparagraph" style="margin-left:38.4pt"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">All organization names would be pre-validated to OV or EV requirements</span><o:p></o:p></p>
<p class="m-6768152368494706811msolistparagraph" style="margin-left:38.4pt"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">All Base Domain Names would have to be pre-validated</span><o:p></o:p></p>
<p class="m-6768152368494706811msolistparagraph" style="margin-left:38.4pt"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Enterprise RAs would be validated by contacting the enterprise using a Reliable Method of Communication</span><o:p></o:p></p>
<p class="m-6768152368494706811msolistparagraph" style="margin-left:38.4pt"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">All certificate requests or API implementations would have to be approved by the Enterprise RA
</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think that we should be able to come to an agreement to use CAA to block an unauthorized CA from
issuing in over 99% of the cases. I’m also hoping we can find a way to allow a verified enterprise Subscriber to have successful certificate requests without suddenly being blocked by CAA.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Again, I think we've spent considerable time trying to unpack what this "blocked by CAA" claim represents, but so far, all representations have been shown to either be hypothetical or unsubstantiated, while those proponents in favor of
a harder stance have demonstrated both the value and the ease at which it can be implemented. I'm unclear if we're simply at the point where you cannot be convinced it's not an issue, and if so, if you're willing to offer any ground to compromise by adopting
a more secure stance, given the issues raised. <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>