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

https://mailarchive.ietf.org/arch/msg/rats/ktS3-_RDHpN-jITeoqsy0p22oqw

# S 1

* [x] Attestation Policies => Appraisal Policies
  * Renamed.
* [x] It says "The reference models defined can also be applied to the
conveyance of other Conceptual Messages in RATS" without explaining how.
Please remove the sentence: there is already better prose for this in
the last paragraph of this same section.
  * Removed the sentence
* [x] It says: "privacy-preserving conveyance methods" -- what does
"privacy-preserving" refer to?
* Added reference to "Cryptographic Blinding" section in "Security
Considerations" section.

# S 2.2

* [x] Please remove the confusing parenthetical "(typically via layered
attestation)", or place it more appropriately.
  * Removed it.

# S 4

* [x] The term "implicit authentication" referring to digital signatures
sounds a bit odd
  * Removed "implicit".
* [x] It says: "(see [I-D.ietf-rats-uccs])" -- which section?
  * Added "see Sections 3 and 4 of".

# Figure 2

* [x] Unsure why this needed to be changed, but noting that since you
were at it, you could’ve moved the Verifier to the left of the Attester
to avoid crossing the RP, which is visually confusing.
* The thing is, in all the other diagrams, the Attester is on the left
and the Verifier is on the right. We wanted to represent it in the same
way here.
* To make the diagram clearer, represented the crossings as *aasvg*
"wire jumps/hops."

# S 7.2.1

* [x] Unsure how “Synchronization Checks” would work in practice.
  * Added example showing how TUDA implements this.
  * Does this clarify the comment?

# S 11.1

* [x] Why is RFC9683 normative?
  * Good point. Thanks. Made it informative.

Author: eckelmeckel

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.
-The Verifier's assessment in the form of Attestation Results is produced based on Endorsements, Reference Values, Attestation Policies, and Evidence -- trustable and tamper-evident Claims Sets about an Attester's system component characteristics -- generated by an Attester.
+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 that can be used in specific RATS-related solution documents:
 
@@ -148,13 +148,12 @@ This document illustrates three main interaction models that can be used in spec
    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}
@@ -177,7 +176,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
@@ -220,7 +219,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
 
@@ -407,7 +406,7 @@ For example, when performing a boot integrity evaluation, a Verifier may only re
 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 {{security-and-privacy-considerations}}.
+For further reference see Section {{security-and-privacy-considerations}}.
 
 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.
@@ -440,7 +439,7 @@ In the second step, the Attester presents the Attestation Result (and possibly a
   generateClaims(attestingEnvironment)   |                       |
      | => {claims, ?eventLogs}           |                       |
      |                                   |                       |
-     |<---------------------------------------------- requestEvidence(
+     |<----------------------------------(----------- requestEvidence(
      |                                   |              handle,
      |                                   |              ?attEnvIDs,
      |                                   |              ?claimSelection)
@@ -452,7 +451,7 @@ In the second step, the Attester presents the Attestation Result (and possibly a
      ?attEnvIDs, collectedClaims)        |                       |
      | => evidence                       |                       |
      |                                   |                       |
-     | {evidence, ?eventLogs} ---------------------------------->|
+     | {evidence, ?eventLogs} -----------)---------------------->|
      |                                   |                       |
 ==========================[Evidence Appraisal]==========================
      |                                   |                       |
@@ -464,7 +463,7 @@ In the second step, the Attester presents the Attestation Result (and possibly a
      |                                   |                       |
 =============[Attestation Result Conveyance and Appraisal]==============
      |                                   |                       |
-     | <------------------------------------ {attestationResult} |
+     | <---------------------------------(-- {attestationResult} |
      |                                   |                       |
      |                                   |                       |
      | {evidence, attestationResult} --->|                       |
@@ -631,6 +630,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.
@@ -969,6 +969,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.