<div dir="ltr"><div>Hi Bruce,</div><div><br></div><div>Could you explain more about the enterprise CA scenario? Were you thinking technically-constrained sub-CA, or independently operated sub-CA (since you can't delegate domain validation to an enterprise RA, and the validation has to be performed by the CA)</div><div><br></div><div>For a TCSC, this doesn't change the requirements, so that should be fine.</div><div><br></div><div>For an independently operated third-party CA, in order to take advantage of this exception, they have to implement an even <i>more</i> complex validation flow than CAA. This was meant to provide an escape hatch for organizations who were using DNS libraries that didn't support CAA, but doesn't absolve them of at-issuance verification (to determine they're the DNS Operator).</div><div><br></div><div>From examining CP/CPSes (where CAs need to disclose this), I'm only aware of a very small list of CAs that rely on this, and they already support CAA (this is largely just a fallback mechanism for them).</div><div><br></div><div>So that's the rationale for the window being July, even though all indications (including from those CAs) is that this could be effective immediately, if not for the CPS update requirement.</div><div><br></div><div>That said, if you're aware of things being overlooked or concerned about other impact, totally open for discussion on that technical merit.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 8, 2021 at 8:49 AM Bruce Morton <<a href="mailto:Bruce.Morton@entrust.com">Bruce.Morton@entrust.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_1732532287117199915WordSection1">
<p class="MsoNormal">No objection to sunsetting the CAA exception. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Although this change will not impact Entrust, I would be concerned if the exception is being used by an dedicated enterprise CA which has not implemented CAA. In this case the 3 months give or take, which is really about 1 month after IPR,
 would probably not be sufficient for this type of CA to implement CAA.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I would consider giving a more than generous period to implement. This would allow the ballot discussion to be based on its technical merit and eliminate the debate on time to implement.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Bruce.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Ryan Sleevi via Servercert-wg<br>
<b>Sent:</b> Wednesday, April 7, 2021 5:29 PM<br>
<b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br>
<b>Subject:</b> [EXTERNAL] [Servercert-wg] Seeking endorsers: Draft ballot to sunset the CAA exception<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<u></u><u></u></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<div>
<p class="MsoNormal">I'm looking for endorsers to a draft ballot to sunset the CAA exception afforded to DNS operators.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">You can see the proposed language is available at <a href="https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/main...sleevi:caa_exception__;!!FJ-Y8qCqXTj2!I_8LQ0eTPSBoT_3giJUD1Eb3uHqVjOAibYmX61fOZBfUFcoXqBpkX57XaeoXnC-FpUA$" target="_blank">https://github.com/cabforum/servercert/compare/main...sleevi:caa_exception</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The motivation is fairly simple: In looking at CA practices and CA incidents, the current implementation introduces significant risk in terms of CA's understanding the requirements and appropriately implementing them.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The logic involved in determining whether or not the CA is the DNS Operator is quite complex, and requires a thorough knowledge of DNS protocols. In practice, what we've seen is CAs simply self-attesting that they are the DNS Operator,
 and not implementing those checks as required, which then further leads to non-compliance incidents that CAA can and would have prevented.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Given that it's now been several years of CAA, and we've seen it already used to enhance and improve our validation methods, requiring a consistent checking of CAA (with the exception of technically-constrained sub-CAs or when the CA has
 already logged a pre-certificate) seems like a reasonable balance.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The CT Log exception is also tricky, and so it may be worth revisiting whether it's necessary, but this ballot doesn't do that yet.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The sunset proposed is three months from now (give or take), which was chosen because the actual use/reliance upon this exception is quite rare, and the CAs that currently rely on it already have some form of CAA checking implemented, to
 the best of my knowledge. If there are concerns with the timeline, concrete details, as always, are welcome.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>

</blockquote></div></div>