On Thu, Oct 22, 2020 at 1:05 PM Ryan Sleevi <[email protected]> wrote:
> > > On Thu, Oct 22, 2020 at 11:59 AM Anton Luka Šijanec <[email protected]> > wrote: > >> Hello! >> >> ... > 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. > All correct. But when I originally proposed CAA, we did not have Certificate Transparency. Nor was DNSSEC deployed. Also, the very first draft of CAA was joint with Ben Laurie and we were proposing using CAA as a means of publishing data of that sort. If the application warranted it, you could establish a check of CAA by pickling the DNSSEC validation chain in the CT logs (we did consider a cert extension). The problem with trying anything of that sort is that PKIX is now patches on patches on patches and this is a lot of complexity for not very much advantage. The WebPKI was originally designed as an authentication and accountability infrastructure to enable online commerce. It is used for much more but many of the constraints imposed by that original application make it a really poor choice for a lot of applications even if Lets Encrypt is giving free certs. WebPKI certs are bound to DNS names. WebPKI certs have a fixed expiry. Neither of those properties is appropriate for the purpose of establishing a secure conversation with my WiFi router, my coffee pot, etc. etc. Another limitation on WebPKI is that it is built using 1980s public key cryptography and the state of the art in crypto is now threshold.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
