Problem Statement: Enrollment and Key-Binding Assumptions in Execution Authority Evidence

Introduction 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 ().

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. 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.

Terminology The verifier / attester / relying-party role terms are used in the sense of the RATS architecture .

Subject: The natural person whose presence and approval a downstream proof attests to.
Enrollment: The event that establishes a binding between a signing key, a subject, and a device, and after which a verifier treats signatures under that key as evidence about the subject. This document treats enrollment as an abstract event with security properties a verifier depends on; it does not define how enrollment is performed.
Key binding: The association between a public key (identified to a verifier by a key identifier, "kid") and the subject and device it was enrolled for. A verifier resolves a proof's kid to an enrolled key and appraises the proof relative to that binding.
Key-substitution attack: An attack in which a key controlled by an adversary is enrolled in place of, or in addition to, the legitimate subject's key, so that adversary-produced proofs verify as if they were the subject's.
Attestation evidence (at enrollment): Evidence, available at enrollment, that the key being enrolled resides in and was generated by a genuine, policy-conforming device key store. This document refers to the existence and appraisal of such evidence as an assumption; it does not specify its format, its issuance, or the ceremony that captures it.
Lifecycle state: The status a verifier maintains for an enrollment -- at minimum active, suspended, and revoked -- governing whether proofs under the enrolled key are currently honored.

Platform Reality 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 are grounded in what is achievable rather than in what would be convenient.

Biometric APIs Report Match, Not Identity 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.

Enrollment Count Is Not Third-Party Readable 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.

Change-Invalidation Catches Only Post-Binding Additions 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.

Assumptions a Verifier Must Be Able to Make 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 () 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 (). 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 , 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 bound these assumptions. In particular, because a biometric match does not identify which biometric matched () and the enrolled count is not third-party readable (), 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.

Relationship to draft-yossif-psea This section is informative. 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 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 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 .

Security Considerations 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 (): 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 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, ). 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.

Out of Scope 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.

IANA Considerations This document has no IANA actions.