KeySet.import_key_set raises on an unknown kty, failing the whole set (RFC 7517 §5) #104

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.