To be clear, the client does NOT send its full list of trust anchors by default. There is a server-side DNS signaling mechanism that allows the client to pick a single anchor without sending the full set.
The feedback at IETF Vancouver was to move away from a client signals, server selects (via trust store name and version) to a server signals, client selects (via OIDs in DNS) On Sat, Feb 8, 2025 at 3:12 AM Bas Westerbaan <bas= 40cloudflare....@dmarc.ietf.org> wrote: > Silly clarification: the TAI identifier is just a compact identifier >> for the root cert, like (making it up) a 4 byte identifier? So the >> client sends the entire list of root certs supported, so about 100, so >> 400 bytes? >> >> In that case I think you can inject it into an end-entity cert on >> issuance, and into the root representations in the trust store. > > > Yeah, this is an interesting alternative design. You can reduce the size > quite a bit more with simple compression techniques. See > > https://github.com/davidben/tls-trust-expressions/issues/64 > https://github.com/bwesterb/go-ncrlite > > > >> Where >> this doesn't work out well is on cross signs where the cert can root >> to multiple places/when more than one cert is needed to cover and the >> config only has one, but this would solve a bunch of the issues for >> command line programs where the trust store format is a bag of certs >> on disk. It could also work for cross signs since the intermediates >> used are known by the CA. >> >> Sincerely, >> Watson >> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
