Matching a CoMID against a single attester or multiple attesters

[andrew-draper]

Verifier matching measurements from a single set of attestation environments

This issue uses the term Attestation Transport to describe the transport over which evidence was passed to the Verifier. A SPDM connection is an example of an Attestation Transport, it carries measurements from the SPDM Attestation Environment and from related DICE Attestation Environments within the same entity.

The simple use case for a Verifier is where it has received a set of measurements through a single Attestation Transport and it needs to match these against a CoMID tag containing reference values.

IMHO we should make the simple case easy to encode. I suggest that when matching a Reference Value Triple containing only environment-map and measurement-values-map, the Verifier must ensure that match them against evidence received from the same Attestation Transport. In some cases there may be multiple Attestation Environment groups which match against the same Reference Value Triple, if this happens then each group would receive an identical Endorsement.

For example, a CoMID tag encoding the semantics "If this device has a measurement identified by OID 1.2.3.4 and SHA-384 hash 0x5678 then the device is an Acme Ethernet Card version 1.0"

Verifier matching measurements from multiple attesters

Higher level Verifiers, or rather the CoRIMs controlling higher level Verifiers, will want to match against more complicated sets of evidence. For example, a CoRIM might want to encode the semantics Match against a type A PCIe card in slot 0, with firmware hash B, and against a second identical PCIe card in slot 1.

Do we need a way for a CoRIM to indicate that it must match against a set of evidence from one source (eg one Attestation Transport) and a potentially different set of evidence from a different source?

An example encoding of reference-values when matching against multiple Attestation Transports

I suggest that we use the mkey field to identify the attestor to be chosen.

For example, the following encoding encodes the two PCIe cards case above: Solution 1:

- Reference Value Triples
  - (first card)
    - Environment Map A
    - Measurement Map
      - mkey = K1
      - mvalue = B
  - (second card)
    - Environment Map A
    - Measurement Map
      - mkey = K2
      - mvalue = B

This would be associated with an Endorsement triple or similar providing more information about the combined system.

The exact values of K1 and K2 are not important, what is important is that all measurements with the same mkey value must come over the same Attestation Transport. Using the integer encoding of mkey normally produces the smallest encoding.

We might need a profile to enable this behavior.

I think this can be extended to multiple levels of compound devices, but wanted to get a sense of whether this is going in the right direction first.

Question

Is it going in the right direction?

[nedmsmith]

Attestation Transport - Is there a reason not to use RATS Arch term 'conveyance'? Conceptually they appear to be the same. Conveyance is not a formal term. Does it need to be? The RAT Arch also defines 'Target Environment' to refer to the various components that are measured and 'Attesting Environment' for the capability that collects these measurements. 'Attestation Environments' isn't defined by RATS Arch and it is upper case implying it needs formal definition. Would it be possible to describe the use case using these terms? I find the third paragraph difficult to follow since the reference values triple reference-value-triple-record is a tuple consisting of an environment-map and a measurement-map. Are you suggesting a change to the schema or commenting on how the matching algorithm is applied? The last sentence in the 3rd paragraph is confusing since this seems to be describing matching behavior for RVs and Evidence, but then segues into Endorsements without naming the triple(s) for which the matching behavior applies.

Regarding the "multiple attesters" topic. Use of mkey to disambiguate multiple instances of Target Environments that have the same measurements seems reasonable. However, if the mkey type is used for some other purpose, then overloading semantics on the same value could become problematic. For example $measured-element-type-choice /= uint is not CBOR tagged. If a Verifier implies that it is used to disambiguate Target Environments, and a different Verifier uses it for some other purpose then there isn't a way for the 2 verifiers to be combined into a generalized verifier. A profile could be used to select between the conflated behaviors, but a better approach might be to require CBOR tagging for $measured-element-type-choice definitions and require new use cases to define a new tag.

[deeglaze]

Is mkey assigned by the evidence reflection through the conveyance or the CoRIM issuer? I'm confused about the phase at which the mkey value is assigned. I've opened an issue about it here too https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/230

[nedmsmith]

An alternative approach is for the AE to add distinguishing values to the evidence set (i.e., add a (first card)/(second card) measurement to the set of claims-value-map (was: measurement-values-map).

This approach fits easily into the ECT (was: EMT) abstraction. The verifier can detect they are values from different component instances (and therefore can avoid conflating them as some sort of erroneous duplication). The reference values matching algorithm only cares about the subset of the evidence claims. Therefore, the (first card)/(second card) information is accepted under the authority of the AE but not under the authority of the RVP.

Assuming this approach makes sense, the representation of (first card)/(second card) etc... using class-values-map or an extension to it is needed next.

[deeglaze]

How do you represent the evidence of same transport? It would seem that the transport itself becomes the "lead attester", and thus you need an authority to associate with it, no?

[nedmsmith]

Another option is to assign an instance ID to each instance of a card in RVs and/or in Evidence. Environments can have both a class ID (e.g., A) and an instance ID (K1, K2). This eliminates the need for mkey. If cards are hot plugged, then RV Env only populates class-id and Evidence populates both Class-id and Instance-id. Option 2:

• Reference Value Triples
  • (first card)
  • Environment Map Class-ID=A, Instance-ID=K1
  • Measurement Map
    • mvalue = B
  • (second card)
  • Environment Map Class-ID=A, Instance-ID=K2
  • Measurement Map
    • mvalue = B

[nedmsmith]

How do you represent the evidence of same transport? It would seem that the transport itself becomes the "lead attester", and thus you need an authority to associate with it, no?

Tracking authority seems orthogonal to this issue. If Evidence isn't signed independently of the conveyance protocol, then the authority of the conveyance protocol is assumed (this is documented in RFC9334).

[deeglaze]

Another option is to assign an instance ID to each instance of a card in RVs and/or in Evidence. Environments can have both a class ID (e.g., A) and an instance ID (K1, K2). This eliminates the need for mkey. If cards are hot plugged, then RV Env only populates class-id and Evidence populates both Class-id and Instance-id. Option 2:

The same conveyance seems to mean a particular attestation session with these instances. I understand Andy's ask as referring to an abstract "same" session without having to name it. @andrew-draper Is that right? If so, I would recommend adding a $measured-element-type-choice alternative that is a session id unification variable. Every attestation verification request leads to a fresh mapping for unification variables. Once it matches, the variable always stands for the value it's bound to. (Think algorithm W)

[deeglaze]

The ECT ns field is pretty much unused in the draft, so that could be set to the session identifier when adding evidence to the ACS to act as an already assigned unification variable.