[TLS] Re: PKI dynamics and trust anchor negotiation

[David Adrian <[e-mail]>]

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=
[e-mail]> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>