EAT Measured Components as measurement values

[thomas-fossati]

EAT Measured Components (MC) are an extension to the EAT type system that can be used to model "measurable" objects of an attester's target environment, i.e., objects whose state can be sampled and digested.

Examples of such measured components include the invariant part of firmware loaded in memory at startup time, a run-time integrity check (RTIC), a file system object, or a CPU register.

MCs are defined as extensions of the EAT Measurement claim, alongside "payload" CoSWIDs.
Unlike CoSWID, these do not require an anchoring file system, making them more suitable for early boot components.

Arm PSA and CCA software components can be straightforwardly mapped to MCs.
Future attester technologies utilizing EAT will be able to use MCs seamlessly.

MCs reuse some parts of the CoRIM type systems (namely, digest and version) and have CBOR and JSON serialisations.

This issue tracks their addition to the measurement-values map.

[thomas-fossati]

The CBOR-only CDDL is as follows:

measured-component = {
  &(id: 1) => component-id
  &(measurement: 2) => digest
  ? &(signers: 3) => [ + bytes ]
  ? &(flags: 4) => bytes .size 4
}

where

component-id = [
  name: text
  ? version: version
]

The semantics of the fields are described in Section 4.1 of I-D.rats-eat-measured-component.

[deeglaze]

flags is not in your referenced document, so I can't assess what its meaning is.

It grinds my gears a little bit to see version as a 1- or 2-element array when we have version-map as a 1- or 2-entry map with the same value space. Oh well.

[thomas-fossati]

flags is not in your referenced document, so I can't assess what its meaning is.

Wrong link, sorry. Fixed now.

It grinds my gears a little bit to see version as a 1- or 2-element array when we have version-map as a 1- or 2-entry map with the same value space. Oh well.

You are right. I will align MC with CoRIM.

[thomas-fossati]

It grinds my gears a little bit to see version as a 1- or 2-element array when we have version-map as a 1- or 2-entry map with the same value space. Oh well.

You are right. I will align MC with CoRIM.

On second thoughts, I've opened #384 .

[deeglaze]

profile-flags
"a 64-bit field with profile-defined semantics, see Section 4.1.3."

How do you fit 64 bits in 4 bytes? That document says at most 64 bits, not exactly. So why isn't this bytes .size 4 / bytes .size 5 / bytes .size 6 / bytes .size 7 / bytes .size 8?

[thomas-fossati]

profile-flags
"a 64-bit field with profile-defined semantics, see Section 4.1.3."

How do you fit 64 bits in 4 bytes? That document says at most 64 bits, not exactly. So why isn't this bytes .size 4 / bytes .size 5 / bytes .size 6 / bytes .size 7 / bytes .size 8?

Thanks for spotting it. It's fixed in the editors' copy.