Allowed methods for multiple ref values

[dkumar-nv]

Imagine a HW Register which has two possible reference values: 0 and 1. I am trying to find out the complete list of spec allowed methods and have listed 4 options below. Can I please get feedback on the allowed list of spec compliant options?

Option 1 (Use anonymous values in measurement-values-map. Violation of spec)

The approach below looks conceptually most reasonable to me but violates "Two or more measurement-map entries within the same environment MUST populate mkey". Is there a reason, though, why spec prohibits multiple anonymous measurement-map entries when they correspond to same measured element and no other measured element is part of same environment?

Note: Veraison/cocli does not throw any error with the option below

{
  "environment": {
    "class": {
      "vendor": "ACME",
      "model": "HW Register Value"
    }
  },
  "measurements": [
    {
      "value": {
        "raw-value": {
          "type": "bytes",
          "value": "AA=="
        }
      }
    },
    {
      "value": {
        "raw-value": {
          "type": "bytes",
          "value": "AQ=="
        }
      }
    }
  ]
}

Option 2 (Duplicate the environment while using anonymous value in measurement-values-map to side step spec violation)
The approach below does not seem to violate "Two or more measurement-map entries within the same environment MUST populate mkey" but is effectively the same as Option 1.

Question: Is there any text in spec that prevents the below? Is the verifier supposed to reject a CoRIM that looks like below?

{
  "environment": {
    "class": {
      "vendor": "ACME",
      "model": "HW Register Value"
    }
  },
  "measurements": [
    {
      "value": {
        "raw-value": {
          "type": "bytes",
          "value": "AA=="
        }
      }
    }
  ]
}


{
  "environment": {
    "class": {
      "vendor": "ACME",
      "model": "HW Register Value"
    }
  },
  "measurements": [
    {
      "value": {
        "raw-value": {
          "type": "bytes",
          "value": "AQ=="
        }
      }
    }
  ]
}

Option 3 (Dummy mkey to meet spec requirement of no more than 1 anonymous measurement-values-map)

Notice that I have used the same mkey value for both reference values since if I give them different names, there is no way for verifier to know that they correspond to the same measured element. This option seems appears unclean since it forces both evidence and CoRIM to have dummy mkey

{
  "environment": {
    "class": {
      "vendor": "ACME",
      "model": "HW Register Value"
    }
  },
  "measurements": [
    {
      "key": {
        "type": "string",
        "value": "Allowed value"
      },
      "value": {
        "raw-value": {
          "type": "bytes",
          "value": "AA=="
        }
      }
    },
    {
      "key": {
        "type": "string",
        "value": "Allowed value"
      },
      "value": {
        "raw-value": {
          "type": "bytes",
          "value": "AQ=="
        }
      }
    }
  ]
}

Option 4 (Same as Option 2 but using mkey in case Option 2 is disallowed)

{
  "environment": {
    "class": {
      "vendor": "ACME",
      "model": "HW Register Value"
    }
  },
  "measurements": [
    {
      "key": {
        "type": "string",
        "value": "Allowed value"
      },
      "value": {
        "raw-value": {
          "type": "bytes",
          "value": "AA=="
        }
      }
    }
  ]
}


{
  "environment": {
    "class": {
      "vendor": "ACME",
      "model": "HW Register Value"
    }
  },
  "measurements": [
    {
      "key": {
        "type": "string",
        "value": "Allowed value"
      },
      "value": {
        "raw-value": {
          "type": "bytes",
          "value": "AQ=="
        }
      }
    }
  ]
}

[yogeshbdeshpande]

@dkumar-nv

This time, the answer is simple and provided from the specification itself.

Option 1, in your choices is a perfectly valid option, see the Section 5.1.5 text below:

`The ref-claims in a reference-triple-record can contain one or more entries. This multiplicity can have different meanings:

• Each ref-claims entry can represent a different possible state of the Environment.
• Each ref-claims entry can represent a possible state of a different measured element (identified by its mkey) within the Environment.`

So one does not need an MKey, but can have multiplicity of Multiple reference state pertaining to an Environment.

Once you are satisfied, please close the issue!

[dhawalfs1]

Thanks @yogeshbdeshpande . Can you please also comment on the following from the spec which is what made me think that Option 1 is a violation of spec.
Two or more measurement-map entries within the same environment MUST populate mkey.

[yogeshbdeshpande]

@dhawalfs1 That is in context of MKey, when used. We will still correct or delete the text altogether to remove ambiguity