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 On Tuesday, May 6, 2025 at 5:00:27 PM UTC-4 David Adrian wrote: > Contact emailsdad...@google.com > > Explainer > https://github.com/tlswg/tls-trust-anchor-ids/blob/main/explainer.md > > Specificationhttps://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 componentInternals>Network>SSL > <https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3ESSL%22> > > 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 tagstls <https://chromestatus.com/features#tags:tls>, ssl > <https://chromestatus.com/features#tags:ssl>, tai > <https://chromestatus.com/features#tags:tai>, tan > <https://chromestatus.com/features#tags:tan>, trust anchor identifiers > <https://chromestatus.com/features#tags:trust%20anchor%20identifiers>, trust > expressions <https://chromestatus.com/features#tags:trust%20expressions>, > trust > anchor negotiation > <https://chromestatus.com/features#tags:trust%20anchor%20negotiation> > > TAG reviewNone > > TAG review statusPending > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?No > > Flag name on about://flagsNone > > Finch feature nameNone > > Non-finch justificationNone > > Requires code in //chrome?False > > Tracking bughttps://bugs.chromium.org/issues/414630735 > > Launch bughttps://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 > <https://chromestatus.com/>. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ce14f910-e9b6-422e-8e79-53d290304222n%40chromium.org.
