JWT::JWK::Set raises on an unknown `kty`, failing the whole set (RFC 7517 §5)

Aperta
  • Qualcosa non va?
#743 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
ruby
Ambito
backend, security

Direzione di ricerca

Read the JWT::JWK::Set construction path and its handling of unsupported key types, then add coverage for a JWKS containing both a recognized key and an unknown kty. Verify that the unknown member is ignored while the recognized key remains available for lookup and verification. The issue offers a reproduction harness, but does not name specific source or test files.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Building a JWT::JWK::Set from a JWKS that contains a key with an unrecognised kty raises JWT::JWKError: Key type AKP not supported, so the whole set fails. 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 with it.

Reproduction
require "jwt"
JWT::JWK::Set.new(mixed_jwks)   # RSA + one {"kty" => "AKP", ...} (ML-DSA, RFC 9964)
# JWT::JWKError: Key type AKP not supported

Measured against ruby-jwt 3.2.0. The set builds 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 ruby-jwt 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. In federated deployments that is an externally triggered outage.

Suggested fix

When constructing a JWT::JWK::Set, skip a member whose kty is unsupported (optionally surface it) rather than raising, so the recognised keys still load and remain usable for kid lookup. This implements the RFC section 5 SHOULD and leaves recognised keys unchanged.

Offer

Happy to share the reproduction harness (mixed classical + AKP JWKS plus a control) and to open a PR with the per-key skip and a test.

Lingua principale
Ruby
Stelle
3.7k
Fork
381
Merge medio
15h 15m
PR unite (30g)
12

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di jwt/ruby-jwt

Tutte le issue di jwt/ruby-jwt

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.