feat!: update library as per draft-ietf-rats-corim-11 and cca-endorsements-04 specs by shefali-kamal · Pull Request #21 · veraison/cover

shefali-kamal · 2026-09-04T10:35:48Z

This PR introduced below changes/updates:

Remove CE and CES as per cca-endorsements-04 spec:

Remove Conditional Endorsement (CE) and CE Series (CES) triple parsing, as they are not supported by the Arm CCA, only supported scheme as of now by Cover

Update library as per draft-ietf-rats-corim-11:

Refactor ECT structures by introducing CommonEct and renaming Ect to ElementEct. Ect now refers to enum representing all ect(s).
Add key-ect support and populate key relations from key triple records
Add support for inputting verfier-key and use it as authority for for key addition ect.
For unsigned corims, input verifier-key is used as authority.
Refactor evidence/reference-value measurement map conversion using From trait on ElementMap
Update CM-Type handling according to CoRIM spec revision 11. Supported only 3 types of cm-type now.
Add profile compatibility checks for input evidence formats
Validate CoRIMs and reject expired or unsupported profiles CoRIMs.
Added Unit tests for added functionality.
Update test data, with CCA required fields, and tests to ensure the complete test suite passes
Apply Rust formatting and Clippy fixes and bump dependencies to latest versions.

setrofim

Also, please update the commit message to be compliant with conventions commits:

Update(library): are not valid type/scope; should be just feat: (the scope is optional and can be omitted if the change is not local to a specific part).
Commit title should not end with a period.
Commits that break compatibility should have a ! following the type/scope (before the :), and should have a BREAKING CHANGE: footer explaining the nature of the change.

setrofim · 2026-09-04T11:00:37Z

+    }
    let result = verifier.verify(&args.scheme, evidence.as_slice(), nonce.as_deref())?;

-    debug!("ACS: {}", serde_json::to_string(&result.acs)?);


Why remove this?

My bad, deleted while removing other debugging statements. Will add it back.

setrofim · 2026-09-04T11:51:45Z

  based on an identifier inside the evidence. This is scheme-specific. For CCA, the instance ID
  is used. Evidence claims are then extracted as ECT (environment-claims tuple) records.
 - The evidence ECTs are then matched to the relations in the corim store. This results in the
-  ACS (appraisal claims set) -- a vector of ECT records containing evidence claims and matched


This is correct. -- in ASCII indicates an em-dash (rather than a hypen), which is what is intended here.

thomas-fossati · 2026-09-15T15:53:47Z

-                        }
-                    }
-                }
+        for kv in self.corims.iter_key() {


Q: why have we dropped the duplicate detection logic?

Now we are using Key-relation (K-ECT) to store attestation verification keys. as per draft-ydb-rats-cca-endorsements-04, each key-attest-triple must contain only one attestation verification key, so each condition key-ect will contain exactly one key corresponding to the instance and impl id.
So that is the reason we do not need to have duplicate detection logic. If a given key-item in the corim-store matches the environment, then we take first element of array (len always 1)

as per draft-ydb-rats-cca-endorsements-04, each key-attest-triple must contain only one attestation verification key, so each condition key-ect will contain exactly one key corresponding to the instance and impl id.

Where is this validated?

Also note that this is generic logic. You cannot assume anything CCA-specific here.

thomas-fossati · 2026-09-15T15:57:42Z

+        .map(|t| t.as_i128() as u64)
+        .unwrap_or(0);
+
+    let not_after = validity.not_after.as_i128() as u64;


I'm quasi sure that this wraps on overflow rather than generating an error.

Thanks for pointing out. I have updated the code.

thomas-fossati · 2026-09-15T16:02:39Z

 impl KeyStore for MemKeyStore {
    fn add(&mut self, kid: &[u8], key: &[u8]) -> Result<()> {
-        debug!("adding kid {:x?}", kid);
+        debug!("Key kid : \"{}\"", str::from_utf8(kid).unwrap());


unsure why do we need to change this in a panic-y way?

Also, please merge this and the following line into a single debug!, as they're logging the same operation.

Changed and updated into single statement.

thomas-fossati · 2026-09-15T16:10:21Z

+    // TODO:
+    // Implement realm evidence profile check here once rust-ccatoken is updated.
+    // This does not have any impact on end result, since all the current supported profiles by
+    // ccaguest and one specificed in draft-ydb-rats-cca-endorsements-04, produce same Evidence object.


to increase visibility, maybe translate this in an issue.

thomas-fossati · 2026-09-15T16:11:49Z

+    Ok(Ect::from(ect))
 }

 fn realm_to_ect<'a>(realm: &Realm) -> Result<Ect<'a>, Error> {


Question: where is the authority set?

My bad, it was missed. I have added now. Please review latest changes.

thomas-fossati · 2026-09-15T16:26:30Z

+        false
+    }
+
+    fn supports_corim(&self, corim: &Corim<'_>) -> Result<bool> {


it looks like we can remove Result<>

setrofim · 2026-09-15T12:22:15Z

    #[arg(name = "key", short, long, action = ArgAction::Append)]
    keys: Vec<String>,

+    /// Public key of Verifier/user of library in PEM format. This key is used as authority of attest/identiy key


Suggested change

/// Public key of Verifier/user of library in PEM format. This key is used as authority of attest/identiy key

/// Public key of Verifier/user of library in PEM format. This key is used as authority of attest/identity key

setrofim · 2026-09-15T12:25:51Z

+            corim_store.add(&parsed_corim)?;
+            corim_loaded = true;
+        } else {
+            info!(


This should be at least a warning as you're ignoring expressly provided input.

Thanks for suggestion. Changed to warn

setrofim · 2026-09-15T12:26:36Z

+                        corim_store.add(&parsed_corim)?;
+                        corim_loaded = true;
+                    } else {
+                        info!(


Again, should be at least a warning

setrofim · 2026-09-16T11:06:33Z

 impl KeyStore for MemKeyStore {
    fn add(&mut self, kid: &[u8], key: &[u8]) -> Result<()> {
-        debug!("adding kid {:x?}", kid);
+        debug!("Key kid : \"{}\"", str::from_utf8(kid).unwrap());


Also, please merge this and the following line into a single debug!, as they're logging the same operation.

… triple parsing, as they are not supported by the Arm CCA, only supported scheme as of now by Cover - Update README and lib.rs to remove obsolete CE Series triple parsing references - update dependencies and remove unsupported CE parsing - Fix Clippy redundant-reference warning with Clippy 0.1.97 - Update anyhow to 1.0.104 to address cargo-deny advisory warning Signed-off-by: Patel, Ajay Kumar <Ajaykumar.Patel@fujitsu.com>

…ments-04 spec - Refactor ECT structures by introducing CommonEct and renaming Ect to ElementEct. Ect now refers to enum representing all ect(s) - Add key-ect support and populate key relations from key triple records - Add support for inputting verfier-key and use it as authority for for key addition ect - For unsigned corims, input verifier-key is used as authority - Refactor evidence/reference-value measurement map conversion using From trait on ElementMap - Update CM-Type handling according to CoRIM spec revision 11. Supported only 3 types of cm-type now - Add profile compatibility checks for input evidence formats - Validate CoRIMs and reject expired or unsupported profiles CoRIMs - Added Unit tests for added functionality - Update test data, with CCA required fields, and tests to ensure the complete test suite passes - Apply Rust formatting and Clippy fixes and bump dependencies to latest versions Signed-off-by: Patel, Ajay Kumar <Ajaykumar.Patel@fujitsu.com>

- Updated `ccatoken` dependency to a newer revision - Upgraded `jsonwebtoken` to version 11.1.0 and refactored `authority.rs` to handle unknown algorithms and elliptic curves more gracefully - Modified `cca/mod.rs` to accommodate changes in platform and realm claims structures - Introduced new test data for CCA claims and tokens, replacing outdated files - Added a script to rebuild CCA tokens using the new claims structure - updated test cases to use updated ccatoken - improve logging and error handling - update attestation keys and its path BREAKING CHANGE: Legacy ccatoken with realm profile as empty string not supported. Realm token to ect tranformation now checks for realm profile explicitly. Signed-off-by: Patel, Ajay Kumar <Ajaykumar.Patel@fujitsu.com>

setrofim · 2026-09-25T15:17:54Z


 for name in "${corims[@]}"; do
 	echo "Rebuilding signed-corim-${name}.cbor..."
+	# echo "compile corim-${name}.json -o signed-corim-${name}.cbor --kid key.pub.pem --key key.priv.pem -f"


Remove commented out code.

setrofim · 2026-09-25T15:29:49Z

-                        }
-                    }
-                }
+        for kv in self.corims.iter_key() {


as per draft-ydb-rats-cca-endorsements-04, each key-attest-triple must contain only one attestation verification key, so each condition key-ect will contain exactly one key corresponding to the instance and impl id.

Where is this validated?

Also note that this is generic logic. You cannot assume anything CCA-specific here.

setrofim · 2026-09-25T15:37:58Z

+        if supported {
+            self.corims.add(&corim)
+        } else {
+            Ok(())


This should be an error -- you should not just silently ignore unrecognised inputs.

Also, this whole check should be moved into add_corim() above, and just call that here after parsing the bytes.

setrofim · 2026-09-25T15:50:20Z

+                return true;
+            }
+        }
+        info!("Unsupported profile \"{}\" ", corim_profile);


This should be a debug! -- it should be up to the caller how to handler unsupported profiles, e.g. report it to the user, return an error, etc.

setrofim · 2026-09-25T15:53:12Z

    );
    appraisal.update_status_from_trust_vector();

-    appraisal.policy_claims =


Why is this being removed? In the updated EAR this coresponds to verifier_claims.

setrofim · 2026-09-25T15:55:01Z

+        jwk::KeyAlgorithm::UNKNOWN_ALGORITHM => {
+            Err(Error::Custom(format!("Unknowm algorithm {}", alg)))
+        }
+        _ => todo!(),


Shouldn't leave todo!s on main. Return an "unsupported algorithm" error instead.

setrofim · 2026-09-25T15:55:09Z

        jwk::EllipticCurve::P384 => CoseEllipticCurve::P384,
        jwk::EllipticCurve::P521 => CoseEllipticCurve::P521,
        jwk::EllipticCurve::Ed25519 => CoseEllipticCurve::Ed25519,
+        _ => todo!(),


setrofim · 2026-09-25T16:18:53Z

-                Ok(result)
+pub fn parse_corim<'a, 'b>(
+    corim: &Corim<'a>,
+    key: &[u8],


Maybe call this corim_key or something, so it's a bit clearer why this needs bot a key and a verifier_key.

setrofim · 2026-09-25T16:21:20Z

-        }
+        // Get cryptographic key for signed corim,
+        // for unsigned corims, use verifier's cryptographic key
+        let key: Vec<u8> = match corim.as_signed_ref() {


As with the param name below, call this corim_key or something else more descriptive than just key, as there is also a verifier_key in this context.

setrofim · 2026-09-25T16:29:09Z

+    fn from_key_triple_record<T>(
+        k: &T,
+        profile: &Option<ProfileTypeChoice>,
+        verifier: &[CryptoKeyTypeChoice],


Rename to verifier_authority.

…A scheme attestation logic - Updated ccatoken and ear dependencies to their latest main branch revisions - Improved error handling across the authority, corim, and verifier modules, specifically within JWK to crypto key conversions (jwk_ec_curve_to_cose) - Modified the CCA scheme implementation to accept a list of trust-anchors and properly handle single attestation key requirements - Restored ear_verifier_claims and added policy IDs to appraisals - Updated test data to match the latest EAR specification naming conventions and standardized the use of cca-token-03.cbor across all tests - Refactored variable names for better readability and reduced scheme module logging verbosity from info to debug Signed-off-by: Patel, Ajay Kumar <Ajaykumar.Patel@fujitsu.com>

setrofim · 2026-10-07T10:03:33Z

Please could you update the rust-ccatoken dependency to latest.

anta5010 · 2026-10-07T10:11:29Z

Please could you update the rust-ccatoken dependency to latest.

These are the latest important changes you're missing:
veraison/rust-ccatoken@2a7a074
veraison/rust-ccatoken@636d70d

thomas-fossati

LGTM; I have left a few more comments inline.

thomas-fossati · 2026-10-08T09:19:01Z

-    // note: sect. 9.4.3 states authorities should be matched here, but it's not clear how given
-    // that evidence and reference/endorsement values obviously come from different sources...
-
    for cond_elt in condition.element_list.as_ref().unwrap() {


this unwrap looks slightly problematic because if there is no element list (as it's the case with EvRelation::from_endorsed_triple_record), it will panic.

Looks like we are missing a unit test for endorsed values :-)

thomas-fossati · 2026-10-08T09:26:38Z

-            }
-        }
-
        if let Some(akts) = &comid.triples.attest_key_triples {


identity key triples are not processed (which is OK, since Arm CCA has currently no use for them), but this should be expliclity documented as a limitation (e.g., in the README, and inline in lib.rs and main.rs)

I think it will be better to have parsing logic for identity-key triples as well. So that input corim-store can be populated with identity key triples as well.
And while fetching trust-anchor, based on key-type of condition key-ECT we can fetch key.

@thomas-fossati your opinion?

There are two reasons why I am a bit reluctant to suggest making this change:

Identity keys would not be used by the appraisal flows currently implemented;

There is ongoing work in the CoRIM draft to provide a precise description of key processing.

Therefore, I would avoid doing something that might need to change soon anyway due to "external forces" :-)

Okay. Then I will document it for now.

thomas-fossati · 2026-10-08T09:35:43Z


+    debug!("reading user/verfier key from \"{}\"", args.verifier_key);
+    let (_, verifier_key) = read_key(&args.verifier_key)?;
+    key_store.add("verifier-key".as_bytes(), &verifier_key)?;


hmm, I am bit confused. It looks like this makes "verifier-key" effectively a reserved kid?
what happens if a user passes --key verifier-key:mykey.pem? would the verifier silently overwrite it?

In any case, it looks like this should be surfaced to the user (documentation/warn on overwrite).

Yeah, "verifer-key" kid is explicitly used so that the same key can be fetched later when used. Since key-store does not have identifier for corim key or verifer-key, if verifer key is added with kid of the verifier key, then fetching it again for use will not be possible because we do not have information on the verifier key kid.

In the document, although instructions are to pass only the verifier-key path.
In the CLI document, will add one note that KID is ignored during key processing.

thomas-fossati · 2026-10-08T09:38:03Z

+            developer: "https://veraison-project.org".to_string(),
+        };
+        ear.raw_evidence = Some(CMW::Monad(Monad::new_media_type(
+            Mime::from_str("application/eat-cwt").unwrap(),


this shouldn't be hardcoded, I think.
can it be derived from Scheme::profile()?

This is not scheme specific, right?
This is defined by rfc9782 media-types which is not scheme specific (my understanding).
So, I dont see any other way to derive this information.

I am a little confused. ear.raw-evidence is the evidence submitted for appraisal. I would expect every appraisal scheme to be aware of its associated media type, no?

Are we sure that every appraisal scheme will use a CMW collection wrapper (like cca) for transporting evidence? I
if yes, then surely we can derive media-type from that. but follow up question is, can we use the media-type of cmw-record (envolop for ear.raw-evidence) and cmw-collection (envolop for evidence token) interchangeably?

thomas-fossati · 2026-10-08T09:51:07Z

+//!     "test/corim/signed-corim-cca-ref-plat.cbor",
+//!     "test/corim/signed-corim-cca-ref-realm.cbor",


just noticed: these files are gone now. this should reference the new files.

setrofim reviewed Sep 4, 2026

View reviewed changes

shefali-kamal changed the title ~~Update(library): update Update COVER library as per draft-ietf-rats-corim-11 spec.~~ feat: update Update COVER library as per draft-ietf-rats-corim-11 spec. Sep 7, 2026

shefali-kamal changed the title ~~feat: update Update COVER library as per draft-ietf-rats-corim-11 spec.~~ feat: Update COVER library as per draft-ietf-rats-corim-11 spec Sep 7, 2026

shefali-kamal changed the title ~~feat: Update COVER library as per draft-ietf-rats-corim-11 spec~~ feat: update library as per draft-ietf-rats-corim-11 spec Sep 7, 2026

shefali-kamal force-pushed the main branch from fe818dd to 6e8915b Compare September 7, 2026 16:08

shefali-kamal requested a review from setrofim September 15, 2026 06:03

shefali-kamal changed the title ~~feat: update library as per draft-ietf-rats-corim-11 spec~~ feat: update library as per draft-ietf-rats-corim-11 and cca-endorsements-04 specs Sep 15, 2026

thomas-fossati reviewed Sep 15, 2026

View reviewed changes

setrofim reviewed Sep 16, 2026

View reviewed changes

shefali-kamal force-pushed the main branch from 6e8915b to fbfa4c2 Compare September 18, 2026 14:38

shefali-kamal changed the title ~~feat: update library as per draft-ietf-rats-corim-11 and cca-endorsements-04 specs~~ feat!: update library as per draft-ietf-rats-corim-11 and cca-endorsements-04 specs Sep 21, 2026

shefali-kamal requested review from setrofim and thomas-fossati September 22, 2026 09:18

ajay-fuji added 3 commits September 23, 2026 13:07

shefali-kamal force-pushed the main branch from fbfa4c2 to c6b5f35 Compare September 23, 2026 08:05

setrofim reviewed Sep 25, 2026

View reviewed changes

thomas-fossati reviewed Oct 8, 2026

View reviewed changes

	/// Public key of Verifier/user of library in PEM format. This key is used as authority of attest/identiy key
	/// Public key of Verifier/user of library in PEM format. This key is used as authority of attest/identity key

		//! "test/corim/signed-corim-cca-ref-plat.cbor",
		//! "test/corim/signed-corim-cca-ref-realm.cbor",

Conversation

shefali-kamal commented Sep 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Remove CE and CES as per cca-endorsements-04 spec:

Update library as per draft-ietf-rats-corim-11:

Uh oh!

setrofim left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ajay-fuji Sep 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

shefali-kamal commented Sep 4, 2026 •

edited

Loading

ajay-fuji Sep 21, 2026 •

edited

Loading