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 tr
On Sat, Feb 8, 2025 at 9:44 AM David Adrian 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 Vancouv
>
> 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
>
I think we should abandon this effort and not publish.
When initially proposed this was supposed to be documenting a
deployed reality. I could just about hold my nose with that,
but adding in ECH (for which key exfiltration is not currently
deployed, nor seemingly needed) and the IANA considerat
Aha, that sounds like the disconnect! One trust anchor identifier indeed
only represents a one trust anchor. And, yeah, absolutely agreed that's a
significant difference!
I'm guessing this mixup came from the talk of user agent strings in the
problem-space-focused interm? TBH, I was quite perplexe
Pull requests
-
* tlswg/draft-ietf-tls-svcb-ech (+0/-2/💬0)
2 pull requests merged:
- Mention situations that result in mixed ECH/non-ECH
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/22
- Add a reference for traffic analysis
https://github.com/tlswg/draft-ietf-tl
