On Fri, May 24, 2024 at 06:14:00PM +0100, Dennis Jackson wrote: > > Trust Expressions, though intended to solve completely different problems, > will accidentally eradicate both of these advantages. Firstly, it provides a > nice on ramp for a new domestic trust store, mostly through the negotiation > aspect but also through the CA pre-distribution. Secondly, by enabling > fragmentation along geographic boundaries whilst maintaining availability of > websites. Without Trust Expressions, we cannot balkanize TLS. With Trust > Expressions, we can and we know people who want to (not anyone in this > thread).
One detail of Trust Expressions is that the extension value is TrustExpressionList, not TrustExpression. That is, client can signal support for multiple root programs. Thus, client X in region Y would signal X+Y, not X_Y to the server. The server that does not want to care about Y can then pick X (which is global) and send certificate accordingly. If getting cert in Y is way more painful than getting cert in X, that is further incentive to do just that... And that one region is one of those cases. And even if it isn't more painful, having more certificates is still more painful, so there is incentive to avoid that. The acknowledgement does not say which root program the server used. > I would suggest we focus our discussion on the use cases of Trust > Expressions and how exactly it would work in practice - these concerns I > shared earlier in the thread are solely technical and operational and you > and I might be able to make better progress towards a common understanding. As for my guesses about how well Trust Expressions would work in practice for various cases presented: - It would not make CA distrusts less painful. I expect most sites do not have alternate certificates that are not off some oddball issuers for some weird devices. Such certificates are not usable for browser usecases, as those either have never been in the trust store, or have fallen out of it. - It is very effective at intermediate suppression. If the client can keep up even remotely up to date, I expect ~100% supression. This includes compat cross-signs that will pop up if root programs shorten root lifetimes. - It does help Post-Quantum deployment quite a lot. Without, until major four all accept common roots, PQ transition is dead in the water. And if site needs to deal with oddball clients, it is dead until quantum armageddon. Not a good place to be, to put it mildly. The SHA-1 to SHA-2 transion was rather painful and took over 10 years. - It could be used for migrating stuff off WebPKI. There is all sorts of stuff tacked on WebPKI that is constant source of pain (especially in any sort of transitions). Getting it off WebPKI into private PKIs would cut the pain by quite a bit. TE could be used that way. I propose API in client TLS libraries that let's cliet use a custom root program, that then gets signaled to server via TE. I do plan to add such API to the TLS library I wrote (later, when TE can archive interop). -Ilari _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
