Need indication whether a piece of evidence is class, instance or dynamic

[andrew-draper]

Some attestation evidence collectors take DICE and SPDM measurements and put them into other formats, for example all class measurements might be used to extend a PCR.

Definitions:

• Class measurement = two devices configured with the same firmware, fuse values etc will have the same value for the measurement
• Instance measurement = two devices configured with the same firmware etc might have different values for the measurement, but the value does not change over time (if not reconfigured)
• Dynamic measurement = a single device may report different values for the measurement over time An example use for a dynamic measurement is a counter indicating how many times the device has been rebooted

Mixing different types of measurement in the same PCR causes problems. A class PCR provides information that the device is in a particular state while an instance PCR provides proof that the device is the same as last time.

Do we need a way for the evidence collector to determine the locality of a measurement without having to understand the difference between types of measurement?

Currently some instance measurement can be identified because their environment-map includes an instance field, but there are instance measurements which do not include instance in environment-map.

One way to fix this would be to add a field to environment-map, perhaps something like: ? &(scope: 3) => &(class-scope: 0) / &(instance-scope: 1) / &(dynamic-scope: 2)

This is primarily for use in evidence, but CoRIM reference values will need to match what the device reports

[nedmsmith]

Given a use case where the Endorser knows about measurements with dynamic scope, the measurement values that are produced in evidence are not known at the time the reference values or endorsed values are authored. However, it is reasonable that the Endorser would know about the capability of the device to produce dynamic measurements.

If the Endorser wished to represent this knowledge using CoRIM they would need to populate the dynamic-scope environment-map which instructs the Verifier to match dynamic scoped Evidence. But the reference values would be null. This suggests the measurement-values-map could be empty. Currently, it is marked as . It would seem to be appropriate to mandate an empty measurement-values-map for Reference Values while expecting non-empty for Evidence.

[andrew-draper]

I was expecting the information about measurement scope to be in evidence/endorsements rather than in reference values. We need to decide whether to special case scope when documenting the environment-map matching rules. My preference would be not to special case it, so the endorser would need to know the scope before building reference values. Would it be better to put scope into evidence-map?

[nedmsmith]

Would it be better to put scope into evidence-map

There isn't an evidence-map, do you mean measurement-map or measurement-values-map? there are three possible approaches: a) remove non-empty<{...}> from measurement-values-map. This will allow RIMs to supply reference values with null reference-values-map. Evidence could contain any defined measurement (but not any). b) define nil RHS variants for each measurement-values-map LHS-RHS statements; where LHS is the code point and RHS is the measurement value. c) option (a) + define any as a possible measurement-values-map statement. Option (a) means the Endorser/RVP asserts the Attester has the ability to produce dynamic values but doesn't specify which values are dynamic. Option (b) means dynamic values must be defined in the schema, but when the reference contains the nil representation, the verifier accepts whatever value is supplied in the non-nil representation in Evidence. Option (c) means the reference can contain expressions for dynamic data with nil values and evidence can contain dynamic data with non-nil values, but the schema is outside the scope of corim. A profile might define the schema.

My preference is (b) because it maintains schema integrity, but doesn't presume all measurements are non-dynamic, but any could be dynamic.

[yogeshbdeshpande]

As per my understanding, this issue has been addressed. @andrew-draper Please check and close this!