Integrated @gmandyam's comments/review.

* [x] **a)** Sec. 7.3.2.2.: Is there a requirement for the handle to be
Verifier-specific with a vednor-defined freshness policy? If so, how do
both the Attester and Verifier ensure that the PubSub Server is
enforcing per-Verifier compliance with the Verifier freshness policy
(e.g. PubSub server communicates handle as part of an attestation
claim)?
* *Henk's reply:* No, but there can be specifications that come with
that prescription.
  * ➡️ Added clarifying sentence at the end of Section 7.3.2.2.

* [x] **b)** Sec. 7.3.2.3: If the Attestation Result can only be
communicated via publication to the PubSub server, then why does the
figure not show the Attestation Result terminating there?
* *Henk’s Response (rephrased, simplified):* Good point — the diagram
already reflects the correct model (the result is published to the
PubSub server), but the *text may be misleading*.
* ➡️ Added clarification by improving/extending the last sentence of
Section 7.3.2.3.

* [x] **c)** Sec. 7.3.2.4: Call flow in figure seems to be overly
limiting. Attester can also subscribe to attestationResult.
* *Henk’s reply (rephrased, simplified):* Agree, but we want to keep
the diagram simple. Maybe this can be described as a “re-application” of
the interaction model.
  * ➡️ Added clarifying sentence at the end of Section 7.3.2.4.

* [x] **d)** Section 9: Need a discussion on security/privacy
considerations for PubSub server. This is different that what is
described in Section 9.3. For instance, if the PubSub server must attest
to the Handle used as part of evidence then this could be discussed in
Section 9. Moreover, "Strong Isolation of Topics" does not directly
address privacy preservation (i.e. limiting dissemination of identifying
information to subscribers that don't require it).
Moreover for "Trusted Association Verification" it is not clear how
this can be achieved in the PubSub server. For instance, are
endorsements specific to the "the trust association between senders and
receivers" required?

  * [x] **d.1)** What does “attest to the Handle” mean?
* Clarification: This seems to ask whether the PubSub server must
vouch for the Handle (e.g., by proving it delivered it, or binding it
cryptographically).
    * ➡️ Added clarifying sentence at the end of Section 9.3.

* [x] **d.2)** Strong Isolation of Topics" does not address privacy
preservation
    * This is a good point: topic isolation != privacy preservation.
* ➡️ Added clarifying sentence for *Strong Isolation of Topics*
bullet point of Section 9.3.

  * [x] **d.3)** "Trusted Association Verification" lacks details
* "Are endorsements required? How are trust relationships
established?": This is currently vague.
* ➡️ Added clarifying sentence for *Trusted Association
Verification* bullet point of Section 9.3.

Signed-off-by: Michael Eckel <michael.eckel@sit.fraunhofer.de>

Author: eckelmeckel

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

@@ -792,6 +792,9 @@ In the sequence diagram above, the Verifier initiates an attestation by generati
 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.
 
+While this model allows for Verifier-specific Handles and custom freshness policies, such policies must be defined and enforced outside the scope of this specification.
+For instance, a Verifier may choose to include a Handle reference in its appraisal policy or request specific handling by the PubSub server through implementation-specific mechanisms.
+
 #### Handle Generation for Uni-Directional Remote Attestation over Publish-Subscribe
 
 ~~~~ aasvg
@@ -876,8 +879,10 @@ When the Handle Distributor generates and publishes a Handle to the "Handle" top
 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 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.
-Verifiers appraise the Evidence and publish the Attestation Result to topic "AttRes" (= Attestation Result) on the PubSub server.
+Although the above diagram depicts only full attestation Evidence and Event Logs, later attestations may use "deltas" for Evidence and Event Logs.
+
+Verifiers appraise the Evidence and publish the Attestation Result to the `AttRes` topic (= Attestation Result) on the PubSub server, which then serves as the dissemination point from which subscribers, such as Relying Parties or other authorized roles, retrieve the result.
+
 
 #### Attestation Result Generation
 
@@ -912,6 +917,9 @@ Attestation Result Generation is the same for both publish-subscribe models,*Cha
 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`.
 
+In some deployments, Attesters may also subscribe to the `AttRes` topic to consume Attestation Results.
+This reuses the same publish-subscribe mechanism described here and may support local policy decisions or caching.
+
 # Implementation Status
 
 Note to RFC Editor: Please remove this section as well as references to {{BCP205}} before AUTH48.
@@ -1029,10 +1037,16 @@ To mitigate these risks, it is essential to implement robust security measures:
   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.
 
+  In addition to isolating topics, privacy can be preserved by minimizing the inclusion of personally identifying information or unique Attester identifiers in messages published to shared topics, unless strictly required by the subscriber’s role or appraisal policy.
+
 * *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.
 
+  Implementations may use Verifier Endorsements or pre-established authorization policies to define valid sender-receiver associations.
+  These policies can be cryptographically enforced using signed metadata, access control lists, or secured registration procedures on the PubSub server.
+  The precise method is deployment-specific.
+
 * *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.
@@ -1044,6 +1058,9 @@ To mitigate these risks, it is essential to implement robust security measures:
 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.
 
+This specification does not require the PubSub server to attest to the Handle or cryptographically prove its dissemination.
+If such assurances are needed (e.g., for auditability or binding Handle provenance), additional mechanisms---such as signed delivery receipts or logs---must be provided by the PubSub infrastructure.
+
 ## 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.