On Tue, Apr 23, 2024 at 01:37:26PM -0700, Devon O'Brien wrote: > After sharing our first draft of TLS Trust Expressions > <https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/> and > several discussions across a couple IETFs, we’d like to proceed with a > call for working group adoption of this draft. We are currently prototyping > trust expressions in BoringSSL & Chromium and will share more details when > implementation is complete. > > As we mentioned in our message to the mailing list from January, our > primary goal is to produce a mechanism for supporting multiple subscriber > certificates > <https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md> > and efficiently negotiating which to serve on a given TLS connection, even > if that ends up requiring significant changes to the draft in its current > state.
The negotiation mechanism mostly looks OK. Might need a few tweaks, e.g.: - Sorting the TrustExpressionList in some canonical order, to simplify TLS server a bit. - Adding record type to TrustExpression for future extension (with unknown trust expressions ignored). The subscriber side is far more challenging. The core issue is that applications act as middlemen between ACME client and TLS library, and those are very variable bunch. There currently is no way of passing the information required, so some application changes will be required. The issue is application limitations that would require drastic changes, which are discouraged, to remove. Examples of application limitations that might be very hard to fix: - Application selects one subscriber certificate to use. - Application selects some fixed (unchangeable by ACME client) N subscriber certificates, and then the TLS library selects among those. And there are very popular applications that are like this. However, even with fixed subscriber certificate, it is still valuable to be able to select among available issuer chains. Some can be significantly smaller than the others (e.g., 1119 bytes vs. 701 bytes vs. 0 bytes). Things get even more lopsided with post-quantum certificates. This would lead to model where the certificate files have: - Subscriber certificate - Default issuer chain - Alternate issuer chains, together with negotiation data. The application would then pass these to the TLS library, which would perform the final merging of data across possible subscriber certificates, and then perform subscriber selection and issuer chain selection from available candidates. And even if alternate issuer chains seem to be associated with the issuer, there is a subtle issue: Name constraints can differ among possible issuer chains. This can happen due to: - explicit name constraints present in some intermediates but not others. This has happened, and led to divergent name constraints. - Root programs imposing implicit name constraints on roots. This has also happened (but I don't know if this has led to divergent name constriants). > To that end, we’re interested in learning whether wg members support > adoption of this deployment model and the currently-described certificate > negotiation mechanism or if they oppose adoption (and why!). The bar to clear for adoption is "good starting point", which this seems to be, even if the details of mechanism do not work out (as detailed above). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
