add mask to operational flags

[thomas-fossati]

Add a mask alongside the operational flags to allow the endorser to tell the verifier it can ignore certain values.

We should support the following semantics:

• exact match of evidence claims (or end-vals) vs ref-vals
• subset of evidence claims (or end-vals) that should be matched against the ref-vals

[nedmsmith]

current definition: ? comid.flags => flags-type

flags-type = bytes .bits $operational-flags
; operational-flags maps to DiceTcbInfo.flags
$operational-flags /= &( not-configured: 0 )
$operational-flags /= &( not-secure: 1 )
$operational-flags /= &( recovery: 2 )
$operational-flags /= &( debug: 3 )
$operational-flags /= &( not-replay-protected: 4 )
$operational-flags /= &( not-integrity-protected: 5 )

Proposed definition: ? comid.flags => $flags-type-choice

$flags-type-choice /= bytes .bits $operational-flags
$flags-type-choice /= flags-record

flags-record = [
  bytes .bits $operational-flags
  operational-flags-mask-type
]

operational-flags-mask-type = bytes .default 0

[nedmsmith]

BTW - is the numeric in &( flag : numeric) describing a bit position or a value?

[thomas-fossati]

BTW - is the numeric in &( flag : numeric) describing a bit position or a value?

it's the bit position. see https://www.rfc-editor.org/rfc/rfc8610.html#section-3.8.2

[thomas-fossati]

what about:

flags-type = {
  flags : bytes .bits $operational-flags
  ? mask : bytes .bits $operational-flags
}

where the existence of the mask field signals the new semantics?

[nedmsmith]

This seems OK too. I went down the path of using a record to avoid having to define code points. The map solution is easier to read and a less intrusive change.