Summary

  • On 28 September, the IETF moved Key Transparency Architecture to AD Evaluation::Revised I-D Needed after its Security Area Director asked the draft to distinguish a label owner from a relying party and clarify the obligations around each deployment mode.
  • Key Transparency can prove a search result, bind it to an append-only history and expose a fork, but the meaning of that result still depends on who could change the label, who authorised the query, which party signed the view and who retained enough state to monitor it later.
  • Operators need a role-qualified verification receipt, not a boolean: proof type, owner, requester role, policy decision, deployment mode, signer, time bounds, prior state and outstanding monitoring duty must travel together.

The green light appears first. A search proof verifies. The tree head is signed. The returned public key is attached to the requested label, and the client can connect this answer to the view it saw before.

Only then does the institutional problem begin. Was the requester the person whose account owns the label, or another person relying on it to start an encrypted conversation? Who was entitled to change the binding? Which policy allowed the lookup? Who must return tomorrow to make sure a recently observed value was not quietly removed? A cryptographic library can answer none of those questions from valid=true alone.

That seam is now holding up an IETF document. On 28 September 2026, Security Area Director Deb Cooley sent comments on revision 09 of Key Transparency Architecture. The Datatracker history records the move from AD Evaluation to AD Evaluation::Revised I-D Needed, with author Brendan McMillion as the action holder. The draft remains an Internet-Draft intended as an Informational RFC. This is a review event, not publication of a standard and not evidence of a deployment.

The review’s most consequential request is linguistic only on the surface. The document defines a User / Account, but later assigns different tasks to a “label owner” and to a user who looks up somebody else’s label. Cooley asks for the draft to distinguish the label owner from the relying party. Without that separation, one word covers both the subject of the directory entry and the consumer making a trust decision about it.

Key Transparency exists because an encrypted messaging service often distributes the public keys that make end-to-end encryption possible. If the service can silently substitute an attacker-controlled public key for a user, encryption may succeed while protecting the wrong relationship. Revision 09’s answer is a cryptographically protected, append-only log. Search, Update and Monitor operations return proofs. Subsequent queries must remain consistent with the client’s earlier view. A service that shows different histories creates a persistent fork.

Persistence is not the same as detection. The architecture says that detecting a fork additionally requires one of three paths: a trusted third party, an anonymous query channel or peer-to-peer comparison. With a third party, users accept a signature on a recent tree head and assume that the signer will not collude with the log. With anonymous or peer exchange, the client looks for contradictory views itself. In every case, a proof is part of a continuing observation process rather than a self-contained certificate of institutional honesty.

The draft makes that dependency clearer by defining three deployment modes. Their names sound like implementation choices. In practice, they allocate accountability.

In Contact Monitoring, no third party carries the detection burden. The label owner regularly checks that the latest value has not changed unexpectedly. A relying user who sees a recently inserted label-version pair must later confirm that it remained visible long enough for the owner to detect it. The second duty survives a policy change: the draft says a required Monitor query must still be allowed even when the user is no longer permitted to repeat the Search or Update that created the duty. Revoking present access cannot erase the evidentiary consequence of an earlier authorised observation.

In Third-Party Auditing, the log does most of the storage and operating work. An auditor periodically signs its view of the tree, and the log gives that signature to users with query responses. The accepted evidence depends on the auditor’s starting position and maximum permitted lag. A signature can be authentic yet too old for the application’s risk tolerance.

In Third-Party Management, a manager performs most of the storage and operation. The service operator remains the policy gate: it enforces access control and authenticates the creation of new label versions before proxying accepted requests. Security depends on the operator and manager not colluding. Cooley asks the draft’s diagram to show a valid search, because a picture containing only Alice’s searches and updates to her own entry leaves the relying-party path obscure.

The companion Key Transparency Protocol shows why the mode cannot be omitted from an audit record. Its configuration identifies the deployment mode, signature and VRF public keys, a reasonable monitoring window and, when applicable, an auditor key, start position and maximum lag. A tree-head signature made by the service operator is not interchangeable with one made under a manager arrangement. An auditor signature says something different again. The bytes may all verify; the trust allocation does not converge.

Client state is another actor even though it is not an organisation. The architecture says users retain prior observations so a later response must extend the view already seen. Losing that state reduces the ability to detect a fork or data later obscured by the log. For applications whose state is naturally ephemeral, such as a web page, or can be erased by an adversary, revision 09 recommends Third-Party Management. The review asks for concrete state-loss examples and clearer treatment of the draft’s claim that a client may enter a permanently invalid state whose detection still requires it to remain online for a bounded period.

Access control creates a parallel seam. The architecture lets applications decide who may search or update, including contact-scoped lookup rules and rate limits. It also preserves some Monitor rights after Search access ends. The AD review asks the text to choose consistent ACL language. That matters because a valid search proof says that the log answered according to its construction; it does not prove that the application was entitled to disclose the label to this requester.

Privacy and deletion make the separation harder. The log may prune serialized user data that expired or became permanently inaccessible while retaining bounded cryptographic material needed for verification. Labels are concealed through a verifiable random function. The review suggests consolidating the privacy discussion and treating RFC 9381 as normative if readers must understand VRFs to understand the design. A proof can preserve privacy at the data-structure layer while an application still makes an incorrect audience decision.

The review also catches a dependency problem in the publication path. The shepherd calls the architecture a foundation for the protocol draft. Cooley warns that references to the protocol must remain examples if the architecture is to publish before it, and asks the shepherd to explain the comparison with RFC 6962, the deployed Certificate Transparency version, rather than its later successor RFC 9162. The architecture also cites MLS to explain credentials in anonymous messaging. These references locate the design; they do not turn it into an implemented service.

The operational repair is not another hash. It is a role-qualified verification receipt. For each accepted operation, retain the proof and label version, but also record whether the requester acted as owner or relying party; the authorization decision and policy version; the deployment mode; the log, manager or auditor key that signed; tree size and relevant timestamps; acceptable lag and monitoring window; the prior client state used for consistency; and any future monitoring action that remains due.

Such a receipt does not enlarge the protocol’s claims. It narrows them. It lets an incident reviewer distinguish five outcomes that a dashboard might otherwise collapse: a cryptographically invalid response, a valid response to an unauthorised query, a stale but correctly signed auditor view, a monitoring obligation that was never completed, and a client that had lost the state needed to detect equivocation.

Revision 10 may answer the Area Director differently. The working group may rename roles, sharpen diagrams, reorganise privacy text or adjust reference classes without adopting any particular receipt. What is already clear is the control boundary. An append-only history can make deception detectable. Only an explicit allocation of roles can make somebody responsible for detecting it.

Sources