Re: The Difference between debcheckout and dgit and what they try to accomplish
Sam Hartman <hartmans@debian.org> writes:
>>>>>> "Russ" == Russ Allbery <rra@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: