[Rats] New RATS Architecture document

[Henk Birkholz <[e-mail]>]

Hi all,

we created a fully revised architecture document that maps and 
represents the state of the current discussion and the material 
presented at the last IETF meeting.

The current Editor's version can be found here:

> https://ietf-rats.github.io/draft-birkholz-rats-architecture/draft-birkholz-rats-architecture.html

We will submit a new version the day after the RATS virtual interim.

TL;DR
Below you can find a list of essential changes & a list of action items 
still to be addressed.


This version of the RATS Architecture document:

* does not define or uses the terms "root(s) of trust" (RoT) or "Trust 
Anchor" (TA) at the moment. (Note: It is a fact that the Asserter Role 
_is_ a TA for the Verifier Role and that an Attester Role _could_ rely 
on RoTs. But - this content will not go into the main body of this 
document),

* does define RATS Roles, Messages, and Principals formerly known as 
"Actors" (borrowing heavily from ABLP),

* provides an even more "base" interaction model diagram for the RATS 
Roles than presented in the last IETF meeting slide deck:

> https://datatracker.ietf.org/meeting/105/materials/slides-105-rats-sessb-rats-architecture-interaction-model-challange-response-yang-module-information-module-00.pdf

* introduces a framework for "level of confidence" in the 
trustworthiness of an Attester and the endorsement of the protection 
characteristics of its "Attesting Computing Context", allowing for other 
entities to use this framework and fill it with, e.g., openly defined 
levels of confidence metrics,

* is not based on the primitive of "trust" but the concept of 
"trustworthiness" as illustrated by the RATS charter,

* simplifies the definitions of Attester and Verifier that seemed to 
have caused some unfortunate confusion following the proposal of Giri 
and starting with commonly-accepted definitions and then justify why 
they may need to be modified,

* differentiates between the Attesting Computing Environment and the 
Attested Computing Environment better, which both are components of an 
Attester,

* uses the "Claim" concept as a building block to compose Evidence, 
Known-Good-Values and Endorsements. Conversely, the "Assertion" concept 
is dropped in this proposal (as initially suggested by Laurence, IIRC?). 
(Note: this was done to simplify the discussion about the information 
model. Please also note: Due to the {J|C}WT definition of "Claim", a 
key/value pair is implied, which is already a data model decision and 
not mandated by an information model), and

* analogously, now uses the term Known-Good-Values instead of 
Attestation Assertions.


For future versions the authors intent:

* to elaborate on the use of RATS Principals, including more exemplary 
diagrams of RATS Role composition and interaction between RATS 
Principals based on the use case document (and by that address a unified 
mapping to TEEP, RIV, and models that use EAT),

* to shift some of the focus on technical-trust as proposed by Thomas. 
(the Endorsements provided by an Asserter are a first step into that 
direction),

* still not to define the roots of trust terms nor invent new words for 
them :) But - start to reference them on a minimal level and define a 
base set of primitives they can provide in order to describe what they 
actually are and can do in the context of RATS as proposed by Ira, Simon 
and Thomas,

* to introduce and define a concise scope for layered attestation, 
addressing, e.g., the staging of Computing Environments and the 
(un-)availability of an Attesting Computing Environment at certain 
points of time, or, another example given, addressing the 
differentiation of an attested boot sequence of an Attester and an 
Attester running TEEs or rich systems for years,

* to address the change of Roles of a Principal over time as proposed by 
Ian,

* to move the remaining architectural sections in the EAT draft into the 
RATS Architecture draft, and

* to shift some of the focus on the out-of-band trust establishment in 
order to illustrate a coherent RATS ecosystem (e.g. the provisioning of 
key material is not include in the "base diagram" anymore for now - this 
will be more elaborated on in future section of the architecture).


Viele Grüße,

Henk