Subject: Re: [Rats] Nine Event Definitions

From: Henk Birkholz <[email-masked]>
Date: Wed, 1 Apr 2020 16:25:51 +0200

Hi Eric,
hi group,

now that the architecture is starting to become stable, we will update 
the current RATS TUDA I-D and pull new terms and concept references in.

This will include a mapping to the "remote attestation event types" that 
are proposed below. As TUDA is all about timestamps that makes a lot of 
sense. There were a few "purple" boxes that represent additional 
candidates to the list below in an older email from Eric. E.g., the 
"handle distribution" time. There is a counterpart to that (quite valid) 
candidate, that is the "loss of centrally time-bound freshness proof" 
due to clock drifts or restarts of "local relative tick counters" (these 
were addressed to some extend by the age Claim, too, I think) that are 
common in less secure environments. So there can be dedicated points in 
time, at which a proof of trustworthy time synchronization looses its 
validity - and a new "centrally time-bound freshness proof" is required 
and MUST be created and distributed, otherwise new streamed evidence 
would be rendered invalid.

There are probably a few other points of time that are of interest from 
the PoV that is TUDA and we will provide updates on that in the 
following days.

As an additional general comment: I find a clear differentiation of 
value generation, claim collection, and evidence creation is missing in 
the set of the very first two timestamp types. A lot of things can 
happen in these two durations and that could also render evidence invalid.

In summary, the TUDA authors find the work on "remote attestation event 
types" relevant and useful as a frame of reference in the RATS 
architecture and support the inclusion into the architecture.

Viele Grüße,

Henk

On 31.03.20 17:13, Eric Voit (evoit) wrote:
> In today's RATS WG call, there was a discussion on RATS timing definitions
> across use cases.  Below are nine Event definitions which span multiple RATS
> use cases.  Each of these nine Event definitions currently appear in a pull
> request to the Architecture document.   (For those of you following the
> alias, you will have seen early versions of these definitions.)    It is
> hoped that by including a common set of event type definitions in the
> Architecture document, we will have a language which can help us more
> formally frame similar characteristics between the use cases.  And then we
> can build call flow / timing diagrams which hopefully expose these
> similarities.
> 
> There are two asks from this email:
> (1) Do you want to propose one or more *additional* event types which you
> believe are common enough to be placed into the architecture document?
> (Note: that *not* having an Event type in the architecture document does not
> preclude you developing your own Event types.  It just makes it harder for
> others to adopt your event definitions within their documents.)
> 
> (2) Are there any issues with the names and definitions described below?
> 
> 
> ------------------------------
> Nine Event Definitions
> ------------------------------
> 
> vg - Value Generation
> A value to appear in a claim was created
> 
> ns - Nonce Sent
> A random number is generated and sent
> 
> nr - Nonce Relayed
> A random number is passed through another entity
> 
> eg - Evidence Generation
> An Attester collects claims and generates Evidence
> 
> er - Evidence Relayed
> A Relying Party relays Evidence to a Verifier
> 
> rg - Result Generation
> A Verifier appraises Evidence and generates an Attestation Result
> 
> ra - Result Appraised
> The Relying Party appraises Attestation Results
> 
> op - Operation Performed
> The Relying Party performs some operation in part driven by the current
> trustworthiness of the Attester
> 
> rx - Result eXpiry
> An Attestation Result should no longer be accepted, according to the
> Verifier that generated them.
> 
> 
> 
> Thanks!
> Eric
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 1 Apr 2020 11:50:53 -0700

> On Mar 31, 2020, at 8:13 AM, Eric Voit (evoit) <evoit=[email-masked]> wrote:
> 
> …

Nonces don’t have to be random numbers, so suggest the changes below. 

The nonce was generated and sent.

> A random number is passed through another entity
The nonce was relayed.

LL