[Rats] Comments on draft-birkholz-rats-architecture-01

[Thomas Hardjono <[e-mail]>]

Here are some comments on draft-birkholz-rats-architecture-01.

There are several typos in the text,  but I will focus on some of the more fundamental questions.


(a) Abstract:

>>> the goal of the RATS Architecture is
>>> to enable interoperable interaction between the RATS Roles. Hence,
>>> the RATS Architecture is designed to enable interoperability via
>>> well-defined semantics of the information model (attestation
>>> assertions/claims),...

Is it true/correct that RATS will address the semantics of the information model (and not just the syntax).

The issue of trust semantics goes very deep into the architecture of the hardware and platform, so much so that  I don't think (correct me) it is practical to compare between two hardware manufacturer platforms (e.g. Intel based PC versus Qualcomm-based iPhones) .  The best that can be achieved (correct me) is that there is a paired-matching between the Computing-Context measured/reported by the device (Attester) and the Computing-Context information (manifest) issued by the Asserter (platform or device manufacturer) and accessible to the Verifier.  The Verifier must somehow know (detect) the differences in Computing-Contexts between two distinct platforms/devices. 

Or did I misunderstand the usage of the term "semantics" in this document.


(b) Page 4

>>> One of the goals of the RATS Architecture is to provide the building
>>> blocks - the roles defined by the RATS Architecture - to enable the
>>> composition of service-chains/hierarchies and work-flows that can
>>> create and appraise evidence about the trustworthiness of devices and
>>> services.

The notion of "service-chains" or assertion-chains needs to be defined clearly (maybe in the next draft).  In fact, service-chains is a topic that is barely discussed in this draft-01.


(c) Page 5 top:

>>> Mandatory and optional trust relationships between its Roles, that
>>> may assume a Root-of-Trust context,

This one is confusing I think, because perhaps of the word "optional".

One of the outcome of a successful RATs interoperability scenario is to enable the establishment of trust (based on the observance of RATS-defined remote attention procedures) between the Asserter and Verifier.


(d) Page 5 Section 3.1 on RATS Role.

>> Claimant:

I'm assuming we going with the word "Asserter" instead of Claimant.


(e) Page 6 second paragraph:

>>> ... supply chain entities (SCE)...

Supply chain entities need to be defined.  Does this mean supply chain of components that make-up a platform (e.g. OEMs), or does it mean something else.



(f) Page 6 third pa paragraph a:

>>> Attester: The producer of attestation evidence that has a root of trust for reporting (RTR)

Why only the RTR?  I would have thought that the Attester (e.g. my device) must also have an RTM.


(g) Page 7, last paragraph:

>>> In general, and RATS Duties are typically associated with a
>>> RATS Role. The list presented in this document is exhaustive.

Did you mean "exhaustive" or "non-exhaustive"


(h) Page 8, Section 4.1.2:

>>> Acquisition and storage of appraisal policies

The term "appraisal policies" needs to be defined.  Dos it mean "processing rules" ? (akin to the X509 cert policies which define the ways to process received certs).


>>> Verification of Attester Identity (attestation provenance)

Is this a typo?  An "Attester Identity" is not the same as the provenance of attestations.


(i) Page 12 first paragraph:

>>> In essence, the
>>> attestation provenance of attestation evidence is the system that
>>> intends to present its trustworthiness in a believable manner.

This sentence sounds circular, but I think I get the intent.

Should it read something like:  The provenance of the attestation-evidence of a given system originates from the system itself, and pertains to the trustworthiness of the system.  It must be presented in a believable manner by the system to external entities, namely the Verifiers and Relying Parties.


(j) Page 12 fourth paragraph:

>>> If the root of trust involved is a root of trust for measurement
>>> (RTM), the producer of information takes on the role of a asserter.


Is this a typo?  Should this instead read ".. the role of an *Attester" (because an Attester, not the Asserter, has the RTM and possibly RTR).


(k) Page 15 Section 7.1

The Lying Endpoint Problem text should be placed in the Use Cases document, not in the Architecture doc.

The entire reason we have RATS (and indeed the whole notion of Remote Attestations) is largely due to the The Lying Endpoint Problem.


(l)  Page 21 section 8.1:

This paragraph is a good explanation of remote attestations because it talks about "telemetry", which seems core to network devices.

Perhaps this paragraph could be moved up front towards the start of the document.


(m) Page 22 Section 8.4:

>>> Claim: Structured Evidence asserted about a Computing Context. It
>>> contains metadata that informs regarding the type, class,
>>> representation and semantics of Evidence information. A Claim is
>>> represented as a name-value pair consisting of a Claim Name and a
>>> Claim Value

Firstly, I would avoid the use of the term "Claim" because it is already used in higher layer protocols and other organizations. The term "Assertion" is good enough for RATS.

Secondly, is the goal/deliverable for RATS to define these name-value pairs? (for both RTMs and RTRs).

The TCG uses the term "manifest" to indicate the list of expected compliments and measurements in the platform, produced by the Asserter (e.g. device manufacturer).


(n) Page 23 second-last paragraph:

>>> Activity: A sequence of actions conducted by Computing Contexts
>>> that compose a Remote Attestation procedure.

Should RATS care about the "activity" or actions of s given device or platform (that concludes in the generation of an attestation).  Isn't activities/actions internal to the device and the device-manufacturer.


(o) Other comments:

The diagrams from the RATS architecture presentation at IETF104 are excellent ("Evolution of RATS Architecture" and "RATS WG Scoping").  It would be good to have them represented somehow in ASCII.





-- thomas --