environments and elements

[nedmsmith]

Triples resulted in morphing 'element-name' into 'environment-map'. Conceptually, environment maps to RATS terminology - target/attesting environments. An environment could consist of multiple measurements derived from different "things" within the environment. For example, a target env could have some firmware, initialization vectors, and maybe fuses. If all of these are digested (as opposed to using raw-value) then the current schema handles this is there should be different 'environments' defined for each (firmware, IV, fuse). That implies a different class-id for each.

Conceptually, 'environment' suggests a higher level of granularity than 'element'.

In DICE Evidence can be bundled into a sequence of TcbInfos and included in certificate extension. The layer certificate is at a higher level of granularity because it contains multiple tcbinfo structures. It seems semantically similar to 'environment'.

The disconnect is the sequence of TcbInfos doesn't have a class identifier unless the certificate attributes subjectName / subjAltName are overloaded as such. However, DICE doesn't require this and doesn't define a mapping to a class-map / class-id for certificate names.

This suggests that even though tcbinfos are grouped by environment, the matching algorithm ignores that and expects to treat each tcbinfo individually. Which aligns with the current semantics for 'environment'.

However, there will be dissonance when discussing this with others because environments can consist of multiple elements.

When we had 'modules' and linked tags, the 'module' satisfied the higher level granularity 'environment' context.

[thomas-fossati]

The way I see this is that with multiple measurements within the same "environment", one has to have a way to identify each measured "thing" (maybe "element"?). So, if needed, each measurement should come with its own identifier, orthogonal to the class/instance identifier. For example, in the PSA profile, which has multiple FW components separately measured within a single environment (i.e., the PSA RoT), we are going to define our $$measurement-map-extension to carry each separately identifiable FW component, e.g.:

$$measurement-map-extension //= (
  comid.psa-software-component => [ + psa-software-component ]
)

psa-software-component = {
  ? psa.measurement-type => text
  ? psa.version => text
    psa.signer-id => psa-hash-type
    psa.digest => [ hash-alg, hash-val ]
}

[thomas-fossati]

one-or-many<( ? element-name , element-value )>