



RATS Working Group                                           H. Birkholz
Internet-Draft                                                  M. Eckel
Intended status: Informational                            Fraunhofer SIT
Expires: 9 May 2026                                               W. Pan
                                                     Huawei Technologies
                                                                 E. Voit
                                                                   Cisco
                                                         5 November 2025


     Reference Interaction Models for Remote Attestation Procedures
            draft-ietf-rats-reference-interaction-models-15

Abstract

   This document describes interaction models for remote attestation
   procedures (RATS) [RFC9334].  Three conveying mechanisms --
   Challenge/Response, Uni-Directional, and Streaming Remote Attestation
   -- are illustrated and defined.  Analogously, a general overview
   about the information elements typically used by corresponding
   conveyance protocols are highlighted.

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 9 May 2026.

Copyright Notice

   Copyright (c) 2025 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



Birkholz, et al.           Expires 9 May 2026                   [Page 1]

Internet-Draft                    REIM                     November 2025


   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Disambiguation  . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Boot Time Integrity . . . . . . . . . . . . . . . . . . .   5
     2.3.  Runtime Integrity . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Boot-to-Runtime Boundary  . . . . . . . . . . . . . . . .   5
   3.  Scope and Intent  . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Essential Requirements  . . . . . . . . . . . . . . . . . . .   6
   5.  Normative Prerequisites . . . . . . . . . . . . . . . . . . .   6
   6.  Generic Information Elements  . . . . . . . . . . . . . . . .   8
   7.  Interaction Models  . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Challenge/Response Remote Attestation . . . . . . . . . .  11
       7.1.1.  Models and Example Sequences of Challenge/Response
               Remote Attestation  . . . . . . . . . . . . . . . . .  13
     7.2.  Uni-Directional Remote Attestation  . . . . . . . . . . .  16
       7.2.1.  Handle Lifecycle and Propagation Delays . . . . . . .  19
     7.3.  Streaming Remote Attestation  . . . . . . . . . . . . . .  20
       7.3.1.  Streaming Remote Attestation without a Broker . . . .  20
       7.3.2.  Streaming Remote Attestation with a Broker  . . . . .  22
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .  28
     8.1.  Implementer . . . . . . . . . . . . . . . . . . . . . . .  28
     8.2.  Implementation Name . . . . . . . . . . . . . . . . . . .  28
     8.3.  Implementation URL  . . . . . . . . . . . . . . . . . . .  28
     8.4.  Maturity  . . . . . . . . . . . . . . . . . . . . . . . .  28
     8.5.  Coverage and Version Compatibility  . . . . . . . . . . .  29
     8.6.  License . . . . . . . . . . . . . . . . . . . . . . . . .  29
     8.7.  Implementation Dependencies . . . . . . . . . . . . . . .  29
     8.8.  Contact . . . . . . . . . . . . . . . . . . . . . . . . .  29
   9.  Security and Privacy Considerations . . . . . . . . . . . . .  29
     9.1.  Cryptographic Blinding  . . . . . . . . . . . . . . . . .  29
     9.2.  Trust Assumptions on the Handle Distributor . . . . . . .  30
       9.2.1.  Security Assumptions  . . . . . . . . . . . . . . . .  30
       9.2.2.  Mitigating Risks  . . . . . . . . . . . . . . . . . .  30
     9.3.  Security Considerations for Brokers in Remote
           Attestation . . . . . . . . . . . . . . . . . . . . . . .  31
     9.4.  Additional Application-Specific Security
           Considerations  . . . . . . . . . . . . . . . . . . . . .  32
       9.4.1.  Confidentiality . . . . . . . . . . . . . . . . . . .  32
       9.4.2.  Mutual Authentication . . . . . . . . . . . . . . . .  33
       9.4.3.  Hardware Enforcement/Support  . . . . . . . . . . . .  33
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  33



Birkholz, et al.           Expires 9 May 2026                   [Page 2]

Internet-Draft                    REIM                     November 2025


   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  33
     11.2.  Informative References . . . . . . . . . . . . . . . . .  34
   Appendix A.  CDDL Specification for a simple CoAP Challenge/
           Response Interaction  . . . . . . . . . . . . . . . . . .  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Introduction

   Remote ATtestation procedureS (RATS, [RFC9334]) are workflows
   composed of roles and interactions, in which Verifiers create
   Attestation Results about the trustworthiness of an Attester's system
   component characteristics.  The Verifier's assessment in the form of
   Attestation Results is produced based on Endorsements, Reference
   Values, Appraisal Policies, and Evidence -- trustable and tamper-
   evident Claims Sets about an Attester's system component
   characteristics -- generated by an Attester.  The roles _Attester_
   and _Verifier_, as well as the Conceptual Messages _Evidence_ and
   _Attestation Results_ are concepts defined by the RATS Architecture
   [RFC9334].  This document illustrates three main interaction models
   between various RATS roles, namely Attesters, Verifiers, and Relying
   Parties that can be used in specific RATS-related specifications.
   Using Evidence as a prominent example, these three interaction models
   are:

   1.  _Challenge/Response Remote Attestation_: A Verifier actively
       challenges an Attester and receives time-fresh Evidence in
       response.

   2.  _Uni-Directional Remote Attestation_: An Attester sends Evidence
       proactively to a Verifier, often using externally generated
       freshness indicators.

   3.  _Streaming Remote Attestation_: A persistent subscription-based
       model where Evidence is pushed continuously to interested
       Verifiers, optionally via a Broker.

   As a basis to describe the interaction models is this document, the
   example of attestation Evidence conveyance is used to illustrate the
   usage scenarios.  This document aims to:

   1.  prevent inconsistencies in descriptions of interaction models in
       other documents, which may occur due to text cloning and
       evolution over time, and to

   2.  highlight the exact delta/divergence between the core
       characteristics captured in this document and variants of these
       interaction models used in other specifications or solutions.



Birkholz, et al.           Expires 9 May 2026                   [Page 3]

Internet-Draft                    REIM                     November 2025


   In summary, this document enables the specification and design of
   trustworthy and privacy-preserving (see Section Section 9.1)
   conveyance methods for RATS Conceptual Messages; specifically
   attestation Evidence conveyed from an Attester to a Verifier.  While
   the exact details for conveyance of other Conceptual Messages is out
   of scope, the models described in this document may be adapted to
   apply to the conveyance of other Conceptual Messages, such as
   Endorsements or Attestation Results, or supplemental messages, such
   as Epoch Markers [I-D.ietf-rats-epoch-markers] or stand-alone event
   logs.

2.  Terminology

   This document uses the following terms defined in Section 4 of
   [RFC9334]: Attester, Verifier, Relying Party, Conceptual Message,
   Evidence, Endorsement, Attestation Result, Appraisal Policy,
   Attesting Environment, Target Environment.

   A PKIX Certificate is an X.509v3 certificate as specified by
   [RFC5280].

   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.

2.1.  Disambiguation

   "Remote Attestation" is a common expression often associated or
   connoted with certain properties.  In the context of this document,
   the term "Remote" does not necessarily refer to a remote entity in
   the scope of network topologies or the Internet.  It rather refers to
   decoupled systems or entities that exchange the Conceptual Message
   type called Evidence [RFC9334].  This conveyance can also be "Local",
   if the Verifier role is part of the same entity as the Attester role,
   e.g., separate system components of the same Composite Device (a
   single RATS entity), or the Verifier and Relying Party roles are
   hosted by the same entity, for example in a cryptographic key Broker
   system (see Section 6 of [RFC9334] for more details).  If an entity
   takes on two or more different roles, the functions they provide
   typically reside in isolated environments that are components of the
   same entity.  Examples of such isolated environments include a
   Trusted Execution Environment (TEE), Baseboard Management Controllers
   (BMCs), as well as other physical or logical protected/isolated/
   shielded Computing Environments (e.g., embedded Secure Elements (eSE)
   or Trusted Platform Modules (TPM)).




Birkholz, et al.           Expires 9 May 2026                   [Page 4]

Internet-Draft                    REIM                     November 2025


2.2.  Boot Time Integrity

   Boot time integrity refers to the trustworthiness of the platform
   during its boot sequence, typically covering firmware, BIOS/UEFI,
   initial bootloaders, and core operating system components up until a
   stable runtime environment is reached.  This may apply equally to
   physical devices and virtual machines.

2.3.  Runtime Integrity

   Runtime integrity refers to the ongoing trustworthiness of a platform
   during normal operation, after the boot sequence completes.  It
   encompasses the integrity of dynamic system state, including loaded
   applications, kernel modules, and active configurations.

2.4.  Boot-to-Runtime Boundary

   The exact boundary between boot time and runtime may vary between
   systems.  Generally, it is marked by the handoff from the final
   bootloader or initial OS kernel to a fully operational environment
   capable of executing arbitrary applications or services.

3.  Scope and Intent

   This document:

   *  outlines common interaction models between RATS roles;

   *  illustrates interaction models using the conveyance of Evidence
      about boot-time integrity as an example throughout this document;

   *  does not exclude the application of those interaction models to
      runtime integrity or the conveyance of other RATS Conceptual
      Messages;

   *  does not cover every detail about Evidence conveyance.

   While details regarding Evidence of runtime integrity are not
   explicitly highlighted, the provided model descriptions serve as a
   foundation for developing corresponding model extensions.  While the
   interaction models described in this document, including their
   variants, cover many relevant conveyance models for Conceptual
   Messages implemented on the Internet, they do not represent an
   exhaustive list of all possible models.







Birkholz, et al.           Expires 9 May 2026                   [Page 5]

Internet-Draft                    REIM                     November 2025


   Procedures, functions, and services needed for a complete semantic
   binding of the concepts defined in [RFC9334] are not covered in this
   document.  Examples of such procedures include: identity
   establishment, key distribution and enrollment, time synchronization,
   and certificate revocation.

   Furthermore, any processes and duties beyond conducting remote
   attestation procedures are out of scope.  For example, utilizing the
   results of a remote attestation procedure generated by the Verifier,
   such as triggering remediation actions or recovery processes, as well
   as the remediation actions and recovery processes themselves, are
   also out of scope.

   The interaction models described in this document are meant to serve
   as a solid foundation and reference for other solution documents
   within or outside the IETF.  Solution documents of any kind can refer
   to these interaction models to prevent duplicating text and to avoid
   the risk of subtle discrepancies.  Similarly, deviations from the
   generic model described in this document can be illustrated in
   solution documents to highlight distinct contributions.

4.  Essential Requirements

   In order to ensure appropriate conveyance of Evidence, the following
   requirements MUST be fulfilled:

   Integrity:  Information provided by an Attester MUST NOT have been
      altered since it was created.  This may be achieved via symmetric
      cryptography, e.g., using COSE Mac0 as in PSA TF-M profile
      (Section 5.2 of [RFC9783]), or asymmetric, such as a COSE Sign
      algorithm like ECDSA.

   Authentication:  The information provided by the Attester MUST be
      authentic.  To do this, the Attester should authenticate itself to
      the Verifier.  This can be done through authentication using a
      digital signature over the Attestation Evidence, which does not
      require additional protocol steps, or by using a secure channel
      (see Sections 3 and 4 of [RFC9781]) that includes authentication.

5.  Normative Prerequisites

   In order to ensure Evidence is appropriately conveyed through the
   interaction models described in this document, the following
   prerequisites MUST be in place to support their implementation:

   Authentication Secret:  An Authentication Secret MUST be established
      before any RATS interaction takes place, and it must be made
      available exclusively to an Attesting Environment of the Attester.



Birkholz, et al.           Expires 9 May 2026                   [Page 6]

Internet-Draft                    REIM                     November 2025


      The Attester MUST protect Claims with this Authentication Secret
      to prove the authenticity of the Claims included in Evidence.  The
      Authentication Secret MUST be established before RATS take place.

   Attester Identity:  A statement made by an Endorser about an Attester
      that affirms the Attester's distinguishability.

      In essence, an Attester Identity can either be explicit (e.g., via
      a Claim in Evidence or Endorsement) or implicit (e.g., via a
      signature that matches a trust anchor).  Note that
      distinguishability does not imply uniqueness; for example, a group
      of Attesters can be identified by an Attester Identity.

      The provenance of Evidence SHOULD be distinguishable with respect
      to the Attesting Environment and MUST be unambiguous with respect
      to the Attester Identity.

      An Attester Identity MAY be an Authentication Secret which is
      available exclusively to one of the Attesting Environments of the
      Attester.  It could be a unique identity, it could be included in
      a zero-knowledge proof (ZKP), it could be part of a group
      signature, or it could be a randomized DAA credential [DAA].

   Attestation Evidence Authenticity:  Attestation Evidence MUST be
      authentic.

      In order to provide a proof of authenticity, Attestation Evidence
      can be cryptographically associated with an identity document
      (e.g., a PKIX certificate or trusted key material, or a randomized
      DAA credential [DAA]), or could include a correct, unambiguous,
      and stable reference to an accessible identity document.

      Authenticity includes the protection of Evidence in a tamper-
      evident manner (e.g., either by signatures or by protection
      mechanisms implemented at both ends of a Secure Channel; see
      Authentication above).

   Evidence Freshness:  Evidence MUST include an indicator about its
      freshness that can be understood by a Verifier (See also
      Section 10 of [RFC9334]).  This enables interaction models to
      support the conveyance of proofs of freshness in a way that is
      useful to Verifiers and their appraisal procedures.









Birkholz, et al.           Expires 9 May 2026                   [Page 7]

Internet-Draft                    REIM                     November 2025


6.  Generic Information Elements

   This section describes the essential information elements for the
   interaction models described in Section 7.  These generic information
   elements may be Conceptual Messages included in the protocol messages
   or may be added as protocol parameters, depending on the specific
   solution.

   Attesting Environment IDs ('attEnvIDs'):  _optional_

      A statement representing one or more identifiers that MUST be
      associated with a corresponding Attestation Environment's keys
      used to protect Claims in Evidence produced by an Attester.
      Exemplary identifiers include attestation key material (e.g., the
      public key associated with the private key that is used to produce
      Evidence), key identifiers, environment names, or individual
      hardware-based immutable identifiers.

      While a Verifier does not necessarily have knowledge about an
      Attesting Environment's identifiers, each distinguishable
      Attesting Environment typically has access to a protected
      capability that includes an Attesting Environment ID.  If no
      Attesting Environment IDs are provided, a local default applies
      based on the Attester.  For example, all Attesting Environments
      will provide Evidence.

   Handle (handle):  _mandatory_

      An information element provided to the Attester from an external
      source included in Evidence (or other RATS Conceptual Messages) to
      determine recentness, freshness, or to protect against replay
      attacks.

      The term Handle encompasses various data types that can be
      utilized to determine recentness, freshness, or provide replay
      protection.  Examples include Nonces, which protect against replay
      attacks, and Epoch Markers that identify distinct periods (Epochs)
      of freshness [I-D.ietf-rats-epoch-markers].  Handles can also
      indicate authenticity or attestation Evidence provenance, as only
      specific RATS roles (e.g., an Attester and a Verifier in a
      challenge-response interaction) are meant to know a certain
      handle.

   Claims (claims):  _mandatory_

      Claims are assertions that represent characteristics of an
      Attester's Target Environment.




Birkholz, et al.           Expires 9 May 2026                   [Page 8]

Internet-Draft                    REIM                     November 2025


      Claims are part of a Conceptual Message and are used, for example,
      to appraise the integrity of Attesters by Verifiers.  The other
      information elements in this section can be presented as Claims in
      any type of Conceptual Message.

   Event Logs (eventLogs):  _optional_

      Event Logs accompany Claims by providing event trails of security-
      critical events in a system.  The primary purpose of Event Logs is
      to ensure Claim reproducibility by providing information on how
      Claims originated.

   Verifier Inputs ('verInputs')  _mandatory_

      Appraisal procedures implemented by Verifiers require certain
      inputs as defined in [RFC9334]: Reference Values, Endorsements,
      and Appraisal Policy for Evidence.  These Conceptual Messages can
      take various forms.  For example, Reference Values that can be
      expressed via Reference Integrity Measurements (RIM) or
      Endorsements that can range from trust anchors to assertions
      cryptographically bound to the public key associated with an
      Attesting Environment.

   Claim Selection (claimSelection):  _optional_

      A (sub-)set of Claims that can be collected and incorporated in
      Evidence by the Attesting Environments of an Attester.

      Claim Selections act as optional filters to specify the exact set
      of Claims to be included in Evidence.  For example, a Verifier
      could send a Claim Selection, among other elements, to an
      Attester.  An Attester MAY decide whether or not to provide all
      requested Claims from a Claim Selection to the Verifier.  If there
      is no way to convey a Claim Selection in a remote attestation
      protocol, a default Claim Selection (e.g., "all") MUST be defined
      by the Attester and SHOULD be known by the Verifier.  In order to
      select Claims, Claims that can be potentially included in Evidence
      by an Attesting Environment have to be known by the Verifier.

   Collected Claims (collectedClaims):  _mandatory_

      Collected Claims represent a (sub-)set of Claims created by an
      Attester.

      Collected Claims are gathered based on the Claim Selection.  If a
      Verifier does not provide a Claim Selection, all available Claims
      on the Attester are part of the Collected Claims.




Birkholz, et al.           Expires 9 May 2026                   [Page 9]

Internet-Draft                    REIM                     November 2025


   Evidence (evidence):  _mandatory_

      A set of Claims that can include: (a) a list of Attestation
      Environment IDs, each identifying an Authentication Secret in a
      single Attesting Environment, (b) the Attester Identity, (c)
      Claims about the Attester's Target Environment, and (d) a Handle.
      Attestation Evidence MUST cryptographically bind all of these
      information elements.  Evidence MUST be protected via an
      Authentication Secret.  The Authentication Secret MUST be trusted
      by the Verifier as authoritatively "speaking for" [lampson06] the
      Attester.

   Attestation Result (attestationResult):  _mandatory_

      An Attestation Result is produced by the Verifier as the output of
      the appraisal of Evidence generated by an Attester.  Attestation
      Results include concise assertions about integrity or other
      characteristics of the appraised Attester that can be processed by
      Relying Parties.

7.  Interaction Models

   This document describes three interaction models for Remote
   Attestation:

   1.  Challenge/Response (Section 7.1),

   2.  Unidirectional (Section 7.2), and

   3.  Streaming (Section 7.3).

   Each section starts with a sequence diagram illustrating the
   interactions between the involved roles: Attester, Verifier and,
   optionally, a Relying Party.  The presented interaction models focus
   on the conveyance of Evidence and Attestation Results.  The same
   interaction models may apply to the conveyance of other Conceptual
   Messages (Endorsements, Reference Values, or Appraisal Policies) with
   other roles involved.  However, that is out of scope for the present
   document.

   All interaction models have a strong focus on the use of a Handle to
   incorporate a proof of freshness and to prevent replay attacks.  The
   way the Handle is processed is the most prominent difference between
   the three interaction models.







Birkholz, et al.           Expires 9 May 2026                  [Page 10]

Internet-Draft                    REIM                     November 2025


7.1.  Challenge/Response Remote Attestation

   Note: In the following diagrams, a leading ? indicates that an
   information element is optional.

.----------.                                                .----------.
| Attester |                                                | Verifier |
'----+-----'                                                '-----+----'
     |                                                            |
=================[Evidence Generation and Conveyance]===================
     |                                                            |
  generateClaims(attestingEnvironment)                            |
     | => claims, ?eventLogs                                      |
     |                                                            |
     |<----- requestEvidence(handle, ?attEnvIDs, ?claimSelection) |
     |                                                            |
  collectClaims(claims, ?claimSelection)                          |
     | => collectedClaims                                         |
     |                                                            |
  generateEvidence(handle, ?attEnvIDs, collectedClaims)           |
     | => evidence                                                |
     |                                                            |
     | {evidence, ?eventLogs}------------------------------------>|
     |                                                            |
==========================[Evidence Appraisal]==========================
     |                                                            |
     |                appraiseEvidence(evidence, ?eventLogs, verInputs)
     |                                       attestationResult <= |
     |                                                            |

      Figure 1: Figure 1: Challenge/Response Remote Attestation

   The Attester boots up and thereby produces Claims about its boot
   state and its operational state during runtime (cf. Section 2), e.g.,
   loaded applications, configurations, and environment variables.
   Event Logs may accompany the produced Claims and provide an event
   trail of security-critical events in the system.  Claims are produced
   by all Attesting Environments of an Attester system.

   The Challenge/Response remote attestation procedure is typically
   initiated by the Verifier by sending a remote attestation request to
   the Attester.  Alternative initiation flows, e.g., via an
   intermediary or through pre-configured requests (e.g., Call-Home
   procedures or trusted trigger events from Relying Parties), are out
   of scope for this document.  A request includes a Handle, an optional
   list of Attestation Key IDs, and an optional Claim Selection.





Birkholz, et al.           Expires 9 May 2026                  [Page 11]

Internet-Draft                    REIM                     November 2025


   In the Challenge/Response model, the Handle is composed of qualifying
   data in the form of a practically infeasible-to-guess nonce
   [RFC4949], such as a cryptographically strong random number.  This
   nonce is typically generated by the Verifier to guarantee Evidence
   freshness and prevent replay attacks; however, depending on
   deployment context, it may also be generated by another trusted role,
   such as a Relying Party.

   The list of Attestation Key IDs selects the attestation keys with
   which the Attester is requested to sign the attestation Evidence.
   Each selected key is uniquely associated with an Attesting
   Environment of the Attester.  As a result, a single Attestation Key
   ID identifies a single Attesting Environment.  Correspondingly, a
   particular set of Evidence originating from a particular Attesting
   Environment in a composite device can be requested via multiple
   Attestation Key IDs.  Methods to acquire Attestation Key IDs or
   mappings between Attesting Environments to Attestation Key IDs are
   out of scope of this document.

   The Attester selects Claims based on the specified Claim Selection,
   which is defined by the Verifier.  The Claim Selection determines the
   Collected Claims, which may be a subset of all the available Claims.
   If the Claim Selection is omitted, then all available Claims on the
   Attester MUST be used to create corresponding Evidence.  For example,
   when performing a boot integrity evaluation, a Verifier may only
   request specific claims about the Attester, such as Evidence about
   the BIOS/UEFI and firmware that the Attester booted up, without
   including information about all currently running software.

   With the Handle, the Attestation Key IDs, and the Collected Claims,
   the Attester produces signed Evidence.  That is, it digitally signs
   the Handle and the Collected Claims with a cryptographic secret
   identified by the Attestation Key ID.  This is done once per
   Attesting Environment which is identified by the particular
   Attestation Key ID.  The Attester communicates the signed Evidence as
   well as all accompanying Event Logs back to the Verifier.

   The Claims, the Handle, and the Attester Identity information (i.e.,
   the Authentication Secret) MUST be cryptographically bound to the
   signature of Evidence.  These MAY be presented obfuscated, encrypted,
   or cryptographically blinded.  For further reference see,
   Section Section 9.









Birkholz, et al.           Expires 9 May 2026                  [Page 12]

Internet-Draft                    REIM                     November 2025


   Upon receiving the Evidence and Event Logs, the Verifier validates
   the signature, Attester Identity, and Handle, and then appraises the
   Claims.  Claim appraisal is driven by Policy and takes Reference
   Values and Endorsements as input.  The Verifier outputs Attestation
   Results.  Attestation Results create new Claim Sets about the
   properties and characteristics of an Attester, which enable Relying
   Parties to assess an Attester's trustworthiness.

   Note: This diagram illustrates the canonical Challenge/Response
   interaction between Attester and Verifier.  Variants that include a
   Relying Party (e.g., Passport or Background-Check models) are shown
   in subsequent sections.

7.1.1.  Models and Example Sequences of Challenge/Response Remote
        Attestation

   According to the RATS Architecture, two reference models for
   Challenge/Response Attestation have been proposed.  This section
   highlights the information flows between the Attester, Verifier, and
   Relying Party undergoing Remote Attestation Procedure, using these
   models.

7.1.1.1.  Passport Model

   The passport model is so named because of its resemblance to how
   nations issue passports to their citizens.  In this model, the
   attestation sequence is a two-step procedure.  In the first step, an
   Attester conveys Evidence to a Verifier, which appraises the Evidence
   according to its Appraisal Policy.  The Verifier then gives back an
   Attestation Result to the Attester, which caches it.  In the second
   step, the Attester presents the Attestation Result (and possibly
   additional Claims/Evidence) to a Relying Party, which appraises this
   information according to its own Appraisal Policy to establish the
   trustworthiness of the Attester.

















Birkholz, et al.           Expires 9 May 2026                  [Page 13]

Internet-Draft                    REIM                     November 2025


.----------.                     .---------------.         .----------.
| Attester |                     | Relying Party |         | Verifier |
'----+-----'                     '-------+-------'         '-----+----'
     |                                   |                       |
=================[Evidence Generation and Conveyance]===================
     |                                   |                       |
  generateClaims(attestingEnvironment)   |                       |
     | => {claims, ?eventLogs}           |                       |
     |                                   |                       |
     |<----------------------------------(----------- requestEvidence(
     |                                   |              handle,
     |                                   |              ?attEnvIDs,
     |                                   |              ?claimSelection)
  collectClaims(claims,                  |                       |
     ?claimSelection)                    |                       |
     | => collectedClaims                |                       |
     |                                   |                       |
  generateEvidence(handle,               |                       |
     ?attEnvIDs, collectedClaims)        |                       |
     | => evidence                       |                       |
     |                                   |                       |
     | {evidence, ?eventLogs} -----------)---------------------->|
     |                                   |                       |
==========================[Evidence Appraisal]==========================
     |                                   |                       |
     |                                   |           appraiseEvidence(
     |                                   |             evidence,
     |                                   |             ?eventLogs,
     |                                   |             verInputs)
     |                                   |  attestationResult <= |
     |                                   |                       |
=============[Attestation Result Conveyance and Appraisal]==============
     |                                   |                       |
     | <---------------------------------(-- {attestationResult} |
     |                                   |                       |
     |                                   |                       |
     | {evidence, attestationResult} --->|                       |
     |                                   |                       |
     |                            appraiseResult(                |
     |                              policy,                      |
     |                              attestationResult)           |
     |                                   |                       |

   Figure 2: Figure 2: Passport Model for Challenge/Response Remote
                             Attestation






Birkholz, et al.           Expires 9 May 2026                  [Page 14]

Internet-Draft                    REIM                     November 2025


7.1.1.2.  Background-Check Model

   The background-check model is so named because of the resemblance of
   how employers and volunteer organizations perform background checks.
   In this model, the attestation sequence is initiated by a Relying
   Party.  The Attester conveys Evidence to the Relying Party, which
   does not process its payload, but relays the message and optionally
   checks its signature against a policed trust anchor store.  Upon
   receiving the Evidence, the Relying Party initiates a session with
   the Verifier.  Once the session is established, it forwards the
   received Evidence to the Verifier.  The Verifier appraises the
   received Evidence according to its appraisal policy for Evidence and
   returns a corresponding Attestation Result to the Relying Party.  The
   Relying Party then checks the Attestation Result against its own
   appraisal policy to conclude attestation.




































Birkholz, et al.           Expires 9 May 2026                  [Page 15]

Internet-Draft                    REIM                     November 2025


.----------.                     .---------------.         .----------.
| Attester |                     | Relying Party |         | Verifier |
'----+-----'                     '-------+-------'         '-----+----'
     |                                   |                       |
=================[Evidence Generation and Conveyance]===================
     |                                   |                       |
  generateClaims(attestingEnvironment)   |                       |
     | => {claims, ?eventLogs}           |                       |
     |                                   |                       |
     |<-------------------------- requestEvidence(               |
     |                              handle,                      |
     |                              ?attEnvIDs,                  |
     |                              ?claimSelection)             |
     |                                   |                       |
  collectClaims(claims,                  |                       |
     ?claimSelection)                    |                       |
     | => collectedClaims                |                       |
     |                                   |                       |
  generateEvidence(handle,               |                       |
     ?attEnvIDs, collectedClaims)        |                       |
     | => evidence                       |                       |
     |                                   |                       |
     | {evidence, ?eventLogs} ---------->|                       |
     |                                   | {handle, evidence,    |
     |                                   |  ?eventLogs} -------->|
     |                                   |                       |
==========================[Evidence Appraisal]==========================
     |                                   |                       |
     |                                   |           appraiseEvidence(
     |                                   |             evidence,
     |                                   |             ?eventLogs,
     |                                   |             verInputs)
     |                                   |  attestationResult <= |
     |                                   |                       |
=============[Attestation Result Conveyance and Appraisal]==============
     |                                   |                       |
     |                                   |<- {attestationResult} |
     |                                   |                       |
     |                        appraiseResult(policy,             |
     |                          attestationResult)               |
     |                                   |                       |

  Figure 3: Figure 3: Background-Check Model for Challenge/Response
                          Remote Attestation

7.2.  Uni-Directional Remote Attestation





Birkholz, et al.           Expires 9 May 2026                  [Page 16]

Internet-Draft                    REIM                     November 2025


.----------.                       .--------------------.   .----------.
| Attester |                       | Handle Distributor |   | Verifier |
'----+-----'                       '---------+----------'   '-----+----'
     |                                       |                    |
 .--------[loop]------------------------------------------------------.
|    |                                                            |    |
| ========================[Handle Generation]========================= |
|    |                                    generateHandle()        |    |
|    |                                       | => handle          |    |
|    |                                       |                    |    |
|    |<---------------------------- {handle} | {handle} --------->|    |
|    |                                       |                    |    |
|    |                                       x                    |    |
|    |                                                            |    |
| ===============[Evidence Generation and Conveyance]================= |
|    |                                                            |    |
| generateClaims(attestingEnvironment)                            |    |
|    | => claims, eventLogs                                       |    |
|    |                                                            |    |
| collectClaims(claims, ?claimSelection)                          |    |
|    | => collectedClaims                                         |    |
|    |                                                            |    |
| generateEvidence(handle, attEnvIDs, collectedClaims)            |    |
|    | => evidence                                                |    |
|    |                                                            |    |
|    | {evidence, eventLogs} ------------------------------------>|    |
|    |                                                            |    |
| ========================[Evidence Appraisal]======================== |
|    |                                                            |    |
|    |                                      appraiseEvidence(evidence, |
|    |                                                      eventLogs, |
|    |                                                      verInputs) |
|    |                                       attestationResult <= |    |
|    ~                                                            ~    |
|    |                                                            |    |
| .-------[loop]-----------------------------------------------------. |
||   |                                                            |   ||
|| ============[Delta Evidence Generation and Conveyance]============ ||
||   |                                                            |   ||
|| generateClaims(attestingEnvironment)                           |   ||
||   | => claimsDelta, eventLogsDelta                             |   ||
||   |                                                            |   ||
|| collectClaims(claimsDelta, ?claimSelection)                    |   ||
||   | => collectedClaimsDelta                                    |   ||
||   |                                                            |   ||
|| generateEvidence(handle, attEnvIDs, collectedClaimsDelta)      |   ||
||   | => evidence                                                |   ||
||   |                                                            |   ||



Birkholz, et al.           Expires 9 May 2026                  [Page 17]

Internet-Draft                    REIM                     November 2025


||   | {evidence, eventLogsDelta} ------------------------------->|   ||
||   |                                                            |   ||
|| ====================[Delta Evidence Appraisal]==================== ||
||   |                                                            |   ||
||   |                                     appraiseEvidence(evidence, ||
||   |                                                eventLogsDelta, ||
||   |                                                     verInputs) ||
||   |                                       attestationResult <= |   ||
||   |                                                            |   ||
| '------------------------------------------------------------------' |
 '--------------------------------------------------------------------'
     |                                                            |

        Figure 4: Figure 4: Uni-Directional Remote Attestation

   Uni-Directional Remote Attestation procedures can be initiated both
   by the Attester and by the Verifier.  Initiation by the Attester can
   result in unsolicited pushes of Evidence to the Verifier.  Initiation
   by the Verifier always results in solicited pushes to the Verifier.

   The Uni-Directional model uses the same information elements as the
   Challenge/Response model.  In the sequence diagram above, the
   Attester initiates the conveyance of Evidence (comparable with a
   RESTful POST operation).  While a request of Evidence from the
   Verifier would result in a sequence diagram more similar to the
   Challenge/Response model (comparable with a RESTful GET operation).
   The specific manner how Handles are generated is not in scope of this
   document.  One example of a specific handle representation is
   [I-D.ietf-rats-epoch-markers].

   In the Uni-Directional model, handles are composed of
   cryptographically signed trusted timestamps as shown in
   [I-D.birkholz-rats-tuda], potentially including other qualifying
   data.  The Handles are created by an external trusted third party
   (TTP) -- the Handle Distributor -- which includes a trustworthy
   source of time, and takes on the role of a Time Stamping Authority
   (TSA, as initially defined in [RFC3161]).  Timestamps created from
   local clocks (absolute clocks using a global timescale, as well as
   relative clocks, such as tick-counters) of Attesters and Verifiers
   MUST be cryptographically bound to fresh Handles received from the
   Handle Distributor.  This binding provides a proof of synchronization
   that MUST be included in all produced Evidence.  This model provides
   proof that Evidence generation happened after the Handle generation
   phase.  The Verifier can always determine whether the received
   Evidence includes a fresh Handle, i.e., one corresponding to the
   current Epoch.





Birkholz, et al.           Expires 9 May 2026                  [Page 18]

Internet-Draft                    REIM                     November 2025


7.2.1.  Handle Lifecycle and Propagation Delays

   The term "uni-directional" refers to individual conveyance channels:
   one from the Handle Distributor to the Attester, and one from the
   Attester to the Verifier.  Together, they establish an attestation
   loop without requiring request/response exchanges.  This model does
   not assume that Verifiers broadcast Handles, as such a setup would
   require Verifiers to take on the Handle Distributor role and
   undermine the separation of duties between these roles.

   The lifecycle of a handle is a critical aspect of ensuring the
   freshness and validity of attestation Evidence.  When a new handle is
   generated by the Handle Distributor, it effectively supersedes the
   previous handle.  However, due to network latencies and propagation
   delays, there may be a period during which both the old and new
   handles are in circulation.  This "grey zone" can potentially lead to
   situations where Evidence may be associated with an outdated handle
   yet still appear to be valid.

   To manage this complexity, it is essential to define a clear policy
   for handle validity and expiration:

   *  _Handle Expiry_: Each handle should have a well-defined expiration
      time, after which it is considered invalid.  This expiry must
      account for expected propagation delays and be clearly
      communicated to all entities in the attestation process.

   *  _Synchronization Checks_: Implement periodic synchronization
      checks between the Handle Distributor and both Attesters and
      Verifiers to ensure that handles are updated consistently across
      all participants.  For example, in TUDA [I-D.birkholz-rats-tuda],
      synchronization checks can be realized by cryptographically
      binding local timestamps from Attesters and Verifiers to fresh
      Epoch Handles issued by a trusted Time Stamp Authority (TSA),
      thereby proving that both entities share a consistent notion of
      time.

   *  _Grace Periods_: Define grace periods during which a newly issued
      handle starts being accepted, and the old handle stops being
      valid.  This period should be long enough to account for the
      maximum expected propagation delay across the network.

   Implementing these measures will help mitigate the risks associated
   with the handle lifecycle, particularly in environments where
   propagation delays are significant.  This careful management ensures
   that the integrity and trustworthiness of the attestation process are
   maintained.




Birkholz, et al.           Expires 9 May 2026                  [Page 19]

Internet-Draft                    REIM                     November 2025


   While periodically pushing Evidence to the Verifier, the Attester
   only needs to generate and convey updates since the previous
   conveyance.  These updates, referred to as "delta" in the sequence
   diagrams, are not limited to net changes of Claim values.  They MUST
   include all state changes detected since the previous conveyance,
   even if values later revert to their prior state.  For example, if an
   Attester goes through a sleep or hibernation cycle and a Claim value
   changes and then reverts, both transitions MUST be reported to the
   Verifier as soon as possible after resuming operation.

   Effectively, the Uni-Directional model allows for a series of
   Evidence to be pushed to multiple Verifiers simultaneously.  Methods
   to detect excessive time drift that would mandate a fresh Handle to
   be received by the Handle Distributor as well as timing of Handle
   distribution are out-of-scope of this document.

7.3.  Streaming Remote Attestation

   Streaming Remote Attestation serves as the foundational concept for
   both the observer pattern [ISIS] and the publish-subscribe pattern
   [DesignPatterns].  It entails establishing subscription states to
   enable continuous remote attestation.  In the observer pattern,
   observers are directly connected to target resources without a
   Broker, while the publish-subscribe pattern involves a central Broker
   for message distribution.

7.3.1.  Streaming Remote Attestation without a Broker

.----------.                                                .----------.
| Attester |                                                | Verifier |
'----+-----'                                                '-----+----'
     |                                                            |
 .--------[loop]------------------------------------------------------.
|    |                                                            |    |
| ========================[Handle Generation]========================= |
|    |                                                            |    |
|    |                                                generateHandle() |
|    |                                                   handle<= |    |
|    |                                                            |    |
|    |<------------ subscribe(handle, attEnvIDs, ?claimSelection) |    |
|    | {handle} ------------------------------------------------->|    |
|    |                                                            |    |
| ===============[Evidence Generation and Conveyance]================= |
|    |                                                            |    |
| generateClaims(attestingEnvironment)                            |    |
|    | => claims, eventLogs                                       |    |
|    |                                                            |    |
| collectClaims(claims, ?claimSelection)                          |    |



Birkholz, et al.           Expires 9 May 2026                  [Page 20]

Internet-Draft                    REIM                     November 2025


|    | => collectedClaims                                         |    |
|    |                                                            |    |
| generateEvidence(handle, attEnvIDs, collectedClaims)            |    |
|    | => evidence                                                |    |
|    |                                                            |    |
|    | {handle, evidence, eventLogs} ---------------------------->|    |
|    |                                                            |    |
| ========================[Evidence Appraisal]======================== |
|    |                                                            |    |
|    |                                      appraiseEvidence(evidence, |
|    |                                                      eventLogs, |
|    |                                                      verInputs) |
|    |                                       attestationResult <= |    |
|    ~                                                            ~    |
|    |                                                            |    |
| .--------[loop]----------------------------------------------------. |
||   |                                                            |   ||
|| ============[Delta Evidence Generation and Conveyance]============ ||
||   |                                                            |   ||
|| generateClaims(attestingEnvironment)                           |   ||
||   | => claimsDelta, eventLogsDelta                             |   ||
||   |                                                            |   ||
|| collectClaims(claimsDelta, ?claimSelection)                    |   ||
||   | => collectedClaimsDelta                                    |   ||
||   |                                                            |   ||
|| generateEvidence(handle, attEnvIDs, collectedClaimsDelta)      |   ||
||   | => evidence                                                |   ||
||   |                                                            |   ||
||   | {evidence, eventLogsDelta} ------------------------------->|   ||
||   |                                                            |   ||
|| ====================[Delta Evidence Appraisal]==================== ||
||   |                                                            |   ||
||   |                                     appraiseEvidence(evidence, ||
||   |                                                eventLogsDelta, ||
||   |                                                     verInputs) ||
||   |                                       attestationResult <= |   ||
||   |                                                            |   ||
| '------------------------------------------------------------------' |
 '--------------------------------------------------------------------'
     |                                                            |

  Figure 5: Figure 5: Streaming Remote Attestation without a Broker

   In the observer pattern, an observer establishes a direct connection
   to the observed resources through a subscription mechanism, which is
   designed specifically for conveying conceptual messages for remote
   attestation purposes.  This mechanism not only facilitates the
   initial subscription request but also actively maintains the state of



Birkholz, et al.           Expires 9 May 2026                  [Page 21]

Internet-Draft                    REIM                     November 2025


   the subscription, ensuring that any changes in the observed resources
   are consistently communicated to the observer.  It handles the
   complexities of managing these connections, including the maintenance
   of pertinent information about the observer's preferences and
   security requirements, ensuring that the transmission of attestation
   data remains both secure and relevant to the observer's specific
   context.

   Setting up subscription state between a Verifier and an Attester is
   conducted via a subscribe operation.  The subscribe operation is used
   to convey Handles required for Evidence generation.  Effectively,
   this allows for a series of Evidence to be pushed to a Verifier,
   similar to the Uni-Directional model.  In the observer pattern, the
   Handle Distributor role is optional.  While the model is typically
   used for direct, bi-lateral subscription relationships where the
   Verifier generates and provides Handles directly, it is also possible
   to include the trusted third party that is a Handle Distributor.  A
   Handle Distributor independently manages the generation and
   distribution of Handles to other RATS roles.  As a result, scenarios
   involving more than bi-lateral interactions are enabled.  However, in
   its basic form, the model assumes direct interaction between an
   Attester and a Verifier, where the Handle generation is a
   responsibility taken on by the Verifier roles.

   Handles provided by a specific subscribing Verifier MUST be used in
   Evidence generation for that specific Verifier.  The streaming model
   without a Broker uses the same information elements as the Challenge/
   Response and the Uni-Directional model.  Methods to detect excessive
   time drift that would render Handles stale and mandate a fresh
   Handles to be conveyed via another subscribe operation are out-of-
   scope of this document.

   If Evidence or delta Evidence repeatedly fails to verify, a Verifier
   may terminate the subscription.  The detailed mechanisms for
   unsubscribe and re-subscribe are protocol-specific and out of scope
   for this document; for example, subscription lifecycle management is
   defined in [I-D.ietf-rats-network-device-subscription].

7.3.2.  Streaming Remote Attestation with a Broker

   This model includes a Broker to facilitate the distribution of
   messages between RATS roles, such as Attesters and Verifiers.  The
   Broker is a trusted third party and acts as an intermediary that
   ensures messages are securely and reliably conveyed between involved
   RATS roles.  The publish-subscribe messaging pattern is widely used
   for communication in different areas.  An example for a publish-
   subscribe model with a Broker is the Message Queuing Telemetry
   Transport [MQTT].  Unlike the _Streaming Remote Attestation without a



Birkholz, et al.           Expires 9 May 2026                  [Page 22]

Internet-Draft                    REIM                     November 2025


   Broker_ interaction model, Attesters are not required to be aware of
   corresponding Verifiers.  In scenarios with large numbers of
   Attesters and Verifiers, the publish-subscribe pattern may reduce
   interdependencies and improve scalability.

   With publish-subscribe, clients typically _connect_ to (or _register_
   with) a publish-subscribe server (PubSub server or Broker).  Clients
   may _publish_ data in the form of a _message_ under a certain
   _topic_. _Subscribers_ to that topic get _notified_ whenever a
   message arrives under a topic, and the appropriate message is
   forwarded to them.  Depending on particular publish-subscribe models
   and implementations, involved roles can be publishers, subscribers or
   both.

   The Broker and Handle Distributor are considered to be trusted third
   parties (TTPs) for all other participating roles, including Attesters
   and Verifiers (see also Section 9).  All roles must establish a trust
   relationship with the Broker and Handle Distributor, as those are
   responsible for the secure and reliable dissemination of critical
   protocol information, such as Handles and Attestation Results.

   Ensuring the security of these trusted third parties is vital, as any
   compromise could undermine the entire remote attestation procedure.
   Therefore, the deployment of Brokers and Handle Distributors requires
   stringent security measures to protect against unauthorized access
   and to ensure that they operate as trustworthy facilitators within
   the remote attestation framework.

   In the following sections, the interaction models _Challenge/Response
   Remote Attestation over Publish-Subscribe_ and _Uni-Directional
   Remote Attestation over Publish-Subscribe_ are described.  There are
   different phases that both models go through:

   1.  Handle Generation

   2.  Evidence Generation and Conveyance

   3.  Evidence Appraisal

   4.  Attestation Result Generation

   The models only differ in the handle generation phase.  From a remote
   attestations procedure's point of view Evidence Generation,
   Conveyance, and Appraisal, as well as Attestation Result Generation
   are identical in both models.






Birkholz, et al.           Expires 9 May 2026                  [Page 23]

Internet-Draft                    REIM                     November 2025


7.3.2.1.  Handle Generation for Challenge/Response Remote Attestation
          over Publish-Subscribe

.----------.                     .---------------.          .----------.
| Attester |                     | PubSub Server |          | Verifier |
'----+-----'                     '-------+-------'          '-----+----'
     |                                   |                        |
==========================[Handle Generation]===========================
     |                                   |                        |
     |                                   |             generateHandle()
     |                                   |              handle <= |
   sub(topic=AttReq) ------------------->|                        |
     |                                   |<--------- pub(topic=AttReq,
     |                                   |                     handle)
     |<---------------------- notify(topic=AttReq, handle)        |
     |                                   |                        |
     ~                                   ~                        ~

     Figure 6: Figure 6: Handle Generation for Challenge/Response
              Remote Attestation over Publish-Subscribe

   The _Challenge/Response Remote Attestation over Publish-Subscribe_
   interaction model uses the same information elements as the
   _Challenge/Response Remote Attestation_ interaction model.  Handles
   are generated by the Verifier on a per-request basis.  In the
   sequence diagram above, the Verifier initiates an attestation by
   generating a new handle and publishing it to the "AttReq" (=
   Attestation Request) topic on the PubSub server.  The PubSub server
   then forwards this handle to the Attester by notifying it.  This
   mechanism ensures that each handle is uniquely associated with a
   specific attestation request, thereby enhancing security by
   preventing replay attacks.

7.3.2.2.  Handle Generation for Uni-Directional Remote Attestation over
          Publish-Subscribe
















Birkholz, et al.           Expires 9 May 2026                  [Page 24]

Internet-Draft                    REIM                     November 2025


.----------.  .-------------.    .---------------.          .----------.
| Attester |  |   Handle    |    | PubSub Server |          | Verifier |
'----+-----'  | Distributor |    '-------+-------'          '-----+----'
     |        '------+------'            |                        |
     |               |                   |                        |
==========================[Handle Generation]===========================
     |               |                   |                        |
     |               |                   |                        |
   sub(topic=Handle) ------------------->|                        |
     |               |                   |                        |
     |               |                   |<--------- sub(topic=Handle)
     |               |                   |                        |
     |               |                   |                        |
     |           generateHandle()        |                        |
     |               | => handle         |                        |
     |               |                   |                        |
     |             pub(topic=Handle,     |                        |
     |               | handle) --------->|                        |
     |               x                   |                        |
     |                                   |                        |
     |<--------------------- notify(topic=Handle, handle)         |
     |                                   |                        |
     |                       notify(topic=Handle, handle) ------->|
     |                                   |                        |
     ~                                   ~                        ~

   Figure 7: Figure 7: Handle Generation for Uni-Directional Remote
                  Attestation over Publish-Subscribe

   Handles are created by a trusted third party, the Handle Distributor
   (see Section 9).  In the sequence diagram above, both an Attester and
   a Verifier subscribe to the topic "Handle" on the PubSub server.
   When the Handle Distributor generates and publishes a Handle to the
   "Handle" topic on the PubSub server, the PubSub server notifies the
   subscribers, Attester and Verifier, and forwards ("notify") the
   Handle to them during Handle Generation.

7.3.2.3.  Evidence Generation and Appraisal













Birkholz, et al.           Expires 9 May 2026                  [Page 25]

Internet-Draft                    REIM                     November 2025


     ~                                   ~                        ~
     |                                   |                        |
.----+-----.                     .-------+-------.          .-----+----.
| Attester |                     | PubSub Server |          | Verifier |
'----+-----'                     '-------+-------'          '-----+----'
     |                                   |                        |
     |                                   |<---------- sub(topic=AttEv)
     |                                   |                        |
 .--------[loop]------------------------------------------------------.
|    |                                   |                        |    |
| ===============[Evidence Generation and Conveyance]================= |
|    |                                   |                        |    |
| generateClaims(attestingEnvironment)   |                        |    |
|    | => claims, eventLogs              |                        |    |
|    |                                   |                        |    |
| collectClaims(claims, ?claimSelection) |                        |    |
|    | => collectedClaims                |                        |    |
|    |                                   |                        |    |
| generateEvidence(handle, attEnvIDs,    |                        |    |
|    |             collectedClaims)      |                        |    |
|    | => evidence                       |                        |    |
|    |                                   |                        |    |
|  pub(topic=AttEv,                      |                        |    |
|    | evidence, eventLogs) ------------>|                        |    |
|    |                                   |                        |    |
|    |                               notify(topic=AttEv,          |    |
|    |                                   |  evidence,             |    |
|    |                                   |  eventLogs) ---------->|    |
|    |                                   |                        |    |
| ========================[Evidence Appraisal]======================== |
|    |                                   |                        |    |
|    |                                   |           appraiseEvidence( |
|    |                                   |                   evidence, |
|    |                                   |                  eventLogs, |
|    |                                   |                  verInputs) |
|    |                                   |   attestationResult <= |    |
|    |                                   |                        |    |
 '--------------------------------------------------------------------'
     |                                   |                        |
     ~                                   ~                        ~

   Figure 8: Figure 8: Evidence Generation and Appraisal for Remote
                  Attestation over Publish-Subscribe

   Exactly as in the Challenge/Response and Uni-Directional interaction
   models, there is an Evidence Generation-Appraisal loop, in which the
   Attester generates Evidence and the Verifier appraises it.  In the
   Publish-Subscribe model above, the Attester publishes Evidence to the



Birkholz, et al.           Expires 9 May 2026                  [Page 26]

Internet-Draft                    REIM                     November 2025


   topic "AttEv" (= Attestation Evidence) on the PubSub server, to which
   a Verifier subscribed before.  The PubSub server notifies Verifiers,
   accordingly, by forwarding the attestation Evidence.  Although the
   above diagram depicts only full attestation Evidence and Event Logs,
   later attestations may use "deltas' for Evidence and Event Logs.  The
   definition of delta Evidence is provided in Section 7.2.1.

   Verifiers appraise the Evidence and publish the Attestation Result to
   topic "AttRes" (= Attestation Result) on the PubSub server.

7.3.2.4.  Attestation Result Generation

     ~          ~                        ~                        ~
     |          |                        |                        |
.----+-----. .--+------------.   .-------+-------.          .-----+----.
| Attester | | Relying Party |   | PubSub Server |          | Verifier |
'----+-----' '--+------------'   '-------+-------'          '-----+----'
     |          |                        |                        |
====================[Attestation Result Generation]=====================
     |          |                        |                        |
     |     sub(topic=AttRes,            |                        |
     |         handle) ----------------->|                        |
     |          |                        |                        |
 .--------[loop]------------------------------------------------------.
|    |          |                        |                        |    |
|    |          |                        |<--------- pub(topic=AttRes, |
|    |          |                        |          attestationResult) |
|    |          |                        |                        |    |
|    |          |<----------------- notify(topic=AttRes,          |    |
|    |          |                        | attestationResult)     |    |
|    |          |                        |                        |    |
 '--------------------------------------------------------------------'
     |          |                        |                        |
     ~          ~                        ~                        ~

     Figure 9: Figure 9: Attestation Result Generation for Remote
                  Attestation over Publish-Subscribe

   Attestation Result Generation is the same for both publish-subscribe
   models,_Challenge/Response Remote Attestation over Publish-Subscribe_
   and _Uni-Directional Remote Attestation over Publish-Subscribe_.
   Relying Parties subscribe to topic AttRes (= Attestation Result) on
   the PubSub server.  The PubSub server forwards Attestation Results to
   the Relying Parties as soon as they are published to topic AttRes.







Birkholz, et al.           Expires 9 May 2026                  [Page 27]

Internet-Draft                    REIM                     November 2025


8.  Implementation Status

   Note to RFC Editor: Please remove this section as well as references
   to [BCP205] before AUTH48.

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [BCP205].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [BCP205], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

8.1.  Implementer

   The open-source implementation was initiated and is maintained by the
   Fraunhofer Institute for Secure Information Technology SIT.

8.2.  Implementation Name

   The open-source implementation is named "CHAllenge-Response based
   Remote Attestation" or in short: CHARRA.

8.3.  Implementation URL

   The open-source implementation project resource can be located via:
   https://github.com/fraunhofer-sit/charra (https://github.com/
   fraunhofer-sit/charra)

8.4.  Maturity

   The code's level of maturity is considered to be "prototype".







Birkholz, et al.           Expires 9 May 2026                  [Page 28]

Internet-Draft                    REIM                     November 2025


8.5.  Coverage and Version Compatibility

   The current version ('6194b3b') implements a challenge/response
   interaction model and is aligned with the exemplary specification of
   the CoAP FETCH bodies defined in Section Appendix A of this document.

8.6.  License

   The CHARRA project and all corresponding code and data maintained on
   GitHub are provided under the BSD 3-Clause "New" or "Revised"
   license.

8.7.  Implementation Dependencies

   The implementation requires the use of the Trusted Computing Group
   (TCG) Trusted Software Stack (TSS), and an HSM interoperable with the
   Trusted Platform Module Library specifications, e.g., a Trusted
   Platform Module (TPM) 2.0 or equivalent implementation.  The
   corresponding project resources (code and data) for Linux-based
   operating systems are maintained on GitHub at https://github.com/
   tpm2-software/tpm2-tss/ (https://github.com/tpm2-software/tpm2-tss/).

   The implementation uses the Constrained Application Protocol
   [RFC7252] (http://coap.technology/) and the Concise Binary Object
   Representation [RFC7049] (https://cbor.io/).

8.8.  Contact

   Michael Eckel (michael.eckel@sit.fraunhofer.de)

9.  Security and Privacy Considerations

   This document outlines three interaction models for remote
   attestation procedures (RATS) [RFC9334].  While the subsequent
   sections address additional security and privacy considerations, the
   security considerations from Section 12 of [RFC9334] must also be
   adhered to.  Additionally, for TPM-based remote attestation, the
   security considerations outlined in Section 5 of [RFC9683] should be
   taken into account.

9.1.  Cryptographic Blinding

   In a remote attestation procedure, both the Verifier and the Attester
   may choose to cryptographically blind certain attributes to enhance
   privacy.  For example, specific information can be included in the
   signature after being processed through a one-way function, such as a
   hash function.




Birkholz, et al.           Expires 9 May 2026                  [Page 29]

Internet-Draft                    REIM                     November 2025


9.2.  Trust Assumptions on the Handle Distributor

   The handle distributor, as a third party in remote attestation
   scenarios, holds a critical position similar to that of a Trusted
   Third Party (TTP).  Given its role in generating handles, it has the
   potential to influence the attestation process significantly.  The
   integrity and reliability of the handles it produces are pivotal for
   ensuring that the attestation evidence remains trustworthy and that
   the attestation process is not susceptible to manipulation or
   interference.

9.2.1.  Security Assumptions

   *  _Integrity and Authenticity_: It is assumed that the handle
      distributor operates with high levels of integrity and
      authenticity.  Handles generated by the distributor must be
      secure, unique, and verifiable.  This ensures that they cannot be
      forged or reused maliciously.

   *  _Isolation and Protection_: The handle distributor must be
      isolated and protected from unauthorized access and attacks.  This
      includes physical security measures for hardware that might house
      the handle distributor's operations, as well as cybersecurity
      measures to protect against online threats.

   *  _Auditability_: The operations of the handle distributor should be
      auditable.  This allows for the verification of its compliance
      with security policies and the integrity of its operations.
      Regular audits help to ensure that the handle distributor is
      functioning as expected and has not been compromised.

   *  _Transparency_: While maintaining security and confidentiality,
      the processes by which handles are generated and distributed
      should be as transparent as possible to authorized parties.  This
      helps in building trust and verifying that handles are distributed
      in a fair and unbiased manner.

9.2.2.  Mitigating Risks

   To mitigate risks associated with the handle distributor being a
   central point of potential failure or attack, several measures should
   be implemented:

   *  _Redundancy_: Deploying multiple, geographically dispersed handle
      distributors can ensure continuity of service even if one
      distributor is compromised or fails.





Birkholz, et al.           Expires 9 May 2026                  [Page 30]

Internet-Draft                    REIM                     November 2025


   *  _Cryptographic Security_: Using strong cryptographic techniques to
      protect the generation and transmission of handles ensures that
      they cannot be tampered with during distribution.

   *  _Certification and Compliance_: The handle distributor should
      comply with relevant security standards and undergo regular
      security certifications.  This ensures that they meet industry-
      wide security benchmarks and maintain high levels of trust.

   By defining and adhering to these security assumptions, the role of
   the handle distributor in remote attestation procedures can be
   securely managed, minimizing risks and enhancing the overall trust in
   the attestation process.

9.3.  Security Considerations for Brokers in Remote Attestation

   The role of the Broker in the "Streaming Remote Attestation with a
   Broker model" introduces potential security vulnerabilities,
   including the ability to perform cross-application attacks by
   manipulating handles and topics.  To mitigate these risks, it is
   essential to implement robust security measures:

   *  _End-to-End Authentication:_ Establishing end-to-end authenticated
      channels between Attesters and Verifiers ensures that data
      integrity and authenticity are preserved across the communication
      process.  This measure prevents the Broker from altering the
      content of the messages, including Handles and other sensitive
      data.

   *  _Strong Isolation of Topics:_ Implementing strong isolation
      mechanisms for topics can help prevent the Broker from
      inadvertently or maliciously routing notifications to unauthorized
      parties.  This includes using secure naming conventions and access
      controls that restrict the Broker's ability to manipulate topic
      subscriptions.

   *  _Trusted Association Verification:_ To further safeguard against
      confusion attacks where the Broker might misroute notifications,
      mechanisms should be in place to verify the trust association
      between senders and receivers continuously.  This can be
      facilitated by cryptographic assurances, such as digital
      signatures and trusted certificates that validate the sender's
      identity and the integrity of the message content.








Birkholz, et al.           Expires 9 May 2026                  [Page 31]

Internet-Draft                    REIM                     November 2025


   *  _Audit and Monitoring:_ Regular audits and real-time monitoring of
      Broker activities can detect and respond to anomalous behavior
      that might indicate security breaches or manipulation attempts.
      Logging all actions performed by the Broker provides an audit
      trail that can be critical for forensic analysis.

   *  _Broker as a Trusted Third Party (TTP):_ Recognizing the Broker as
      a TTP necessitates stringent security certifications and
      compliance with security standards to ensure that they operate
      under strict governance and security protocols.  This includes
      regular security assessments and certifications that validate the
      Broker's security practices.

   By addressing these vulnerabilities proactively, the integrity and
   confidentiality of the attestation process can be maintained,
   reducing the risks associated with Broker-mediated communication in
   remote attestation scenarios.  It is crucial for solution architects
   to incorporate these security measures during the design and
   deployment phases to ensure that the attestation process remains
   secure and trustworthy.

9.4.  Additional Application-Specific Security Considerations

   The security and privacy requirements for remote attestation can vary
   significantly based on the deployment environment, the nature of the
   attestation mechanisms used, and the specific threats each scenario
   faces.  This section details additional security considerations that
   are pertinent to the interaction models discussed in this document.

9.4.1.  Confidentiality

   The need for confidentiality in the transmission of attestation
   information is critical, particularly when exchanges occur over
   public or untrusted networks, such as the public Internet.  For
   instance, in the _Streaming Remote Attestation with a Broker_ model
   (cf.Section 7.3.2), where data might traverse multiple nodes,
   employing TLS can provide necessary confidentiality protections.
   Similarly, for scenarios involving sensitive environments like
   carrier management networks, evaluating the confidentiality of the
   transport medium is crucial to ensure that attestation data remains
   secure against interception or eavesdropping.










Birkholz, et al.           Expires 9 May 2026                  [Page 32]

Internet-Draft                    REIM                     November 2025


9.4.2.  Mutual Authentication

   Mutual authentication is particularly relevant in models such as the
   _Challenge/Response Remote Attestation_ (cf. Section 7.1) where both
   the Attester and the Verifier engage in bidirectional exchanges of
   sensitive information.  Ensuring that both parties can authenticate
   each other prevents impersonation attacks, enhancing the
   trustworthiness of the attestation results.

9.4.3.  Hardware Enforcement/Support

   In environments where the integrity and security of attestation
   evidence are paramount, hardware-based security features play a
   critical role.  Technologies like Hardware Security Modules (HSMs),
   Physically Unclonable Functions (PUFs), and Trusted Execution
   Environments (TEEs) provide robust protections against tampering and
   unauthorized access.  These are especially important in high-security
   settings such as financial services or military applications, where
   attestation processes must rely on physically secure and tamper-
   resistant components to meet stringent regulatory and security
   standards.

   By addressing these application-specific security requirements within
   the context of defined interaction models, security strategies can be
   tailored to fit the unique challenges and operational contexts of
   different attestation scenarios.

10.  Acknowledgments

   Olaf Bergmann, Michael Richardson, and Ned Smith

11.  References

11.1.  Normative References

   [BCP205]   Best Current Practice 205,
              <https://www.rfc-editor.org/info/bcp205>.
              At the time of writing, this BCP comprises the following:

              Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.








Birkholz, et al.           Expires 9 May 2026                  [Page 33]

Internet-Draft                    REIM                     November 2025


   [I-D.ietf-rats-epoch-markers]
              Birkholz, H., Fossati, T., Pan, W., and C. Bormann, "Epoch
              Markers", Work in Progress, Internet-Draft, draft-ietf-
              rats-epoch-markers-02, 9 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
              epoch-markers-02>.

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

   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
              2001, <https://doi.org/10.17487/RFC3161>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://doi.org/10.17487/RFC5280>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://doi.org/10.17487/RFC7049>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://doi.org/10.17487/RFC7252>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://doi.org/10.17487/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://doi.org/10.17487/RFC9334>.

11.2.  Informative References

   [DAA]      Brickell, E., Camenisch, J., and L. Chen, "Direct
              Anonymous Attestation", page 132-145, ACM Proceedings of
              the 11th ACM conference on Computer and Communications
              Security, 2004.




Birkholz, et al.           Expires 9 May 2026                  [Page 34]

Internet-Draft                    REIM                     November 2025


   [DesignPatterns]
              Gamma, E., Helm, R., Johnson, R., and J. Vlissides,
              "Design Patterns - Elements of Reusable Object-Oriented
              Software", Publisher Addison-Wesley, 1994.

   [I-D.birkholz-rats-tuda]
              Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
              "Time-Based Uni-Directional Attestation", Work in
              Progress, Internet-Draft, draft-birkholz-rats-tuda-07, 10
              July 2022, <https://datatracker.ietf.org/doc/html/draft-
              birkholz-rats-tuda-07>.

   [I-D.ietf-rats-endorsements]
              Thaler, D., Birkholz, H., and T. Fossati, "RATS
              Endorsements", Work in Progress, Internet-Draft, draft-
              ietf-rats-endorsements-07, 25 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
              endorsements-07>.

   [I-D.ietf-rats-network-device-subscription]
              Birkholz, H., Voit, E., and W. Pan, "Attestation Event
              Stream Subscription", Work in Progress, Internet-Draft,
              draft-ietf-rats-network-device-subscription-07, 21 July
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              rats-network-device-subscription-07>.

   [ISIS]     Birman, K. and T. Joseph, "Exploiting Virtual Synchrony in
              Distributed Systems", DOI 10.1145/41457.37515, 1987,
              <https://doi.org/10.1145/41457.37515>.

   [lampson06]
              Lampson, B., "Practical Principles for Computer Security",
              2006.

   [MQTT]     OASIS, "Message Queuing Telemetry Transport (MQTT) Version
              5.0 Committee Specification 02", Specification Version
              5.0, 2018.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://doi.org/10.17487/RFC4949>.

   [RFC9683]  Fedorkow, G. C., Ed., Voit, E., and J. Fitzgerald-McKay,
              "Remote Integrity Verification of Network Devices
              Containing Trusted Platform Modules", RFC 9683,
              DOI 10.17487/RFC9683, December 2024,
              <https://doi.org/10.17487/RFC9683>.




Birkholz, et al.           Expires 9 May 2026                  [Page 35]

Internet-Draft                    REIM                     November 2025


   [RFC9781]  Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
              Bormann, "A Concise Binary Object Representation (CBOR)
              Tag for Unprotected CBOR Web Token Claims Sets (UCCS)",
              RFC 9781, DOI 10.17487/RFC9781, May 2025,
              <https://doi.org/10.17487/RFC9781>.

   [RFC9783]  Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
              Fossati, "Arm's Platform Security Architecture (PSA)
              Attestation Token", RFC 9783, DOI 10.17487/RFC9783, June
              2025, <https://doi.org/10.17487/RFC9783>.

   [turtles]  Rudnicki, R., "Turtles All the Way Down: Foundation,
              Edifice, and Ruin in Faulkner and McCarthy",
              DOI 10.1353/fau.2010.0002, The Faulkner Journal 25.2,
              2010, <https://doi.org/10.1353/fau.2010.0002>.

Appendix A.  CDDL Specification for a simple CoAP Challenge/Response
             Interaction

   The following CDDL specification is an exemplary proof-of-concept to
   illustrate a potential implementation of the Challenge/Response
   Interaction Model.  The communication protocol used is CoAP.  Both
   the request message and the response message are exchanged via the
   FETCH operation and corresponding FETCH request and FETCH response
   body.

   In this example, Evidence is created via the root-of-trust for
   reporting primitive operation "quote" that is provided by a TPM 2.0.























Birkholz, et al.           Expires 9 May 2026                  [Page 36]

Internet-Draft                    REIM                     November 2025


   charra-bodies = charra-attestation-request / charra-attestation-response

   charra-attestation-request = [
       hello: bool,    ; if true, the TPM 2.0 AK Cert shall be conveyed
       key-id: bytes,  ; the key ID to use for signing
       nonce: bytes,   ; a (random) nonce, providing freshness and/or recentness
       pcr-selections: [ * pcr-selection ]
   ]

   pcr-selection = [
       tcg-hash-alg-id: uint .size 2,  ; TPM2_ALG_ID
       pcrs: [
           pcr: uint .size 2
       ]
   ]

   charra-attestation-response = [
       attestation-data: bytes,  ; TPMS_ATTEST.quoted
       tpm2-signature: bytes,
       ? ak-cert: bytes,         ; TPM2 attestation key certificate (AK Cert)
   ]

Authors' Addresses

   Henk Birkholz
   Fraunhofer SIT
   Rheinstrasse 75
   64295 Darmstadt
   Germany
   Email: henk.birkholz@sit.fraunhofer.de


   Michael Eckel
   Fraunhofer SIT
   Rheinstrasse 75
   64295 Darmstadt
   Germany
   Email: michael.eckel@sit.fraunhofer.de


   Wei Pan
   Huawei Technologies
   Email: william.panwei@huawei.com


   Eric Voit
   Cisco Systems
   Email: evoit@cisco.com



Birkholz, et al.           Expires 9 May 2026                  [Page 37]
