What is an mkey really?

[deeglaze]

I'm confused what mkey is supposed to mean. Why isn't the mkey an element of the environment itself? What is a sub-environment if not just a more specific environment? It seems like it was added to help represent accepted claims and not as a way to represent a reference integrity manifest.

The ACS reusing the CoRIM CDDL seems to have had ill effects.

[nedmsmith]

As far as I know Intel isn't using mkey. I agree that the 'sub-environment' philosophical context doesn't make a lot of sense, but it has been used to provide some additional context in terms of providing hints for identifying the entity that is responsible for the environment-map name space. But as an extensible value, it could be used for other things too. I don't think it is absolutely necessary to try to resolve the philosophy / justification right now, but it may be worth some text that discourages its use?

[nedmsmith]

The ACS reusing the CoRIM CDDL seems to have had ill effects.

This statement seems like a non-sequitur. Does it belong in a different issue?

[nedmsmith]

Is mkey assigned by the evidence reflection through the conveyance or the CoRIM issuer? I'm confused about the phase at which the mkey value is assigned.

This is quoted from #70 which points to #230 as the discussion thread for this question.

[nedmsmith]

I believe the original intent was for mkey values to be created as part of manifest authoring.
However, since mkey is extensible, it's possible that an extension defines different semantics.

[deeglaze]

When you say manifest authoring, are you talking about reference manifests or manifests that are reflected from evidence at the time of verification? The latter is the part I'm confused about. I don't know how you identify an ephemeral SPDM channel ahead of time for reference values.

[nedmsmith]

When you say manifest authoring, are you talking about reference manifests

Reference/Endorsement Manifests

manifests that are reflected from evidence at the time of verification?

Consider a hot-plug use case (or other similar use case) where a component is discovered to be in the system but a Reference / Endorsement Manifest didn't predict its discovery. Lets say it was a second NIC card. Upon insertion a system bus starts reporting activity on the endpoint. An Attesting Environment might collect claims and include additional evidence. If only the class-map environment is used, both NICs would have the same measurements, but there would be two instances of evidence. How should a Verifier disambiguate the two? Possibly there was a glitch that reported the same evidence block twice? Or it was a hot-plug event that shows two NICs when there used to only be one. If the Attesting Env had a way to disambiguate each NIC, that might help the Verifier. One possible approach is to leverage mkey to encode bus endpoint identifiers (but an alternative is to define a new measurement/claim type and add it to the other measurements in the evidence block) - I don't think this is resolved yet. In terms of handling reference values, it is possible that an endorsement manifest reports the existence of the system bus. But it can't know if the endpoint is populated (until the hot plug event). The ephemeral SPDM channel use case seems to have similar dynamics. The challenge with SPDM and the way it reports evidence is there isn't the logical equivalent of environment-map only measurements. If you argue that the SPDM session key / transcript is equal to an instance-id this also doesn't work because the transcript is dynamically generated (kind of like a hot-plug event). So there needs to be a way for Attesting Environments to assert new context but where Verifiers don't expect to find corresponding reference values. I think an elegant approach is to let Attesting Envs assert additional claims in Evidence. Normally, the verifier just accepts these assertions anyway - it just records the authority by which they're asserted. It's up to RPs / policy to determine its relevance to trustworthiness. It's a matter of using the measurement-values-map extension mechanisms to satisfy the particular use case be it hot-plug or something similar.

[deeglaze]

Attesters report evidence though, not reference values and endorsements. There's a phase distinction between provisioning and runtime here. I don't think that attesters should be reusing CoRIM as a representation of evidence, here adding in some kind of mkey metadata.

[nedmsmith]

I don't think that attesters should be reusing CoRIM as a representation of evidence

Evidence needs to follow the schema of the reference values (or vice versa), otherwise, there needs to be a schema translation layer built into the tooling. The RATS Arch and Endorsement I-D point to the complexity issues associated with both schema translation and format translation. There are existing specs in TCG that are aligned with CoMID at the ECT level of abstraction. One defines CBOR encoding while the other an BER encoding. Both align with the CoRIM schema's ECT structures.

The use of mkey to solve a real problem is only one possible approach. I'm not advocating necessarily for this approach.

[nedmsmith]

added the preferable first release label

This issue, #230, is referenced from issue #70. A resolution to #70 is needed which may resolve the #230 thread as well?

It isn't clear to me that there is an issue here. The thread seems to be soliciting clarification and context. Hence, I think its premature to prioritize it as something to be fixed.

Issue #248 also has an mkey thread (and my feedback there is to resolve #70 first as well)

[deeglaze]

I can appreciate that the translation step can be a burden, but you have a very real problem here for phase distinction. Can we have a shared base CDDL that both evidence and CoRIM use to avoid problems in representations?

There's already a problem with measurement-map's authorized-by leaking from stateful-environment-map's conditions on authorizers to reference values' ability to misattribute authorization of reference values to a principal other than the CoRIM issuer.

Make illegal states unrepresentable. While it may lead to code points that seem largely the same, the phase of when the data is generated is important to distinguish with a hard line.

[nedmsmith]

problem with measurement-map's authorized-by

Seems like we need an issue detailing the concern with authorized-by.
This doesn't seem related to mkey however.

[deeglaze]

Okay, might I suggest that we change this issue to deprecate mkey in favor of something like $$environment-map-extensions? I'm finding it particularly difficult to model SEV-SNP attestations to account for CHIP_ID as instance of the host, and REPORT_ID as instance of the guest on the host, and REPORT_ID_MA as instance of the guest across migrations. @thomas-fossati have you thought more about Realms CCA ephemeral instance ids?

[deeglaze]

It probably doesn't make sense for environment-map to be extensible by profile since you need to be able to name specific instances across profiles. But that also makes mkey difficult to account for as profile-extensible, since that is also naming the subject :-/

[nedmsmith]

It probably doesn't make sense for environment-map to be extensible by profile
But that also makes mkey difficult

Removing mkey would force data models to consider using an environment identifier instead.

Nevertheless, all three forms are extensible using $class-id-type-choice, $group-id-type-choice, or $instance-id-type-choice. But given tagged-bytes is common to all of them (tagged-bytes = #6.560(bytes)). There's little / no reason for a profile to need to extend the identifier since bytes can contain any value opaquely. It just has to be globally unique.

Some have positioned that mkey has value in that it could use a small (number/string) value as an environment (or object or component or measurement or ...) identifier that is locally scoped to more efficiently build RIMs. This idea is explained in more detail in #248

[savithahh]

• reference-triple-record definition in https://trustedcomputinggroup.org/wp-content/uploads/TCG-Endorsement-Architecture-for-Devices-V1-R38_pub.pdf:

reference-triple-record = [
environment-map ; target environment
[ + measurement-map ] ; reference measurements
]
In this case can the mkey be used identify the subcomponent in each measurement-map within the same environment?

• This differs from the definition in https://www.ietf.org/archive/id/draft-ietf-rats-corim-05.html#:

reference-triple-record = [
environment-map
measurement-map
]
Clarification will help. Thank you!

[nedmsmith]

• reference-triple-record definition in https://trustedcomputinggroup.org/wp-content/uploads/TCG-Endorsement-Architecture-for-Devices-V1-R38_pub.pdf:

reference-triple-record = [ environment-map ; target environment [ + measurement-map ] ; reference measurements ] In this case can the mkey be used identify the subcomponent in each measurement-map within the same environment?

• This differs from the definition in https://www.ietf.org/archive/id/draft-ietf-rats-corim-05.html#:

reference-triple-record = [ environment-map measurement-map ] Clarification will help. Thank you!

The IETF corim design team, at one point, thought the multiplicity of measurement-maps wasn't desirable since it requires disambiguation in terms of which environment it belongs in. mkey could be used for that purpose, but it also could be used to provide other information such as identifying an originator of the measurement. It also seems to be a less elegant way to model parent-child relationships.

Since then, the scope of environment-map was clarified to be global. But the namespace scope for mkey, if used, has some value as a locally scoped identifier (which seems to reduce the verbosity of the overall expression).

[savithahh]

The IETF corim design team, at one point, thought the multiplicity of measurement-maps wasn't desirable since it requires disambiguation in terms of which environment it belongs in. mkey could be used for that purpose, but it also could be used to provide other information such as identifying an originator of the measurement. It also seems to be a less elegant way to model parent-child relationships.

Since then, the scope of environment-map was clarified to be global. But the namespace scope for mkey, if used, has some value as a locally scoped identifier (which seems to reduce the verbosity of the overall expression).

Thank you for the info!

• What are the other options available to model parent-child relationships?

• Will the definition of reference-triple-record be considered for an update with [ + measurement-map ], to be uniform across specifications?

[savithahh]

The IETF corim design team, at one point, thought the multiplicity of measurement-maps wasn't desirable since it requires disambiguation in terms of which environment it belongs in. mkey could be used for that purpose, but it also could be used to provide other information such as identifying an originator of the measurement. It also seems to be a less elegant way to model parent-child relationships.
Since then, the scope of environment-map was clarified to be global. But the namespace scope for mkey, if used, has some value as a locally scoped identifier (which seems to reduce the verbosity of the overall expression).

Thank you for the info!

• What are the other options available to model parent-child relationships?
• Will the definition of reference-triple-record be considered for an update with [ + measurement-map ], to be uniform across specifications?

This will help to have the evidence and the reference triple records aligned per "TCG DICE Concise Evidence Binding for SPDM". Should this be opened as a separate topic? Appreciate your comments.

[andrew-draper]

I also agree that mkey is really part of the environment-map/class. My products are not dependent on mkey but I am ok with the field existing in the correct place in the syntax.

One significant issue will be backwards compatibility with DICE/SPDM import of manifests which include mkey. That process has moved to a new draft draft-smith-rats-evidence-trans - I think that document needs to provide backwards compatibility with manifests published by existing attesters.

If we decide that we have to keep mkey then IMHO it should move to environment-map/class

[thomas-fossati]

If we decide that we have to keep mkey then IMHO it should move to environment-map/class

👍

[deeglaze]

I've dug a little into the corim repo and see an example for PSA tokens that mkey is used to distinguish the bootloader and PRoT as separately measured components.

Given that the corim repo represents a value triple with an evironment and an array of measurements and the draft has no such array, there is no added benefit of mkey given the "merge" semantics, unless the idea is that

Triple[E, [M, ...]]

should be interpreted as duplicating E, and mkey is still allowed to keep measurement-values-map from getting merged together.

[Triple[E, M], ...]

Now I wonder, given this example, if mkey is expected to be the name of "one of the things the attester measured", and not simply a distinguishing name for otherwise identical components. The BL/PRoT example suggests that the constraint of "identical" wasn't intended.
It certainly makes more sense to me to allow an attestation report with multiple fields to use mkey as a field name and mval as a representation of the value kind, instead of having a profile add duplicate value kinds to account for the many fields (see my draft profile for SEV-SNP)

With this interpretation of mkey, it makes verifiers less burdensome to write. There's little reason for me to use the values map extension. I can use svn-type for all the different TCB values, all given a different mkey. I can use version for the build/major/minor tuples.

[thomas-fossati]

For PSA, we could (re)use EAT measured components, e.g.:

[
  / env / {
    / class / 1 : {
      / class-id / 1 : 1234(h'0123456789')
    }
  },
  / measurement / {
    / EAT measured components / 5678 : [
      [
        / id / [
          / name / "PRoT",
          / version / [ "3.2.1" ]
        ],
        / measurement / [
          / alg / "sha-256",
          / val / h'3996003d486fb91ffb056f7d03f2b2992b215b31dbe7af4b373431fc7d319da3'
        ],
        / signers / [ h'4277bb97ba7b51577a0d38151d3e08b40bdf946753f5b5bdeb814d6ff57a8a5e' ]
      ],
      [
        / id / [
          / name / "BL",
          / version / [ "1.2.3" ]
        ],
        / measurement / [
          / alg / "sha-256",
          / val / h'ffaf003d486fb91ffb056f7d03f2b2992b215b31dbe7af4b373431fc7d319da3'
        ],
        / signers / [ h'4277bb97ba7b51577a0d38151d3e08b40bdf946753f5b5bdeb814d6ff57a8a5e' ]
      ]
    ]
  }
]

[thomas-fossati]

@deeglaze would something like the above work for you if we added SVNs to EAT measured components?

I.e.:

[
  / env / {
    / class / 1 : {
      / class-id / 1 : ...
    }
  },
  / measurement / {
    / EAT measured components / 5678 : [
      [
        / id / [
          / name / "host microcode"
        ],
        / SVN / 1
      ],
      [
        / id / [
          / name / "host firmware"
        ],
        / SVN / 3
      ],
      [
        / id / [
          / name / "guest firmware"
        ],
        / SVN / 24
      ],
      / etc. /
    ]
  }
]

[deeglaze]

SVN was an example of many things we account for in TDX and SEV-SNP quotes. I don't know why 5678 would be a valid place to replicate the mkey/mval meaning when there are already standard measurement value types.