On Sat, Feb 8, 2025 at 9:44 AM David Adrian <davad...@umich.edu> wrote: > > 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)
Somewhat of a side note: I was under the (possible mis)-impression that the trust anchor indicator was originally an indicator of the complete set owned by the client (which I think is what trust store name and version meant), not one per root, vs. compressing the already existing authorities_extension without needing a shared dictionary (which trust anchor identifiers now does). While this might seem like a small difference it has a rather large impact on the impact of clients that CAs don't care about to implement. Separately: A DNS based hint of what indication would be useful to send solves some problems but not others. It doesn't really help servers determine what the universe of clients is supporting and isn't that they see without some more information. Sincerely, Watson > > 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 -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
