Summary
KeySet.import_key_set() raises InvalidKeyTypeError on the first key whose kty is not in the registry, so the entire key 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 verification of the classical keys alongside it.
Reproduction
A JWK Set with a classical key and one key whose kty is not recognised (for example a post-quantum ML-DSA key, kty: "AKP", RFC 9964, on a build without AKP support):
from joserfc.jwk import KeySet
KeySet.import_key_set({"keys": [
{"kty": "AKP", "alg": "ML-DSA-65", "pub": "AAAA"},
{"kty": "oct", "k": "MDEyMzQ1Njc4OWFiY2RlZg", "kid": "classical"},
]})
# joserfc.errors.InvalidKeyTypeError: invalid_key_type: Invalid key type: 'AKP'
The set imports fine once the unknown key is removed.
Why this matters
RFC 7517 Section 5: "Implementations SHOULD ignore JWKs within a JWK Set that use 'kty' (key type) values that are not understood by them." As post-quantum keys (ML-DSA, RFC 9964) begin appearing in published key sets, a consumer on the current behaviour stops verifying every signature from that issuer, including the classical ones, the moment such a key is published. In federated deployments (OpenID Connect, open banking) that is an externally triggered outage.
Suggested fix
In import_key_set, skip a key whose kty is present but not in the registry, per RFC 7517 Section 5, leaving recognised-but-malformed keys to raise as before.
Fix
I have opened #103 with this change plus a regression test. Happy to adjust.
Summary
KeySet.import_key_set()raisesInvalidKeyTypeErroron the first key whosektyis not in the registry, so the entire key 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 verification of the classical keys alongside it.Reproduction
A JWK Set with a classical key and one key whose
ktyis not recognised (for example a post-quantum ML-DSA key,kty: "AKP", RFC 9964, on a build without AKP support):The set imports fine once the unknown key is removed.
Why this matters
RFC 7517 Section 5: "Implementations SHOULD ignore JWKs within a JWK Set that use 'kty' (key type) values that are not understood by them." As post-quantum keys (ML-DSA, RFC 9964) begin appearing in published key sets, a consumer on the current behaviour stops verifying every signature from that issuer, including the classical ones, the moment such a key is published. In federated deployments (OpenID Connect, open banking) that is an externally triggered outage.
Suggested fix
In
import_key_set, skip a key whosektyis present but not in the registry, per RFC 7517 Section 5, leaving recognised-but-malformed keys to raise as before.Fix
I have opened #103 with this change plus a regression test. Happy to adjust.