Intent to Prototype: Trust Anchor Identifiers (TAI)

77 views
Skip to first unread message

David Adrian

unread,
May 7, 2025, 12:00:27 AM (6 days ago) May 7
to blink-dev, Emily Stark

Contact emails

[email protected]

Explainer

https://github.com/tlswg/tls-trust-anchor-ids/blob/main/explainer.md

Specification

https://github.com/tlswg/tls-trust-anchor-ids

Summary

Trust Anchor Identifiers (TAI) is a TLS protocol extension that enables a TLS server to efficiently advertise which trust anchors it supports (which roots its certificates chain to), and allows the client to select. It provides a fallback path in case the selection is wrong or otherwise out of date. In addition to enabling multi-certificate use cases, the same Trust Anchor Identifier mechanism can be used to elide intermediate certificates, saving hundreds to thousands of bytes transmitted during the handshake. This work is adopted by the IETF TLS working group.



Blink component

Internals>Network>SSL

Motivation

Enable TLS endpoints to reliably and efficiently present certificates to peers that vary in supported trust anchors, particularly in larger PKIs like the Web PKI. Without a negotiation mechanism, the authenticating party must obtain a single certificate that simultaneously satisfies all relying parties. This is challenging when relying parties are diverse. PKI transitions, including those necessary for user security, naturally lead to relying party diversity, so the result is that service availability conflicts with security and overall PKI evolution. This avoids a conflict between service availability and user security. As authentication requirements evolve to meet user security, the result is increased variance in the ecosystem. If TLS endpoints cannot reliably meet each supported peer's requirements (e.g. because no single certificate satisfies both the oldest and newest supported peers), connections will fail. Often, the result is user security is deprioritized in favor of avoiding any kind of breakage. We approach this by following the standard TLS negotiation pattern. This same approach also enables eliding of intermediate certificates to up to date clients, which reduces the size of the certificate chain transmitted on the wire. This can be a significant amount of bandwidth at scale.



Initial public proposal

https://github.com/tlswg/tls-trust-anchor-ids/tree/main

Search tags

tlsssltaitantrust anchor identifierstrust expressionstrust anchor negotiation

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

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/issues/414630735

Launch bug

https://launch.corp.google.com/launch/4382800

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5132064512540672?gate=6323389589094400

This intent message was generated by Chrome Platform Status.

David Adrian

unread,
May 7, 2025, 2:29:31 AM (6 days ago) May 7
to blink-dev, David Adrian, Emily Stark
Following up to say:
  • This is a TLS launch associated with an IETF draft, not a web platform launch associated with a W3C spec. As such, we are primarily doing the Blink process for visibility.
  • We will follow up with an Intent to Experiment (via Finch, not OT)
  • Since it's not web platform, we don't plan on doing TAG review, etc.
-dadrian
Reply all
Reply to author
Forward
0 new messages