Summary
JWKSet.import_keyset() raises InvalidJWKValue when any key in the set has a kty it does not recognise, so the entire set fails to import. Per RFC 7517 section 5 an unrecognised key should be ignored, not fatal, so one post-quantum key in a published JWKS takes down the classical keys with it.
Reproduction
A JWK Set with a classical RSA key, an EC key, and one post-quantum ML-DSA key (kty: "AKP", RFC 9964):
from jwcrypto.jwk import JWKSet
JWKSet.from_json(mixed_jwks) # or JWKSet().import_keyset(mixed_jwks)
# jwcrypto.jwk.InvalidJWKValue
Measured against jwcrypto 1.5.8. The set imports fine once the AKP key is removed. Fixture and probe available on request.
Why this matters
RFC 7517 section 5: "Implementations SHOULD ignore JWKs within a JWK Set that use kty values that are not understood by them." ML-DSA (FIPS 204 / RFC 9964, kty: "AKP") is starting to appear in published key sets as post-quantum migration begins. When an issuer adds one to a JWKS that jwcrypto consumers read, those consumers stop verifying every signature from that issuer, including classical RS256/ES256, on a spec-compliant key publication they do not control. jwcrypto is widely used in enterprise and identity Python stacks, so the blast radius is significant.
Suggested fix
In import_keyset, skip a member whose kty is not recognised (optionally warn) rather than raising InvalidJWKValue, so the rest of the set still loads. This implements the RFC section 5 SHOULD and leaves recognised keys unchanged. A lenient default matches the RFC; a strict opt-in could be retained for callers who want it.
Offer
Happy to share the reproduction harness (mixed classical + AKP JWKS plus a control) and to open a PR with the per-key tolerance and a test.
Summary
JWKSet.import_keyset()raisesInvalidJWKValuewhen any key in the set has aktyit does not recognise, so the entire set fails to import. Per RFC 7517 section 5 an unrecognised key should be ignored, not fatal, so one post-quantum key in a published JWKS takes down the classical keys with it.Reproduction
A JWK Set with a classical RSA key, an EC key, and one post-quantum ML-DSA key (
kty: "AKP", RFC 9964):Measured against jwcrypto 1.5.8. The set imports fine once the AKP key is removed. Fixture and probe available on request.
Why this matters
RFC 7517 section 5: "Implementations SHOULD ignore JWKs within a JWK Set that use
ktyvalues that are not understood by them." ML-DSA (FIPS 204 / RFC 9964,kty: "AKP") is starting to appear in published key sets as post-quantum migration begins. When an issuer adds one to a JWKS that jwcrypto consumers read, those consumers stop verifying every signature from that issuer, including classical RS256/ES256, on a spec-compliant key publication they do not control. jwcrypto is widely used in enterprise and identity Python stacks, so the blast radius is significant.Suggested fix
In
import_keyset, skip a member whosektyis not recognised (optionally warn) rather than raisingInvalidJWKValue, so the rest of the set still loads. This implements the RFC section 5 SHOULD and leaves recognised keys unchanged. A lenient default matches the RFC; a strict opt-in could be retained for callers who want it.Offer
Happy to share the reproduction harness (mixed classical + AKP JWKS plus a control) and to open a PR with the per-key tolerance and a test.