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

Abierto
  • ¿Algo no está bien?
#743 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
ruby
Área
backend, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Ruby
Estrellas
3.7k
Forks
381
Merge medio
19 h 13 min
PR fusionados (30 d)
8

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de jwt/ruby-jwt

Todos los issues de jwt/ruby-jwt

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.