Hey Ilari, I think you are still misunderstanding the scheme. To clarify:
On 01/03/2024 18:01, Ilari Liusvaara wrote:
The unrecognized identifier issue is a bit more subtle. Suppose that a client: - Has only partial list of certificates (enough to cover the built-in trust store). - Allows an admin to add a new trust anchor, or to override validation error. Then such client can get into situation where server sends chain that should be valid, but instead references a certificate the client does not have. Which is a hard error.
As laid out in 3.1, this draft works with a fixed list of certificates. Clients cannot use the scheme if they are not willing to have a full list of the certificates. Clients can trust a superset or subset of roots that are present on the list, any certificates not in the fixed pass 1 list are simply not compressed in that pass. A key goal of this draft is not to risk any breakage (unlike with suppressing intermediates).
If you have any editorial feedback on where you think this part of the draft is unclear, suggestions are welcome. I'm not sure where you've got the idea that only partial lists of certificates are possible.
Best, Dennis
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
