Autonomous Decentralized Key Management (ADKM) Requirements
draft-mcewan-adkm-requirements-00

Internet Engineering Task Force                                G. McEwan
Internet-Draft                                            September 2026
Intended status: Informational                                          
Expires: 25 March 2027

      Autonomous Decentralized Key Management (ADKM) Requirements
                   draft-mcewan-adkm-requirements-00

Abstract

   This document defines the high-level functional, operational,
   security, and protocol requirements for Autonomous Decentralized Key
   Management (ADKM).  The design goal is straightforward.
   Cryptographic key state bound to a stable identifier should be able
   to begin, evolve, and be independently verified without requiring a
   central administrative authority or globally ordered consensus ledger
   to remain online and authoritative.

   These requirements establish the minimum properties for key-state
   inception, forward commitment, local evidence verification, duplicity
   detection, cryptographic agility, and transport independence.  They
   are intended to guide the standardization of ADKM data models and
   exchange protocols without prescribing a single implementation.

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 5 March 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

McEwan                    Expires 25 March 2027                 [Page 1]
Internet-Draft              ADKM Requirements             September 2026

   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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Functional Requirements . . . . . . . . . . . . . . . . . . .   3
     3.1.  Autonomous Inception and Binding  . . . . . . . . . . . .   3
     3.2.  Key-State Evolution . . . . . . . . . . . . . . . . . . .   3
     3.3.  Forward Commitment and Pre-Rotation . . . . . . . . . . .   3
     3.4.  Verification and Evidence Sufficiency . . . . . . . . . .   4
   4.  Operational and Security Requirements . . . . . . . . . . . .   4
     4.1.  Duplicity and Equivocation Detection  . . . . . . . . . .   4
     4.2.  Cryptographic Agility . . . . . . . . . . . . . . . . . .   4
     4.3.  Transport and Storage Independence  . . . . . . . . . . .   4
     4.4.  Privacy and Metadata Minimization . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Autonomous Decentralized Key Management (ADKM) addresses a narrow but
   important problem.  An identifier may need to remain stable for years
   while the cryptographic keys controlling it rotate, recover from
   compromise, change threshold policies, or move between
   infrastructure.  Verification of that history should not depend on a
   central service remaining available or on every participant sharing a
   globally ordered ledger.

   Traditional Public Key Infrastructure (PKI) and distributed ledgers
   solve important classes of trust and coordination problems.  ADKM is
   not intended to replace those systems.  It defines requirements for a
   different operating model in which the authoritative key state of an
   identifier can be established from cryptographically verifiable
   events and independently checked by a relying party.

McEwan                    Expires 25 March 2027                 [Page 2]
Internet-Draft              ADKM Requirements             September 2026

   The purpose of this document is to keep that model explicit.  Any
   normative ADKM data model, serialization profile, or key-state
   exchange protocol claiming conformance with these requirements is
   expected to preserve the properties defined below.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [BCP14] when, and only when, they appear in all capitals, as shown
   here.

3.  Functional Requirements

3.1.  Autonomous Inception and Binding

   *REQ-1 (Self-Certifying Inception):* The architecture MUST enable
   generation of a stable Self-Certifying Identifier (SCID) from initial
   cryptographic key material and configuration parameters without
   requiring an online request to a central registry.

   *REQ-2 (Identifier Stability):* The SCID MUST remain immutable across
   routine key rotations, emergency key replacements, and signing-
   threshold changes throughout the identifier's lifecycle.

3.2.  Key-State Evolution

   *REQ-3 (Explicit State Transitions):* State modifications, including
   key rotation, threshold changes, witness-list changes, delegation,
   and revocation, MUST be represented as explicit, cryptographically
   signed key events.

   *REQ-4 (Append-Only Log Structure):* Key events MUST form an ordered,
   append-only history in which each event cryptographically references
   the digest of its predecessor.

3.3.  Forward Commitment and Pre-Rotation

   *REQ-5 (Forward Commitment Support):* ADKM specifications MUST
   support a mechanism for committing to future rotation keys in
   advance, such as pre-rotation digests recorded in an earlier
   establishment event.

McEwan                    Expires 25 March 2027                 [Page 3]
Internet-Draft              ADKM Requirements             September 2026

   *REQ-6 (Key-Compromise Isolation):* Satisfying a forward rotation
   commitment MUST require key material that cannot be derived solely
   from the active signing keys.  Compromise of the active signing keys
   alone therefore cannot satisfy a previously established forward
   commitment.

3.4.  Verification and Evidence Sufficiency

   *REQ-7 (Local Evidence Verification):* A relying party MUST be able
   to validate the authoritative key state of an identifier from the
   key-event history, the cryptographic evidence required by the
   applicable ADKM profile, and locally available validation rules.

   *REQ-8 (Ledger Independence):* Key-state validation MUST NOT require
   a synchronous query to a globally ordered consensus ledger or central
   certification authority.

4.  Operational and Security Requirements

4.1.  Duplicity and Equivocation Detection

   *REQ-9 (Duplicity Detectability):* The ADKM data structures MUST make
   conflicting event histories for the same identifier and sequence
   position cryptographically demonstrable.

   *REQ-10 (Portable Duplicity Proofs):* Evidence of duplicity MUST be
   self-contained and portable enough for an independent observer to
   verify the conflicting signed evidence without trusting the reporting
   node.

4.2.  Cryptographic Agility

   *REQ-11 (Algorithm Agility):* The key-event schema MUST support
   explicit use of multiple cryptographic algorithms, key sizes, digest
   algorithms, and signature schemes, including migration to post-
   quantum algorithms.

   *REQ-12 (In-Band Algorithm Identification):* Public keys, digests,
   and signatures MUST carry sufficient in-band information to identify
   the cryptographic algorithm or suite required to interpret and verify
   them.

4.3.  Transport and Storage Independence

   *REQ-13 (Transport Agnosticism):* The key-event format MUST be
   independent of any single network transport.  Implementations may
   carry the same verifiable events over transports such as HTTP, CoAP,
   Bluetooth Low Energy, gossip protocols, or air-gapped media.

McEwan                    Expires 25 March 2027                 [Page 4]
Internet-Draft              ADKM Requirements             September 2026

   *REQ-14 (Storage Independence):* Key-state evidence MUST remain
   verifiable regardless of whether it is obtained from peer caches,
   dedicated supporting infrastructure, or local storage, provided the
   required cryptographic evidence is available.

4.4.  Privacy and Metadata Minimization

   *REQ-15 (Data Minimization):* Key-event payloads MUST NOT require
   personally identifiable information or unhashed application state
   merely to establish or verify key state.

   *REQ-16 (Selective Anchor Disclosure):* When application state is
   bound to a key event, the architecture MUST support digest-based
   anchoring or an equivalent mechanism that permits the binding to be
   verified without requiring disclosure of the underlying application
   data.

5.  Security Considerations

   The requirements in this document are intended to reduce dependence
   on continuously available authorities and to improve resilience
   during key compromise, network partitioning, and equivocation.  They
   do not eliminate the need for careful implementation of key
   generation, key custody, recovery, threshold policy, replay
   protection, event ordering, or evidence distribution.

   In particular, the security benefit of forward commitment depends on
   meaningful separation between active signing keys and the key
   material needed to satisfy a future commitment.  If both are
   compromised together, the isolation property described by REQ-6 is
   lost.

   Concrete ADKM protocol specifications should analyze their threats
   and security assumptions using the guidance in [RFC3552].

6.  IANA Considerations

   This document has no IANA actions.

7.  Normative References

   [BCP14]    Best Current Practice 14,
              <https://www.rfc-editor.org/info/bcp14>.
              At the time of writing, this BCP comprises the following:

McEwan                    Expires 25 March 2027                 [Page 5]
Internet-Draft              ADKM Requirements             September 2026

              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.  Informative References

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

Author's Address

   George McEwan
   Email: mcewan@utah.gov

McEwan                    Expires 25 March 2027                 [Page 6]