Re: [Rats] Use case -> architecture document

[Henk Birkholz <[e-mail]>]

Hi Kathleen,
hi list,

there was an interesting follow-up on discussion how RFC4949 data origin 
authentication ("The corroboration that the source of data received is 
as claimed."), attestation provenance & device identity are strongly 
intertwined, but mean different things in the context of RATS (well, 
actually the example this was discussed on was a subset of RATS: the RIV 
use-case).

Another good example coming out of that discussion were the subtle 
difference between the RFC4949 term "fresh" ("Recently generated; not 
replayed from some earlier interaction of the protocol") evidence and 
the "freshness of evidence" (in contrast to "recentness of claim _and_ 
evidence creation"), which also mean quite different things.

Last example I want to provide as food of though from that discussion is 
"proof of possession" vs "proof of availability at a specific point in 
time" This differentiation is a quite important for DICE-based remote 
attestation procedures, where the persistence of an alias key and 
corresponding certificates for attestation can be significantly shorter 
than, e.g. an associated DevID [1]. The point being, the semantics 
around the terms are vital, but unfortunate also easily conflated, if 
not worded with precision in a bigger context.

The conclusion was to be very carefully about not conflating different 
things for the sake of simplicity, I think.

Viele Grüße,

Henk

[1] 
https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf

On 16.10.19 16:35, Kathleen Moriarty wrote:
> origin authentication