On Thu, Oct 22, 2020 at 11:59 AM Anton Luka Šijanec <an...@sijanec.eu> 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 someone@else.example. Then someone.example issues a lot of > certificate signing requests to CAs that are not allowed for his > domain, filling someone@else.example'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: > report@violation.example", 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.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
