Subject: Re: [Acme] CAA DNS RR IODEF e-mail spam && client side CAA verification

From: Ryan Sleevi <[email-masked]>
Date: Thu, 22 Oct 2020 13:04:48 -0400

On Thu, Oct 22, 2020 at 11:59 AM Anton Luka Šijanec <[email-masked]>
wrote:

> Hello!
>
> I hope I am addressing this e-mail to the correct mailing list. After
> glancing through the CAA DNS RR specifications for allowing only
> specific CAs to issue certificates for a specific domain, I saw that
> the iodef field for specifying the URI for sending violations is not
> verified when submitting reports to different domains.
>
> What I mean by this is that someone.example can specify an email
> address of [email-masked]. Then someone.example issues a lot of
> certificate signing requests to CAs that are not allowed for his
> domain, filling [email-masked]'s inbox with violation spam.
>
> I propose a system, such as the one used for DMARC, to allow
> whitelisted cross-domain violation email delivery.
>
> For example, if IODEF field of caa.example specifies "mailto:
> [email-masked]", CAs will before sending a report check if
> the TXT record caa.example._caa.violation.example. has a value of
> "CAA=v1; caa-reports=allow;" or something similar.
>
> If such a system is already in place, how can I make sure I am
> correctly implementing it on my domain? Can someone direct me to the
> specification?
>
> My second suggestion is that client browsers would verify certificates
> by performing DNS CAA queries and validating if the certificate is okay
> and optionally send violation reports. What are your thoughts?

This is intentionally, and explicitly, not part of CAA. CAA is designed as
an ACL on issuance; were clients to check, this would necessitate that
domains continue to authorize future certificate issuance.

For example, if I used CA A at Time 0, but later switched new issuance to
CA B at Time 10, if clients checked at Time 11, I would be required to list
both A and B as authorized; A, because it had authorized some of my
existing certificates, and B, because it was authorized for new
certificates.

Short of replacing every unexpired, unrevoked certificate from A, I would
not be able to safely and securely only authorize B going forward.

Section 1 of RFC 8659 makes this unambiguous:
> Relying Parties MUST NOT use CAA records as part of certificate
validation.