multi-valued measurements

[thomas-fossati]

see https://github.com/ietf-rats-wg/draft-ietf-rats-corim/wiki/Multiple--vs-Single-measurements-Environments

[nedmsmith]

Note that the CDDL in [1] is not an acccurate depiction of DiceTcbInfoSeq as the DiceTcbInfo contains both the 'name fields' (aka environment-map) and the 'values fields' (aka measurement-values-map). The CDDL in [2] more accurately depicts DiceTcbInfoSeq.

The CDDL in [1] is similar to an as yet unpublished variation of DiceTcbInfoSeq that compresses common fields where the name fields are common. But this variation instructs the Verifier to uncompress them resulting in a DiceTcbInfoSeq.

[1] ; ENV --1:m--> MEAS
[ environment-map, [ + measurement-map ] ]

[2]
[ + (environment-map, measurement-map) ]

[nedmsmith]

Note also that (ENV --1:m--> MEAS) can be achieved by [ environment-map, measurement-map ] if measurement-values-map contains multiple measurements that have different code points. The only case where (ENV --1:1--> MEAS) is true is when a singleton code point is used in measurement-values-map.

The interesting case for (ENV --1:m--> MEAS) and [1] above is when there are multiple instances of measurements that have the same code point. In such a scenario, the only way to disambiguate 'm1' from 'm2' is by array position. However, this seems dubious as tooling might swap entries and more importantly, array position doesn't add semantic context for which component in the system was the original source of the measurement. Using environment-map.class-map.index easily disambiguates them, which is an expression of [2] above.

[thomas-fossati]

Note that the CDDL in [1] is not an acccurate depiction of DiceTcbInfoSeq as the DiceTcbInfo contains both the 'name fields' (aka environment-map) and the 'values fields' (aka measurement-values-map). The CDDL in [2] more accurately depicts DiceTcbInfoSeq.

Thanks for the clarification, wiki page updated.

[thomas-fossati]

The interesting case for (ENV --1:m--> MEAS) and [1] above is when there are multiple instances of measurements that have the same code point.

yes, that's the case that we want to support natively.

In such a scenario, the only way to disambiguate 'm1' from 'm2' is by array position. However, this seems dubious as tooling might swap entries and more importantly, array position doesn't add semantic context for which component in the system was the original source of the measurement.

yes, let's not do that.

Using environment-map.class-map.index easily disambiguates them, which is an expression of [2] above.

Interesting idea, I hadn't thought about using class's index.
It looks ok semantically, though less compact.

[nedmsmith]

[ environment-map, measurement-map ] should also be listed as a form of ENV --1:m--> MEAS

[thomas-fossati]

[ environment-map, measurement-map ] should also be listed as a form of ENV --1:m--> MEAS

you mean in case the measurement values are different, right?

(I reckon a more precise headline for my musing is "multi-valued same-type measurements".)

[nedmsmith]

It looks ok semantically, though less compact.

If we are expecting to rely on CBOR compaction [3], then CDDL that aims to only optimize for size can result in semantic expressiveness gaps.

[3] https://datatracker.ietf.org/doc/html/draft-ietf-cbor-packed

[nedmsmith]

(I reckon a more precise headline for my musing is "multi-valued same-type measurements".)

Yes, if 'same-type' means same code point.

[thomas-fossati]

ok, so I'm reading the description of index in the editor's copy:

• index (index 4): Is used when there are clones (i.e., multiple instances) of the same class of environment. Each clone is given a different index value to disambiguate it from the other clones. For example, given a chassis with several network interface controllers (NIC), each NIC can be given a different index value.

and I am a bit concerned that the idea of "clone" doesn't really fit the use case I'm trying to model. Those multiple measurements associated with the PSA "mutable" RoT (PRoT) are not "clones" of the PRoT, they are measurements of PRoT sub-components. It's partitioning rather than cloning.

[nedmsmith]

the idea of "clone" doesn't really fit

This was the use case justification that we were aware of at the time. If there is additional justification then it seems OK to add that also. The question is what will a Verifier do with the information? We've defined class-map matching to mean every field in class-map that appears in Reference Values needs to have corresponding fields in Evidence. Otherwise, the Attester fails appraisal.

However, if they match, then each field in class-map is also a Claim that goes into the set of accepted claims. A match that uses only class-id in the environment and (hypothetically) has an index claim in Evidence or Endorsements, results in the same accepted claims set as one that includes index in the environment.

The verifier may not care if index describes a clone or something else unless there is an appraisal policy that affixes the use case semantics of 'clone' or 'PRoT sub-component'. There is a lot of flexibility in class-map to name things (which is why DiceTcbInfo specs refer to them as 'name' fields). For example, an OID arc (47) for 'PRoT' could use sub-arcs (47.1, 47.2,..._ to refer to the sub-components. The Verifier can just as easily perform matching. However, the appraisal policy that has use case specific semantics would need to know that sub-arcs (and not index) refers to sub-components and not clones.

CoMID expects the module designer will make these decisions as part of tag creation.

[thomas-fossati]

We've defined class-map matching to mean every field in class-map that appears in Reference Values needs to have corresponding fields in Evidence. Otherwise, the Attester fails appraisal.

Hmm, right. If index has global meaning and it's not just a placeholder to allow local disambiguation then it won't work.

[nedmsmith]

then it won't work

Can you say more about what doesn't work?

[thomas-fossati]

The PSA software components claim is an unordered set of measurements:

psa-software-components = (
    psa-software-components-key => [ + psa-software-component ]
)

There is no defined order that could be associated with an index in a consistent way.

Therefore, if index has to have a meaningful mapping with evidence and it's not just a trick to disambiguate then it does not fit.

Basically, the primitive I need for matching is an "equality among unordered sets".

[nedmsmith]

Basically, the primitive I need for matching is an "equality among unordered sets".

This seems to have similar semantics as coswid-triple-record. Aside from psa-software-component possibly being different than a concise-swid-tag-id and having a corresponding coswid tag in the RIM (i.e., &(tags: 1) => [ + $concise-tag-type-choice ]), there seems to be equity among the unordered set of concise-swid-tag-id.

coswid-triple-record = [
  environment-map
  [ + concise-swid-tag-id ]
]

Are the matching semantics that all instances of psa-software-component must be present in Evidence or appraisal fails? I believe those are the semantics for concise-swid-tag-id.

[thomas-fossati]

Are the matching semantics that all instances of psa-software-component must be present in Evidence or appraisal fails?

yes.

[nedmsmith]

Is this issue resolved? Maybe as "do not fix"?

[yogeshbdeshpande]

@nedmsmith @thomas-fossati I want to resurrect the discussion on
(ENV --1:m--> MEAS)

There are other use cases apart from PSA, where we have a set of Measurements (Digests to be precise). The set belongs to an Environment.

Currently we do not have an adequate and elegant way to express this using CoRIM Reference Value Triple!

We do not want Supply chain to use m triples with the same Environment (in the subject) and then put each MEAS of (m) in the object. This is not elegant.
In our use case, all the Measurements for the Environment appears in the Evidence, hence we need matching all.

As far as concern about Evidence Matching Policy, we can make a careful assessment of the situation as:
If None of the Measurements (for the Environment) matches : Then Verifier fails the appraisal.
if a partial match happens (the result can be a complete failure ) OR a Partial Failure based on the Verifier Appraisal Policy .

A Verifier matches all the Measurements belonging to the Environment with the set of Reference Values.

[nedmsmith]

I was looking for text (both in I-D.corim and TCG Endorsement arch) that clarifies whether an array of reference triples mean OR or AND matching logic. That is to say, given an array of reference triples in the same tag / same triples-map statement. Do all of the EMT statements have to match (aka AND logic) or is it OR logic where if any triples in the array match, then the evidence matches? The examples seem to suggest OR logic, but the prose sections don't seem very clear to me. E.g.: given a reference-triple array as follows:

[
   (env=ENV1, meas=MEAS1),
   (env=ENV2, meas=MEAS2),
   (env=ENV3, meas=MEAS3)
]

and given Evidence as:

(env=ENV2, meas=MEAS2),

Is there a match on (ENV2, MEAS2) because (ENV2, MEAS2) appears in the list of RV triples or is it not a match because all of the RV triples are not matched?
The examples suggest the former. Hence, there doesn't appear to be a way to represent AND matching logic with the current schema except for Example 3 below.

AND logic therefore uses inner arrays. There are several examples that follow.
Example 1:

[
   [ (env=ENV1, meas=MEAS1) ],
   [ (env=ENV2, meas=MEAS2) ],
   [ (env=ENV3, meas=MEAS3) ]
]

If evidence matching algorithms allow for: ~[ (env=ENV2, meas=MEAS2) ] matching. Then evidence can omit the inner array brackets: (ENV2, MEAS2).

If the reference values expression was:

[
   [ (env=ENV1, meas=MEAS1) ],
   [ (env=ENV2, meas=MEAS2), (env=ENV4, meas=MEAS4) ],
   [ (env=ENV3, meas=MEAS3) ]
]

AND matching logic implies: [ (env=ENV2, meas=MEAS2), (env=ENV4, meas=MEAS4) ] would not match given evidence only included (env=ENV2, meas=MEAS2) and not (env=ENV4, meas=MEAS4).

Yogesh may be suggesting AND logic where only the measurement component of an EMT has multiplicity.
Example 2:

[
   (env=ENV1, [ meas=MEAS1] ),
   (env=ENV2, [ meas=MEAS2, meas=MEAS4] ),
   (env=ENV3, [ meas=MEAS3] )
]

The current schema supports measurement multiplicity by defining code points that have values expressed as arrays.
Example 3:

[
   (env=ENV1, meas=MEAS1 ),
   (env=ENV2, meas-x=[MEAS2, MEAS4] ),
   (env=ENV3, meas=MEAS3)
]

[nedmsmith]

There are other use cases apart from PSA

Note the TCG Endorsement arch spec suggests there are use cases for multi-valued measurement sets for a given environment and it implies AND matching logic:
"measurement-map : Contains one or more reference measurements.  Attester Evidence MUST match all measurements in measurement-map."

If we allow an arbitrary set of measurement values with the same key (Example 2 above), I think that presents ambiguity as it isn't clear if value2 appearing at array position 0 is different from value2 appearing at array position 1.

[thomas-fossati]

@nedmsmith @thomas-fossati I want to resurrect the discussion on (ENV --1:m--> MEAS)

There are other use cases apart from PSA, where we have a set of Measurements (Digests to be precise). The set belongs to an Environment.

Currently we do not have an adequate and elegant way to express this using CoRIM Reference Value Triple!

We do not want Supply chain to use m triples with the same Environment (in the subject) and then put each MEAS of (m) in the object. This is not elegant. In our use case, all the Measurements for the Environment appears in the Evidence, hence we need matching all.

If matching multiple different digests in one go is the goal, defining a multi-digest measurement is an "elegant" (and more compact) solution. We made the measurement map extensible to allow use cases that do not fit the DICE model.

[nedmsmith]

I think this issue is tied to the environment scoping issue #176 because scope may determine whether a collection of measurements is grouped by EMT structure or by the scope of the chosen EMT name.

[nedmsmith]

If matching multiple different digests in one go is the goal, defining a multi-digest measurement is an "elegant" (and more compact) solution. We made the measurement map extensible to allow use cases that do not fit the DICE model.

This is Example 3 above.

[yogeshbdeshpande]

I think, we are over-complicating the discussion here:

For Example 1: (stated by Ned above)
The Device composition is clearly identified by a set of Environments => If the reported Evidence is ONLY expected to report Env2: (with an expected set of Measurements, which in this example is (env=ENV2, meas=MEAS2, the MEAS2 should be matched to complete the Appraisal.

Example 2: Ned got the use case right, the ENV has Multiple Measurements:
We can make the condition tight for now, if the Environment(ENV) in Evidence matches the one in the Reference Values (inside Verifier), then ALL the measurements reported in the Evidence for the ENV MUST match the corresponding one found in Reference Values (inside Verifier), else Verifier Fails appraisal.

@nedmsmith To your point: If we allow an arbitrary set of measurement values with the same key (Example 2 above), I think that presents ambiguity as it isn't clear if value2 appearing at array position 0 is different from value2 appearing at array position 1.

We have sufficient semantics in the schema today to define what each Measurement at a specific position (say 0 or 1) implies, that should be clarified by the Supply Chain, when provisioning reference values. The Verifier will match the corresponding one received in the Evidence.

Example 3:
To your point:
The current schema supports measurement multiplicity by defining code points that have values expressed as arrays.

My view point:
a. I propose we handle the use case natively in the core spec rather than relying on the extension points.

b. The extension point does not exist at the correct place to express the multiplicity I am referring to

[yogeshbdeshpande]

@nedmsmith @thomas-fossati I want to resurrect the discussion on (ENV --1:m--> MEAS)
There are other use cases apart from PSA, where we have a set of Measurements (Digests to be precise). The set belongs to an Environment.
Currently we do not have an adequate and elegant way to express this using CoRIM Reference Value Triple!
We do not want Supply chain to use m triples with the same Environment (in the subject) and then put each MEAS of (m) in the object. This is not elegant. In our use case, all the Measurements for the Environment appears in the Evidence, hence we need matching all.

If matching multiple different digests in one go is the goal, defining a multi-digest measurement is an "elegant" (and more compact) solution. We made the measurement map extensible to allow use cases that do not fit the DICE model.

@thomas-fossati : measurement-map is NOT extensible, however, measurement-values-map is extensible.
I would avoid extending just the measurement-values-map to fit the use case, I have in mind.

[thomas-fossati]

@nedmsmith @thomas-fossati I want to resurrect the discussion on (ENV --1:m--> MEAS)
There are other use cases apart from PSA, where we have a set of Measurements (Digests to be precise). The set belongs to an Environment.
Currently we do not have an adequate and elegant way to express this using CoRIM Reference Value Triple!
We do not want Supply chain to use m triples with the same Environment (in the subject) and then put each MEAS of (m) in the object. This is not elegant. In our use case, all the Measurements for the Environment appears in the Evidence, hence we need matching all.

If matching multiple different digests in one go is the goal, defining a multi-digest measurement is an "elegant" (and more compact) solution. We made the measurement map extensible to allow use cases that do not fit the DICE model.

@thomas-fossati : measurement-map is NOT extensible, however, measurement-values-map is extensible.

That's what I meant.

I would avoid extending just the measurement-values-map to fit the use case, I have in mind.

why not, extensibility is a feature not a bug ;-)

[yogeshbdeshpande]

@nedmsmith @thomas-fossati I want to resurrect the discussion on (ENV --1:m--> MEAS)
There are other use cases apart from PSA, where we have a set of Measurements (Digests to be precise). The set belongs to an Environment.
Currently we do not have an adequate and elegant way to express this using CoRIM Reference Value Triple!
We do not want Supply chain to use m triples with the same Environment (in the subject) and then put each MEAS of (m) in the object. This is not elegant. In our use case, all the Measurements for the Environment appears in the Evidence, hence we need matching all.

If matching multiple different digests in one go is the goal, defining a multi-digest measurement is an "elegant" (and more compact) solution. We made the measurement map extensible to allow use cases that do not fit the DICE model.

@thomas-fossati : measurement-map is NOT extensible, however, measurement-values-map is extensible.

That's what I meant.

I would avoid extending just the measurement-values-map to fit the use case, I have in mind.

why not, extensibility is a feature not a bug ;-)

I meant the use case requirement is that we extend the measurement-map instead of just measurement-values-map.

Hence the proposal!

[yogeshbdeshpande]

@nedmsmith @thomas-fossati I want to resurrect the discussion on (ENV --1:m--> MEAS)
There are other use cases apart from PSA, where we have a set of Measurements (Digests to be precise). The set belongs to an Environment.
Currently we do not have an adequate and elegant way to express this using CoRIM Reference Value Triple!
We do not want Supply chain to use m triples with the same Environment (in the subject) and then put each MEAS of (m) in the object. This is not elegant. In our use case, all the Measurements for the Environment appears in the Evidence, hence we need matching all.

If matching multiple different digests in one go is the goal, defining a multi-digest measurement is an "elegant" (and more compact) solution. We made the measurement map extensible to allow use cases that do not fit the DICE model.

@thomas-fossati : measurement-map is NOT extensible, however, measurement-values-map is extensible.

That's what I meant.

I would avoid extending just the measurement-values-map to fit the use case, I have in mind.

why not, extensibility is a feature not a bug ;-)

I meant the use case requirement is that we extend the measurement-map instead of just measurement-values-map.

Hence the proposal, to avoid extension but make it a first class change in the specification!

[thomas-fossati]

Now I am confused. I understood this was about changing ref-val and end-val triples to allow 1 or more measurement-maps, not about extending measurement-map.

[yogeshbdeshpande]

Now I am confused. I understood this was about changing ref-val and end-val triples to allow 1 or more measurement-maps, not about extending measurement-map.

Yes I do NOT propose extending the map. You are correct!

I propose we add multiplicity!

[nedmsmith]

Example 4:

[
   (env=ENV1, [ meas=MEAS1] ),
   (env=ENV2, [ (mkey=x, meas=MEAS2), (mkey=y, meas=MEAS4)] ),
   (env=ENV3, [ meas=MEAS3] )
]

[yogeshbdeshpande]

I am all for Example 4:
Since We have all the required bits already: We just need to do the following: ==> To Achieve Example 4:
reference-triple-record = [
environment-map
[measurement-map]
]

[nedmsmith]

We just need to do the following: ==>

... and document the verifier behavior for matching reference values to evidence / ACS and for conditional endorsement condition matching.

[yogeshbdeshpande]

We just need to do the following: ==>

... and document the verifier behavior for matching reference values to evidence / ACS and for conditional endorsement condition matching.

100% Agree!

[thomas-fossati]

We just need to do the following: ==>

... and document the verifier behavior for matching reference values to evidence / ACS and for conditional endorsement condition matching.

... and make sure that this all works with existing conditional triples using naked measurement-values-maps

[nedmsmith]

... and make sure that this all works with existing conditional triples using naked measurement-values-maps

...and not forgetting the ability to include authority as part of the condition.

[yogeshbdeshpande]

I have started a Draft [WIP] PR.
#181

I admit I will need your help in completing this neatly 🥇

I will update examples, once we limit and evaluate the impact!

[thomas-fossati]

Can we close this? Yogesh's PR #181 was closed with reason: "we have an alternative called integrity registers".

[yogeshbdeshpande]

Sure let's close this!

[nedmsmith]

+1