Network Working Group G. McEwan Internet-Draft 20 September 2026 Intended status: Informational Expires: 24 March 2027 Autonomous Decentralized Key Management (ADKM) Problem Statement draft-mcewan-adkm-problem-statement-00 Abstract 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. Status of This Memo 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. McEwan Expires 24 March 2027 [Page 1] Internet-Draft ADKM Problem Statement September 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Related Approaches and Scope Boundaries . . . . . . . . . . . 5 3.1. PKI and Administrative Trust Models . . . . . . . . . . . 5 3.2. Shared Consensus and Distributed Ledgers . . . . . . . . 5 3.3. Key Transparency . . . . . . . . . . . . . . . . . . . . 6 3.4. Self-Certifying and Decentralized Identifiers . . . . . . 6 3.5. Summary of the Gap . . . . . . . . . . . . . . . . . . . 6 4. The Problem Statement . . . . . . . . . . . . . . . . . . . . 7 4.1. Gap 1: Stable Identifier Continuity Across Key-State Evolution . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Gap 2: Limiting the Consequences of Active-Key Compromise . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Gap 3: Separating Cryptographic Validity from Freshness . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Gap 4: Duplicity and Equivocation Without Global Total Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Gap 5: Interoperable Deterministic Representation . . . . 9 5. Scope and Boundaries . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Informative References . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 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. McEwan Expires 24 March 2027 [Page 2] Internet-Draft ADKM Problem Statement September 2026 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. 2. Terminology 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): McEwan Expires 24 March 2027 [Page 3] Internet-Draft ADKM Problem Statement September 2026 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. McEwan Expires 24 March 2027 [Page 4] Internet-Draft ADKM Problem Statement September 2026 3. Related Approaches and Scope Boundaries 3.1. PKI and Administrative Trust Models 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. 3.2. Shared Consensus and Distributed Ledgers 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. McEwan Expires 24 March 2027 [Page 5] Internet-Draft ADKM Problem Statement September 2026 3.3. Key Transparency 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. 3.4. Self-Certifying and Decentralized Identifiers 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. 3.5. Summary of the Gap 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; McEwan Expires 24 March 2027 [Page 6] Internet-Draft ADKM Problem Statement September 2026 * 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. 4. The Problem Statement 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. 4.1. Gap 1: Stable Identifier Continuity Across Key-State Evolution 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. 4.2. Gap 2: Limiting the Consequences of Active-Key Compromise 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. McEwan Expires 24 March 2027 [Page 7] Internet-Draft ADKM Problem Statement September 2026 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. 4.3. Gap 3: Separating Cryptographic Validity from Freshness 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. 4.4. Gap 4: Duplicity and Equivocation Without Global Total Order 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. McEwan Expires 24 March 2027 [Page 8] Internet-Draft ADKM Problem Statement September 2026 4.5. Gap 5: Interoperable Deterministic Representation 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. 5. Scope and Boundaries 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: McEwan Expires 24 March 2027 [Page 9] Internet-Draft ADKM Problem Statement September 2026 * 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. 6. Security Considerations 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: McEwan Expires 24 March 2027 [Page 10] Internet-Draft ADKM Problem Statement September 2026 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. 7. IANA Considerations This document has no IANA actions. 8. Informative References [RFC5280] Cooper, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . McEwan Expires 24 March 2027 [Page 11] Internet-Draft ADKM Problem Statement September 2026 [RFC6960] Santesson, S., "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, . [RFC7401] Moskowitz, R., "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [KEYTRANS] McMillion, B., "Key Transparency Architecture", Work in Progress, Internet-Draft, draft-ietf-keytrans- architecture-09, June 2026, . [DCBOR] McNally, W., Allen, C., Bormann, C., and L. Lundblade, "dCBOR: Deterministic CBOR", Work in Progress, Internet- Draft, draft-mcnally-deterministic-cbor-18, August 2026, . [DID-CORE] Sporny, M., Longley, D., and D. Chadwick, "Decentralized Identifiers (DIDs) v1.0", July 2022, . Author's Address George McEwan Email: mcewan@utah.gov McEwan Expires 24 March 2027 [Page 12]