cocli corim verify — x5chain + --root verification

[magickli1]

Hi,

corim-tool already supports verifying a signed CoRIM via the embedded COSE x5chain header and optional --root (README). cocli corim verify currently only documents --key (JWK).

I'm working on adding the same x5chain-based verification to cocli:

cocli corim verify --file signed-corim.cbor --root root-ca.der

--key would remain supported as an alternative, as in corim-tool.

Before I open a PR, I'd like to confirm:

1. Is this the expected direction for CLI parity with corim-tool?
2. For x5chain validation, is full PKIX path validation the expected approach (validity, CA/basic constraints, key usage, chain building to trusted roots)? Or should a lighter check (e.g. signature chain only) be sufficient?
3. Any preferences on --root flag naming or trust-store behavior (system roots + explicit --root)?
4. Should optional --crl support be included? (corim-tool does not have this yet.)

Happy to contribute if this aligns with the project's roadmap.

[thomas-fossati]

Hi @magickli1, this sounds like a useful feature to add to cocli.
Thanks for suggesting it!

Regarding your questions:

Is this the expected direction for CLI parity with corim-tool?

yes

For x5chain validation, is full PKIX path validation the expected approach (validity, CA/basic constraints, key usage, chain building to trusted roots)? Or should a lighter check (e.g. signature chain only) be sufficient?

The expected behaviour is full path validation (§6 of RFC5280).

Any preferences on --root flag naming or trust-store behavior (system roots + explicit --root)?

Rather than --root, which can be slightly ambiguous, I would call it --trust-anchors (noting it can be more than one, so the parameter value needs to be a list).
Semantically, it should be an override of the system's configured trust anchors: if the user does not supply the parameter, the system's default roots are used; otherwise, the custom roots supplied by the user are used.

Should optional --crl support be included? (corim-tool does not have this yet.)

Yes, that sounds like a good idea and is also in line with full RFC5280 compliance.

[magickli1]

Thanks @thomas-fossati for confirming the direction on CLI parity, PKIX scope, trust-anchor semantics, and CRL support.

Following your guidance, I'm implementing:

• RFC 5280 §6 core PKIX path validation on x5chain — signature chain, validity period, name & basic constraints, path-length — then COSE signature verification with the PKIX-validated leaf key. This is not a full §6 implementation: certificate-policy processing is out of scope, and revocation is opt-in (see --crl below).
• --trust-anchors (repeatable; DER or PEM): when omitted, the OS trust store is used; when supplied, only those anchors are trusted — they override the system store (no merge).
• Optional repeatable --crl for revocation checks on the verified chain. Caveat: when omitted — or a chain issuer has no matching CRL — revocation status is not checked (fail-open); this deviates from RFC 5280 §6.1.3(3)/§6.3, which requires determining revocation status.
• When both --key and x5chain-related flags are present, --key takes precedence.

Progress

• veraison/corim — library support in PR #276 (TrustAnchors, LoadTrustAnchors, SignedCorim.VerifyWithX5Chain).
• cocli — will open a follow-up PR after corim#276 merges, using --trust-anchors as you suggested.
• corim-tool — on upstream main today, corim verify documents --root (system store plus optional user roots); it does not yet expose --trust-anchors, --crl, or the override-only semantics you described. cocli will follow your naming and behaviour; corim-tool can align in a separate change if needed.

Migration (cocli draft users)

Before (local draft)	After (upstream PR)
--root	--trust-anchors
--system-roots	(removed) — omit --trust-anchors to use the system trust store

I'll open the cocli PR once corim#276 lands. Happy to adjust anything before then.