Add any-of matching operator to wrap measurement values

[deeglaze]

When you have requirements that fields 1-100 must be certain values, and field 0 may be one of many values when in the presence of those other field values, the representation of the matching condition repeats the same 100 certain values for each alternative for field 0. It's far simpler to allow for measurement values to have independently flexible measurement conditions when in that case.

This is still a weak pattern expression language, but the "any-of" use case is a particularly commonly needed one.

This PR seeks to solve one aspect of the multiplicity problem discussed in #256

[andrew-draper]

Looks good, but will probably clash with #257

[deeglaze]

Do we want to merge this or wait for @nedmsmith ?

[yogeshbdeshpande]

We need to be a bit careful, in applying any-of semantics everywhere! Especially in this case, I am struggling to see the justification for line 16:

[deeglaze]

The idea is generally that base CoRIM measurement values should allow for basic patterns for comparisons. The RVP doesn't have to use the new tag, but being choosey about where is "more appropriate" for it I think isn't necessarily our place to say.

[yogeshbdeshpande]

In general looks good to me, with minor clarifications

[yogeshbdeshpande]

If we decide to introduce any-of semantics, then we should also provide a comparison logics for this semantics, for each one of the elements inside the value map.

While this is not a gating criterion for progressing this PR, it might be worth noting this using Edit on an already opened github issue, or creating a new one, if absent!

[deeglaze]

Is the description in the matching operators section insufficient for defining the comparison semantics?

What do you mean comparison logics?

[yogeshbdeshpande]

nits

[thomas-fossati]

It may be worth trying to frame this more generally in terms of "matchers", of which any-of would be an instance.

For example, we could make the type of each claim value a $type-matcher:

measurement-values-map = non-empty<{
  ? svn: $svn-matchers
  ? digest: $digest-matchers
  ; ...
}>

A matcher would be defined as a choice between different high-level matcher types, e.g., the naked type, a multiple type (similar to any-of here), a range type, etc., depending on what makes sense for that claim.

match-multiple<T> = #6.554([ 2* T ])
match-range<T> = #6.555(range-desc<T>)
; match-regex, match-masked-bytes, etc.

For example, for SVNs, it makes sense to define all three above:

$svn-type = uint

$svn-matchers /= $svn-type
$svn-matchers /= match-multiple<$svn-type>
$svn-matchers /= match-range<$svn-type>

For digests (typically, random binary blobs) it makes little sense to add anything more than the "multiple" matcher:

$digest-type = [ val: bytes, alg: int ]

$digest-matchers /= $digest-type
$digest-matchers /= match-multiple<$digest-type>

etc.

[deeglaze]

"matcher" is more often called a "pattern" in programming languages (as in "pattern matching"). I could definitely be down for framing the values as having their own generic or specific pattern forms, but I don't think making them extensible is necessarily the right choice. If there are profile-specific representation choices, then they should use the values map extension socket, IMHO.

[deeglaze]

In this regard, raw-value-mask could be a specific pattern for raw-value, such that a bstr matches a pattern #6.TBD(mask, raw-value-after-zeroextended-mask) instead of needing two values, but that representation choice is only good if the mask isn't needed on its own for lookup.

[thomas-fossati]

"matcher" is more often called a "pattern" in programming languages (as in "pattern matching").

WFM, Pattern Matching looks like a good section title :-D

I could definitely be down for framing the values as having their own generic or specific pattern forms, but I don't think making them extensible is necessarily the right choice.

The proposal is not to make them extensible.
The proposal is to define a few useful pattern-matching constructs in terms of their semantics, rules and CBOR tagging. Then define the type of a claim in terms of a fixed type choice that is built from those blocks.

If there are profile-specific representation choices, then they should use the values map extension socket, IMHO.

Yes.

[nedmsmith]

If I characterize this vs. what is described in Intel Profile. This uses CDDL macros to define "possible state" while Intel Profile uses CDDL directly. Use of CDDL directly is possibly more flexible as it is not limited by assumptions of the macro processor. For example, any-of<> models subset semantics, but what about superset and disjoint set? These are use cases that Intel would like to support.

The Intel Profile supports numeric ranges (greater-than, less-than, greater-equal, less-equal, inequality etc). The above suggests there could be a range macro, but didn't define it, so it isn't clear that it would have the same utility as the CDDL definition.

The Intel Profile also supports time and epoch types.

I think the use of macros is interesting and creative, but why is it better than using CDDL directly?

[deeglaze]

any-of is not subset semantics, I think it's your <evidence_object><member><reference_set>, where the reference set is the [ + T ], and evidence_object is provided by the ECT, if I understand correctly.

If this is the case, then I'd want to allow for these set expressions in any reference value. Where you have set-type = [ * any ], I'd suggest set-type<T> = [ * T ].

[nedmsmith]

I recommend waiting until we have a WGLC candidate then deciding if it makes sense to wait on WGLC or proceed.