<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 17, 2016 at 11:11 AM, Rick Andrews via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Posting to public list (seems to have been dropped)<br>
<br>
I'll need to poll folks internally, but Symantec would probably support this.<br>
How do other CAs feel?<br>
<br>
-Rick<br>
<br>
-----Original Message-----<br>
From: Jeremy Rowley [mailto:<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert<wbr>.com</a>]<br>
Sent: Monday, October 17, 2016 7:41 AM<br>
To: Gervase Markham <<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>>; Bruce Morton<br>
<<a href="mailto:Bruce.Morton@entrust.com" target="_blank">Bruce.Morton@entrust.com</a>>; Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>; Rick Andrews<br>
<<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>><br>
Subject: RE: [cabfpub] Continuing the discussion on CAA<br>
<br>
I'd support a position if CAA was a validation check rather than an issuance<br>
check. That way there isn't a difference between "enterprise" and "retail".<br>
Instead, it's tied to the domain validation process and is required whenever<br>
domain validation is required.<br></blockquote><div></div></div><br></div><div class="gmail_extra">Let's Encrypt checks CAA at validation time rather than issuance time, because DNS checks are slow and unreliable. Doing the check at validation time allowed us to consolidate the external-facing parts of our process into a single component, and monitor the performance of that component with the knowledge that it is affected by factors outside our control.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, we also have a preference for checking CAA at validation time.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regarding Gervase's comment about where in the process to do a high-risk domain check: Let's Encrypt does a high-risk domain check against a static list both at validation time and at issuance time, because it is very cheap to do.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Hard vs soft CAA enforcement: Let's Encrypt doesn't allow human override when we find a CAA record that forbids issuance. The number of support requests we get due to incorrect CAA records is vanishingly small, though I acknowledge that providers with a different customer mix might get different results.</div><div class="gmail_extra"><br></div><div class="gmail_extra">DNS fail open or closed: Let's Encrypt currently treats a SERVFAIL when looking up CAA as "no CAA record present, okay to issue." However, we are working to change this, so a CAA SERVFAIL will prevent issuance. In our investigations we've found that 0.1% of domains with a current Let's Encrypt certificate return SERVFAIL for CAA.</div></div>