Composing Application-Layer Action Evidence with Remote Attestation Procedures
draft-sokolov-rats-aep-composition-02

Remote ATtestation ProcedureS (RATS)                          A. Sokolov
Internet-Draft                                           Tyche Institute
Intended status: Informational                              28 June 2026
Expires: 30 December 2026

  Composing Application-Layer Action Evidence with Remote Attestation
                               Procedures
                 draft-sokolov-rats-aep-composition-02

Abstract

   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.

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 30 December 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Sokolov                 Expires 30 December 2026                [Page 1]
Internet-Draft                AEP over RATS                    June 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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  The Action Evidence Package . . . . . . . . . . . . . . . . .   3
   4.  Composition with RATS . . . . . . . . . . . . . . . . . . . .   3
   5.  A Result Vocabulary . . . . . . . . . . . . . . . . . . . . .   4
   6.  Feasibility Note  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Appraisal by a Conformant RATS Verifier . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     8.1.  Freshness Is Not Automatic in an Appraisal Scheme . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     10.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  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 [RFC9334] 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.

Sokolov                 Expires 30 December 2026                [Page 2]
Internet-Draft                AEP over RATS                    June 2026

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses RATS terminology as defined in [RFC9334]: the
   roles Attester, Verifier, Relying Party, Endorser, and Reference
   Value Provider, and the conceptual messages Evidence, Endorsements,
   Reference Values, and Attestation Results.

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

4.  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 [I-D.ietf-rats-corim])
       and Endorsements by a Verifier.

   2.  The AEP is conveyed as a further Evidence item.  Candidate
       conveyances are an EAT [RFC9711] 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 CMW collection -- the RATS Conceptual Messages
       Wrapper [I-D.ietf-rats-msg-wrap] -- that groups the platform
       Evidence and the AEP into one message.

   3.  A Verifier -- or, following the layered Platform-Verifier /
       Workload-Verifier pattern of [I-D.ietf-rats-multi-verifier], a
       platform Verifier and an application Verifier in composition --
       appraises both and emits an Attestation Result.

Sokolov                 Expires 30 December 2026                [Page 3]
Internet-Draft                AEP over RATS                    June 2026

   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
   [RFC9334] Section 10 freshness mechanisms -- nonces, synchronised-
   clock timestamps, and Epoch IDs/handles -- apply unchanged.

5.  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
   [I-D.ietf-rats-ar4si] defines four trustworthiness tiers -- none,
   affirming, warning, contraindicated -- serialised in an EAR
   [I-D.ietf-rats-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.

6.  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 [ZENODO-AEP].

Sokolov                 Expires 30 December 2026                [Page 4]
Internet-Draft                AEP over RATS                    June 2026

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

Sokolov                 Expires 30 December 2026                [Page 5]
Internet-Draft                AEP over RATS                    June 2026

   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 [ZENODO-AEP].

8.  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 Section 7) 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.

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

Sokolov                 Expires 30 December 2026                [Page 6]
Internet-Draft                AEP over RATS                    June 2026

   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.

9.  IANA Considerations

   This document has no IANA actions.  (If a future revision defines an
   EAT claim or a CMW type for an AEP, the corresponding registrations
   would appear here.)

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://www.rfc-editor.org/info/rfc9334>.

   [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
              Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
              DOI 10.17487/RFC9711, April 2025,
              <https://www.rfc-editor.org/info/rfc9711>.

10.2.  Informative References

   [I-D.ietf-rats-ar4si]
              Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
              Scarlata, "Attestation Results for Secure Interactions",
              Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
              10, 18 May 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rats-ar4si-10>.

Sokolov                 Expires 30 December 2026                [Page 7]
Internet-Draft                AEP over RATS                    June 2026

   [I-D.ietf-rats-ear]
              Fossati, T., Voit, E., Trofimov, S., and H. Birkholz, "EAT
              Attestation Results", Work in Progress, Internet-Draft,
              draft-ietf-rats-ear-04, 26 May 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
              ear-04>.

   [I-D.ietf-rats-msg-wrap]
              Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
              D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
              in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23,
              11 December 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rats-msg-wrap-23>.

   [I-D.ietf-rats-corim]
              Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
              W. Pan, "Concise Reference Integrity Manifest", Work in
              Progress, Internet-Draft, draft-ietf-rats-corim-10, 2
              March 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-rats-corim-10>.

   [I-D.ietf-rats-multi-verifier]
              Deshpande, Y., jun, Z., Labiod, H., and H. Birkholz,
              "Remote Attestation with Multiple Verifiers", Work in
              Progress, Internet-Draft, draft-ietf-rats-multi-verifier-
              00, 5 May 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rats-multi-verifier-00>.

   [ZENODO-AEP]
              Sokolov, A., "Hardware-rooted attestation for AI-agent
              evidence: composing IETF RATS with action evidence
              packages", 2026,
              <https://doi.org/10.5281/zenodo.20818672>.

Acknowledgements

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

Author's Address

   Anton Sokolov
   Tyche Institute
   Tallinn
   Estonia
   Email: anton.sokolov@tyche.institute

Sokolov                 Expires 30 December 2026                [Page 8]