| Internet-Draft | NHE Identity | August 2026 |
| Ruvalcaba | Expires 12 February 2027 | [Page] |
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.¶
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 (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.¶
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.¶
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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174].¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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].¶
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.¶
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.¶
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.¶