[cabfpub] Continuing the discussion on CAA

Ryan Sleevi sleevi at google.com
Tue Oct 25 15:21:41 UTC 2016

On Tue, Oct 25, 2016 at 1:57 AM, Gervase Markham via Public <
public at cabforum.org> wrote:
> I think this is definitely worth exploring, and I am confident we can
> work out some reasonable parameters. However, I wonder if, if we are not
> checking CAA at every issuance, it would be wise for CAs to be required
> to implement a "no more certs, please" procedure where the customer can
> tell the CA to throw away all cached validation information, including
> the CAA check results. This could be automated in circumstances where
> the customer has a login.

I think it may also be useful to do this for non-customers, but domain

Consider the following certificate: https://crt.sh/?id=35360532

It was issued 2016-09-26 to a customer on Google service's
Since roughly 2016-03-31, googleusercontent.com has had a CAA record of 0
issue symantec.com

So why was this certificate issued? Well, as Jacob mentioned in
https://cabforum.org/pipermail/public/2016-October/008576.html , Let's
Encrypt checks CAA at validation time, not issuance time. Despite our CAA
record helpfully preventing any new validations, this particular user had a
pre-existing cached validation, according to Let's Encrypt, and so the new
certificate was issued using the pre-existing validation.

Ironically/unfortunately, it was this pre-existing validation (
https://crt.sh/?id=14639682 ) that lead us to place CAA on the domain to
begin with.

Now, I'm not suggesting Let's Encrypt has misissued this certificate - it's
why I've been continuing to call it 'unauthorized' issuance - and with
respect to the BRs, everything LE did was correct. In particular, the
re-use of cached information is fully permitted in the BRs (as many CAs
know). However, from a our perspective, this was certainly 'a surprise' and
not intended.

So if we're going that route, I do believe we need to set a much tighter
upper-bound than the currently permissible 39 months. Unlike WHOIS
information, for which we know some registrars don't provide or some
registries make it considerably more difficult (c.f. the CAPTCHA/OCR issues
of Comodo recently), CAA is something that any domain holder can express or
maintain themselves, and any CA can query.

So it seems like one week or so should be the upper-bound to how long this
information can be re-used.

As for how we're dealing with this unauthorized issuance, at least with an
LE model, we need to submit every one of these 'unauthorized' certificates
as problem reports, and hope that Let's Encrypt agrees with us on the basis
of domain holder, and then hope that the associated cached data is thrown
away. Further, for what it's worth, the BRs do not require that such cached
info be thrown away on a problem report - that's simply Let's Encrypt going
above and beyond the BRs to do what is common sense and necessary for
security, and which other CAs may not be at that same level of maturity.

> > 2) If a customer has a single base domain and needs to issue 6 million
> certs
> > an hour for the various sub domains, then there isn't a way for the CA to
> > simply accept the base domain's CAA record.
> I'm not sure how to address this without changing the way CAA works.
> AIUI it's specced to work from the requested domain down to the root. So
> I'm not sure I'd say this problem is "easily solved". Does PHB have a
> comment?

I'm not PHB, but you're absolutely correct that it's "not how CAA works".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161025/1bba8ec9/attachment-0003.html>

More information about the Public mailing list