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.

[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.