Internet-Draft ADKM Requirements September 2026
McEwan Expires 25 March 2027 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-mcewan-adkm-requirements-00
Published:
Intended Status:
Informational
Expires:
Author:
G. McEwan

Autonomous Decentralized Key Management (ADKM) Requirements

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.

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.

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.

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.

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:
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <https://www.rfc-editor.org/info/rfc3552>.

Author's Address

George McEwan