Summary

  • draft-mcewan-adkm-problem-statement-00 asks how a stable identifier can retain verifiable key-state continuity without requiring a new administrative issuer decision for every transition or mandatory participation in a global consensus system.
  • Its sharpest operational boundary is that an active signing key may be valid for daily use yet deliberately insufficient, on its own, to authorize an arbitrary successor state—especially when compromise of that very key is the event the system must survive.
  • A defensible deployment needs separate receipts for ordinary signatures, successor authorization, recovery participation, history validity, freshness, conflict observation, application policy and observed effect.

At 02:14, a service key signs ordinary traffic. At 02:16, an operator sees evidence that the key may have leaked. At 02:18, a perfectly formed event appears: the same key authorizes a replacement key and retires itself.

Every signature verifies.

That is not the end of the investigation. It is the start. If possession of the active key is enough to appoint its successor, compromise becomes hereditary. The attacker does not merely borrow today’s authority. It can manufacture tomorrow’s authority, sign the transition that appears to cure the incident, and leave the defender with a cryptographically immaculate record of permanent loss.

The September 2026 individual Internet-Draft Autonomous Decentralized Key Management Problem Statement gives that problem a useful architectural boundary. It asks how a stable identifier can survive rotation, emergency replacement, threshold change, delegation, recovery and revocation while the relying party can verify a linked event history. It does not select a format or announce a solution. It identifies the questions a future solution cannot evade.

One key, several kinds of power

Security systems often flatten authority into a single boolean: signature valid or signature invalid. The draft’s terminology makes that shortcut difficult to defend. A Key State includes keys, thresholds, roles and authorization parameters. A Key Event establishes or changes that state. A Controller is authorized by the current state to approve only the transitions permitted by protocol rules.

That last qualification matters. A key may be authorized to sign an application message but not to lower a threshold. It may rotate an operational key only when a recovery key joins. It may delegate a constrained role but not erase every existing controller. It may revoke itself but not appoint an unrestricted successor. A threshold of two operational keys may be sufficient for routine rotation while emergency recovery requires a different quorum held across failure domains.

The point is not to prescribe those rules here. The draft explicitly declines to do so. The point is to record that the word “valid” is incomplete unless the verifier can name the authority class exercised by the signature.

Evidence surface Question it can answer Question it cannot answer alone
Active-key signature Did this key sign these bytes? Was this key sufficient for this transition class?
Transition policy Which roles and thresholds governed the change? Were the inputs fresh and uncompromised?
Linked event history Does the presented state follow a permitted chain? Is this the latest or only chain?
Recovery approval Did a separate recovery capability participate? Was every recovery capability still independent?
Consistency evidence Was a conflicting history observed in the checked scope? Does no undiscovered history exist elsewhere?
Application decision Did local policy accept this state for this operation? Did the operation succeed in the real system?

A clean chain can be the wrong chain

The draft defines Local Evidence Verification carefully. A relying party can validate a presented state and the authenticated history leading to it using locally available evidence, without making a synchronous call to a designated authority. That property is valuable for an edge site, an intermittently connected network or an air-gapped environment.

But the definition includes its own limit: local verification does not prove that the state is the latest state that exists. A chain can be internally valid and old. It can be internally valid and one of two conflicting chains. It can be valid under a policy that the application no longer accepts. Portable proof moves evidence; it does not import a universal clock, a global observer or local authorization policy.

That is why the draft separates three questions that many interfaces collapse:

  1. Does the history validate cryptographically?
  2. Is the presented state fresh enough for this application?
  3. Has any conflicting history been observed?

An offline maintenance terminal may accept a state observed yesterday for a low-risk diagnostic. A financial signing service may require a checkpoint from the last minute and independent conflict checking. Both can use the same event history while reaching different local decisions. The protocol’s job is to expose the evidence and its age, not to make one hidden freshness rule look universal.

The terminal compromise must be written down

Recovery diagrams usually show a happy path: active key lost, recovery capability invoked, successor installed. The draft states the harder rule. No key-state protocol can guarantee recovery if an attacker obtains every secret and recovery capability that the protocol treats as sufficient to authorize future state.

That produces a governance obligation before an incident. The operator must define the compromise matrix:

  • active operational key only;
  • one key inside a multi-key threshold;
  • active key plus one recovery share;
  • control of the device but not the offline recovery capability;
  • control of all operational and recovery secrets;
  • loss of observers or network isolation during recovery.

For each row, the design should say whether recovery remains possible, which authority must act, what delay or observation is required and which condition is terminal. “We support rotation” is not an answer. Rotation executed by the compromised key can be an attacker’s persistence mechanism.

Two histories without one world ledger

ADKM does not require every event to enter a single global total order. That avoids making identifier continuity depend on the availability, governance and finality of one consensus system. It also preserves a real risk: a malicious controller can show different relying parties different valid histories.

The problem statement lists independently operated observers, gossip, cross-checking and transparency as possible sources of consistency evidence. It chooses none. That restraint is useful. Certificate Transparency and the KEYTRANS architecture show how logs, tree heads, consistency proofs, monitoring and gossip can make inconsistent views detectable. They do not turn every absence of a reported conflict into proof of global uniqueness.

An observer receipt therefore needs scope. Which observer saw which event or commitment? At what time? Which prior state did it remember? Which peers or logs were cross-checked? Was the relying party partitioned? Could selective disclosure or collusion hide a branch? “No fork found” must never be stored without the search boundary that gave the sentence meaning.

Neighboring systems are not failed versions of ADKM

The draft is careful not to announce a replacement for established systems.

PKIX binds names and keys through certification authorities and trust anchors; OCSP supplies certificate-status information. That is an intentional administrative trust model. Certificate Transparency makes certificate issuance auditable. HIP demonstrates self-certifying identifiers derived from public-key material. DID Core supplies a common data model and a framework in which methods define update, recovery and version behavior. Key Transparency focuses on consistent service-scoped identity-to-key views.

ADKM asks a narrower interoperability question: can controller-authorized state evolution, stable identifier continuity, linked history, compromise containment and explicit consistency evidence share a common application-independent protocol model? The neighboring systems can remain inputs, deployment options or complementary layers.

Canonical bytes solve only the byte problem

Key events must be signed over unambiguous bytes. JSON Canonicalization Scheme, deterministic CBOR and the ongoing dCBOR work supply relevant building blocks. If two implementations serialize the same event differently, signatures and digests can diverge even when human readers think the data match.

Canonicalization is necessary, but it does not decide who may lower a threshold, whether a recovery share is independent, whether an event is recent or whether a state is authorized for a payment. Deterministic encoding makes disagreement reproducible. It does not make the underlying decision legitimate.

The transition receipt

A production design should be able to emit one bounded transition receipt without pretending that the receipt is a global verdict. It should contain the stable identifier and inception binding; prior-state digest; event sequence or epoch; event type; old and new keys, roles and thresholds; exact policy version; each approval and its authority class; recovery participation; deterministic representation profile; event digest; observer references and times; conflict-check scope; freshness source and maximum permitted age.

Downstream, the application should add a separate decision receipt: which state it accepted, for which operation, under which local policy, with which result. This preserves the line between coordination and execution. A key-state event may be authentic. The application can still deny it. The application may allow it. The operation can still fail.

What the draft does not prove

The primary document is revision 00 of an individual Internet-Draft dated 20 September 2026, intended as Informational and expiring 24 March 2027. It does not establish working-group adoption, IETF consensus, implementation, interoperability, deployment or security of a named system. It chooses no serialization, observer network, ledger, recovery algorithm or event schema. Its value is the map of the unresolved territory.

Sources