Individual Submission C.X. Ruvalcaba Internet-Draft Saluca LLC Intended status: Standards Track 11 August 2026 Expires: 12 February 2027 NHE Identity: A Verifiable Key-Committed Identity and Genesis- Attestation Format for Autonomous Agents draft-ruvalcaba-nhe-identity-00 Abstract This document specifies how a Non-Human Entity (NHE) is identified and how one party verifies another's identity. An NHE identity is a verifiable cryptographic commitment: control of an identity key, bound by an append-only hash chain to the entity's genesis and to the lineage of its configuration, rather than a mere name. The document defines the identity chain data model (record structure, genesis sentinel, linkage rule, and the no-fork property), a proof-of-control challenge/response, an optional capability attestation that reveals a specific capability without revealing the rest of the configuration, and an optional hardware-rooted genesis-attestation profile. The data model is specified here; the concrete on-the-wire encoding is deferred to the next revision. 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 12 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Ruvalcaba Expires 12 February 2027 [Page 1] Internet-Draft NHE Identity August 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. Relationship to the NHE Architecture . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Identity Chain Model . . . . . . . . . . . . . . . . . . . . 3 4.1. Record Structure . . . . . . . . . . . . . . . . . . . . 4 4.2. Genesis and Linkage . . . . . . . . . . . . . . . . . . . 4 4.3. Verification . . . . . . . . . . . . . . . . . . . . . . 4 5. Proof of Control . . . . . . . . . . . . . . . . . . . . . . 5 6. Capability Attestation (Optional) . . . . . . . . . . . . . . 5 7. Hardware-Rooted Genesis-Attestation Profile (Optional) . . . 5 8. Cryptographic Agility . . . . . . . . . . . . . . . . . . . . 6 9. Revocation and Operator Control . . . . . . . . . . . . . . . 6 10. Wire Format (to be specified in -01) . . . . . . . . . . . . 6 11. Security Considerations . . . . . . . . . . . . . . . . . . . 6 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 13. Normative References . . . . . . . . . . . . . . . . . . . . 7 14. Informative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Every other interface of the NHE reference architecture [I-D.ruvalcaba-nhe-arch] is scoped to identity: continuity, memory, inter-entity messaging, audit, and authority are all bound to "which entity." An identity that is only a name is forgeable and therefore useless as that anchor. This document specifies identity as a verifiable commitment: an entity is identified by control of an identity key, and that key is bound by an append-only, independently verifiable hash chain to the entity's genesis and to the succession of configurations it has held. The construction is deliberately simple and self-contained: a relying party --- a peer entity, an operator, or any verifier --- can confirm an identity from the chain alone plus a signature, with no registration authority in the base case. An optional profile adds hardware-rooted genesis attestation for deployments that require it. Ruvalcaba Expires 12 February 2027 [Page 2] Internet-Draft NHE Identity August 2026 2. Relationship to the NHE Architecture This document specifies the Identity interface of [I-D.ruvalcaba-nhe-arch] and inherits its scope framing. An NHE identity is a functional construct --- a key commitment and a configuration lineage --- and asserts nothing about the entity being alive, sentient, or a person. The identity mechanism is precisely what makes the architecture's invariants enforceable: *inspectability*, because the chain is an independently verifiable audit of identity and configuration lineage; *operator control*, because identity keys and chain progression are subject to operator- held revocation (Section 9); and *bounded authority*, because authority grants elsewhere in the suite name this identity as their subject. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. Identity key: The long-term key pair whose control defines the entity. May be a hybrid of a classical and a post-quantum signature key (Section 8). Identity key hash: A cryptographic digest of the identity public key; the stable identifier for the entity. Configuration profile: The structured description of the entity's capabilities and constraints at a point in time; committed to the chain by its digest, not by value. Identity chain: The append-only hash chain of identity records binding the identity key to its genesis and configuration lineage. Genesis record: The first record of an identity chain. Relying party: Any party that verifies an entity's identity --- a peer, an operator, or a third-party verifier. 4. Identity Chain Model An identity is a chain of records. Each record commits, in order, to the identity key hash, the current configuration profile digest, a pointer to the preceding record, a timestamp, and a signature by the identity key. Ruvalcaba Expires 12 February 2027 [Page 3] Internet-Draft NHE Identity August 2026 4.1. Record Structure An identity record is the ordered tuple: record = { identity_key_hash : digest of the identity public key profile_hash : digest of the configuration profile prior_record_hash : link to the immediate predecessor timestamp : RFC 3339, sub-second precision signature : identity-key signature over the above } The canonical serialization of a record, used both for the prior_record_hash computation and for transport, is the canonical form of the ordered tuple {identity_key_hash, profile_hash, prior_record_hash, timestamp, signature}, with binary fields encoded as lowercase hexadecimal and object members in the fixed order shown. Canonicalization MUST be deterministic so that any verifier recomputes byte-identical input. 4.2. Genesis and Linkage The prior_record_hash of the genesis record is a sentinel of 32 zero octets (0x00 repeated 32 times). For every non-genesis record, the prior_record_hash MUST equal the SHA3-256 digest of the canonical serialization of its immediate predecessor for the same identity key hash. [ genesis ] [ record 1 ] [ record 2 ] prior = 0x00*32 <- prior = H(genesis) <- prior = H(record 1) sig(key) sig(key) sig(key) The chain has the *no-fork* property: at most one record exists for each (identity_key_hash, prior_record_hash) pair, so no two records may claim the same predecessor. A configuration change is recorded by appending a new record with a new profile_hash; the identity key is continuous across the change, which is how an entity's configuration lineage is bound to a single identity. 4.3. Verification A relying party verifies an identity chain by, for each record in insertion order: (a) verifying the record signature against the identity public key; (b) for each non-genesis record, recomputing the SHA3-256 digest of the canonical serialization of its immediate predecessor and confirming it equals the record's prior_record_hash; and (c) confirming the no-fork property. Signature verification and per-record hash recomputation are each O(1); full-chain verification Ruvalcaba Expires 12 February 2027 [Page 4] Internet-Draft NHE Identity August 2026 is O(n) in chain length. A relying party that only needs the current identity MAY verify from a trusted checkpoint rather than from genesis. 5. Proof of Control Presenting a chain proves the chain is well-formed; it does not prove the presenter controls the identity key. To prove control, a verifier issues a challenge comprising a fresh nonce and a freshness counter, and the entity returns a signature by its identity key over the challenge together with its current record's prior_record_hash. The verifier accepts only if the signature verifies against the identity public key committed in the presented chain and the freshness counter has not been seen before. This binds the live proof to the specific identity and defeats replay. 6. Capability Attestation (Optional) An entity MAY prove that a specific capability is present in its configuration profile without revealing the remainder of the profile, by producing a proof that is verifiable against the identity public key and that attests to the presence of the named capability in the profile committed by profile_hash. This lets a relying party confirm "this entity is authorized for capability X" without learning the entity's full configuration. The proof system is negotiable; the requirement is only that the proof be verifiable against the committed identity and profile digest. 7. Hardware-Rooted Genesis-Attestation Profile (Optional) Deployments that require identity rooted in hardware MAY use this profile. At provisioning, a genesis hash is computed as a digest over a canonical, fixed-order, length-prefixed serialization of the entity's provisioning inputs (its initial configuration commitments), and a genesis record containing the genesis hash and a manufacturer signature over it is published to a content-addressable registry. The device holds a device-root-bound identity private key inside a secure boundary; only the corresponding public key is exported. Attestation proceeds as a challenge/response: the verifier sends a nonce and freshness counter; the device signs an attestation tuple (the challenge, a device serial, and a commitment to its current configuration-version counter) with the device-rooted key; the verifier fetches the genesis record from the registry keyed by a digest of the device serial and verifies a signature chain from a manufacturer certificate, through the device public key, to the attestation tuple, and that the committed configuration version is consistent with the authorized version. Keys used for Ruvalcaba Expires 12 February 2027 [Page 5] Internet-Draft NHE Identity August 2026 confidentiality MUST be derived from a high-entropy device root secret; published identity values (the genesis hash, serial) MUST appear only as non-secret domain-separation inputs, never as keying material. 8. Cryptographic Agility Identity signatures SHOULD be hybrid: a classical signature (for example Ed25519 [RFC8032]) composed with a post-quantum signature (for example ML-DSA), so that identity survives the compromise of either primitive alone. The chain-linkage hash in this document is SHA3-256. The set of permitted signature suites and hash functions is registry-controlled (Section 12) so the format can migrate without a new protocol version; a verifier MUST reject records using a suite it does not implement. 9. Revocation and Operator Control An operator MUST be able to revoke an identity or a key. Revocation is itself expressible as a chain event (a terminal record marking the identity or a key as revoked, signed under operator-held authority) and/or as a registry status in the hardware-rooted profile. A relying party MUST treat a revoked identity as invalid regardless of otherwise well-formed chain and proof of control. This is the mechanism by which the architecture's operator-control invariant is realized at the identity layer: a continuous identity is never continuous against its operator. 10. Wire Format (to be specified in -01) The data model above --- record tuple, genesis sentinel, linkage rule, no-fork property, and verification procedure --- is fixed by this revision. The concrete encoding of records and messages on the wire (field encodings, the challenge/response and attestation message layouts, and the registry interaction for the hardware-rooted profile) is deferred to the next revision, following the compact- binary approach of HCTP [I-D.ruvalcaba-hctp]. 11. Security Considerations Identity is the root of all scoping in the NHE suite; compromise of an identity key compromises the guarantees of every interface bound to that identity. Identity key protection is therefore the highest- value control, and the hybrid-signature requirement (Section 8) exists to keep the root secure across cryptographic transitions. Ruvalcaba Expires 12 February 2027 [Page 6] Internet-Draft NHE Identity August 2026 The chain provides tamper-evidence and lineage, not confidentiality: it reveals the sequence and timing of configuration changes and the profile digests. Where that metadata is sensitive it MUST be protected by the transport. The no-fork check is essential --- without it an entity could maintain divergent identities from a shared predecessor; verifiers MUST enforce it. Proof of control MUST use unpredictable nonces and monotonic freshness to defeat replay. In the hardware-rooted profile, deriving any confidentiality key from published or low-entropy identity values is cryptographically broken and MUST NOT be done; keys come from the device root secret, with published values used only as domain separation. Finally, revocation (Section 9) is a security-critical path: a verifier that cannot learn revocation status MUST treat the identity as untrusted for high-value actions rather than assume validity. 12. IANA Considerations A future revision will request two registries: "NHE Identity Signature Suites" (classical, post-quantum, and hybrid combinations) and "NHE Identity Hash Functions" (chain-linkage digests), each under a Specification Required policy [RFC8126]. No IANA action is requested by this skeleton revision. 13. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 14. Informative References [I-D.ruvalcaba-hctp] Ruvalcaba, C.X., "The Hash-Chain Context Transfer Protocol (HCTP)", Work in Progress, Internet-Draft, draft- ruvalcaba-hctp-00, August 2026, . [I-D.ruvalcaba-nhe-arch] Ruvalcaba, C.X., "An Architecture for Non-Human Entities (NHE)", Work in Progress, Internet-Draft, draft-ruvalcaba- nhe-arch-00, August 2026, . Ruvalcaba Expires 12 February 2027 [Page 7] Internet-Draft NHE Identity August 2026 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . Author's Address Cristian Xavier Ruvalcaba Saluca LLC Email: cristian@saluca.com Ruvalcaba Expires 12 February 2027 [Page 8]