Skip to content

Restore crypto.Signer for foreign JWS (HSM/KMS)

Latest
Latest

Choose a tag to compare

View all tags
@yaronf yaronf released this 02 Oct 10:11
· 5 commits to main since this release
v0.6.2
92de25a

Summary

Additive compatibility restore for foreign JWS (native signers/verifiers unchanged). Builds on v0.6.1.

Highlights

  • crypto.Signer (HSM/KMS) accepted again for foreign JWS RSA / ECDSA / Ed25519 / ML-DSA on both NewJWSSigner and NewJWSVerifierWithAlg.
  • Validation uses Public() shape + existing curve / ML-DSA parameter-set checks; panics from Public() are recovered as construction errors.
  • ML-DSA note: default jwx still signs only with *mldsa.PrivateKey. Opaque ML-DSA Signers need a custom jws.RegisterSigner. ML-DSA stays foreign-JWS only (not a native RFC 9421 algorithm).
  • JWK still rejected in raw constructors (NewJWSSignerFromJWK / preferred NewJWSVerifier).

Upgrade from v0.6.1

You use Action
Native only / raw stdlib JWS keys No change.
Opaque crypto.Signer for RS*/PS*/ES*/EdDSA Works again (was rejected at construction in v0.6.0–v0.6.1).
Opaque crypto.Signer for ML-DSA Construction accepted; register a custom jwx ML-DSA signer for Sign, or keep using raw *mldsa.PrivateKey.
JWK in NewJWSSigner Unchanged — use NewJWSSignerFromJWK.

Backward compatibility

This partially rolls back v0.6’s “raw stdlib only” foreign-JWS key policy. Callers already using raw keys are unaffected. Same caveat as jwx: external crypto.Signer makes alg/key misuse harder to catch than in-process stdlib types.

Fixes #34.

Thanks to @ilya-korotya for reporting the regression and for the draft fix in #35.

Full notes: internal-docs/RELEASE-v0.6.2.md.

Assets 2
Loading