Update to latest corim-store plus fixes#416
Conversation
- Up the required go version 1.26 due to it being required by the latest corim-store. - Use the new corim-store API to implement CoSERV handling. - Switching to using AddBytes instead of AddCorim inside SubmitEndorsements so that the raw token bytes are added to the store alongside the parsed CoRIM. Store configuration is also updated to allow adding signed CoRIMs without signature verification (as they have already been verified prior to adding them to the store). - Update not-after in integration-tests CoRIM to be in the future, as validity is now being considered when retrieving endorsements. Signed-off-by: Sergei Trofimov <sergei.trofimov@arm.com>
setrofim
force-pushed
the
setrofim/store-update
branch
2 times, most recently
from
a78f5b7 to
627ddb3
Compare
Update AppraiseClaims to expect the new endorsements format introduced in d4c39f7. Also update expected results in integration tests to expect "affirming" for realm. They were originally "warning" because all schemes were tested using the same end-to-end test that could only provision one CoRIM, and so only platform endorsements were provisioned. We have since switched CCA to use its own flow that provisions both platform and realm endorsements. The fact that we were still expecting "warning" partially obscured the other issue being fixed here. Signed-off-by: Sergei Trofimov <sergei.trofimov@arm.com>
setrofim
force-pushed
the
setrofim/store-update
branch
from
627ddb3 to
892f8af
Compare
| refVal.PersonalizationValue, err = measurement.Val.RawValue.GetBytes() | ||
| switch mkey { | ||
| case cca.CCARealmInitialMeasurementMkey: | ||
| digest, err := readMeasurementDigestBytes(&measurement) |
There was a problem hiding this comment.
Just wondering, we are reading via readMeasurementDigestBytes(),
we should also check the allowed Digest Algorithm for CCA, as ONLY three values are allowed.
cca-realm-measurement-type = bytes .size 32 / bytes .size 48 / bytes .size 64
There was a problem hiding this comment.
But this has no bearing on verification algorithm. This has already been validated by the profile-validation when the CoRIM was originally added. Here, we only care whether digests match the evidence. Structural validity of CoRIMs and evidence tokens is validated elsewhere.
There was a problem hiding this comment.
Sure, I wanted to check, whether when storing CoRIMs in the store this aspect has been validated or not???
There was a problem hiding this comment.
Yes, this is validated by the profile-specific validation code.
| } | ||
|
|
||
| func allMatch(lhs, rhs [][]byte) bool { | ||
| if len(lhs) != len(rhs) { |
There was a problem hiding this comment.
Orthogonal to this code review, something to remember is the case when len (lhs) can be > than len(rhs) which we should allow, but the reverse should be a failure!! Here I assume rhs is reference and lhs is Evidence
4 participants
corim-store, switching to it to handle CoSERV