Profile-directed comparison and profile-id comparison

[deeglaze]

In the space of candidate and condition having a profile id, we've discussed

both without: use base semantics condition with, candidate without: use the profile matching algorithm for any extensions, but I think we're missing wording in the spec that if there are any non-base CDDL bits of a CoRIM that it MUST have a profile-id to give them meaning. The text in the current draft just falls back to binary equality,

If a codepoint's comparison algorithm is not stated or does not default to the comparison algorithms described in this specification, then the Verifier MUST compare the binary equality of the CBOR encodings of the values.

But I worry that a -1: 1 in one profile may have completely different meaning from -1: 1 in another, and the lack of a profile can mean that two completely different measurements are getting viewed as the same.

We haven't discussed condition without, candidate with: I'm guessing we use the base semantics' matching algorithm applies and rejects to match any nonstandard values. condition with, candidate with: This one really does require mentioning in the document. I think that we need to require equality or at least condition profile-specified matching condition to allow for subsumption judgments.

In an email thread I discussed the merits and dangers of allowing a profile in a condition to override the profile in the ACS. Recap here

is there any downside to giving that flexibility to the profile?

There is, but we probably shouldn't rule it out entirely.

Evidence can be translated to an ECT with some specific profile that assigns meaning to nonstandard codepoints, and another profile comes along and says, "ya ya ya, whatever" and adds its CoRIM issuer authority to the ACS entry that still has the evidence's profile identifier associated and not the CoRIM's. I mean I guess if you trust both the CoRIM issuer and the semantics of the profile, then you could trust this behavior, but it seems like it would be cause for confusion and inadvertent privilege escalation. You shift more burden into the policy side of the Verifier to accept a profile's overreach to subsume ACS entries' profiles. Given that the base CDDL says that a profile MUST NOT override its specified semantics for its codepoints, I would think that you might want the option for an ACS entry's profile to also have non-expansive matching semantics.

If we do allow for the profile to do whatever, we ought to add a note that profile identifier comparisons that are not binary equality are NOT RECOMMENDED due to the additional burden of ensuring the interactions are acceptable by policy.

[deeglaze]

There is a lot of punning between evidence and condition for matching evidence that can be useful for simple CoRIMs but not for more specific profiles like Ned's Intel TDX profile's inclusion of set relations.

Do we clone measurement-map into actual-measurement-map and condition-measurement-map to allow profiles to enhance all code points of any measurement-values-map to allow for more expressive match conditions? It would allow us to move tagged-min-svn out of measurement-values-map and just into condition-measurement-map so we don't have any inexact measurements.

[nedmsmith]

Is the "not fo

There seems to be missing text.

[nedmsmith]

In the space of candidate and condition having a profile id, we've discussed

Does "condition" refer to a condition statement in a triple? What does "candidate" refer to?

[nedmsmith]

Do we clone measurement-map into actual-measurement-map and condition-measurement-map to allow profiles to enhance all code points of any measurement-values-map to allow for more expressive match conditions?

The Intel Profile for Corim (different from the Intel profile for TDX EAT claims) contains definitions for both possible state and actual state. The profile expects condition statements will include measurement-values-map extensions for negative code points. However, it doesn't expect condition statements will express "possible state" as the ACS only expresses actual state. This implies the richness of the condition need only cover expressions of actual state.

[deeglaze]

Maybe "possible state" is where we're missing each other. I'm simply talking about a condition that matches more than one actual state. The space of all actual states that it matches is what I call possible state.

"Expressions of actual state" refers to your expression language, does it not?

Expressions are used to specify richer Reference Values measurements that expect non-exact matching semantics

By having non-exact matching, you are expressing a space of measurements that is not a singleton set.