Subject: [Rats] Comments on draft-birkholz-rats-architecture-02

From: Laurence Lundblade <[email-masked]>
Date: Thu, 3 Oct 2019 13:06:47 -0700

1 Introduction
However, threats to the endpoint [RFC5209] and system components [RFC4949] of transited communication gear (i.e.  hosts) are increasingly relevant for assessing the trustworthiness  properties of a communication channel.

I don’t think RATS is directly relevant to trustworthiness of communication channels. Communication channels should not be mentioned.

The use of “transited” is not very clear here. It sounds like the communication gear is moving through something when I think you mean data moving through communication gear. But more importantly, we’re not trying to allow the relying party to assess the trustworthiness of routers some communication passed through, so this seems wrong.  (We are trying to allow the owner / operator of routers to assess the status of their communication gear, but that is different and doesn’t involve any transiting).

Generally through out document, use of terms “entity”, “host”, “system component”…
Claims and evidence are about a particular subject. EAT uses the term “entity” for that. There is not consistency in this document on that yet. Looks to me like “host”, “entity”, “system component”, “computing environment”, “remove system components”, and “endpoint" are all used to refer to the subject of the attestation at one time or another.

2. Terminology definition of “entity”
This document is using the term “entity” to refer to more than just the subject of the attestation, involving it with “principle” and “role”. I would prefer that “entity” just be the subject of the attestation. That is the way EAT uses it.

No matter how we factor or would word we use, I think we must have a term that solely and clearly names to the subject of the attestation.

To be clear, I believe RATS/EAT is always about trustworthiness of device, HW and/or SW. It is about an implementation of something. It never about trustworthiness of an organization or a person.

4.3.1 on Relying Party
I would say the RP is providing some service or allowing access to some data. They are really the end consumer of all of this. They want it so they know whether to deliver the service or not and if they deliver, how much to deliver. For example, how large a payment to allow if it is allowed at all, or which documents or content the entity is allowed to access if at all.

3.3 and 3.4 Information model Interoperability between RATS
I suggest we do not discuss information model or interoperability in this document. In order to do justice to the topic of interoperability, it would have to go into CBOR/JSON/COSE/JOSE, how crypto algorithms are agreed upon, how keys are distributed and quite a lot more. Profile documents would have to be discussed too.

Remove information model from 4.1 too.

Absent — out of band trust establishment
As we know, somehow the Verifier has to obtain the public keys to verify signatures. That is a critical step to make the system work. Readers need to understand this, so it needs to be in this document.

4.3.2 on Known-Good-Values
They can also typically be HW Versions and SW versions. In the TEE world, these can be reported safely and securely.

It would be better to say they are “integrity protected” rather than “signed”. They might get to the verifier by TLS.

Absent — Discussion on use of Evidence without KGV
A few sentences about the RP evaluating evidence against other than KGV seems needed. For example, evidence may go into a machine-learning based risk engine that learns ro correlate certain evidence values with known fraud. Or, the evidence may be compared to typically user behavior, such as the geographic location of payments.