Summary

  • In draft-ietf-keytrans-architecture-09, a tombstone in the old transparency log tells clients to find a label's newest version in the new log and prevents an unreachable new log from making an old value look current.
  • The same draft separately requires continued monitoring of both logs and says the old log must remain available long enough for users—including significantly offline users—to complete monitoring.
  • A service therefore needs a log-retirement receipt that binds the old final tree head, distribution path, client cohorts, completion evidence, exceptions, decision owner and a restoration condition. That receipt is an operational proposal, not KEYTRANS text.

A user returns after months offline. Her application still remembers a tree head from the old transparency log. The service has moved every current key binding to a new log, written tombstones into the old one and removed the old endpoint. The migration dashboard is green. The returning client is not.

It can learn that software now prefers a different service, but it can no longer finish the monitoring that would connect its retained state to the old log's final history. The architecture draft names the consequence sharply: if shutdown comes before a user completes monitoring, that user may be unable to detect some forms of misbehaviour by the old log.

This is the institutional seam inside a cryptographic migration. A tombstone is evidence about where a label's newest version should be sought. It is not evidence that every relying client has closed the old history. Treating it as both would turn a routing marker into a retirement vote.

The marker has a narrow and valuable meaning

Key Transparency addresses a difficult feature of end-to-end encrypted communication. A service may distribute public keys for user accounts, yet the service itself could be compromised or malicious. A searchable, cryptographically protected log lets users examine identity-to-key bindings and test whether they are receiving a globally consistent view. The architecture deliberately describes a building block; the KEYTRANS charter says integration into a complete service still requires decisions at other layers.

Migration is expected, not exceptional. A service may need new cryptographic keys, another cipher suite, a different deployment mode, more capacity or recovery from a failed log. Section 5 of the architecture therefore says clients should generally be able to interact with multiple independent logs. It also sets the essential invariant: all users must share a consistent policy for directing Search, Update and Monitor operations so that honest logs produce one global view and dishonest behaviour remains detectable.

The gradual-migration example gives the tombstone its role. Search the old log first. Consult the new one only if the newest old-log version of the label is an application-defined tombstone. Send ordinary updates to the new log, while adding a tombstone to the old log when needed. This ordering blocks a dangerous fallback. If the new log is unreachable, the client must not accept the pre-migration value in the old log as if it were still current.

That is a strong result. It says which log owns freshness for this label. It does not say that the migrated value is semantically correct, that every owner verified it, that all clients observed the marker, or that the old service can disappear.

Two logs create two unfinished duties

The next sentence in the architecture matters more for governance than the tombstone itself: both logs are monitored as if operated independently. A migration can redirect updates quickly while historical accountability remains open on two surfaces.

The old log must stop accepting modifications at a defined point. Clients still need to connect previously retained state to that final state. The new log must show the migrated label versions and support fresh monitoring. Label owners need to verify their own updates. Contacts need to reject inconsistent histories. Depending on deployment mode, an auditor, manager, anonymous channel or peer exchange may also carry part of the detection assumption.

None of those duties is represented by a single fleet percentage. “All active devices migrated” is not the same assertion as “every relevant owner completed old-log monitoring.” A user can possess the new application version but not yet have opened it. A device can have contacted the new log while lacking the state needed to close the old one. An account can be dormant rather than abandoned. A restored backup can reintroduce an old tree head after the main device was counted as complete.

The draft accommodates this reality without pretending to solve population policy. It says the old log must remain operational long enough for all users to complete monitoring and explicitly warns that some may be offline for a significant time. It does not supply a universal number of days. That omission is appropriate. A high-risk enterprise messenger, a consumer application with long-dormant accounts and an ephemeral web client do not have the same state-loss pattern or recovery channel.

The common protocol can define verifiable history. The application must define which client states it promises to recover and who may accept the residual risk of ending that promise.

A final tree head is necessary, not self-executing

The architecture's immediate-migration example makes another boundary visible. The old log's final tree size and root hash must be distributed over a trustworthy channel. Users issue final Monitor queries up to that point. Label owners initialise their state in the new log by processing an Update for the migrated version and checking that migration was correct.

The final head can be placed in a well-known label in the new log, which users monitor as if they owned it, or distributed with application code. Either path gives clients a common cryptographic stopping point. It does not answer who selected that point, whether every supported client received it or what happens when a client presents an earlier head after the old endpoint has gone.

The protocol draft adds useful coordinates. Log configuration includes max_ahead, max_behind, a mandatory reasonable_monitoring_window and an optional maximum_lifetime. The Reasonable Monitoring Window expresses the general frequency at which label owners are expected to monitor; it helps place common distinguished entries and bound retained monitoring state. It is not a census of actual users. Nor does a maximum lifetime automatically become a customer-support promise. A parameter can bound a proof obligation without identifying the institution that accepts a stranded client.

This is where systems often smuggle a policy choice into configuration. Engineers set a retention period because storage has a cost. Product teams call old clients unsupported. Security teams see declining traffic. Legal teams apply account-retention rules. Each fact may matter. None alone grants the authority to extinguish the last verifiable path from an old client state.

The retirement receipt

A responsible service should keep one compact, signed log-retirement receipt. It need not disclose user identities or private monitoring state. It should make the decision reproducible.

Old-log boundary. Record the log configuration, signing identity, last accepted modification, final tree size and root, timestamp, deployment mode and the proof that the final head is consistent with the prior public head.

Migration rule. Freeze the exact client policy for searches, updates and monitoring, the tombstone syntax and semantics, the new-log identity, and the versions that implement the rule. A future reader must be able to distinguish “redirect this label” from “discard all prior evidence.”

Distribution evidence. Name each trustworthy channel used for the final head: code release, well-known label, managed policy or another authenticated path. Record delivery success by supported client cohort, not merely aggregate downloads.

Completion evidence. Separate new-log contact, migrated-label verification, final old-log monitoring and recovery testing. An account or device should not be called complete because it satisfied only the easiest of those states.

Offline and state-loss policy. Define the longest supported return interval, backup restoration assumptions, reinstallation and multi-device behaviour, inaccessible-account treatment and a protected exception path. State which populations are measurements and which are estimates.

Decision rights. Name the security owner who attests to cryptographic closure, the service owner who accepts availability risk, the privacy or legal owner who bounds retained data, and the executive role authorised to retire the endpoint. Record objections rather than averaging them away.

Fallback. Preserve the old service in a read-only or recoverable state until a stated trigger expires. Define how a returning client that cannot bridge its head is handled, how an inconsistent proof escalates, and what evidence would require restoration or extended availability.

This receipt is not a new public log of customers. Most evidence can remain controlled while a narrow public statement identifies the old and new logs, final head, supported-client horizon, decision date and accountable role.

Draft state is part of the evidence

The architecture is not yet an RFC. Datatracker records revision 09 as submitted to the IESG for publication, with an intended Informational status. The shepherd review reports working-group consensus and no significant objection, while also describing a relatively small specialist community. That is evidence of process maturity, not permission to claim a final standard or deployment.

The companion protocol remains active work. IETF 126 minutes record discussion of a replacement update-request format because the previous one was not implementable, and a client implementer warned that unspecified wire formats could invite non-interoperability. Those observations do not weaken the migration principle. They reinforce the need to keep architecture, protocol revision, running implementation and local retirement decision in separate columns.

The smallest common rule is already visible: do not let an unreachable new log revive stale identity material, and do not remove the old monitoring surface before clients have had a defensible opportunity to close it. The rest belongs in attributable application policy and observable operation.

Sources

  1. KEYTRANS Architecture, revision 09
  2. Architecture document history and shepherd review
  3. KEYTRANS Protocol, revision 05
  4. KEYTRANS working-group charter
  5. IETF 126 KEYTRANS minutes
  6. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  7. Lu Heng, “Running Code Primary”