Summary

  • The 1 November KEYTRANS architecture draft adds a Client Integrity section absent from its 7 October predecessor.
  • It names a blunt dependency: if the service operator can deliver modified client code or log configuration to one user, that user's key checks can be disabled even while the public log appears sound.

A public ledger can tell the truth to everyone who asks the right question. It cannot force a phone to ask. That is the opening exposed by revision 11 of the IETF KEYTRANS architecture draft. Its new Section 7.3 moves attention from the log's cryptography to the software that decides whether to verify a proof at all.

Key Transparency is meant to expose a communication service that quietly swaps the public key associated with someone's account. Clients search a log and check cryptographic evidence; monitoring and outside observers can make divergent views harder to hide. The draft's earlier chapters describe those protections and several deployment modes. The new section asks who controls the code and configuration that run the checks.

The answer often points back to the service operator. It commonly distributes both the app and the log configuration, while Key Transparency is meant to constrain that same operator. Section 7.3 says an operator able to send one user modified software or configuration can defeat Key Transparency for that user. The modifications need no spectacular attack on a Merkle tree. They can switch off proof verification or monitoring, or substitute a public key controlled by the operator for the log or an outside party. The verifier can be shown a new set of instructions while the ledger remains legible elsewhere.

The 7 October revision 10 had no Client Integrity section. Revision 11 adds four assumptions: the device must execute code securely, the client must implement the protocol securely, the log configuration must be authentic, and the client's clock must be accurate. The section's examples separate these faults. A compromised device may expose private keys and plaintext directly. A rolled-back client state can weaken the memory needed to catch inconsistent log views. A bad clock can let a stale view pass when it should have expired.

The draft names possible counterweights. Binary Transparency would publish each released software version in an append-only log before clients install it, exposing targeted updates to wider inspection. Open source and reproducible builds could help outsiders check what the released program actually does. Platform protections can guard devices and local state; authenticated time from independent servers can make stale views harder to accept. These are implementation choices described by the draft. It reports no operator attack, adoption or deployment result.

The decision for a messaging service is concrete: can its operator target one user's verifier without leaving a public software-release trace? Until a service can answer with its actual update, configuration and client-state controls, a key-transparency badge says more about the log than about the phone holding it. The Datatracker record lists the document as active working-group work submitted to the IESG for publication.