Modelling Supply Chain Updates to existing Reference Values or Endorsements

[yogeshbdeshpande]

Lifecycle of Triples

CoRIM design is based on how fundamentally a Statement from Supply Chain is modelled using Triples

• Reference Value Triples model Reference Values pertaining to Target Environment

• Endorsed Value Triple model Endorsed Values pertaining to a Target Environment

• There are Identity and AE Triples which link keys that are associated to the Device Identity or the Attesting Environment

• Endorsed Values can also be pertaining to a Stateful Environment which is essentially an Environment with a known state [example, Firmware Component Environment running a specific revision of Firmware]

• Conditional Endorsements are fundamentally a series of Endorsements that are applicable when a series of stateful environments match received from Evidence against the Verifier Data (Received from Supply Chain)

• A Supply Chain may want to make an authoritative statement with a series of stateful environments (this is essentially a product revision) to which a set of Endorsements may be applicable.

One can distil the Subject of Triples to be one of the following:

1. A Target Environment
2. An Attesting Environment
3. An Array of Environments ==> Note one can model this using a Domain Membership/Dependency as a subject or
4. A Stateful Target Environment
5. A Series/Array of Stateful Target Environments

Update story

When modelling an Update story, The Sea of Triples pertaining to a specific subject (identified here as sub can be updated, meaning new statements about the same subject sub can be issued to a Verifier. The New Statement can have two effects in a Verifier:

1. It replaces the existing statement (previously issued), i.e. New Statement B overwrites Statement A issued previously.

If the Supply Chain wants to retain the old predicates/objects (issued via A) in a Verifier, it re-issues the same predicates/objects in Statement - B

OR

2. The new Statement updates (adds) to the existing statement (previously issued). Supply Chain just issues an incremental change in the object pertaining to the subject identified by subj

i.e. Now the Verifier has a two valid statements A and B and both are applicable during Evidence Appraisal

While both 1. and 2. are valid and acceptable ways of modelling an Update Story, the CoRIM specification should NOT mandate only one method.

The reason been:

1. Existing Supply Chain methods, will NOT be able to move to CoRIM, if they do not find the specification "fit for purpose"

2. Specification should be flexible to allow Supply Chain Actors to Model Update story based on their specific use case requirements

Taking the above facts into consideration, the Pull Request (https://github.com/ietf-rats-wg/draft-ietf-rats-corim/pull/170) Models a flexible method of "Modelling an Update story", which encompasses both the requirements from 1. and 2. above.

[yogeshbdeshpande]

@nedmsmith @henkbirkholz @thomas-fossati @andrew-draper

Lets brainstorm the Issue and associated PR during IETF 118 Hackathon

[nedmsmith]

The staging of when an x-triple is applied can be resolved IMHO without knowing the specific details of the x-triple. Consider x-corim as a form of update (where to-be-updated triples are in a previously issued corim and their replacement triples are in a new corim). Processing of the x-corim happens as part of a corim selection stage (before appraisal stages). Can we agree that x-triple processing should apply before appraisal stages?

Note: It is reasonable to consider an update story applied at the tag level. I'll use x-tag to refer to this idea for the purposes of this discussion. An x-tag might contain triples that are to be discarded and a new tag containing replacement triples. Since this approach is applied at the tag level, it likely occurs after CoBOM extraction and before Evidence Collection.

Given the most current expression of reference values and endorsed values should be available at the time Evidence Collection happens, it seems reasonable that x-triples (as well as x-tags and x-corims) should be processed before Evidence Collection (or just after, at the latest).

[nedmsmith]

Continuing the x-triples options thread from #170. Endorsed Value we have two options: (option-a) Specify what is to be updated by specifying selection criteria as a type value - e.g.; RefVal/EndVal/CondEnd as the Subject of a triple. (option-b) Specify what is to be updated by re-issuing the triple (like RefVal Triple) OR an EndVal Triple with different triples expressions. Note: In both cases, there can be two forms of "update", ADD or a REPLACE semantics.

I suggest we discuss ADD and REPLACE semantics separately first, then consider if it makes sense to combine them. In all 3 forms (x-corim, x-tag, x-triple), ADD semantics augments existing triples. All 3 forms require context that ensures the added triples are added to the right grouping. In x-corim, the to-be-replaced corim sets the context. The new corim should have the same tags and groups as the to-be-augmented corim. In x-tag, the to-be-replaced tag sets the context. The new tag should have the same triples and groups as the to-be-augmented tag. The new triples are added based on matching contexts. In x-triple, the to-be-replaced triple needs to include grouping context, otherwise, the augmentation could be misapplied (for example, when there are multiple instances of the same triple given multiple components).

I don't think Option-a and Option-b are significantly different. Option-a includes matching criteria (much like conditional endorsement triples) in a triple subject that is applied to existing triples and the triple object (augmented triples) are appended to the grouping. Option-b doesn't include matching criteria as a triple subject. Rather the grouping context is used to identify and remove existing triples that are replaced by the new triples containing both the old and augmentation triples. In effect, the selection criteria is: "if the to-be-augmented triples are a subset of the new triples then replace all triples with the new triples". Option-a seems to allow finer granularity selection criteria where only a subset of the to-be-augmented triples need match. To make option-b have equivalent semantics it would require tweaking that somehow adds this granularity.

In all cases, x-corim, x-tag, x-triple-option-a, x-triple-option-b; the end result is the same. The substantive differences impact suppliers' authoring tools (which likely obfuscate the differences). and the verifier community, which needs to support the various approaches. (or rely on profiles to trim the various approaches).

REPLACE semantics means the new triples modify the existing triples. For x-corim and x-tag, REPLACE works identically as for ADD. The difference is there are no augmentation triples in the set of new triples. For x-triple, option-a, the selection criteria (triple subject) contain the to-be-replaced triples (including grouping context) and the object contains the new triples (with identical grouping context). For option-b, the grouping context identifies which triples to replace, and the new triples overwrite the old triples (that have the same grouping context).

Given tooling for REPLACE, ADD can be implemented by including the triples that don't change into the replacement image.

Given x-corim or x-tag, the grouping context is the same for both x- and non-x statements. The overlapping context serves as the selection criteria. The new corim / tag contains the REPLACED/ADDED triples.

[andrew-draper]

My view on this is that we need to define what is the unit of processing, ie which group of triples are processed together to perform an action. We need to provide CoRIM authors with a way to replace the whole unit of processing.

For some triples this is obvious, Conditional Endorsement Triple can be replaced on its own. If the replacement is applied then

But there are some places where the verifier must process multiple triples together. In those cases replacing one triple could leave the verifier open to attack if the attacker controls which CoRIM files the verifier is allowed to see.

Finally, I don't think we have agreed on the sea of triples approach to the Attestation Context yet, IMHO we should work on that before looking at x- triples