Conditional endorsement series triple section reworded

[nedmsmith]

Added description to conditional series triple to address issues #310 and #321.
Updated example here to better illustrate a use case.

[deeglaze]

The ordering leads to negative conditions in the head of the rule still. The possible evaluation inconsistency from Issue #321 remains.

If the conditions are mutually-exclusive, then there's no need to order them and the triple is syntactic sugar for multiple normal conditions.
If the conditions are not mutually-exclusive, then you need a way to stratify condition matching to regain logical consistency.

Given that you haven't stated any condition, I don't know what your intention is here.

[nedmsmith]

Additional use case context: Some have characterized the triple as being an optimization of endorsement triples. The way to realize the same semantics using conditional-endorsement-triple is that there will be multiple valid RIMs containing statements about valid SVN ranges. A vendor may increment an SVN when a new image of security sensitive code is released, resulting in multiple valid RIMS in circulation. If at some later point one of the implementations is found to have a vulnerability, the affected RIM(s) can be revoked.

Nevertheless, there can be a range of RIMS that declare multiple valid SVN values. The RIMS could match the same component resulting in multiple ACS entries but with different matching reference SVN values.

The question then is how should these values be processed and by whom? Ideally, the best answer should be selected, because there will be additional endorsement statements that assert additional information based on SVN state. This approach distributes state across multiple RIMS resulting in multiple ACS entries that then needs to be post-processed to find the "best" correct answer.

Comparing this to the series triple. One RIM can be used to communicate the information that would otherwise be spread across in multiple RIMs and avoids adding, unnecessarily, multiple correct answers to the ACS that then need to be filtered in some way to find the best answer.

Any vendor that relies on SVNs to manage security change control will likely need this capability. If they don't proactively increment SVNs as part of their release process, then they will need to release / install updates that update the SVN. The alternative is they merely have to revoke an already issued RIM.

[thomas-fossati]

Though one to parse... I am not sure I get what you mean here. Is it that "each selected mkey MUST have the same corresponding set of mvals across all series-condition-record entries" ?

[deeglaze]

Say you have 3 measurement-map in a selection. One has no mkey with mval { 0: …}. One has mkey 1 with mval: { 1: …, 4: … } and one has mkey 2 with mval {0: …, 7: …}. That has to be the same selection structure for all selections in the series.

[thomas-fossati]

OK, surely L1188 needs unpacking. I suggest reorganising it this way:

1. make a short normative statement, followed by
2. an example

[deeglaze]

A B and C being the same across conditions would make only the first condition match if any do. You need to check that for all n > 0, for all m in cond[n].selection, there uniquely exists some m’ in cond[0].selection such that m’.mkey = m.mkey AND keys(m.mval) = keys(m’.mval).

[deeglaze]

Likewise every mkey in cond[0] must appear in later conds.

[nedmsmith]

The existing text says that selection matching is based on the results of the condition. That means the selection conditions are not searching ACS, rather they are searching the results of the condition match. The above explanation seems to assume selection matching is over ACS no?

[deeglaze]

Say your stateful environment record is [E, [mval: {1: min-svn(1)}, {mkey: 1, mval: {1: min-svn(2), 4: h'f00'}]]

You have have multiple ECTs that match E and these measurement-maps. You then need to narrow down.
[[{mval: {1: 10}}, {mkey: 1, mval: {1: min-svn(3), 4: h'f00'}}, some endorsements],
[{mval: {1: 9}}, {mkey: 1, mval: {1: min-svn(2), 4: h'f00'}}, some endorsements]].

We have the same mkeys. The first selection binds your A to {1: 10} and B to {1: min-svn(3), 4: h'f00'}. That makes the second in the series invalid, since {1: 9} != {1: 10}. This is why I restricted only to the keys of the mval.

[nedmsmith]

I made another editing pass. Is it OK?

[deeglaze]

"a selection" and "3 measurement-map statements" seems like the wrong way of describing it, since a list of measurement-map with the same mkey is ill-formed. You can only have one measurement-map with a specific mkey in a list of measurement-map.

I think you mean there are 3 conditional-series-record, and for each record, they have 1 measurement-map in their list each, and that measurement map has the same mkey, and an mval of the form you state below. That would be fine. It would also be fine for each record to have more than 1 measurement-map, such as

[[mkey: 0, mval: {A: _variable-X_, B: _variable-Y_, C: _variable-Z_ }], [mkey: 1, mval: {D: _variable-W_}]]

I don't think "mval contains" is appropriate either, since the first mval also contains "A=variable-X" without the closure. You need to state that mval contains exactly those 3 key/value pairs and no more.