On Mon, Jul 22, 2024 at 1:36 PM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote:
> I would like to hear from the authors (or others in the TLS implementation > community) if they think Trust Expressions / Trust Anchors can be pushed > into non-browser endpoints by default and the work they think would be > required to achieve it? > > I think I see how, with substantial investment, an application like a > browser could adopt these designs. I'm not sure I can see a TLS library > ever being able to offer it by default. > Today, TLS libraries used in “general purposes” systems, like the default HTTP libraries or such for languages, have a pretty simple model of trust: list of certs, each with notBefore/notAfter/eku at best. Already that lags behind some of the nuance that web browsers use, whether Mozilla’s simple notBefore-of-issued-cert measure, or Chrome’s more complex SCT time validation. As an example, the popular Python package “certifi” provides a set of “curated” roots, which is actually the Firefox root set. When Firefox stopped trusting certificates issued by “e-commerce management” after a certain date, that package removed the root entirely, meaning that unlike with Firefox (and Chrome), all previously issued certificates were also rejected. We’re in the early days of these “bounded trust” capabilities, and I have some hope that we will settle into a small number of additional rules that are sufficient to make root distrust (or scope reduction) easier on the ecosystem. At that point, libraries like OpenSSL will need to decide if they want to be able to reflect the web PKI (as interpreted by at least one browser, anyway), in which case they will need to add these sorts of checks, and root store providers will need to configure them. Maybe we end up with a standard language for expressing them, but root stores already differ in format today without much pain, so I don’t think that’s necessary. I think that most program authors who use these “standard” TLS implementations are generally expecting to validate as a browser would, unless they take additional steps, so I see this lack as a bug in those libraries, or at least a capability that needs to be easily available in each stack ecosystem. Trust Anchor negotiation will require configuration of both sides, but so does cipher negotiation and so forth, and I think that it will be fine for a library to come with “sane, web-like” defaults, and then provide a mechanism for configuring alternative policies when desired. Whether it should be or not, especially given recent events, it’s generally easier to get a configuration change deployed than a software update. But also, even if the legacy endpoints never get a trust anchors configuration update or support, those that *do* support it can be treated appropriately without disrupting the frozen clients. This would let modern clients like browsers continue to tend to the web PKI, without the opposing force of such possible disruptions. From my experience with root programs, this would be a very welcome capability! Mike
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
