Assert mkey as local to the environment and add mkeyvalues to measurement-map.

[deeglaze]

This change addresses the multiplicity of the same type issue #256.

A follow-up PR will address the multiplicity of reference values to avoid representation combinatorial explosion for cartesian products.

[deeglaze]

Consider this a draft as I work out the kinks with multiple authorized-by. I can't find the button to change to Draft mode.

[thomas-fossati]

Very nice, thanks.

The only thing lacking is a clear description of how the element key interacts with the matching rules.

[andrew-draper]

If you want a magic key value then perhaps use NULL or a tagged value rather than a magic string.
Alternatively, can authorities be moved up a level?

[deeglaze]

Authorities are more predicate than they are object, so I'm happy to move them into the triple / stateful-environment-map. I'd like to ask the group about it though.

[henkbirkholz]

The "__"-prefix are intended to be a placeholder (not a magic string). Personally, I think in the context of this map, negative values are perfectly fine.

[deeglaze]

I've changed the placeholder string to a &(fixme-authority: -1) codepoint since I plan to follow up with another PR that lifts authorities out of measurement-map and into the surrounding uses when appropriate.

[andrew-draper]

Suggested change

	The following describes each member of the `measurement-map`:
	The `measurement-map` contains one or more measured-entities, each is identified by the map key.
	It may also contain special values which apply to all measured-entities.

[henkbirkholz]

Suggested change

	The following describes each member of the `measurement-map`:
	The `measurement-map` contains one or more measured elements, each is identified by the map key.

It may also contain special values which apply to all measured-entities.

Should this be the negative value space?
See "fixme-authorities" for context

[thomas-fossati]

I agree with Henk that L802 in the suggested text is insufficient. It needs some clear description of the negative codepoint space which is reserved for common attributes.

[andrew-draper]

Suggest moving this to the end and replacing it with something like:

Suggested change

	* `"__authorities"`: The cryptographic identities of individuals or organizations that are
	The special map key NULL indicates that the corresponding value is a list of authorities for the measurement.
	In an ACS entry this indicates which entity deckared the validity of the measurement.
	In a reference value entry this provides a list of the authorities whose authority declaration is required.

[deeglaze]

Oh interesting, I didn't think it was a list of required authorities but rather a list of allowed authorities. At least one must match. Perhaps authorities should be an explicit pattern that is consistent with that interpretation:

authority = $crypto-key-type-choice
authorities = [ + authority ] / #6.562([ + authorities ]) / #6.563([ + authorities ])

We ensure #6.563 has a subset relationship with the list it's matched against, so all listed authority patterns in #6.563 must match some entry of acs-authorities.

This is different from #6.562 since that is any pattern fully matches the value (not an entry of the value, presumed array)

[andrew-draper]

Suggested change

	* `measurement-values-map`: A map value that associates measurement values with the named measured element within the environment. Described in {{sec-comid-mval}}.
	When the map value is a uint or string, the map value holds the corresponding measurement values.
	Described in {{sec-comid-mval}}.

[thomas-fossati]

This is a list of definitions, we should not remove the term that is defined. We need instead to define the measurement-values-map value more clearly.

[andrew-draper]

Suggested change

	The types defined for identifying a measured element are uint, or a textual string different from `"__authorities"`.
	The types defined for identifying a measured element are uint, or a textual string.

[andrew-draper]

Why is this a bad thing?
When matching a reference value against the ACS, I was expecting the mkey to be used as part of finding measurement elements to be compared. Isn't that how the processing happens?

[deeglaze]

I conceptualize environment map as a "place" and measurement-map as "properties", so I wouldn't say that a particular property from an attester should be considered more refinement on the place it's describing. If there is environment information, I think it should be in the transformation.

[andrew-draper]

I think this is going in the right direction, but I don't think we are aligned on all the key concepts yet.

[andrew-draper]

Can we define a type, then have the text refer to the type rather than the key which identifies the type?

[andrew-draper]

ditto

[andrew-draper]

Can we use an intermediate name for this, for example:

Suggested change

	? "__authorities" => [ + $crypto-key-type-choice ]
	? "__authorities" => measurement-authorities

This will make the textual description much easier to read.

[yogeshbdeshpande]

Also, the proposal is to add the multiplicity in such a way that it does not break the existing CDDL in a way that it preserves those implementations which honour singularity of measurement-map, so that it comes out as a non breaking change!

[thomas-fossati]

Also, the proposal is to add the multiplicity in such a way that it does not break the existing CDDL in a way that it preserves those implementations which honour singularity of measurement-map, so that it comes out as a non breaking change!

We decided that backwards compatibility was a non-goal. Why is this suddenly a criterion now?

[thomas-fossati]

One more aspect in favour of introducing multiplicity inside measurement-map is we align with TCG specification which advises multiplicity of measurement-map

The same effect can be obtained by minting a new triple.

[nedmsmith]

I think that we ought to organize the CDDL a little more instructively though, so that any position that has non-exact matching semantics has a codepoint name *-pattern or some such.

Yes, agreed, so we'd be breaking compatibility anyway...

We agreed to stage the separable proposals; one that deals with multiplicity of measurement values and one that deals with matching rules. The latter is a significant shift from previous assumptions about exact-match matching rules. Given the Intel Profile is mostly about non-exact-match matching and the ability to specify reference values as such, more attention is needed on what is being proposed (and PRs should be focused only on this aspect of functionality).

[thomas-fossati]

We agreed to stage the separable proposals;

Absolutely. In fact, they are already separate.

[nedmsmith]

Also, the proposal is to add the multiplicity in such a way that it does not break the existing CDDL in a way that it preserves those implementations which honour singularity of measurement-map, so that it comes out as a non breaking change!

We decided that backwards compatibility was a non-goal. Why is this suddenly a criterion now?

I don't believe that that was the case. The goal is to append first, deprecate second, and remove third (possibly in the distant future).

[nedmsmith]

We agreed to stage the separable proposals;

Absolutely. In fact, they are already separate.

The PR (i think #257) was removing code points in measurement-map, changing authorized-by, adding new code point with multiplicity semantics and adding a pattern macro.

Maybe you can explain how these are in separate PRs?

[thomas-fossati]

The PR (i think #257) was removing code points in measurement-map

Yes, #257 is doing that.

changing authorized-by,

It's only changing the codepoint, not the semantics or the encoding or the relative position - which are the fundamental aspects of "auth"

adding new code point with multiplicity semantics and adding a pattern macro.

No, that is done in #258

[thomas-fossati]

Also, the proposal is to add the multiplicity in such a way that it does not break the existing CDDL in a way that it preserves those implementations which honour singularity of measurement-map, so that it comes out as a non breaking change!

We decided that backwards compatibility was a non-goal. Why is this suddenly a criterion now?

I don't believe that that was the case. The goal is to append first, deprecate second, and remove third (possibly in the distant future).

In the last few meetings, we had a few backwards compatibility-related discussions and the consensus was that for measurements we should have no constraints. The way we got to the current shape was by starting with the backwards compatible proposal, removing the constraint, and reorganising the data structure accordingly.

[nedmsmith]

In the last few meetings, we had a few backwards compatibility-related discussions and the consensus was that for measurements we should have no constraints.

OK. I would like to respectfully disagree then.

[deeglaze]

Multiple measurement-map and multiplicity in the measurement-map here both have flaws for conditional-endorsement-series-triple-record that I'm not sure what the taste is for the changes.

There's Target Environment targeting via stateful-environment-map, and a series of conditions that inherit the authorized-by of the measurement-map in stateful-environment-map. With multiple measurement-map, there's no singular authorized-by to apply to each series record. There's also no singular measurement-map key that the condition or consequence measurement-values-map are meant to match against/contribute to.

There's also the design choice of allowing the consequence to contribute endorsements to multiple measurement-map keys if the condition matches. This is a shared problem between multiple measurement-map and this PR's + mkey => mval encoding.

[henkbirkholz]

The meeting yesterday seems to have started the unraveling of progress of the last month. And that while we started to consolidate publication goals. IMHO, this discussion basically sets us back - significantly so - and I apologize for highlighting that so bluntly. There is no technical issue with this PR. An underlying question that this discussion uncovers, though, might be something to the extend of: "where does the authority member go" or "on which granularity level do we need it". That would be a fine discussion. Unearthing #181 does not necessarily help here (reflection my opinion again with my initial statement, I started this comment with: I think it actually is a detriment to progression).

In the last few meetings, we had a few backwards compatibility-related discussions and the consensus was that for measurements we should have no constraints.

OK. I would like to respectfully disagree then.

I think the discussion should focus on "where does the authority member go", yes. We also re-confirmed to follow the "augment, deprecate, remove later (maybe in the far future)" approach that Dionna emphasized in the past weeks. This approach can be reflected in this PR (addressing "removing code points in measurement-map"). As Thomas highlighted the "adding new code point with multiplicity semantics and adding a pattern macro" issue is handled in #258.

@nedmsmith why do you disagree? Could we address your first and second point in this PR?

[nedmsmith]

There is no technical issue with this PR

Part of the PR removes code points which is a breaking change. That seems like a technical issue.

[nedmsmith]

"adding new code point with multiplicity semantics and adding a pattern macro" issue is handled in #258.

These are separable issues / changes that appear to be conflated into a single PR. The "multiplicity" discussion has been ongoing for a long time where we agreed to remove multiplicity in measurements - which places heavier use of environment-map to disambiguate individual measurements of the same type. Now we are reconsidering that decision, but instead of reverting back to the original approach (which has the additional benefit of compatibility with the TCG spec) we're introducing something different. It's not clear what the benefit is while also not addressing the incompatibility concern.

The any-of macro is aimed at addressing the non-exact-match semantics that we agreed to not touch until after the current draft was in WGLC and a follow-on draft could address it. Given the Intel Profile addresses this consideration, it makes sense for the design team to consider it as a starting point.

[nedmsmith]

"where does the authority member go" or "on which granularity level do we need it".

This is a third separable technical issue. There has been a discussion topic for a long time as well. The main consideration is scope. Although, some of the thread discussion seems to question semantics of how the authority mechanism works. It would be helpful to avoid conflating these two topics IMHO also. Given the general case doesn't need to use authorized-by, we should consider whether spending a lot of time on name change or scope vs. getting to WGLC is justified. For example, if we can't identify something that is broken or a security flaw etc., then maybe its OK to leave it as is?

[nedmsmith]

Multiple measurement-map and multiplicity in the measurement-map here both have flaws for conditional-endorsement-series-triple-record

It would be helpful to identify the flaws explicitly.

[thomas-fossati]

There is no technical issue with this PR

Part of the PR removes code points which is a breaking change. That seems like a technical issue.

I strongly disagree with this characterisation.
(Note that if we really need to keep compatibility with TCG's CoRIM, we can always mint a new triple that uses the new measurements-map and keep the old one around and maybe slowly deprecate it.)

But the core question is: Why is it a requirement for IETF CoRIM to be backwards compatible with TCG CoRIM?

[nedmsmith]

There is no technical issue with this PR

Part of the PR removes code points which is a breaking change. That seems like a technical issue.

I strongly disagree with this characterisation. (Note that if we really need to keep compatibility with TCG's CoRIM, we can always mint a new triple that uses the new measurements-map and keep the old one around and maybe slowly deprecate it.)

But the core question is: Why is it a requirement for IETF CoRIM to be backwards compatible with TCG CoRIM?

In cddl/measurement-map.cddl (see below), the minus show lines deleted and + shows lines added. The deleted lines breaks existing examples. Hence, all the examples have been updated.

measurement-map = {
  - ? &(mkey: 0) => $measured-element-type-choice
  - &(mval: 1) => measurement-values-map
  - ? &(authorized-by: 2) => [ + $crypto-key-type-choice ]
  + ? &(fixme-authorities: -1) => [ + $crypto-key-type-choice ]
  + + $measured-element-type-choice => measurement-values-map
}

If the idea is TCG can create new code points that preserve existing behavior, then that would be a breaking change for TCG since the code points will differ. On the other hand, if IETF corim wants to do something different all it has to do is define a new code point leaving the existing ones alone.

We could re-ask the question above: "Why break backwards compatibility to add new capabilities?"

Another point to recall is IANA is assigning CBOR tags based on the TCG specs.

If IETF corim wants to avoid documenting the removed stuff it could deprecate them:

measurement-map = {
  // &(mkey: 0) depreciated
  // &(mval: 1) deprecated
  // &(authorized-by: 2) deprecated
  + ? &(fixme-authorities: -1) => [ + $crypto-key-type-choice ]
  + + $measured-element-type-choice => measurement-values-map
}
$measured-element-type-choice /= uint // where uint is in the range 3..max-uint since 0..2 are deprecated
$measured-element-type-choice /= tstr

BTW: allocating from the negative code point space contradicts the previously agreed convention that this is reserved for profiles/vendor specific use which has been discussed with IANA. Other than the code point change and name change, which is thrown away anyway, there doesn't seem to be value in deprecating authorized-by.

[thomas-fossati]

If the idea is TCG can create new code points that preserve existing behavior, then that would be a breaking change for TCG since the code points will differ.

The other way around.

On the other hand, if IETF corim wants to do something different all it has to do is define a new code point leaving the existing ones alone.

This 👆 (If we need to maintain backwards compatibility.)

Another point to recall is IANA is assigning CBOR tags based on the TCG specs.

If their semantics are preserved, the CBOR tags can be reused in other contexts.

BTW: allocating from the negative code point space contradicts the previously agreed convention that this is reserved for profiles/vendor specific use which has been discussed with IANA.

The convention doesn't apply to the measurement-map because there is no extension registry associated with it.

Other than the code point change and name change, which is thrown away anyway, there doesn't seem to be value in deprecating authorized-by.

Reserving the negative codepoint space seems like a cleaner solution.

[nedmsmith]

Another way to approach the multi-valued attributes for measurements conversation is to ask the question of how many instances of measurements, that are of the same type, are needed for a given environment? Do we need 10s, 100s, 1000s, millions, billions etc.?

By defining the code point space using both strings and uints, there are effectively two infinities of measurements (of the same type) supported. Do we need that many?

If we think the pragmatic answer is less than 2 * infinity, then can we reduce the uint space by 2 or 3, or maybe 100 such that the code points from 0-99 are reserved? Given past specs have used some of the code point space, what is the rationale for clobbering them? Or can we get by with ( 2 * infinity) - 3 or (2 * infinity) - 99?

We could ask the same question for UUIDs. Can we get by with (2 * infinity) - all values size(2^16)?

If realistically we only need on the order of 1000, then we could define $measured-element-type-choice /= uint to be in the range of say 100 - 1100. There would still be an infinity of text labels for corner cases that needed more than 1000.

[deeglaze]

The &(fixme-authorities: -1) number choice was intentional to keep it out of the way but also feel wrong so that we fix it in a follow-up. I can revert this. My goal was to allow for a single authority to apply to all mkey/mval pairs (I see it still does, just with an awkward 2 key). We can instead keep authority where it is and if you want a different authority, you add another triple with that authority.

Now there's the contention of removing a single level of indirection by keeping multiplicity in the measurement-map versus lifting to a choice between measurement-map and [ + measurement-map ]. I like the former but yes the value space does clash with $measured-element-type-choice.

We can make $measured-element-type-choice's non-negative value space a registry and change uint to int. Negative numbers can be local to the environment, as their interpretation is dependent on the profile anyway. I don't want to try to argue that 1000 fields ought to be good enough for anybody.

So for example, we can maintain backward compatibility by

measurement-map = {
  ? &(mkey: 0) => $measured-element-type-choice / measurement-values-map
  ? &(authorities: 2) => authorities
  + $measured-element-type-choice => measurement-values-map
}

$measured-element-type-choice /= int except 2 (how do you say this?)
$measured-element-type-choice /= tstr
$measured-element-type-choice /= tagged-oid
$measured-element-type-choice /= tagged-uuid
authorities = [ + $crypto-key-type-choice ]

If mkey: 0 is provided with a value from the base spec's $measured-element-type-choice, then mval: 1 must be provided. We treat key 1 as the mkey's value during processing of the key/value pairs for backward compatibility. W

If the argument is that it's weird to have a registry that contains just 0, 1, 2 and unlikely to contain anything else, then don't create a registry and leave it open for a future RFC to assign the values, no? Or is that reservation only guaranteed by having a registry?

[nedmsmith]

I don't think that works since a $measured-element-type-choice = 0 is possible and could result in use of the same code point in the same map. This will produce indeterminate behavior.

A safer and possibly more prudent approach is to carve out a code point namespace for dynamically supplied code points e.g., 100 - 10000 or something like that. This way there is room for measurement-map to retain use of a portion of the code point namespace for future challenges if needed.

$measured-element-type-choice /= 100..10000

[deeglaze]

It's not indeterminant because $measured-element-type-choice doesn't contain map types. If you use 0 as a regular key, you can have the measurement-values-map as the value.

[thomas-fossati]

To clarify this point, where there seems to be a bit of confusion:

If the argument is that it's weird to have a registry that contains just 0, 1, 2 and unlikely to contain anything else, then don't create a registry and leave it open for a future RFC to assign the values, no? Or is that reservation only guaranteed by having a registry?

There is no registry associated with measurement-map. The 0, 1, and 2 codepoints are just locally-scoped placeholders. In this regard, we are not constrained by IANA, only by what we write in the CDDL. The measurement-map case is very different from, say, the triples space or the measurement-values-map's where the codepoints have global (IANA-regulated) values. (This is also the reason why the nint/uint codepoints-space partitioning convention we use in other places is not meaningful here.)

Stepping back a meter or two, it seems to me we are constraining ourselves unnecessarily only to keep backwards compatibility with the CDDL presented in the TCG document, which is provided just as an example in an appendix (i.e., it is not normative).

And, I am still having a very hard time understanding why keeping "on-the-wire" compatibility with TCG has become a necessity. We work on the assumption that TCG CoRIM provides the info model, whilst IETF CoRIM is (one possible) data model. Therefore, if IETF CoRIM wants to implement the k-v in Figure 9 of DICE Endorsement using [ + k => v] rather than a clumsy [ + [ k, v ] ], it should be free to do that. That's entirely a data model choice. 😕

If instead on-the-wire compatibility with TCG is a requirement, then the CDDL should be considered frozen, and IETF should only be working on clarifying the semantics and processing rules.

[yogeshbdeshpande]

I have evaluated both the options => WE have discussed so far:

I will try to summarise my view prior to going on holidays from tomorrow:

Option 1: Model a series of key-val inside single measurement-map

like Env: meas-map {+mkey => v}

This semantics make sense if the ONE Measured Element/Component of an Environment has multiple Measurements at say different points in time, or some other some other variation aspect. The reason I say so is I am not clear Where does Authorities go?

Outside in the Meas-map i.e., like
meas-map {
authorities
+mkey => val
}

It implies I can specify only one authority for the entire series ?

OR I can specify multiple, then I am not clear how to express the same, in an un-ambiguous manner?
Which authority belong to which row of key-val ??

<>

Option 2:

Env : [+meas-map]
with each meas-map has a single
{ ? key => mkey
val => mVal
? authority: [crypto]
}

This is the one proposed in Rev-0 and in TCG DICE.

Here, Each meas-map has one or more authority for the Measured Element specified and identified by mkey (Optionally)

If I have Multiple measured elements of the same Platform TCB (identified by a unique Environment) I can specify multiple measurement-map each identifying individual Measured Element ..?

So Option 2, seems more clear to me , unless I am missing something on Option -1

@thomas-fossati : On your comment above, rather than clumsy :
rather than a clumsy [ + [ k, v ] ]
Why do you have two brackets here ?

Should not it be: [k,v, a ] ??

[thomas-fossati]

@thomas-fossati : On your comment above, rather than clumsy : rather than a clumsy [ + [ k, v ] ] Why do you have two brackets here ?

Because this is what Dionna's first proposal in this PR looked like, in order to be backwards compatible with the current layout of the measurement-map.

[yogeshbdeshpande]

@thomas-fossati : On your comment above, rather than clumsy : rather than a clumsy [ + [ k, v ] ] Why do you have two brackets here ?

Because this is what Dionna's first proposal in this PR looked like, in order to be backwards compatible with the current layout of the measurement-map.

ok I got it! the reference was to her earlier proposal

[deeglaze]

There are reasons for keeping an authority with an individual k/v pair, so the original measurement-map multiplicity is more expressive. It would be nice to have a simple way to put an authority over a gaggle of pairs instead of one or all, but in the spirit of simplicity we should just stick with the v0 multiplicity and drop the + k => v approach.

[thomas-fossati]

There are multiple different ways to slice this cake, e.g.: { + k => [ a, v ] }.

It seems to me that we can run in circles forever unless we clarify the point I raised previously, which is still unanswered:

If instead on-the-wire compatibility with TCG is a requirement, then the CDDL should be considered frozen, and IETF should only be working on clarifying the semantics and processing rules.