Skip to content

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

Description

@RalphBragg

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions