[TLS] Re: PKI dynamics and trust anchor negotiation

[Watson Ladd <[e-mail]>]

On Sat, Feb 8, 2025 at 9:44 AM David Adrian <[e-mail]> 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=[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]



--
Astra mortemque praestare gradatim