[Seat] Re: New Version Notification for draft-mihalcea-seat-use-cases-02.txt

[Henk Birkholz <[e-mail]>]

On 10.05.26 17:29, Muhammad Usama Sardar wrote:
> Hi Thomas,
> 
> Thank you for your feedback. I have updated the PR [0] with some 
> additional clarifications. Please check if that works for all of you. If 
> not, please propose edits in the PR.
> 
> On 10.05.26 12:47, Thomas Fossati wrote:
>> If we leave it in the document, it should be presented as one possible
>> defence-in-depth approach, rather than as a requirement.
> 
> I'm concerned that this might open a new discussion, rather than closing 
> the one at hand. I think the line between "defense-in-depth" and 
> "requirement" is a bit fuzzy, depending on quite a lot of factors. For 
> example:
> 
>   * In some cases, the Claims may not change at all. In those cases, TLS
>     nonce might be sufficient.
>   * Some cases might just need one-time attestation.
>   * In almost all cases, the attestation nonce -- in current hardware
>     architectures -- does not go as deep as it should actually go.
> 
> And so on...
> 
> Does all of it mean that we remove Evidence freshness as a requirement 
> and instead make it defense-in-depth?
> 
> Best,
> 
> -Usama
> 
> [0] https://github.com/tls-attestation/use-cases-and-properties/pull/43
> 
> 
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

There is a difference between recentness and freshness that we cannot 
discuss away or into oblivion.

a) recentness and policy can derive freshness (for your application's 
purpose)
b) freshness means that an authentic and time-bound assertion (e.g., 
RATS Evidence) reflects reality as is. That of course is an unobtainable 
golden principle. E.g., the coherence of Evidence generated and the 
Verifier processing the Evidence until an Attestation Result is 
generated might overlay with a change of reality, which would render the 
Attestation Result moot on reception.

There are various ways to deal with that "timing issue".

https://www.ietf.org/archive/id/draft-ietf-rats-ar4si-09.html#name-below-zero-trust 
provides a generic approach to improve the assertion of freshness.

Policy can define certain (overlapping) windows of freshness;"some 
tolerance".

In the end, it are the Relying Parties requirements that impose the ways 
freshness is derived. The relativity of time in space inherently always 
renders this a policy problem in the end.


Viele Grüße,

Henk