[cabfpub] Continuing the discussion on CAA

Jacob Hoffman-Andrews jsha at letsencrypt.org
Tue Oct 18 18:26:59 UTC 2016

On Mon, Oct 17, 2016 at 11:11 AM, Rick Andrews via Public <
public at cabforum.org> wrote:

> Posting to public list (seems to have been dropped)
> I'll need to poll folks internally, but Symantec would probably support
> this.
> How do other CAs feel?
> -Rick
> -----Original Message-----
> From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> Sent: Monday, October 17, 2016 7:41 AM
> To: Gervase Markham <gerv at mozilla.org>; Bruce Morton
> <Bruce.Morton at entrust.com>; Ryan Sleevi <sleevi at google.com>; Rick Andrews
> <Rick_Andrews at symantec.com>
> Subject: RE: [cabfpub] Continuing the discussion on CAA
> I'd support a position if CAA was a validation check rather than an
> issuance
> check. That way there isn't a difference between "enterprise" and "retail".
> Instead, it's tied to the domain validation process and is required
> whenever
> domain validation is required.

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.

So, we also have a preference for checking CAA at validation time.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161018/2cd95b61/attachment-0003.html>

More information about the Public mailing list