You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, we only support provisioning of TAs/EVs via unsigned CoRIMs. We should add support for handling Signed CoRIMs as well. Prior to extraction of TAs/EVs, the signature on the CoRIM should be verified, and the CoRIM should be rejected without further processing if the verification fails.
In order to verify the signature, services need access to the public counterpart of the signing key. These could be provisioned for every party with the provisioner role (perhaps tied to their login account), alternatively, the key can be included in the unprotected header of the COSE_Sign1 message, embedded in a certificate that chains back to a CA cert provisioned as part of the services deployment. The latter approach offers more flexibility and is simpler to implement (initially at least, we can forgo the management API for the keys).
We need to
Add support for processing signed CoRIMs
Verifying the signature of the signed CoRIM by
a. Extracting key certificate (and, optionally, intermediate certificates) from the unprotected header of COSE_Sign1 message.
b. Validating that certificate chains back to a known CA.
c. Using the associated key to verify the signature on the COSE_Sign1 message.
Initially, the CA cert(s) can be ingested from a file upon service initialization (similar to the attestation result signing key). In the future, he can add management REST API for managing CA certificates.
Note: embedding and later extraction of key certs from the message headers will require new API in the CoRIM library, and modifications to the cocli tool, tracked by issues veraison/corim#159 and veraison/cocli#32.
### Is your feature request related to a problem? Please describe
Support signature verification of CoRIM
The text was updated successfully, but these errors were encountered: