Subject: [Rats] Comments on architecture diagrams

From: Laurence Lundblade <[email-masked]>
Date: Fri, 23 Aug 2019 11:38:10 -0700

Here’s a few comments on the architecture diagrams below.

A) Use the term "reference values" or "known-good-values” instead of “Attestation Assertions”. We’ve overused the terms “attestation” and “assertion” in confusing ways.

B) The out-of-band trust establishment is not shown. In the simplest case it is the publication or distribution of a public key. This happens along arc I2. Probably there should be an I2a for trust establishment and an I2b for reference value publication.

C) The signing key is provisioned on arc I1. This needs to be shown.

D) The characteristics of the Attester will vary widely. Some will be super hardened like a secure element. Others will not. There will be some implied claims for the Attester. These are associated with the signing key because the manufacturer of the Attester will only put a particular private signing key into Attester with specific characteristics. So also on arc I1 is the manufacture and construction of the Attester. 

E1) Need to get clear on the terminology “Asserter” and “Claimant”. I’m not very enthusiastic about either because they seem like more overload of terms we already have confusion around. “Supply Chain Entity” is better, but I like “Manufacturer” because it seems simpler and more direct to me.

E2) Possibly the Attester/Claimant/Manufacturer box has to split in to two to show the manufacturer of the attester separate from the supplier of the reference values.

F) Don’t use the term “RoT key” because it implies a RoT is required. EAT uses “attestation key material” or AKM. Could just be “attestation key”. I choose AKM because of ECDAA where the secrets used for signing are more complex than just one key pair.

G) I don’t understand why "only evidence containing verifiable AtAS” is so. For one, the token / evidence might be encrypted over I3 as part of a privacy management or monetization strategy so they can’t selectively pull the token apart. Next, it would break the signing. Next, there’s no reason for it. 

H) In “TEE, eSE or similar”, remove “or similar” so there is no strong implication it has to be such. Probably remove “RoT” too. (Sometimes TEE’s implement TPM’s. Sometimes called soft TPM. In this case I argue that the whole TEE is the RoT because a compromise in the TEE kernel or boot sequence will compromise the soft TPM).

LL