Account for multiplicity in conditional endorsements

[deeglaze]

A conditional endorsement series is about a target environment plus additional state expectations that lead to further endorsements.

I removed the undefined CBOR tag around multiple measuremnt-maps since array and map have different CBOR major tags and a custom tag is not required.

[yogeshbdeshpande]

Suggested change

	endv: [ + mkeyvalue-pair ]
	endv: [ + measurement-map]

[deeglaze]

We don't want to have authorized-by in the endorsed values, since it is not meaningful here.

[yogeshbdeshpande]

It is not true, Endorsements or Reference Values, all should support Authority!

[deeglaze]

No, authority in a measurement-map in a CoRIM represents a condition. Authority in a measurement-map in an ECT represents actual authorities that signed the information. For any added measurement, the only authority is the CoRIM issuer. Given that the triple has already given two other positions for stating an authority condition, it doesn't make sense for the endv to have its own conditionality semantics.

[yogeshbdeshpande]

I understand your point, however, this has a deeper implications.

By not providing a source of Authority for Added Endorsements in the triple, has implications.

It means the supplier of Endorsements has to have an implicit authority of CoRIM Signer.

It cannot inherit the Authority from RefValue provider Authority as they may not be the same!

Which implies, that for a Env with ClassID : X, with FW running from Authority coming from FW Supplier PQR (in RefVal), the Test House is vouching for its Endorsements.

It is fine to have CoRIM as a single source of Authority in this case, in most of the cases, so we can start with that.

I was thinking as Authority is optional retaining it will provide, the flexibility to introduce endorsements coming from different authority, For an Environement, like for FW Element -1 : Authority X, FW Element 2: Authority Y

[deeglaze]

The only integrity protection you can ensure is who signed the information. #244 affirms that authorized-by is a condition, and not part of an addition. If it's not part of the condition and is actual addition, we need to have a triple signed by the delegate that the CoRIM issuer is authorized to sign on its behalf. I don't think we should do that though. You generally do that with PKI certificate paths.

Please express your example in terms of the conditional series triple so I may understand.

[yogeshbdeshpande]

We agreed with Ned's PR that is optionality is not required!

[yogeshbdeshpande]

@deeglaze Some more work needs to be done! Also, I already floated PR #276 , please have a look and comment. I am happy to fold this one on PR #276 and proceed with just one copy rather than multiple identical intent PR's

[nedmsmith]

Is there an issue that this PR links to so that reviewers can know the problem statement that motivates this PR?

If we think there are use cases that can't be supported by the current triple it would be helpful to characterize them.

If the goal is to create a series triple that is more generalized, then we should start with the internal representation.

evs = [
  condition: [ + ECT ]
  series: + {
    selection: [ + ECT ]
    addition: [ + ECT ]
  }
]

Since the ECT can be mapped to the external representation readily, the CDDL for a revised series triple should be relatively straight forward.

[yogeshbdeshpande]

issue #288 tracks the discussion!