Add ES256 and PS256 signing algorithm support

[zshenker]

Summary

The Common Access Token spec supports the ES256 and PS256 signing algorithms in addition to HS256. This PR adds both signing and verification for those two asymmetric algorithms. HS256 (HMAC-SHA256) behavior is unchanged.

Algorithm	COSE id	Structure	sign() key	verify() key
HmacSha256	5	COSE_Mac0	raw symmetric key	raw symmetric key
Es256	-7	COSE_Sign1	PKCS#8 DER private	SPKI DER public
Ps256	-37	COSE_Sign1	PKCS#8 DER private	SPKI DER public

Changes

• Algorithm enum (header.rs): adds Es256 / Ps256, updates identifier()/from_identifier(), adds an is_mac() helper to distinguish COSE_Mac0 from COSE_Sign1 algorithms.
• Crypto primitives (utils.rs) via RustCrypto (p256, rsa, sha2): ES256 is ECDSA P-256 + SHA-256 (deterministic RFC 6979, 64-byte r || s signatures); PS256 is RSASSA-PSS + SHA-256/MGF1 using OsRng for the salt (WASM-friendly via getrandom).
• Token wiring (token.rs): sign()/verify() dispatch per algorithm; asymmetric algorithms reuse the existing COSE_Sign1 input and emit CWT tag 61 + COSE_Sign1 tag 18.
• Key format: existing &[u8] API preserved — PKCS#8 DER private keys for signing, SPKI DER public keys for verifying. New Error::InvalidKey (error.rs) for malformed keys.
• Tests (tests.rs): 13 new tests — round-trip sign/verify, COSE_Sign1 tag bytes, wrong-key & cross-algorithm rejection, payload tampering, PSS salt randomization, invalid-key errors, and identifier round-trips.
• Docs/example: new examples/asymmetric_signing.rs, README signing-algorithms section, updated crate docs.
• Deps: bump thiserror to 2; bump rust-version to 1.72 (required by the RustCrypto crates). The crypto stack uses current stable RustCrypto versions (the newer 0.14/0.10 releases are pre-1.0 release candidates).

Verification

• cargo test — 42 lib tests + 73 doctests pass
• cargo clippy --all-targets — clean
• cargo fmt --check — clean
• cargo run --example asymmetric_signing — ES256 and PS256 both sign and verify

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR extends the Common Access Token crate to support asymmetric signing and verification using ES256 (P-256 ECDSA) and PS256 (RSA-PSS), in addition to the existing HS256 (HMAC-SHA256) support. It updates the algorithm model, token encoding/verification dispatch, cryptographic primitives, and adds tests/examples/docs to cover the new functionality.

Changes:

• Add Algorithm::{Es256, Ps256} (+ COSE identifiers) and use is_mac() to select COSE_Mac0 vs COSE_Sign1.
• Implement ES256/PS256 signing + verification utilities using RustCrypto (p256, rsa, sha2, rand_core).
• Add asymmetric round-trip tests and new examples/docs demonstrating key formats and COSE tags.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/utils.rs	Adds ES256/PS256 compute + verify helpers with PKCS#8/SPKI DER key parsing.
src/token.rs	Tags tokens as COSE_Mac0 (HS256) vs COSE_Sign1 (ES256/PS256) and dispatches sign/verify accordingly.
src/tests.rs	Adds asymmetric algorithm tests (round-trips, tag bytes, wrong-key, tampering, invalid-key errors).
src/header.rs	Extends Algorithm enum with identifiers and is_mac() helper.
src/constants.rs	Adds COSE algorithm identifier constants for ES256/PS256.
src/error.rs	Introduces Error::InvalidKey for malformed DER keys.
src/lib.rs	Updates crate-level docs to mention ES256/PS256 support.
README.md	Documents the new algorithms, key formats, and COSE_Sign1 usage.
examples/asymmetric_signing.rs	Adds an example of signing/verifying with ES256/PS256.
examples/sample_es256_ps256_tokens.rs	Adds an example to mint and print sample ES256/PS256 tokens.
Cargo.toml	Adds crypto dependencies and bumps rust-version / thiserror.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jedisct1]

Thanks for putting this together. I reviewed the PR description, the changed files, the existing review comments, the token/header/utils implementation around the diff, and the current CI results. This is an automated review by Swival (https://swival.dev) using only open-source models, intended to help both the PR author and the maintainers.

My recommendation is not to merge this yet.

The main blocker is that the PR advertises an MSRV that the dependency graph no longer satisfies. Cargo.toml:14 sets rust-version = "1.72.0", while Cargo.toml:24-30 adds the RustCrypto stack through p256, rsa, sha2, and rand_core. With Rust/Cargo 1.72.0 on this branch, cargo check fails before compiling this crate because the resolver selects zeroize v1.9.0, pulled through the new crypto dependencies, and that crate's manifest uses the 2024 edition, which Cargo 1.72 cannot parse.

I also verified that the branch does build and test successfully on the latest local toolchain, and cargo fmt --check plus cargo clippy --all-targets -- -D warnings pass there. That does not cover the compatibility contract in Cargo.toml, though. Since this is a library crate and Cargo.lock is not committed, downstream users building with the declared Rust version can hit the same dependency resolution failure. That makes the MSRV bump inaccurate and creates a real compatibility regression for users who rely on the crate metadata.

Before this merges, the PR should either constrain the new dependency graph so it actually builds with Rust 1.72, or raise rust-version to the real minimum supported compiler and make that intentional in the PR. If the project wants to keep the lower MSRV, a direct dependency constraint or a different crypto dependency choice may be needed, because simply having CI pass on latest stable does not prove the published crate is usable with its declared minimum.

I would keep the PR open because the core ES256 and PS256 direction appears plausible and the new tests exercise the main signing and verification paths. The compatibility issue above needs to be fixed first, and the existing comments about the embedded demo private keys in the examples are also worth addressing before merge, even though I see those as secondary to the MSRV regression.