Summary

  • draft-ietf-tls-trust-anchor-ids-06 proposes compact identifiers that help a TLS peer select a certificate path; the request is neither a complete statement of trust nor a promise that the selected path will validate.
  • The draft permits clients to omit trusted anchors, signal untrusted anchors, or use broad groups. A correct selection can therefore end in rejection, after which a server-advertised availability list can support at most one new-connection retry.
  • The leadership task is to keep seven controls distinct: signal policy, server path inventory, selection and fallback, local validation, recovery, privacy posture, and outcome evidence.

Imagine a telemetry dashboard with a reassuring line: the server served the CA requested by the client. It is tempting to read that line as proof that certificate negotiation and trust policy agree. Under the mechanism now being developed in the IETF TLS Working Group, that inference would be wrong.

The working group's revision 06 introduces short Trust Anchor IDs. The idea addresses a practical asymmetry. A TLS endpoint can hold several certificate paths for the same service: perhaps one ending at an established root, another at a newly introduced authority, and a third reserved for recovery. The existing certificate_authorities extension can communicate acceptable authorities, but its distinguished names may consume too much space. A compact individual ID—or a group ID representing several anchors—lets the relying party give the authenticating party a smaller selection signal.

The draft was updated on 30 September 2026. Its header states an intended status of Standards Track, while the frozen Datatracker record leaves both intended_std_level and std_level null. It remains an Internet-Draft, not an RFC. The evidence establishes a proposal and its stated use cases, not implementation, deployment, interoperability or adoption.

The request is allowed to be wrong

The draft's most consequential sentence is not a cryptographic formula. It is the permission for a client's requested list to be an imperfect account of trust. A client may trust anchors that it does not list. It may list an anchor it does not trust. It may name a group that contains some anchors its policy would reject. It may send only a subset—or nothing at all—to constrain ClientHello size or to avoid exposing a distinctive trust-store fingerprint.

That flexibility changes the semantics of the wire signal. The list answers a selection question: Which path should the other endpoint try? It does not conclusively answer the acceptance question: Which path will my validation policy authorize?

This distinction is familiar elsewhere in network engineering. A route advertisement is not proof that every packet will reach its application. A capability hint is not a service-level commitment. A certificate-path hint is similarly an input to a choice, not the final acceptance receipt.

The proposed flow makes the boundary visible. An authenticating party inventories the certificate paths it can send and associates each path with the individual ID of its issuing trust anchor plus any matching group patterns. A relying party sends an unordered RequestedTrustAnchorList in a ClientHello or CertificateRequest. The authenticating party intersects those IDs with its path metadata and chooses a candidate. If certificate_authorities is also present, the draft allows a path satisfying either extension to guide selection. If nothing matches, the endpoint can fail with handshake_failure or send a fallback path.

Only then does trust become operative. The relying party still checks whether the issuer is trusted and whether the chain satisfies the rest of its TLS, PKIX and application policy. Name binding, validity, algorithms, constraints and any locally chosen revocation behavior do not disappear because an ID matched. Bad metadata or an intentionally imprecise request can make the server select a path the client rejects. The result is a failed connection, not an expanded trust store.

A strict path is still a path to validate

Revision 06 also proposes a useful receipt for successful matching. When the selected certificate corresponds to a requested Trust Anchor ID, the authenticating party can attach an empty trust_anchors extension to its Certificate message. That marker comes with a strong assembly rule: the certificate list must be complete, correctly ordered and free of extraneous certificates.

For a relying party, this can remove one source of ambiguity. Instead of searching among certificates to build a possible path, it may process the supplied list as a prebuilt path. RFC 4158 explains why path construction can become a graph problem; RFC 5280 defines the validation discipline that follows. The draft can simplify the first problem without cancelling the second. Disabling path building is not disabling path validation.

That difference belongs in production evidence. An operator should be able to distinguish “the server said this list was the path selected for ID X” from “the client validated that path under policy Y”. One is a selection and assembly claim. The other is an authorization outcome. Combining them into a single green trusted=true field erases the most useful failure boundary.

Recovery corrects a guess, not a policy

The design anticipates that the initial signal may mislead. A server can place a non-empty, preference-ordered list of individual Trust Anchor IDs in EncryptedExtensions. If the client later rejects the served certificate, it can compare that availability list with anchors it actually trusts, reconcile the server's preference with its own, and open a new connection requesting only one selected individual ID.

This recovery is bounded. The draft allows at most one retry. If the server did not provide a list, if no trusted match exists, or if the retry fails, the implementation returns an error to the application. Recovery also adds a round trip. It may make a less ubiquitous certificate path viable as a first attempt, but it converts a mistaken heuristic into observable latency and sometimes into an outage.

That makes retry policy a budget, not a cosmetic implementation detail. A service that uses a newly trusted authority may prefer it first, keeping the established path available for clients that reject the new one. A client that withheld its full trust list for privacy may accept a second connection as the price of that discretion. Neither party can claim the mechanism is free. Someone owns the added connection, the tail latency, the failure counter and the customer-visible consequence.

Compression moves work into governance

Group IDs solve a packing problem. They can represent a set of trust anchors without naming every member in the handshake. But compression does not make the members equivalent. A group can include an authority that a client does not trust. The client may still advertise the group because the signal is meant to improve the probability of a useful server choice rather than enumerate policy faithfully.

Stable groups therefore require governance outside the packet. Who allocates the identifier? Which anchors are included at a given time? How quickly do implementations learn that membership changed? Does a server's path metadata reflect the same group definition as the client? A stale group mapping cannot silently grant trust, but it can deterministically select a path that fails. The security boundary survives; availability absorbs the error.

This is a useful constraint on institutional storytelling. The server's certificate choice is not an endorsement of the issuing authority. The client's group advertisement is not a vote for every group member. The handshake records a coordination attempt among independently governed inventories and policies. It does not manufacture collective legitimacy.

Privacy depends on when the list appears

The draft divides implementations into those that never advertise Trust Anchor IDs, those that advertise conditionally, and those that advertise unconditionally. The difference changes the observer. A conditional signal generally requires an active probe that elicits it. An unconditional ClientHello list can be collected passively.

A user-unique unconditional list would be a durable fingerprint. The draft advises against it and points toward lists shared by an anonymity set. Even then, a list derived from previous connection state can correlate sessions. Privacy is therefore not achieved merely by shortening an identifier or placing several anchors in a group. It depends on population size, stability, emission conditions and the state used to construct the list.

The server's recovery list also needs scope. An AvailableTrustAnchorList should be filtered for the requested service, including its SNI context. An operator that exposes every path held by a shared platform may disclose more institutional topology than the requesting service needs. Sensitive anchors are poor candidates for this negotiation mechanism.

The operational receipt needs seven columns

The cleanest implementation of Heng Lu's minimum-initial principle is not a universal trust registry. It is a small, local, auditable receipt that preserves independent authority while making the coordination decision inspectable.

First, record the signal policy: the exact individual and group IDs advertised, whether emission was conditional or unconditional, and which privacy rule produced the list. Second, record the server path inventory: candidate paths, their anchor and group metadata, and the provenance and version of those mappings. Third, record selection and fallback: which extension matched, why that path won, and what happened when no match existed.

Fourth, preserve validation policy as its own authority: trust-store version, application identity, relevant constraints and the actual validation result. Fifth, record recovery: the availability list, preference reconciliation, whether the one permitted retry occurred, and its latency. Sixth, record the privacy mode and the service/SNI filtering applied on both sides. Seventh, record the outcome: selected path, rejection reason, handshake result and application-visible service result.

Those fields should not be collapsed into a single certificate-success metric. They are valuable precisely because different teams own them. The client platform team may choose the signal. The service operator controls path inventory. A security authority governs acceptance policy. A product team pays the latency cost. An incident responder needs the combined receipt without being allowed to rewrite any participant's policy.

Sources