On 22/07/2024 12:28, Ilari Liusvaara wrote:
I don't see TE requiring breaking API changes on client: API that lets one add a set of (pseudo) trust anchors plus TE advertisement for those should work?
I agree adding a new API for T.E. which applications could opt in to would be fine. But could T.E. ever be enabled by default without breaking the existing API and requiring application changes?
For example, applications which access the server certificate via a callback or after handshake completion are going to be surprised by anything non-X.509 and also likely differ in policy from the system trust store (making any use of the system root store's trust expression label by default quite troubling).
Similar issues apply for where applications configure the TLS certificate validation policy in advance, ship their own root store (even if its say a copy of an existing one) or hook up a custom certificate validation library.
Server-side both require much more extensive API changes. However, I think that it is feasible to add support without breaking API changes (by extending certificate loading to support alternate issuer chains).
A similar picture seems to apply here. Adding a new API is fine but then needs server-side applications to opt in to using it. Otherwise overloading existing file / directory mechanisms might be possible if there's not too many fussy applications out there which are going to barf.
I'm pretty pessimistic about these API issues (Hyrum's Law etc) but I haven't had much exposure to OpenSSL's APIs from the perspective of other clients / servers - so curious if you do see a way to enable it by default without changing existing applications.
Best, Dennis
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
