| Internet-Draft | Enrollment Problem Statement | July 2026 |
| Yossif | Expires 23 January 2027 | [Page] |
Any scheme that produces cryptographic evidence of execution authority roots its entire trust chain in an enrollment: the moment at which a key becomes bound to a subject and a device, and at which a verifier begins to treat signatures under that key as meaningful. Every downstream proof is only as trustworthy as that binding. If an attacker substitutes a key of their choosing at enrollment, every subsequent proof verifies correctly and yet attests to the wrong party. This document is a problem statement. It describes the foundational key-substitution threat, records the relevant public facts about consumer-platform biometric and key APIs that bound what an enrollment can establish, and states the assumptions a verifier of execution authority evidence must be able to make about the enrollment its proofs depend on. Specific enrollment ceremonies are out of scope. This document defines no protocol or mechanism.¶
This note is to be removed before publishing as an RFC.¶
This is an individual submission to the IETF. "Informational" above is the intended status; this document has not been adopted by any IETF working group and does not represent IETF consensus. The author intends to request dispatch of this work (for example through the SECDISPATCH working group) toward consideration by an appropriate working group. Review and comments are welcome.¶
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 23 January 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.¶
Execution-authority evidence -- a signed proof that a present, verified human approved a specific action -- lets a verifier appraise a signature and conclude that an enrolled key produced it. The strength of that conclusion depends entirely on a prior fact the proof itself does not carry: that the key was bound, at enrollment, to the subject and device the verifier believes it belongs to. A proof establishes "this enrolled key signed this action"; it cannot establish "this key is the right key" -- that is settled, or not, at enrollment.¶
Key substitution at enrollment is therefore the foundational threat. If an attacker causes a key of their choosing to be enrolled in place of, or alongside, the legitimate subject's key, then every proof the attacker later produces verifies correctly against the enrolled public key. Signature verification, freshness checks, action binding, replay counters, and lifecycle checks all pass, because they are all evaluated relative to the enrolled key -- and the enrolled key is the attacker's. No amount of downstream cryptographic rigor recovers from a wrong binding at the root: the entire evidence chain inherits the trust of its enrollment and can be no stronger.¶
This makes enrollment the security-critical joint of any execution-authority scheme, and yet the point most often left to an unspecified, deployment-local procedure. A verifier that appraises proofs is implicitly relying on properties of that procedure it did not observe and cannot re-derive from the proof. This document makes those reliances explicit. It states the problem -- what a verifier must be able to assume about enrollment, and what platform reality permits an enrollment to establish -- and deliberately does not prescribe a solution. The concrete steps of any enrollment ceremony are out of scope (Section 8).¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. In this document they are used to state assumptions a verifier must be able to make and requirements on any enrollment a verifier depends on; this document itself specifies no enrollment procedure.¶
The verifier / attester / relying-party role terms are used in the sense of the RATS architecture [RFC9334].¶
The assumptions a verifier would like to make about enrollment are bounded by what consumer operating-system biometric and key-store APIs actually expose. The facts in this section are public properties of widely deployed mobile platforms and constrain what any enrollment built on them can establish. They are stated so that the requirements of Section 5 are grounded in what is achievable rather than in what would be convenient.¶
Consumer-platform biometric authentication APIs return a match success or failure result. They do not report which enrolled biometric matched. A successful result establishes that some biometric enrolled on the device satisfied the platform's matcher; it does not identify a particular finger, face, or other enrolled template, and it does not distinguish among multiple enrolled biometrics. An enrollment that gates a key on biometric authentication therefore binds the key to "a biometric enrolled on this device", not to a specific, individually identified biometric.¶
The number of distinct biometrics enrolled on a device is not exposed to a third-party application. An application cannot enumerate the enrolled set or read its size; it can observe only the platform's authentication result and, where the platform provides it, an opaque indicator that the set has changed (below). An enrollment procedure therefore cannot, from within a third-party application, establish that the device holds exactly one enrolled biometric, nor attribute a match to a known member of the set.¶
Platform key stores can invalidate a biometric-gated key when the device's enrolled biometric set is modified after the key was created. This mechanism detects changes made after the key was bound: a biometric added, or the set otherwise altered, subsequent to key creation causes the platform to invalidate the key. It does not, and cannot, retroactively characterize the biometrics already enrolled at the moment of binding. Whatever was present in the enrolled set when the key was created is inside the binding from the start; only later modifications are observable as such. Consequently, invalidation-on-change protects the integrity of an enrollment going forward from binding time, but says nothing about the composition of the enrolled set at binding time.¶
A verifier of execution-authority evidence appraises each proof relative to an enrollment it did not perform. For that appraisal to be sound, the verifier must be able to make the assumptions in this section about the enrollment. These are stated as requirements on any enrollment a verifier depends on, and as the corresponding facts the verifier must be able to establish. This document does not specify how an enrollment satisfies them; it specifies only that a sound scheme must satisfy them.¶
ASSUME-1 (Key-binding provenance). The verifier MUST be able to resolve a proof's kid to an enrolled key whose binding to the subject and device has known, appraisable provenance. It MUST NOT have to accept, as the basis of appraisal, a kid-to-key binding of unknown origin. The provenance MUST be such that a substituted key (Section 3) is detectable at enrollment rather than being silently accepted and honored on every later proof.¶
ASSUME-2 (Attestation evidence at enrollment). The verifier MUST be able to assume that, at enrollment, evidence was captured and appraised establishing that the enrolled key resides in and was generated by a genuine, policy-conforming device key store, rather than being an arbitrary key asserted by client software. This document states the need for such evidence and its appraisal; the specific evidence formats, the challenge or freshness construction, and the ceremony that captures them are out of scope (Section 8).¶
ASSUME-3 (Lifecycle states). The verifier MUST maintain, and be able to rely on, an authoritative lifecycle for each enrollment with at minimum the states active, suspended, and revoked. It MUST honor proofs only for an active enrollment and MUST be able to move an enrollment out of the active state, so that a compromised or retired binding stops being a valid root for new proofs. Revocation SHOULD be terminal for the compromised binding: recovering authority SHOULD require a fresh enrollment rather than reactivation of the suspect binding.¶
ASSUME-4 (Invalidation on biometric-set change). Where the enrollment gates the signing key on biometric user verification, the verifier MUST be able to assume that a modification of the device's enrolled biometric set after binding invalidates the key, so that a biometric added after enrollment cannot silently gain the authority of the enrolled key. Per Section 4.3, this assumption covers post-binding modifications only; it does not extend to the composition of the enrolled set at binding time, and a scheme MUST NOT assume otherwise.¶
The platform facts of Section 4 bound these assumptions. In particular, because a biometric match does not identify which biometric matched (Section 4.1) and the enrolled count is not third-party readable (Section 4.2), ASSUME-4 binds a key to "a biometric enrolled at binding time and unchanged since", which is the strongest binding the platform permits and is weaker than a binding to a specific, individually identified biometric. A scheme's analysis MUST reflect that limit rather than assume an identity-level biometric binding the platform does not provide.¶
This section is informative. [I-D.yossif-psea] defines a token profile for execution-authority evidence and states explicitly that enrollment is the root of trust while placing the enrollment procedure itself out of its scope. That is a deliberate and defensible scope boundary: a token profile can specify what a proof carries and how a verifier appraises it without mandating a single enrollment ceremony.¶
The consequence, however, is that the profile's guarantees are conditional on enrollment assumptions the profile does not itself state in full. This document does not change that scope boundary; it documents what the boundary assumes. The assumptions of Section 5 are the reliances a verifier of such proofs is already making implicitly, made explicit so that a deployment can be held to them and so that the key-substitution threat of Section 1 is addressed where it actually lives -- at the root -- rather than being obscured by the rigor of the downstream proof. The delegation-constraint problem that sits above execution evidence is treated separately in [I-D.yossif-agent-mandate-problem].¶
This document defines no mechanism; the considerations below frame analysis of any enrollment a verifier depends on and are not exhaustive.¶
The dominant threat is key substitution at enrollment (Section 1): it is undetectable downstream by construction, because every downstream check is evaluated relative to the enrolled key. A scheme that hardens the proof path while leaving enrollment provenance (ASSUME-1) or enrollment-time attestation (ASSUME-2) unspecified concentrates all residual risk at the point it has left unaddressed, and gains little assurance overall. The strength of the whole chain is the strength of the enrollment binding.¶
The platform limits of Section 4 are themselves security-relevant. Because a biometric match does not identify the matching biometric and the enrolled set's size is not readable, a deployment cannot assume that biometric gating binds a key to one specific person's biometric to the exclusion of every other biometric enrolled on the device; it binds to the enrolled set as it stood at binding time. A biometric enrolled on the device before the key was bound is inside the binding and is not caught by change-invalidation (ASSUME-4, Section 4.3). A scheme that overstates the biometric binding -- treating "a biometric on this device approved" as "this specific individual approved" -- makes a claim the platform does not support.¶
Lifecycle handling (ASSUME-3) is the recovery path when a binding is found to be compromised. A verifier that cannot authoritatively suspend or revoke an enrollment, or that permits a revoked binding to be reactivated rather than requiring fresh enrollment, leaves a known-bad root able to produce honored proofs. Because this document specifies no ceremony, the freshness and provenance guarantees that a concrete enrollment would need are not analyzed here and are deferred to a document that defines one.¶
Specific enrollment ceremonies are out of scope of this document. It defines no procedure by which a device and key are enrolled, no attestation-evidence format or its freshness construction, no supervision or provisioning model, and no wire protocol. It states only the threat, the platform facts that bound what an enrollment can establish, and the assumptions a verifier must be able to make about whatever enrollment a deployment chooses. Any concrete enrollment design is left to a separate document.¶
This document has no IANA actions.¶