-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modelling Supply Chain Updates to existing Reference Values or Endorsements #171
Comments
@nedmsmith @henkbirkholz @thomas-fossati @andrew-draper Lets brainstorm the Issue and associated PR during IETF 118 Hackathon |
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 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). |
Continuing the x-triples options thread from #170. 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. |
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. 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 |
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 EnvironmentEndorsed 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 aseries 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:
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: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
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:
Existing Supply Chain methods, will NOT be able to move to CoRIM, if they do not find the specification "fit for purpose"
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 (#170) Models a flexible method of
"Modelling an Update story", which encompasses both the requirements from 1. and 2. above.
The text was updated successfully, but these errors were encountered: