<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 9, 2016 at 10:48 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_-6768152368494706811WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">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></p></div></div></blockquote><div><br></div><div>I think you're missing that it's somewhat core to the discussion.</div><div><br></div><div>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.</div><div><br></div><div>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)</div><div> <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><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_-6768152368494706811WordSection1">
<p class="MsoNormal"><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></p></div></div></blockquote><div><br></div><div>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.</div><div> </div><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_-6768152368494706811WordSection1"><p class="MsoNormal"><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></p></div></div></blockquote><div><br></div><div>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.</div><div> </div><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_-6768152368494706811WordSection1">
<p class="MsoNormal"><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:<u></u><u></u></span></p>
<p class="m_-6768152368494706811MsoListParagraph" style="margin-left:38.4pt">
<u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Accept the Subscriber agreement<u></u><u></u></span></p>
<p class="m_-6768152368494706811MsoListParagraph" style="margin-left:38.4pt">
<u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><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<u></u><u></u></span></p>
<p class="m_-6768152368494706811MsoListParagraph" style="margin-left:38.4pt">
<u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">All Base Domain Names would have to be pre-validated<u></u><u></u></span></p>
<p class="m_-6768152368494706811MsoListParagraph" style="margin-left:38.4pt">
<u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><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<u></u><u></u></span></p>
<p class="m_-6768152368494706811MsoListParagraph" style="margin-left:38.4pt">
<u></u><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><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
<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">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></p></div></div></blockquote><div><br></div><div>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. </div></div></div></div>