Merge pull request #74 from ietf-rats-wg/addressing-issue-73-review-thomas

Integrated Thomas Fossati's review from 2025-07-17 (RATS mailing list).

Author: henkbirkholz

draft-ietf-rats-reference-interaction-models.md

@@ -52,11 +52,11 @@ normative:
   RFC7252: COAP
   BCP205:
   RFC9334: RATS
-  RFC9683: RIV
   I-D.ietf-rats-epoch-markers: epoch-markers
 
 informative:
   I-D.birkholz-rats-tuda: TUDA
+  RFC9683: RIV
   RFC9783: psa-token
   RFC9781: uccs
   DAA:
@@ -134,7 +134,7 @@ Analogously, a general overview about the information elements typically used by
 # Introduction
 
 Remote ATtestation procedureS (RATS, {{-RATS}}) are workflows composed of roles and interactions, in which Verifiers create Attestation Results about the trustworthiness of an Attester's system component characteristics.
-Verifiers generate assessments in the form of Attestation Results that are based on Endorsements, Reference Values, Appraisal Policies, and Evidence -- trustable and tamper-evident Claims Sets about 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 {{-RATS}}.
  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:
@@ -149,13 +149,12 @@ The roles *Attester* and *Verifier*, as well as the Conceptual Messages *Evidenc
    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.
-The reference models defined can also be applied to the conveyance of other Conceptual Messages in RATS.
 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.
 
-In summary, this document enables the specification and design of trustworthy and privacy-preserving conveyance methods for RATS Conceptual Messages; specifically attestation Evidence conveyed from an Attester to a Verifier.
+In summary, this document enables the specification and design of trustworthy and privacy-preserving (see Section {{cryptographic-blinding}}) 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 {{-epoch-markers}} or stand-alone event logs.
 
 # Terminology {#terminology}
@@ -178,7 +177,7 @@ Examples of such isolated environments include a Trusted Execution Environment (
 
 ## 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 (typically via layered attestation).
+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.
 
 ## Runtime Integrity
@@ -221,7 +220,7 @@ 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 -psa-token}}), 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 implicit authentication using a digital signature over the Attestation Evidence, which does not require additional protocol steps, or by using a secure channel (see {{-uccs}}) that includes 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 {{-uccs}}) that includes authentication.
 
 # Normative Prerequisites
 
@@ -444,7 +443,7 @@ In the second step, the Attester presents the Attestation Result (and possibly a
   generateClaims(attestingEnvironment)   |                       |
      | => {claims, ?eventLogs}           |                       |
      |                                   |                       |
-     |<---------------------------------------------- requestEvidence(
+     |<----------------------------------(----------- requestEvidence(
      |                                   |              handle,
      |                                   |              ?attEnvIDs,
      |                                   |              ?claimSelection)
@@ -456,7 +455,7 @@ In the second step, the Attester presents the Attestation Result (and possibly a
      ?attEnvIDs, collectedClaims)        |                       |
      | => evidence                       |                       |
      |                                   |                       |
-     | {evidence, ?eventLogs} ---------------------------------->|
+     | {evidence, ?eventLogs} -----------)---------------------->|
      |                                   |                       |
 ==========================[Evidence Appraisal]==========================
      |                                   |                       |
@@ -468,7 +467,7 @@ In the second step, the Attester presents the Attestation Result (and possibly a
      |                                   |                       |
 =============[Attestation Result Conveyance and Appraisal]==============
      |                                   |                       |
-     | <------------------------------------ {attestationResult} |
+     | <---------------------------------(-- {attestationResult} |
      |                                   |                       |
      |                                   |                       |
      | {evidence, attestationResult} --->|                       |
@@ -635,6 +634,7 @@ To manage this complexity, it is essential to define a clear policy for handle v
 
 * *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 {{-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.
@@ -973,6 +973,7 @@ This document outlines three interaction models for remote attestation procedure
 While the subsequent sections address additional security and privacy considerations, the security considerations from {{Section 12 of -RATS}} must also be adhered to.
 Additionally, for TPM-based remote attestation, the security considerations outlined in {{Section 5 of -RIV}} should be taken into account.
 
+{: #cryptographic-blinding}
 ## Cryptographic Blinding
 
 In a remote attestation procedure, both the Verifier and the Attester may choose to cryptographically blind certain attributes to enhance privacy.