Subject: [Rats] Yang module comments, plus relation to EAT

From: Laurence Lundblade <[email-masked]>
Date: Fri, 18 Oct 2019 10:55:55 -0700

Here’s a few thoughts / questions / comments on the Yang module, some oriented to make EAT and the Yang attestation procedure less ships in the night.

The yang module describes a conveyance protocol, a means of moving attestations over yang-based transports. It should support EAT format attestations as well as TPM-format attestations. 

It is probably be wrong to call the yang module "ietf-basic-remote-attestation” if all it can do is TPM-based attestation. It needs to be able to carry EATs to have that name.

EAT eventually should have claims that can carry the tpml2-quote fields, particularly the PCRs to start paving a path for transition to the more rich and flexible EAT format. I would expect this to be discussed when we work on the EAT measurement issue <https://github.com/ietf-rats-wg/eat/issues/31>.

Seems like there’s some parallel between YANG compute-nodes and EAT submodules. Need a normative reference to know what a compute-node really is.

Seems like uptime is defined identically in EAT and YANG. There is one thing in common for sure. :-)

The draft seems to allows both IETF and TCG schemes for hash algorithm identification. It uses the RFC6920 IDs for IETF hash identification, not the COSE IDs. However it doesn’t seem to use “ni:” URLS or have normative reference to RFC6920. This seems a bit confused. Can we just use one scheme for hash algorithm identification? Seems like COSE would be the one to choose.

Similarly for signature algorithms, can’t we just use COSE IDs?

It looks like UUID are used as a key id. If it is used as a think it is, then it seems a simple random number would be better. COSE key IDs can basically be like that. The internal details of UUID with the clock and time fields seems arcane complexity from a time when good RNGs weren’t available. Implementations can still make them in UUID format. It is just an implementation detail. No one is going actually parse a UUID to get the clock and time fields out.

Is ima this one? https://sourceforge.net/p/linux-ima/wiki/Home/. I’m not sure how that relates to TPMs and TCG. Maybe it doesn’t. IMA is something we want to take into account in work on the EAT measurement issue <https://github.com/ietf-rats-wg/eat/issues/31>.

The document is lacking normative references, for example to IMA (and TCG documents).

LL