Sam Hartman <hartm...@debian.org> writes: >>>>>> "Russ" == Russ Allbery <r...@debian.org> writes:
> Russ> debian.org already publishes a CAA record, which conveys that > Russ> information (although has its own verification concerns, but I > Russ> think debian.org is using DNSSEC so you can verify the record > Russ> that way). It says that all debian.org hosts will only use > Russ> certificates from either LE or Amazon: > Russ, you may be more up to date on webpki than I am. > Does that say anything about which root letsencrypt will chain to? > I.E. can letsencrypt change what their chain looks like? It does, but that's because it's not the greatest for clients, which makes it a touch hard to use on the dgit side. My understanding is that the CAA record is intended as a constraint on CAs, not really a verification step for clients. A CAA is not supposed to issue certificates for a domain that has a CAA record and that doesn't list that issuer. Because of that, the interpretation of the CAA record is somewhat up to the domain. It's intended to protect you against legitimate CAs being socially-engineered to issue a certificate for your domain. That also means there's no easy way to map a CAA record value to a specific certificate or certificate chain. It therefore doesn't solve the dgit problem directly, but it does provide some verification that debian.org domains are only going to use LE (and Amazon) certs unless that CAA record changes, and therefore dgit could do client-side certificate pinning to those two certificate chains, at the cost of having to manually track changes to those chains. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
