[dcondrey]

Problem

coset has no first-class support for the x5chain header parameter (RFC 9360, IANA label 33), which carries a signer-first chain of DER-encoded X.509 certificates. Consumers that need it (e.g. CoseSign1 verifiers) currently have to read/write it manually via Header.rest / HeaderBuilder::value(33, ...).

Fix

Adds a new X5Chain type (AsCborValue-based, matching RFC 9360's COSE_X509 = bstr / [ 2* bstr ] CDDL: a single certificate encodes as a bare bstr, two or more as an array, signer-first) plus Header::x5chain(&self) -> Result<Option<X5Chain>> and HeaderBuilder::x5chain(self, chain) -> Self.

This mirrors the crate's existing pattern for non-core registered parameters: CoseKey::to_sec1_octet_string() / CoseKeyBuilder::new_ec2_pub_key_sec1_octet_string(), which read/write typed values out of the generic params/rest bag rather than promoting them to dedicated struct fields. Keeping x5chain in rest (rather than adding a new Header field) keeps this purely additive: no breaking change to Header's public fields, no change to decode behavior for other header parameters, and the existing duplicate-label detection on rest already guards against also setting label 33 via the raw .value() escape hatch.

Scope: this is "Layer 1" (header parsing) from the proposal in #129 by @magickli. Basic shape validation is included (non-empty chain, non-empty per-certificate DER, CDDL-correct bstr/array selection); no size/count limits beyond what RFC 9360 itself states, and no PKIX/CRL/crypto verification ("Layer 2" from the issue), which is out of scope for this crate's types-first design and left for the maintainers to decide where it should live.

Addresses #129 (narrower than the full issue: Layer 1 only, as the issue itself proposes splitting out).

Testing

• cargo test (default features), cargo test --all-features, cargo test --features=std: pass, 133/133
• cargo clippy --all-features --all-targets -- -Dwarnings: clean
• cargo fmt --all -- --check (current nightly toolchain; CI pins nightly-2025-04-01, not available locally): clean
• RUSTDOCFLAGS="-Dwarnings" cargo doc --no-deps --document-private-items: clean
• cargo build --release --target thumbv6m-none-eabi (no_std): clean
• cargo +1.82.0 build --release --all-features (MSRV is 1.81; the 1.81 toolchain wasn't available locally, 1.82 was): clean

CHANGELOG.md is left untouched; this repo's history shows it's only updated in dedicated "Prep for release" commits, not individual feature PRs.

[daviddrysdale]

Thanks for this, looks good other than the very minor things mentioned.

I'm no longer at Google so I can't run workflows or merge. @landiwiese ?

[landiwiese]

I was able to successfully run the approval workflow and I can approve once David's comments are addressed. Thank you!

[dcondrey]

Comment have been resolved.

[landiwiese]

@daviddrysdale Let me know if the updates look good to you then I'll approve.

[daviddrysdale]

LGTM