Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Representing ACS entries with multiple measurements, and extension point for new matching algorithms #211

Open
andrew-draper opened this issue Mar 6, 2024 · 2 comments
Labels
preferable first release Desirable to accommodate in initial release

Comments

@andrew-draper
Copy link
Collaborator

andrew-draper commented Mar 6, 2024

The contents of environment-map are chosen by the attesting environment (AE) making measurements, but it is constrained by the protocol used to collect the evidence.

If an target environment (TE) being measured has multiple measurements of the same type, for example multiple digest measurements or multiple raw value entries, then one option is for the AE to store each measurement under a different environment-map. This is not always the natural way to store the data.

I suggest that a solution to this is to store the first measurement of a particular type under the standard measurement-map entry (eg 2 for digest or 4 for raw value) and to store the other measurements of this type using negative codepoints within measurement-values-map.

The verifier needs to know which comparison algorithm to use for measurements at negative codepoints.

I suggest that, for measurements at negative codepoints, the verifier should use the CBOR tag at the start of the reference value to select the comparison algorithm. Some types, for example svn(1) and raw-value(4), already have tags defined.

If we choose this mechanism then we need to change the CDDL to add optional tags to relevant measurement-values-map values so that stateful-environments can indicate which comparison algorithm should be used for negative types.

If we do not use the CBOR tag of the stateful-environment to select the comparison algorithm for a negative codepoint then we need to define a different way to do this. Using profiles to do this will mean either additional code in every verifier or the need for a profile definition language to indicate that environment E with codepoint -X must use comparison algorithm A.

A related problem occurs when the data format requires extended comparison algorithms which differ from those described in the base specification. The specification of an extended comparison algorithm should define a CBOR tag which tells the verifier to use that algorithm, and the stateful-environment which provides the expected value should be tagged with that tag.

PR #203 requests adding a tag for digests.

@deeglaze
Copy link
Collaborator

deeglaze commented Mar 6, 2024

I think "a TE with multiple measurements of the same type" is a category error, no? It is a family of target environments. Your claim "This is not always the natural way to store the data." may be valid intuitively, but it breaks the model I understand.

I don't know how you you store multiple measurements in the same environment of the same type when appraising evidence. Can you go into more detail about that?


Outside of that, assigning meaning to values in negative codepoints I think is already specified but just not clearly enough.

A CBOR tag's comparison semantics must be global since the tag is IANA-registered. Since there was confusion about this in the meeting, we need new text in the definition of a profile to clarify the "syntax and semantics of a standard CoRIM type" wording to include the meaning of tagged values in extensions. We can point to the following existing wording to solidify the point:

"If the stateful environment measurement-values-map value is tagged with a CBOR tag [STD94] then the Verifier MUST use the comparison algorithm associated with that tag."

So, your proposal to have a tagged digest satisfies using the right algorithm, but it doesn't give extra meaning like an ACS with digests in /2/ can have reference values in /-8/ match and give "authorized-by" tags in /2/.

@yogeshbdeshpande yogeshbdeshpande added the preferable first release Desirable to accommodate in initial release label May 7, 2024
@yogeshbdeshpande
Copy link
Collaborator

@andrew-draper Can we close this, as we think, this has been addressed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
preferable first release Desirable to accommodate in initial release
Projects
None yet
Development

No branches or pull requests

3 participants