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.