| Internet-Draft | ADKM Problem Statement | September 2026 |
| McEwan | Expires 24 March 2027 | [Page] |
Many Internet applications require stable, long-lived identifiers whose controlling cryptographic keys evolve over time. Existing standards provide mature mechanisms for certification, transparency, self-certifying identifiers, decentralized identifiers, and shared consensus over state. However, these mechanisms address different trust and deployment models.¶
This document identifies an interoperability gap in deployments that require stable identifier continuity, controller-authorized key-state evolution, independently verifiable event histories, and consistency evidence without requiring either a designated administrative issuer to authorize each state transition or participation in a global consensus system.¶
The document defines the problem space for Autonomous Decentralized Key Management (ADKM), describes related approaches, and identifies requirements and scope boundaries for a possible application-independent key-state evolution architecture.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The operational integrity of many Internet security protocols depends on associating an identifier representing a device, service, software component, organization, or other subject with cryptographic key material.¶
Establishing an initial binding between an identifier and a public key is well understood, and several mature standards address certification, transparency, self-certifying identifiers, decentralized identifiers, and related functions. A distinct problem arises when an application requires the identifier to remain stable while its controlling key state changes over time.¶
Such changes can include routine key rotation, emergency replacement, modification of signing thresholds, delegation, recovery, and revocation. A relying party may also need to determine whether a presented key state follows from an authenticated sequence of authorized transitions and whether conflicting histories have been observed.¶
Existing mechanisms solve important portions of this problem under different trust and deployment assumptions. PKI relies on established certification and administrative trust relationships. Transparency systems provide auditable views of bindings maintained by services or certification authorities. Some distributed systems provide shared ordering or consensus over state. Self-certifying identifier systems cryptographically bind identifiers to key material, and decentralized identifier frameworks allow method-specific approaches to key rotation and recovery.¶
ADKM focuses on a narrower architectural question: how to provide a common, application-independent mechanism for verifiable evolution of controller-managed key state associated with a stable identifier, where successive states are authorized primarily through cryptographically linked evidence rather than repeated authorization by a designated external issuer or participation in a global consensus system.¶
This document is a problem statement. It does not select a particular event format, consistency mechanism, serialization, storage model, or deployment topology.¶
Controller:¶
An entity authorized by the current key state of an identifier to approve one or more permitted key-state transitions.¶
Self-Certifying Identifier (SCID):¶
An identifier whose relationship to initial cryptographic key material can be verified from the identifier and associated cryptographic evidence without relying solely on a central naming registry.¶
Key State:¶
The set of public keys, signing thresholds, roles, and other authorization parameters that are valid for an identifier at a particular state in its evolution.¶
Key Event:¶
An authenticated statement that establishes or changes key state.¶
Key Event History:¶
An authenticated sequence of key events from an identifier's inception state to a later presented state.¶
Autonomous Key-State Evolution:¶
A model in which permitted key-state transitions can be authorized by the controller according to the protocol's rules without requiring a new authorization assertion from a designated external administrative authority for each transition.¶
Local Evidence Verification:¶
The ability of a relying party to validate a presented key state and the authenticated event history leading to that state using locally available cryptographic evidence and protocol rules, without requiring a synchronous query to a designated authority.¶
Local evidence verification does not, by itself, prove that the presented state is the latest state that exists.¶
Consistency Evidence:¶
Cryptographic or protocol evidence used to determine whether conflicting key-event histories have been issued or observed.¶
Freshness:¶
The degree of confidence that a presented key state reflects a sufficiently recent state for the relying party's application. Freshness is distinct from cryptographic validity.¶
X.509 and PKIX [RFC5280] provide a mature framework for binding names and attributes to public keys through certification authorities and established trust anchors. Certificate status and revocation mechanisms, including CRLs and OCSP [RFC6960], provide mechanisms for changing the validity of certificate-based bindings.¶
Certificate Transparency [RFC9162] adds publicly auditable logging of certificate issuance and allows relying parties and monitors to detect suspect or unexpected certificates.¶
These mechanisms are appropriate for many deployment profiles and are not replaced by the problem considered here. Their trust model intentionally depends on certification authorities, trust anchors, certificate status mechanisms, or associated administrative infrastructure.¶
ADKM focuses on deployments in which identifier continuity and authorization of successive key states are established primarily by cryptographically linked controller events rather than by obtaining a newly issued certificate or equivalent authorization from a designated certification authority for each transition.¶
The distinction is architectural rather than a claim that one model supersedes the other.¶
Some distributed ledger and consensus systems provide a shared ordering or agreed state for key-related updates. These systems can provide valuable consistency properties and can reduce dependence on a single administrative authority.¶
In doing so, they introduce a dependency on the availability, governance, finality, and operational characteristics of the selected consensus system. Different ledger architectures make different trade-offs, and this document does not assume that all distributed ledgers use the same consensus or ordering model.¶
ADKM focuses on deployment profiles in which verification of an identifier's key-state history does not require participation in, or continued operation of, a particular global consensus system. An ADKM deployment may still use a ledger or other shared infrastructure as an optional source of additional consistency or timestamp evidence.¶
Key Transparency systems, including the architecture developed by the IETF KEYTRANS working group [KEYTRANS], provide verifiability for identity-to-public-key bindings maintained within service-scoped authentication infrastructure. The architecture is particularly concerned with providing users and relying parties with consistent and auditable views of those bindings.¶
ADKM addresses a different, though potentially complementary, question: how the controller of an identifier can cryptographically authorize successive key states and expose an independently verifiable history of those transitions.¶
These approaches are not mutually exclusive. Transparency infrastructure could be used to provide additional consistency evidence for key state managed using an ADKM architecture.¶
Self-certifying identifiers are established in existing work. For example, the Host Identity Protocol [RFC7401] defines Host Identity Tags derived from public-key-based Host Identities and describes them as self-certifying.¶
W3C Decentralized Identifiers (DIDs) [DID-CORE] define a common data model and method framework for decentralized identifiers and their verification methods. DID methods can define update, rotation, revocation, recovery, and versioning behavior. These behaviors are method-specific, and not all DID methods provide the same key-management or historical-state properties.¶
The ADKM problem is not the invention of self-certifying or decentralized identifiers. The interoperability gap is the absence of a common protocol model for stable identifier continuity and verifiable controller-authorized key-state evolution across implementations and application domains.¶
Certification, transparency, self-certifying identifiers, decentralized identifier architectures, and consensus systems are individually established design patterns.¶
ADKM asks whether the IETF should define a common protocol model that brings the following properties together:¶
stable identifier continuity across key changes;¶
controller-authorized key-state evolution;¶
cryptographically verifiable event history;¶
mechanisms for limiting the consequences of active-key compromise;¶
explicit consistency and equivocation handling;¶
verification that can be performed from locally available evidence, subject to explicit freshness assumptions; and¶
operation without requiring either a designated administrative issuer to authorize each transition or a mandatory global consensus ledger.¶
ADKM addresses the absence of a common, application-independent IETF protocol model that combines the properties described in Section 3.5.¶
Any useful architecture needs to address at least the following problem areas.¶
Existing standards demonstrate several forms of cryptographically derived, self-certifying, and decentralized identifiers. The remaining interoperability question is how a stable identifier can retain verifiable continuity while its controlling keys, signing thresholds, and authorization parameters evolve over time.¶
The architecture needs to define how an inception state is bound to the identifier and how subsequent state transitions remain cryptographically linked to that initial binding without requiring the identifier to be re-established through an external registry after each transition.¶
Compromise of a currently authorized private key can allow an attacker to create signatures that are cryptographically indistinguishable from those created by the legitimate controller for as long as that key remains authorized.¶
A key-state management architecture therefore needs to define how authority to establish a successor key state is authenticated when one or more currently active signing keys may have been compromised.¶
In particular, some deployments may require a mechanism in which possession of the currently active signing keys alone is insufficient to authorize arbitrary future key states. This problem statement does not prescribe a particular mechanism for providing that property.¶
A relying party may need to validate a presented key state in an intermittently connected, disconnected, air-gapped, or edge environment.¶
Portable cryptographic evidence can allow the relying party to determine whether a presented state follows from an authenticated history of permitted transitions. However, such evidence alone cannot generally prove that no later valid transition or conflicting history exists.¶
The architecture needs to distinguish:¶
validation of the presented event history;¶
evidence that the presented state is sufficiently fresh for the application; and¶
evidence that no conflicting history has been observed.¶
The protocol should make these assumptions explicit rather than treating cryptographic validity, freshness, and global consistency as equivalent properties.¶
Without a designated authority or mandatory global consensus mechanism enforcing a single authoritative sequence, a compromised or malicious controller may be able to produce two or more conflicting event histories.¶
The architecture therefore needs a consistency model that allows conflicting, otherwise validly authenticated histories to be detected, evidenced, and compared without requiring all key events to participate in a single global total order.¶
Possible approaches include independently operated observers, gossip, cross-checking, transparency mechanisms, or other forms of consistency evidence. This problem statement does not select among them.¶
Cryptographic verification of key-state events requires implementations to agree on the bytes, or on an unambiguous canonical representation, covered by signatures and digests.¶
Existing mechanisms provide relevant building blocks. JSON Canonicalization Scheme [RFC8785] defines a canonical representation for JSON. CBOR [RFC8949] defines deterministic encoding rules, and ongoing work on dCBOR [DCBOR] further narrows CBOR choices to support interoperable deterministic encoding.¶
ADKM does not assume that a new serialization format is required. It does require a clear definition of the representation, framing, canonicalization, and extensibility properties needed for interoperable event verification, with reuse of existing IETF mechanisms where they satisfy those requirements.¶
To remain focused and actionable, ADKM separates cryptographic key-state management from higher-layer application semantics.¶
In Scope:¶
an architectural and data model for stable identifiers and authenticated succession of key states;¶
rules for validating inception, rotation, threshold changes, delegation, recovery, and revocation events;¶
mechanisms for representing and exchanging authenticated key-event histories;¶
mechanisms for representing, discovering, or exchanging consistency evidence associated with conflicting histories;¶
explicit treatment of freshness and rollback concerns;¶
deterministic representation and framing requirements for key-state events, reusing existing IETF serialization mechanisms where practical; and¶
protocol elements necessary for interoperability across independent implementations.¶
Out of Scope:¶
human identity proofing, real-world identity verification, or legal identity assurance levels;¶
credential payload formats, claims semantics, or credential presentation protocols;¶
application authorization or access-control policy;¶
global human-readable naming or discovery systems;¶
requiring use of a particular distributed ledger or global consensus network; and¶
defining new cryptographic primitives where existing, appropriately reviewed algorithms can satisfy the protocol requirements.¶
Any protocol developed for this problem space would operate directly on long-lived cryptographic authority and therefore requires an explicit threat model.¶
Active-Key Compromise:¶
The architecture should limit, to the extent possible, the ability of a compromised current key state to authorize unbounded future key states. The specific mechanism is a solution question rather than a requirement of this problem statement.¶
Complete Endpoint Compromise:¶
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. The security model must identify which compromise combinations remain recoverable and which are terminal.¶
Equivocation:¶
A malicious or compromised controller may attempt to present conflicting histories to different relying parties. In the absence of mandatory global ordering, the protocol must define how conflicting histories can be detected and how resulting evidence is interpreted.¶
Freshness, Replay, and Rollback:¶
A cryptographically valid historical state may no longer be the state that an application should accept. The protocol must distinguish valid historical evidence from sufficiently fresh evidence and must describe how relying parties can detect or bound replay and rollback risks.¶
Observer and Network Attacks:¶
If consistency or freshness evidence depends on independently operated observers, gossip, cross-checking, or similar mechanisms, the threat model must account for eclipse attacks, partitioning, delayed propagation, selective disclosure, and collusion.¶
Algorithm Agility:¶
Long-lived identifiers may outlive the recommended lifetime of a cryptographic algorithm. The architecture should support migration of key types and cryptographic suites without requiring abandonment of identifier continuity.¶
Privacy:¶
Distribution of key-event histories or consistency evidence can create correlation and metadata risks. A future protocol should minimize unnecessary disclosure and should not assume that all event histories need to be globally published.¶
Resource Exhaustion:¶
Long event histories, conflicting-history proofs, and unsolicited state data may create storage, bandwidth, and verification costs. Implementations will need bounded validation and denial-of-service protections.¶
This document has no IANA actions.¶