



Remote ATtestation ProcedureS                                T. Kamimura
Internet-Draft                 VeritasChain Standards Organization (VSO)
Intended status: Informational                           10 January 2026
Expires: 14 July 2026


 On the Relationship Between Remote Attestation and Behavioral Evidence
                               Recording
               draft-kamimura-rats-behavioral-evidence-01

Abstract

   This document provides an informational discussion of the conceptual
   relationship between remote attestation, as defined in RFC 9334 (RATS
   Architecture), and behavioral evidence recording mechanisms.  It
   observes that these two verification capabilities address
   fundamentally different questions - attestation addresses "Is this
   system in a trustworthy state?" while behavioral evidence addresses
   "What did the system actually do?" - and discusses how they could
   conceptually complement each other in accountability frameworks.
   This document is purely descriptive: it does not propose any
   modifications to RATS architecture, define new mechanisms or
   protocols, or establish normative requirements.  It explicitly does
   not define any cryptographic binding between attestation and
   behavioral evidence.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Remote ATtestation
   ProcedureS (RATS) Working Group mailing list (rats@ietf.org), which
   is archived at https://mailarchive.ietf.org/arch/browse/rats/.

   Source for this draft and an issue tracker can be found at
   https://github.com/veritaschain/draft-kamimura-rats-behavioral-
   evidence.

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




Kamimura                  Expires 14 July 2026                  [Page 1]

Internet-Draft        RATS and Behavioral Evidence          January 2026


   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 14 July 2026.

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Document Status . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.1.  What Attestation Alone Establishes (X)  . . . . . . .   4
       1.2.2.  What Behavioral Evidence Alone Establishes (Y)  . . .   5
       1.2.3.  What Considering Both Together Could Enable (X+Y) . .   5
       1.2.4.  Remaining Trust Gaps  . . . . . . . . . . . . . . . .   6
       1.2.5.  Domain Examples . . . . . . . . . . . . . . . . . . .   6
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  RATS Terminology (Reused Without Modification)  . . . . .   7
     2.2.  Behavioral Evidence Terminology . . . . . . . . . . . . .   7
   3.  Conceptual Layering . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Attestation Layer (RATS)  . . . . . . . . . . . . . . . .   8
     3.2.  Behavioral Evidence Layer . . . . . . . . . . . . . . . .   9
     3.3.  Separation of Concerns  . . . . . . . . . . . . . . . . .  10
   4.  Conceptual Relationship . . . . . . . . . . . . . . . . . . .  10
     4.1.  Different Questions, Different Answers  . . . . . . . . .  10
     4.2.  Temporal Considerations . . . . . . . . . . . . . . . . .  11
     4.3.  No Cryptographic Binding Defined  . . . . . . . . . . . .  11
   5.  Illustrative Example  . . . . . . . . . . . . . . . . . . . .  12
   6.  Non-Goals and Explicit Out-of-Scope Items . . . . . . . . . .  13
     6.1.  No Changes to RATS  . . . . . . . . . . . . . . . . . . .  13
     6.2.  No Protocol or Format Definition  . . . . . . . . . . . .  13
     6.3.  No Normative Requirements . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14



Kamimura                  Expires 14 July 2026                  [Page 2]

Internet-Draft        RATS and Behavioral Evidence          January 2026


     7.1.  No Security Composition Claimed . . . . . . . . . . . . .  14
     7.2.  Warning Against False Sense of Security . . . . . . . . .  14
     7.3.  Conceptual Attack Considerations  . . . . . . . . . . . .  14
     7.4.  Independent Security Analysis Required  . . . . . . . . .  15
     7.5.  RATS Threat Model Unchanged . . . . . . . . . . . . . . .  16
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Changes from -00  . . . . . . . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   The IETF RATS (Remote ATtestation ProcedureS) Working Group has
   developed a comprehensive architecture for remote attestation
   [RFC9334], enabling Relying Parties to assess the trustworthiness of
   remote systems through cryptographic evidence about their state.
   This attestation capability addresses a fundamental question in
   distributed systems: "Is this system in a trustworthy state?"

   A related but distinct verification need exists in many operational
   contexts: the ability to verify what actions a system has actually
   performed after the fact.  This question - "What did the system
   actually do?" - is addressed by behavioral evidence recording
   mechanisms, which create tamper-evident records of system actions and
   decisions.

   This document observes that these two verification capabilities
   address different aspects of system accountability and discusses
   their conceptual relationship.  The document does not propose any
   technical integration, protocol, or cryptographic binding between
   these mechanisms.  Any discussion of "complementary" use is purely
   conceptual and does not imply a composed security property.

1.1.  Document Status

   This document is purely INFORMATIONAL and NON-NORMATIVE.  It:

   *  Does NOT propose any new RATS mechanisms or architecture changes

   *  Does NOT modify or extend the RATS architecture as defined in
      [RFC9334]

   *  Does NOT define new protocols, claims, tokens, or data formats

   *  Does NOT establish normative requirements for any implementation



Kamimura                  Expires 14 July 2026                  [Page 3]

Internet-Draft        RATS and Behavioral Evidence          January 2026


   *  Does NOT define any cryptographic binding or security composition
      between attestation and behavioral evidence

   *  Remains fully compatible with and respectful of existing RATS
      concepts and design philosophy

   The language in this document uses descriptive terms (MAY, COULD,
   CAN) exclusively to indicate possibilities and observations.  This
   document does not use normative requirements language (MUST, SHOULD,
   SHALL) as there are no mandatory behaviors or requirements being
   specified.

   This document treats behavioral evidence recording systems in general
   terms, using VeritasChain Protocol (VCP) [VCP-SPEC] as one
   illustrative example among various possible approaches.  Other
   systems such as Certificate Transparency [RFC6962] and general
   append-only log architectures employ similar cryptographic techniques
   for different purposes.

1.2.  Motivation

   This document is motivated by an observation that attestation and
   behavioral evidence recording, while both contributing to system
   accountability, answer fundamentally different questions.
   Understanding this distinction could help system architects avoid
   conflating these mechanisms or assuming one substitutes for the
   other.

1.2.1.  What Attestation Alone Establishes (X)

   Remote attestation, as defined in [RFC9334], enables a Relying Party
   to assess whether an Attester is in a trustworthy state at the time
   of attestation.  When attestation succeeds, the Relying Party gains
   assurance that:

   *  The Attester's software configuration matches expected Reference
      Values

   *  The Attester is running on genuine, uncompromised hardware (where
      hardware roots of trust are used)

   *  The Attester's identity can be cryptographically verified

   However, attestation alone does NOT establish:

   *  What specific actions the Attester will take after attestation





Kamimura                  Expires 14 July 2026                  [Page 4]

Internet-Draft        RATS and Behavioral Evidence          January 2026


   *  Whether the Attester's future behavior will conform to any
      particular policy

   *  A verifiable record of what the Attester actually did during
      operation

1.2.2.  What Behavioral Evidence Alone Establishes (Y)

   Behavioral evidence recording mechanisms create tamper-evident
   records of system actions and decisions.  When properly implemented,
   such mechanisms could provide:

   *  A chronological record of what actions the system performed

   *  Cryptographic integrity protection for those records

   *  Evidence for after-the-fact examination of system behavior

   However, behavioral evidence recording alone does NOT establish:

   *  That the system recording the evidence was in a trustworthy state
      when it generated the records

   *  That the system's software, configuration, or hardware was
      uncompromised

   *  That the records accurately reflect what the system actually did
      (a compromised system could generate false records)

1.2.3.  What Considering Both Together Could Enable (X+Y)

   When an observer has access to both valid Attestation Results for a
   system AND a verifiable behavioral evidence trail from that system,
   the observer could potentially reason:

   *  "At time T1, attestation confirmed the system was in a known-good
      state"

   *  "The behavioral evidence records actions from T1 to T2"

   *  "If the system remained in the attested state throughout this
      period, these behavioral records could be considered more
      trustworthy"








Kamimura                  Expires 14 July 2026                  [Page 5]

Internet-Draft        RATS and Behavioral Evidence          January 2026


   *Critical Limitation:* This reasoning is purely conceptual and
   informal.  This document explicitly does NOT claim that considering
   attestation and behavioral evidence together creates any composed
   security property.  Significant trust gaps remain (see
   Section 1.2.4).

1.2.4.  Remaining Trust Gaps

   Even when both attestation and behavioral evidence are available,
   significant trust gaps remain that this document does not address:

   *  *Time-of-check vs. time-of-use:* Attestation confirms state at a
      point in time; the system could be compromised immediately after
      attestation

   *  *Attestation-to-logging binding:* No cryptographic mechanism is
      defined to bind Attestation Results to specific behavioral
      evidence entries

   *  *Logging fidelity:* Even a trustworthy system could have bugs in
      its logging implementation

   *  *Selective omission:* A system could pass attestation yet
      selectively omit events from its behavioral records

   *  *Compromised logging infrastructure:* The logging infrastructure
      itself could be compromised independently of the attested system

   These gaps would need to be addressed by specific technical
   mechanisms not defined in this document.  Deployments considering
   both attestation and behavioral evidence should carefully analyze
   their threat model and not assume that informal complementarity
   provides strong security guarantees.

1.2.5.  Domain Examples

   The following examples illustrate domains where both capabilities
   could be relevant.  These examples are illustrative only and do not
   constitute normative guidance:

   *  *Financial Services:* Algorithmic trading systems may face
      regulatory requirements for both system integrity verification and
      decision audit trails

   *  *Artificial Intelligence:* AI governance frameworks increasingly
      distinguish between system certification and operational logging





Kamimura                  Expires 14 July 2026                  [Page 6]

Internet-Draft        RATS and Behavioral Evidence          January 2026


   *  *Critical Infrastructure:* Systems controlling physical processes
      may benefit from attestation of their configuration alongside
      records of their actions

2.  Terminology

2.1.  RATS Terminology (Reused Without Modification)

   This document reuses terminology from the RATS Architecture [RFC9334]
   without modification or extension.  The following terms are used
   exactly as defined in that document:

   Attester  A role performed by an entity that creates Evidence about
      itself and conveys it to a Verifier.  (RFC 9334, Section 2)

   Verifier  A role performed by an entity that appraises Evidence about
      an Attester.  (RFC 9334, Section 2)

   Relying Party  A role performed by an entity that uses Attestation
      Results to make authorization decisions.  (RFC 9334, Section 2)

   Evidence  Information about an Attester's state, generated by the
      Attester.  (RFC 9334, Section 2)

   Attestation Results  Output produced by a Verifier, indicating the
      trustworthiness of an Attester.  (RFC 9334, Section 2)

   Claims  Assertions about characteristics of an Attester.  (RFC 9334,
      Section 2)

   Reference Values  Expected values against which Evidence is compared.
      (RFC 9334, Section 2)

2.2.  Behavioral Evidence Terminology

   The following terms are used in this document to describe behavioral
   evidence concepts.  These terms are grounded in general systems and
   security literature rather than being newly defined by this document.

   *Note on "Audit" Terminology:* The term "audit" in this document
   follows common systems engineering usage (e.g., "audit log", "audit
   trail") referring to chronological records of system events
   maintained for post-hoc examination.  This usage is consistent with
   standard security terminology as found in sources such as NIST SP
   800-92 (Guide to Computer Security Log Management) [NIST-SP800-92]
   and general operating systems literature.  It does not imply
   regulatory auditing, financial auditing, or compliance certification
   in any jurisdiction-specific sense.



Kamimura                  Expires 14 July 2026                  [Page 7]

Internet-Draft        RATS and Behavioral Evidence          January 2026


   Audit Event  A recorded occurrence representing a discrete action,
      decision, or state change in a system.  This term is used in
      general systems security contexts and should not be confused with
      RATS Evidence, which describes system state rather than behavior.

   Audit Trail  A chronologically ordered sequence of Audit Events that
      can be examined to reconstruct system behavior.  When
      cryptographic integrity mechanisms are applied, such trails may be
      "verifiable" in the sense that tampering can be detected.

   Behavioral Evidence  In this document, "behavioral evidence" refers
      to records of what a system has done (its actions and decisions),
      as distinct from RATS Evidence, which describes what state a
      system is in (its configuration and properties).  This term is
      used specifically to avoid confusion with the precise RATS
      definition of "Evidence".

3.  Conceptual Layering

   This section describes an observational framework for understanding
   how attestation and behavioral evidence recording address different
   verification needs.  This framework is purely conceptual and does not
   define any technical integration or protocol.

3.1.  Attestation Layer (RATS)

   The RATS architecture [RFC9334] addresses trustworthiness assessment
   through remote attestation.  At its core, attestation answers
   questions about system state:

   *  Is the system's software configuration as expected?

   *  Is the system running on genuine, uncompromised hardware?

   *  Does the system's current state match known-good Reference Values?

   *  Can the system's identity and configuration be cryptographically
      verified?

   These questions are fundamentally about the properties and
   characteristics of a system at a point in time or across a
   measurement period.  The RATS architecture provides mechanisms for
   generating, conveying, and appraising Evidence that enables Relying
   Parties to make trust decisions about Attesters.

   Key characteristics of attestation as defined by RATS:

   *  Focuses on system state and configuration



Kamimura                  Expires 14 July 2026                  [Page 8]

Internet-Draft        RATS and Behavioral Evidence          January 2026


   *  Enables trust decisions before or during interactions

   *  Produces Attestation Results for Relying Party consumption

   *  May rely on hardware roots of trust

   *  Addresses the question: "Can I trust this system's current state?"

3.2.  Behavioral Evidence Layer

   Behavioral evidence recording mechanisms address a different category
   of verification need.  Rather than assessing system state, they
   record what a system has done:

   *  What decisions did an algorithm make?

   *  What actions did the system execute?

   *  What inputs led to what outputs?

   *  What was the sequence and timing of operations?

   These questions are fundamentally about system behavior over time.
   Verifiable behavioral evidence mechanisms could provide ways to
   record, preserve, and verify the integrity of behavioral records,
   enabling after-the-fact examination of system actions.

   Key characteristics of behavioral evidence systems (in general
   terms):

   *  Focus on system behavior and decisions

   *  Enable verification after events have occurred

   *  Produce verifiable records for post-hoc examination

   *  May rely on cryptographic structures such as hash chains, Merkle
      trees, or append-only logs

   *  Address the question: "What did this system do?"

   As an illustrative example, VCP [VCP-SPEC] defines audit trails using
   three integrity layers: event integrity (hashing), structural
   integrity (Merkle trees), and external verifiability (digital
   signatures and anchoring).  Certificate Transparency [RFC6962] uses
   similar cryptographic techniques for a different purpose (public
   logging of certificates).  Other behavioral evidence systems could
   employ different mechanisms.



Kamimura                  Expires 14 July 2026                  [Page 9]

Internet-Draft        RATS and Behavioral Evidence          January 2026


3.3.  Separation of Concerns

   The distinction between attestation and behavioral evidence can be
   understood as a separation of concerns:

      +==========+========================+========================+
      | Aspect   | Attestation (RATS)     | Behavioral Evidence    |
      +==========+========================+========================+
      | Primary  | Is this system         | What did this system   |
      | Question | trustworthy?           | do?                    |
      +----------+------------------------+------------------------+
      | Focus    | System state           | System behavior        |
      +----------+------------------------+------------------------+
      | Temporal | Point-in-time or       | Historical record of   |
      | Scope    | measurement period     | actions                |
      +----------+------------------------+------------------------+
      | Primary  | Trust decision before/ | Post-hoc examination   |
      | Use Case | during interaction     | and accountability     |
      +----------+------------------------+------------------------+
      | Trust    | Hardware/software      | Logging infrastructure |
      | Anchor   | roots of trust         | integrity              |
      +----------+------------------------+------------------------+

            Table 1: Conceptual Comparison of Attestation and
                           Behavioral Evidence

   This separation suggests that attestation and behavioral evidence
   address different needs.  This document observes that neither
   mechanism fully substitutes for the other, but explicitly does not
   claim that using both together creates a composed security property
   (see Section 7).

4.  Conceptual Relationship

   This section discusses the conceptual relationship between
   attestation and behavioral evidence.  All discussion in this section
   is observational and does not define any protocol, binding, or
   security composition.

4.1.  Different Questions, Different Answers

   A key observation is that attestation and behavioral evidence answer
   different questions:

   Attestation answers:  "At time T, was this system in a trustworthy
      state?"

   Behavioral evidence answers:  "Between times T1 and T2, what actions



Kamimura                  Expires 14 July 2026                 [Page 10]

Internet-Draft        RATS and Behavioral Evidence          January 2026


      did this system perform?"

   Neither question's answer implies the other's:

   *  A system could pass attestation at time T but subsequently perform
      unexpected actions (visible only through behavioral records, if
      recorded honestly)

   *  A system could have complete behavioral records while being
      compromised in ways that attestation might have detected (if
      attestation had been performed)

4.2.  Temporal Considerations

   Attestation and behavioral evidence may operate on different temporal
   rhythms:

   Attestation Patterns:
      *  At system boot or initialization

      *  Periodically during operation

      *  On-demand when a Relying Party requests

   Behavioral Evidence Patterns:
      *  Continuously, as events occur

      *  At varying granularities depending on event significance

      *  With periodic integrity commitments

   One conceptual model involves attestation confirming system state at
   discrete moments, while behavioral evidence records actions between
   those moments.  However, this document explicitly notes that no
   cryptographic mechanism is defined to bind these two types of
   evidence together.  The "gap" between attestation events represents a
   period during which system state could change without detection.

4.3.  No Cryptographic Binding Defined

   This document explicitly does NOT define any cryptographic binding
   between Attestation Results and behavioral evidence records.  Such a
   binding would require:

   *  A protocol for cryptographically linking Attestation Results to
      specific behavioral evidence entries

   *  Mechanisms to prevent replay, substitution, or mismatch attacks



Kamimura                  Expires 14 July 2026                 [Page 11]

Internet-Draft        RATS and Behavioral Evidence          January 2026


   *  Clear semantics for what such a binding would prove

   *  Analysis of the composed security properties

   None of these are provided by this document.  Any deployment
   considering both mechanisms should not assume that informal
   correlation provides the security properties that a formal
   cryptographic binding might offer.

5.  Illustrative Example

   This section provides a purely illustrative, non-normative example of
   how attestation and behavioral evidence could conceptually relate in
   a hypothetical scenario.  This example:

   *  Does NOT define any protocol or establish any requirements

   *  Is NOT exhaustive of possible deployment patterns

   *  Does NOT imply that this is the only or best way to use these
      mechanisms

   *  Is intended solely to illustrate the conceptual distinctions
      discussed in this document

   Consider a hypothetical automated decision-making system:

   Phase 1: System Startup  The system boots and undergoes remote
      attestation.  A Verifier confirms that the system's software,
      configuration, and hardware environment match expected Reference
      Values.  A Relying Party receives Attestation Results indicating
      the system is in a trustworthy state.

   Phase 2: Operational Period  During operation, the system generates
      behavioral evidence for significant actions.  These records are
      maintained in a tamper-evident structure.  Note: Nothing
      cryptographically binds these records to the earlier attestation.

   Phase 3: Post-Hoc Examination  An examiner later wishes to understand
      the system's behavior.  The examiner could: (a) check that
      Attestation Results existed for relevant times, and (b) examine
      the behavioral evidence for those times.  However, the examiner
      should understand that the informal correlation between these does
      not constitute a cryptographic proof (see Section 1.2.4).

   This example is purely conceptual.  Actual deployments would require
   careful security analysis specific to their threat model.




Kamimura                  Expires 14 July 2026                 [Page 12]

Internet-Draft        RATS and Behavioral Evidence          January 2026


6.  Non-Goals and Explicit Out-of-Scope Items

   To maintain clarity about this document's limited scope, the
   following items are explicitly out of scope and are NOT addressed:

6.1.  No Changes to RATS

   This document does NOT:

   *  Propose any modifications to the RATS architecture

   *  Define any new attestation mechanisms, Evidence formats, or
      Attestation Result structures

   *  Suggest that RATS should incorporate behavioral evidence
      capabilities

   *  Propose work items for the RATS Working Group

6.2.  No Protocol or Format Definition

   This document does NOT:

   *  Specify any protocol for connecting attestation and behavioral
      evidence

   *  Define any new claims, tokens, or data structures

   *  Mandate any particular behavioral evidence format or mechanism

   *  Define interoperability requirements between attestation and
      behavioral evidence systems

6.3.  No Normative Requirements

   This document does NOT:

   *  Establish normative requirements for either attestation or
      behavioral evidence implementations

   *  Specify trust relationships or delegation models

   *  Define any cryptographic binding or security composition

   The sole purpose of this document is to observe and explain the
   conceptual relationship between attestation and behavioral evidence
   as distinct mechanisms addressing different verification questions.




Kamimura                  Expires 14 July 2026                 [Page 13]

Internet-Draft        RATS and Behavioral Evidence          January 2026


7.  Security Considerations

   This document is purely informational and does not define any
   protocols or mechanisms.  However, because it discusses the
   conceptual relationship between two security-relevant mechanisms, the
   following security considerations are important.

7.1.  No Security Composition Claimed

   This document explicitly does NOT claim that considering attestation
   and behavioral evidence together creates any composed security
   property.  In particular:

   *  No cryptographic binding is defined between Attestation Results
      and behavioral evidence records

   *  The informal observation that both mechanisms "could be used
      together" does not imply any formal security guarantee

   *  Each mechanism's security properties must be analyzed
      independently

   *  The combination does not automatically inherit the security
      properties of either mechanism

7.2.  Warning Against False Sense of Security

   Readers should be cautioned against assuming that having both
   attestation and behavioral evidence provides comprehensive security.
   Specifically:

   *  *Attestation does not guarantee future behavior:* A system that
      passes attestation at time T could be compromised at time T+1

   *  *Behavioral evidence does not guarantee system integrity:* A
      compromised system could generate false or incomplete behavioral
      records

   *  *Informal correlation is not cryptographic proof:* Observing that
      a system had valid Attestation Results and behavioral evidence for
      the same time period does not constitute a cryptographic proof of
      correct behavior

7.3.  Conceptual Attack Considerations

   At a conceptual level (without defining any specific protocol),
   deployments considering both attestation and behavioral evidence
   should be aware of risks including:



Kamimura                  Expires 14 July 2026                 [Page 14]

Internet-Draft        RATS and Behavioral Evidence          January 2026


   Replay:  Without appropriate binding, an attacker could potentially
      present valid attestation from one context alongside behavioral
      evidence from another context.

   Diversion:  An attacker could potentially direct a Relying Party to
      behavioral evidence from a different (legitimately attested)
      system than the one actually performing operations.

   Relay:  An intermediary could potentially relay attestation
      challenges to a legitimate system while recording behavioral
      evidence from a compromised system.

   Selective omission:  A system could pass attestation yet selectively
      omit events from its behavioral evidence records, particularly if
      the logging mechanism is not included in attestation measurements.

   Time-of-check vs. time-of-use (TOCTOU):  A system's state at
      attestation time may differ from its state when generating
      behavioral evidence, particularly if re-attestation is infrequent.

   These considerations are presented at a conceptual level to inform
   threat modeling.  This document does not define mechanisms to address
   these risks.

7.4.  Independent Security Analysis Required

   The following security considerations apply independently:

   Attestation Security:  Security considerations for remote attestation
      are thoroughly addressed in [RFC9334].  These considerations are
      unchanged by this document.

   Behavioral Evidence Security:  Behavioral evidence recording
      mechanisms have their own security considerations, including:

      *  Key management for signing records

      *  Protection against selective omission

      *  Integrity of external anchoring mechanisms

      *  Privacy considerations for sensitive data

      *  Trustworthiness of the logging infrastructure itself







Kamimura                  Expires 14 July 2026                 [Page 15]

Internet-Draft        RATS and Behavioral Evidence          January 2026


7.5.  RATS Threat Model Unchanged

   This document does not alter the RATS threat model as defined in
   [RFC9334].  It introduces no new attack surfaces to the RATS
   architecture.  Any deployment-specific threat analysis should
   consider attestation and behavioral evidence as separate mechanisms
   with independent trust assumptions and failure modes.

8.  IANA Considerations

   This document has no IANA actions.

9.  References

9.1.  Normative References

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

9.2.  Informative References

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/info/rfc6962>.

   [NIST-SP800-92]
              National Institute of Standards and Technology, "Guide to
              Computer Security Log Management", NIST Special
              Publication 800-92, September 2006,
              <https://csrc.nist.gov/publications/detail/sp/800-92/
              final>.

   [VCP-SPEC] VeritasChain Standards Organization, "VeritasChain
              Protocol (VCP) Specification Version 1.1", 2025,
              <https://veritaschain.org/spec>.

Acknowledgments

   The author thanks the RATS Working Group for developing the
   comprehensive attestation architecture documented in RFC 9334.  This
   document builds upon and respects the careful design work reflected
   in that architecture.  The author also thanks reviewers who provided
   feedback emphasizing the importance of clearly distinguishing
   conceptual observations from security claims.





Kamimura                  Expires 14 July 2026                 [Page 16]

Internet-Draft        RATS and Behavioral Evidence          January 2026


Changes from -00

   *  Strengthened Motivation section with explicit X/Y/X+Y reasoning

   *  Added explicit "Remaining Trust Gaps" subsection

   *  Significantly expanded Security Considerations with warnings
      against false sense of security and conceptual attack
      considerations

   *  Added NIST SP 800-92 reference to ground "audit" terminology

   *  Added explicit "No Cryptographic Binding Defined" section

   *  Clarified that the illustrative example is non-normative and non-
      exhaustive

   *  Restructured Non-Goals into categorized subsections

   *  Added RFC 9334 section references to terminology definitions

   *  Removed unused references (SCITT architecture, reference-
      interaction-models, RFC 9162)

Author's Address

   Tokachi Kamimura
   VeritasChain Standards Organization (VSO)
   Email: kamimura@veritaschain.org
   URI:   https://veritaschain.org





















Kamimura                  Expires 14 July 2026                 [Page 17]
