Intent to Prototype: TLS trust expressions

[David Benjamin]

Contact emails

davi...@chromium.org, asymm...@chromium.org, b...@chromium.org, dad...@google.com

Explainer

https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md

Specification

https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html

Summary

TLS trust expressions are a TLS extension to allow clients to efficiently communicate trusted certification authorities to servers. Servers can then deploy multiple certificates and transparently select between them. This enables a multi-certificate deployment model, for a more agile and flexible PKI that can better meet security requirements.

Blink component

Internals>Network>SSL

Motivation

Today, TLS servers typically provision a single certificate for all supported clients, because clients do not communicate which CAs are trusted. In this model, the single certificate must simultaneously meet requirements for all relying parties. This constraint imposes costs on the ecosystem as PKIs evolve over time. The older the relying party, the more its requirements may have diverged from newer ones, forcing subscribers to choose between compatibility with new clients, or breaking old clients. This translates to analogous costs for CAs and relying parties: * For a new CA to be usable by subscribers, it must be trusted by all relying parties. This is particularly challenging for older, unupdatable relying parties. Existing CAs face similar challenges when rotating or deploying new keys. * When a relying party must update its policies to meet new security requirements, it must choose between compromising on user security or imposing a significant burden on subscribers that still support older relying parties. Trust expressions remove this constraint, by allowing servers to deploy multiple certificates and transparently select between them.

Initial public proposal

https://mailarchive.ietf.org/arch/msg/tls/jpVMGyTeYhM8vLTTkteYlxXbh7c/

Search tags

tls, x509, certificate

[The following fields are not actually part of the website's process leading up to generating an I2P email. I've noticed other I2Ps leave them unfilled, so I assume their inclusion in the email is simply a bug in the website. We'll get to those when they show up in the process.

See also https://github.com/GoogleChrome/chromium-dashboard/issues/3677 ]

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

No

https://github.com/web-platform-tests/wpt/issues/20159

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5096767277498368

This intent message was generated by Chrome Platform Status.