Improved Uni-Directional Remote Attestation: freshness mechanisms.

Fixes issue #67.

* [x] **a)** Can the Verifier retrieve the handle and convey it to the
Attester?
  * @gmandyam concern:
* Suggests an alternative path where Verifier fetches handle from
the Handle Generator and relays it to the Attester.
  * @henkbirkholz's reply:
* Possible if handle is authenticatable (e.g., Epoch Marker), but
introduces latency and semantics issues.
    * Recommends against unless lifetime/epoch span is well understood.
* ➡️ Added short note in Section 7.2 (Handle Generation) to explain
why it is discouraged.

* [x] **b)** Handle Expiry and stale handles:
  * @gmandyam's concern:
* Suggests that if Attester knows expiry, it MUST NOT send Evidence
with stale handle.
  * @henkbirkholz's reply:
    * Agrees — this needs normative clarification.
  * ➡️ Strengthened *Handle Expiry* bullet in Section 7.2.1.

* [x] **c)** Is this really unidirectional? Broadcast/multicast variant?
  * @gmandyam's concern:
* Argues that since the Attester talks to both Handle Distributor
(receiving) and Verifier (sending), it is not "uni" but "two-way".
* Suggests covering multicast/broadcast cases where Attester can
only receive from Verifiers.
  * @henkbirkholz's reply:
* Clarifies that two separate one-way channels are used (one for
handle acquisition, one for evidence conveyance).
* Broadcasting handles from Verifiers would defeat the model unless
Verifier also plays Handle Distributor role.
* ➡️ Clarified in Section 7.2 that the "uni-directional" term applies
to each channel independently, not the whole system.
  * ➡️ Explicitly mentioned why multicast from Verifier is not modeled.

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

Author: eckelmeckel

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

@@ -611,11 +611,19 @@ One example of a specific handle representation is {{-epoch-markers}}.
 
 In the Uni-Directional model, handles are composed of cryptographically signed trusted timestamps as shown in {{-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 {{-TSA}}).
+In some deployments, a Verifier may obtain a Handle from the Handle Distributor and forward it to an Attester.
+While feasible if the Handle can be authenticated (e.g., an Epoch Marker with a verifiable timestamp), this indirection introduces additional latency for the Attester and can make freshness semantics harder to appraise.
+Therefore, direct distribution of Handles from the Handle Distributor to Attesters is the recommended approach.
+
 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.
 
+The term "uni-directional" refers to the individual conveyance channels: one from the Handle Distributor to the Attester, and one from the Attester to the Verifier.
+Together, they establish the 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.
+
 ### Handle Lifecycle and Propagation Delays
 
 The lifecycle of a handle is a critical aspect of ensuring the freshness and validity of attestation Evidence.
@@ -627,6 +635,7 @@ To manage this complexity, it is essential to define a clear policy for handle v
 
 * *Handle Expiry*:
   Each handle should have a well-defined expiration time, after which it is considered invalid.
+  An Attester that is aware of the expiration time MUST NOT send Evidence with an expired handle.
   This expiry must account for expected propagation delays and be clearly communicated to all entities in the attestation process.
 
 * *Synchronization Checks*: