Autonomous Decentralized Key Management (ADKM) Requirements

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.

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 when, and only when, they appear in all capitals, as shown here.

Functional Requirements

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.

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.

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.

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.

Operational and Security Requirements

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.

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.

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.

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.

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 .

IANA Considerations This document has no IANA actions.