[Feature Request / Contribution Proposal] x5chain header helpers for Header / HeaderBuilder #129

Hi, and thanks for coset — it's been solid for COSE encode/decode.

Any CoseSign1 consumer that embeds signing certificates in the x5chain header (RFC 9360, label 33) currently has to read/write the value manually via Header.rest / value(...), even though iana::HeaderParameter::X5Chain is already defined.

For example, a typical verify flow needs to:

1. parse the header CBOR into an ordered certificate chain (leaf first; intermediates as concatenated DER);
2. validate that chain against trust anchors, optionally check CRLs, then verify the COSE signature with the validated leaf key.

Step (1) looks like a natural fit for coset; step (2) may not, given the crate's types-first / no_std-friendly design. I'm working on this for corim-rs#56 and would like maintainer input on scope before opening a PR.

My proposal is to split the work:

Layer 1 (header parsing) — add typed x5chain helpers on Header / builders: decode/encode the RFC 9360 wire shape, basic shape checks (non-empty chain, size/count limits, DER concatenation rules), but no PKIX, CRL, or crypto backend.

// on Header / HeaderBuilder
fn x5chain(&self) -> Result<Option<X5Chain>, CoseError>;
fn x5chain(self, chain: X5Chain) -> Self;

impl X5Chain {
    fn from_cbor_value(v: &Value) -> Result<Self, CoseError>;
    fn to_cbor_value(&self) -> Value;
    fn certificates(&self) -> &[Vec<u8>]; // DER, leaf first
}

Layer 2 (PKIX trust verification) — CoseSign1::verify_with_x5chain and PKIX/CRL checks need an X.509/crypto stack. That could be an optional coset feature, a companion crate, or left to callers. I have a prototype in corim-rs (feature = "openssl"), but I'm not asking to merge it as-is.

What do you think — should Layer 1 live in coset, and where would you prefer Layer 2? If Layer 1 sounds reasonable, I'm happy to send a PR for that first.