]> Tyche Institute

Tallinn Estonia anton.sokolov@tyche.institute

Security Remote ATtestation ProcedureS (RATS) attestation evidence AI agents accountability This document sketches a composition pattern in which an application-layer "action evidence package" (AEP) -- a signed, append-only record of an action taken by an automated (for example, AI-agent) system, the authority under which it was taken, and its outcome -- is treated as Evidence in the sense of the RATS Architecture (RFC 9334) and bound to platform Evidence produced by a hardware root of trust. The intent is that a single Verifier, or a composition of Verifiers, can appraise both the platform state and the application-layer action together, and emit an Attestation Result that a Relying Party can use to reason about what an automated system did and on what platform it did so without trusting the operator's self-report for either. This is an individual sketch intended to ask the working group whether the pattern is already covered by existing mechanisms or warrants a short document.

Introduction Records of automated decision-making are increasingly produced for accountability purposes: an action identifier, an authorising principal, inputs and tool calls, and an outcome, chained so that tampering is detectable. Such an action evidence package (AEP) is useful but has the standard self-report limitation: every field is asserted by the same software stack whose integrity is in question. The signature proves the record was produced by a key the runtime holds; it does not prove what the runtime was. The RATS Architecture separates the party that produces Evidence (Attester), the party that appraises it (Verifier), and the party that acts on the verdict (Relying Party). Binding an AEP to platform Evidence appraised under RATS supplies the independence the self-report lacks. This document describes the composition and asks whether it is novel enough to specify.

Conventions and Definitions 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. This document uses RATS terminology as defined in : the roles Attester, Verifier, Relying Party, Endorser, and Reference Value Provider, and the conceptual messages Evidence, Endorsements, Reference Values, and Attestation Results.

The Action Evidence Package An AEP is an application-layer, signed, append-only record. For the purposes of this document its salient properties are: (a) it records an action, an authorising principal, and an outcome; (b) it is chained for tamper-evidence; and (c) it is produced by the same software stack that performs the action. Property (c) is precisely why it benefits from composition with platform Evidence.

Composition with RATS The composition treats the AEP as application-layer Evidence conveyed alongside platform Evidence:

1. The platform produces hardware-rooted Evidence (for example, a TPM quote over measured-boot registers, or a TEE attestation token), appraised against Reference Values (for example, conveyed as a Concise Reference Integrity Manifest ) and Endorsements by a Verifier.
2. The AEP is conveyed as a further Evidence item. Candidate conveyances are an EAT carrying the AEP (or a digest of it) as a claim or submodule (the EAT submodule / Detached-Submodule-Digest mechanism is the standard nesting facility here), or a Collection CMW -- the RATS Conceptual Message Wrapper -- that groups the platform Evidence and the AEP into one message.
3. A Verifier -- or, following the layered Platform-Verifier / Workload-Verifier pattern of , a platform Verifier and an application Verifier in composition -- appraises both and emits an Attestation Result.

The binding between the two is load-bearing: the AEP, at record time, SHOULD incorporate a reference to a fresh platform appraisal (or to the platform Evidence and the nonce that scoped it), so that a later Relying Party can ask not only "what did the automated system do, and under what authority?" but "and was it done on a platform whose state was independently attested within the same freshness window?". The Section 10 freshness mechanisms -- nonces, synchronised-clock timestamps, and Epoch IDs/handles -- apply unchanged. When the Collection CMW conveyance is used, this binding obligation is reinforced by the conveyance specification itself: Section 8.2 of requires that Evidence messages within a Collection CMW carrying Evidence of a composite or layered device be cryptographically bound together, and notes that the binding need not be an outer signature: it can be achieved through identifiers or linking claims, such as nonces, across the collection's items. The platform-appraisal reference that the AEP incorporates at record time is exactly such a linking claim.

A Result Vocabulary For a non-specialist Relying Party, this work resolves an appraisal to a small two-axis vocabulary: an authorisation axis computed from the AEP and policy (Authorised / Unauthorised / Indeterminate) and a platform axis (Attested / Contested / Expired). AR4SI defines four trustworthiness tiers -- none, affirming, warning, contraindicated -- serialised in an EAR . Two of the platform terms map directly onto those tiers: an affirming appraisal to Attested; a warning or contraindicated appraisal that runs but contradicts Reference Values to Contested; while the none tier, in which the Verifier asserts nothing, denotes an inconclusive appraisal rather than a pass or fail. Expired is deliberately NOT an AR4SI trustworthiness tier: it captures a separate, token-level condition -- evidence stale relative to the freshness policy, or supporting material that has lapsed -- surfaced by the EAT exp claim and by nonce-based evidence freshness, not by the trustworthiness vocabulary. This correspondence is provisional and SHOULD be validated against a Verifier's actual EAR output; the working group's view on whether such a mapping belongs in a document, or purely in deployment guidance, is solicited.

Feasibility Note A small emulated feasibility check (software TPM via swtpm, with a minimal Verifier stand-in) folds the hash of an AEP outcome and a fresh nonce into an attestation-key-signed quote, with a model-artefact measurement in a platform register, and resolves the three platform-axis cases and rejects a forged outcome bound to a valid quote. It is emulated and minimal; it demonstrates the binding, not a hardware-rooted guarantee. Details are in .

Appraisal by a Conformant RATS Verifier To validate the result-vocabulary correspondence of the preceding section against a real Attestation Result rather than a stand-in, the composition was exercised end-to-end against a conformant RATS Verifier: an instance of the open-source Project Veraison Verifier, built and run locally. This is an independent exercise of an open-source implementation; it is NOT a conformance claim, an endorsement, or any partnership with the Veraison project. The Attester was an emulated software TPM (swtpm), not a hardware guarantee. A fresh EC P-256 Attestation Key (AK) was created in the swtpm; the AEP outcome digest was measured into a Platform Configuration Register (PCR 4); and a genuine swtpm TPM quote was produced over PCRs 1-4 with the freshness nonce as qualifying data. The quote was packed into the Verifier reference TPM evidence wire format (NODE_ID || SIZE || TPMS_ATTEST || TPMT_SIGNATURE). A Concise Reference Integrity Manifest (CoRIM) was provisioned carrying two items keyed by a single instance identifier: the AK public key as a trust anchor, and the golden PCR composite digest as a Reference Value. The quote was then submitted through one challenge-response session per appraisal, and the Verifier returned a signed EAR. The verdicts below were read from the decoded EARs (the EAR profile was the Verifier own, signed with ES256):

• Case A, good state with the AEP outcome digest measured into PCR 4: the Verifier returned ear.status "affirming" (the platform-axis term Attested).
• Case B, PCR 4 re-measured with a different outcome so the PCR composite digest diverges from the golden Reference Value: "contraindicated" (the platform-axis term Contested).
• Case D, one byte flipped inside TPMS_ATTEST so the quote signature no longer verifies against the AK: "contraindicated" (a forged outcome, rejected).

Case A was independently re-verified outside the Verifier: the quote PCR digest equals the provisioned golden value, and the signature verifies against the AK public key, which are exactly the two checks the Verifier performs. These results confirm the provisional mapping of the preceding section against a real EAR for the two platform terms an appraisal of this kind can produce. The third platform term, Expired, is a freshness condition; the reference scheme used here does not produce it, which motivates the freshness consideration below. Full artifacts (the reproducible driver script, the decoded EARs, the submitted evidence tokens, and the independent re-verifier) accompany .

Security Considerations Composition does not dissolve trust assumptions; it relocates them. The platform axis depends on the hardware vendor's Endorsements and the Verifier's independence; the AEP axis depends on the integrity of the key the runtime holds, which is exactly what the platform Evidence is meant to ground. Binding an AEP to a platform appraisal is only as fresh as the weaker of the two freshness mechanisms. Attesting a specific model or workload version requires that artefact be measured into the attested state, which is a deployment commitment. A forged AEP outcome presented under an otherwise-valid platform quote MUST be detectable through the output-binding: the outcome digest is covered by the quote's signed data, so an implementation that binds the AEP reference outside the signed data does not achieve this property. The feasibility note (and the appraisal in ) demonstrates this binding in emulation only (a software TPM); on real hardware the guarantee holds to the extent the outcome digest is genuinely inside the signed and quoted data.

Freshness Is Not Automatic in an Appraisal Scheme The end-to-end appraisal above surfaced a freshness observation worth recording for implementers. A challenge-response transport supplies a session nonce, and the EAT freshness mechanisms of RFC 9711 are available; but whether the nonce is actually enforced depends on the Verifier appraisal scheme, not on the transport. In the reference TPM scheme exercised here, the appraisal compared only the quote signature and the PCR digest against the Reference Value; it did not compare the nonce the Attester bound into the quote qualifying data (the ExtraData field of TPMS_ATTEST) against the session expected nonce. As a result, a replayed or stale quote, correctly signed over a matching PCR state, could still be appraised as affirming. Freshness in this deployment was therefore enforced outside the conformant Verifier, in the application own appraisal step. The idiomatic remedy is two small, separable pieces, and applies generally to any scheme whose evidence carries an attester-bound nonce in signed qualifying data: (1) the appraisal scheme surfaces the attester-bound qualifying data (here, TPMS_ATTEST.ExtraData) as an extracted claim, so that an appraisal policy has a value to compare; and (2) an appraisal policy compares that claim against the session expected nonce and returns a contraindicated verdict when they differ. This is offered as a responsible-disclosure observation about a community-maintained reference scheme, not a deployed production trust service.

IANA Considerations This document has no IANA actions. (If a future revision defines an EAT claim for the AEP, or registers a media type that would identify an AEP carried as a Record CMW or as an entry of a Collection CMW , the corresponding registrations would appear here.)

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. Informative References The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. Cisco Systems Fraunhofer SIT MIT Linaro Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. Linaro Cisco Arm Limited Fraunhofer SIT This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Arm Ltd Huawei Technologies France S.A.S.U. Huawei Technologies France S.A.S.U. Fraunhofer SIT IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details.

Acknowledgements Thanks to the Veraison community for the discussion that prompted this sketch.