Resumen

  • Una JWS debe rechazarse cuando su encabezado protegido crit nombra una extensión que el verificador no entiende y admite, aun si la firma coincide.
  • El mecanismo permite evolucionar JOSE sin que un receptor antiguo aplique en silencio las reglas anteriores a un mensaje cuyo significado ha cambiado.
  • La comprobación matemática, el procesamiento semántico y la decisión de uso pertenecen a capas diferentes y necesitan resultados separados.

Dos sistemas verifican los mismos bytes

Pensemos en dos servicios que reciben exactamente la misma JWS. Ambos conocen la clave, aceptan el algoritmo y reconstruyen correctamente la entrada firmada. En los dos, la operación criptográfica termina con éxito. El primero, sin embargo, entiende una extensión anunciada como crítica; el segundo nunca la implementó. Solo el primero puede declarar válida la JWS.

La diferencia no es una preferencia local escondida. Está inscrita en el encabezado protegido. crit contiene nombres de parámetros de extensión presentes en el encabezado JOSE. El destinatario debe comprender y soportar cada uno. Si no puede hacerlo, la RFC 7515 le exige considerar inválido el objeto. No puede conservar el resultado de la firma, ignorar el parámetro y seguir con la interpretación conocida.

La lista está sometida a condiciones precisas. No puede estar vacía, repetir nombres ni mencionar un parámetro que no aparece. Tampoco sirve para enumerar los campos ya definidos por JWS y JWA: su finalidad son las extensiones. Solo puede aparecer en el encabezado protegido, pues permitir que un intermediario altere la lista sin romper la firma anularía su función.

Un parámetro desconocido que no figure en crit suele poder ignorarse. Ahí reside el equilibrio. Los metadatos opcionales no paralizan el ecosistema. En cambio, aquello que altera la manera necesaria de construir, leer o validar el mensaje obliga a una decisión explícita de compatibilidad.

La aportación no fue un campo más

Nat Sakimura comparte la autoría de la RFC 7515 con Michael B. Jones y John Bradley. Su trabajo en estándares de identidad y en la OpenID Foundation se desarrolla en un entorno donde un formato atraviesa navegadores, bibliotecas, proveedores, gateways y aplicaciones durante muchos años. Atribuirle en solitario el diseño sería incorrecto; observar el problema institucional que resolvió la obra conjunta resulta más útil.

Una extensión futura no puede confiar en que todos los receptores se actualicen a la vez. Tampoco puede aceptar que los antiguos den por válido un mensaje bajo reglas que ya no corresponden. crit establece una especie de control de capacidad dentro de la propia evidencia: el emisor declara qué conocimientos son indispensables y el receptor solo continúa si dispone de ellos.

Eso no convierte la lista en una etiqueta de peligro. Una extensión puede ser importante para una implementación y, aun así, ser opcional para interpretar el objeto. Otra, aparentemente pequeña, puede cambiar la entrada exacta sobre la que opera la firma. La pregunta correcta no es si el nombre parece grave, sino si ignorarlo preserva el mismo significado y las mismas propiedades de seguridad.

La secuencia de validación de la RFC 7515 acompaña esta idea. Hay que decodificar y comprobar el encabezado protegido, verificar que los campos exigidos y sus valores sean comprendidos, construir la entrada de firma y ejecutar el algoritmo. Una interfaz de biblioteca que aplana todos esos resultados en true o false deja al integrador sin saber qué propiedad obtuvo realmente.

Cuando la carga útil deja de codificarse

La RFC 7797 es una demostración concreta del mecanismo. JWS normalmente incorpora a la entrada firmada una representación base64url de la carga útil. Con el parámetro protegido b64 en false, puede usar la carga sin esa codificación. No se trata de una anotación decorativa: cambian los octetos que se firman y las restricciones de transporte de la serialización.

Por ello, la extensión obliga a incluir b64 en crit. Un software que desconoce esta modalidad no intenta aplicar la construcción habitual. Encuentra un nombre crítico que no sabe procesar y rechaza. Dos implementaciones no pueden presumir interoperabilidad solo porque ambas obtuvieron algún resultado criptográfico sobre construcciones posiblemente distintas.

El perfil de uso añade otra decisión. La RFC aconseja que una aplicación no mezcle sin disciplina objetos con carga codificada y sin codificar. La serialización compacta requiere cautela con determinados octetos. Además, un JWT no puede usar b64:false. Así, una biblioteca JWS puede implementar correctamente la extensión, reconocerla y verificarla, pero la capa JWT debe impedir ese uso.

Este caso permite redactar tres preguntas de control. ¿La firma corresponde a la entrada construida? ¿El procesador comprendió y aplicó todas las extensiones obligatorias? ¿El tipo de mensaje y la política de la aplicación admiten esa combinación? El primer sí no hereda autoridad sobre los otros dos.

El nombre del algoritmo tampoco decide la política

La RFC 7518 cataloga algoritmos e identificadores para JOSE. Que un programa reconozca uno y sea capaz de ejecutarlo no significa que deba aceptarlo en todo despliegue. La RFC 7515 reserva a la aplicación la elección de algoritmos apropiados. Una firma puede ser criptográficamente válida y, a la vez, usar una opción prohibida por el perfil de seguridad.

Las mejores prácticas de la RFC 8725 vuelven más concreta esa separación para JWT. La aplicación necesita restringir los algoritmos y evitar que la entrada controlada por quien envía el objeto determine por sí sola el procedimiento de verificación. Debe validar emisor, sujeto, audiencia y las reglas propias del caso de uso. Los distintos tipos de JWT pueden requerir políticas excluyentes para que una credencial no sea aceptada en el contexto equivocado.

crit no da confianza a un emisor ni concede permiso a una operación. Tampoco certifica que una extensión conocida sea apropiada. Solo hace imposible afirmar conformidad cuando falta una semántica declarada como necesaria. Después quedan intactas las decisiones sobre claves, algoritmos, perfiles, claims y efectos.

La firma múltiple necesita una regla nombrada

La serialización JSON permite asociar varias firmas a un objeto. En la descripción general de la RFC 7515, al menos una debe validarse, pero la aplicación decide qué combinación considera aceptable. Esa libertad puede ser útil para migraciones de clave, algoritmo o proveedor; también puede ocultar un atajo.

Cada firma tiene su encabezado protegido y puede cargar una lista crítica diferente. Durante una transición, una firma nueva podría exigir una extensión que solo entienden los consumidores actualizados, mientras una firma antigua mantiene el servicio. Si la aplicación conserva indefinidamente la regla «cualquiera basta», la ruta antigua se convierte en mecanismo de degradación. Si exige todas desde el primer día, puede bloquear a receptores legítimos.

La solución no está en otro booleano, sino en una política de transición: cuáles firmas cuentan, qué extensiones y algoritmos se permiten, qué audiencia recorre cada camino y cuándo vence la compatibilidad. El registro debe indicar cuál firma satisfizo la regla. Sin ese dato, una tasa de éxito oculta si la modernización avanza o si todo el tráfico sigue pasando por el carril heredado.

Auditar significado, no solo integridad

Un evento de verificación útil conserva tres familias de evidencia. La criptográfica documenta algoritmo, referencia de clave, construcción de la entrada y resultado. La semántica registra el encabezado protegido, los nombres críticos, el componente que procesó cada extensión y cualquier rechazo por incompatibilidad. La aplicativa registra perfil, emisor, audiencia, políticas de claims, decisión de autorización y acción solicitada.

No hace falta guardar secretos ni volcar tokens enteros. Sí hacen falta motivos inequívocos. «Firma inválida» conduce a investigar claves cuando el fallo real fue una extensión desconocida. «Token válido» sugiere permiso cuando la aplicación rechazó la audiencia. Un incidente se prolonga si la telemetría borra precisamente la frontera que el estándar diseñó.

La lección de Sakimura y sus coautores es más amplia que un parámetro JOSE. Una prueba de origen e integridad solo es útil dentro de una interpretación compartida. crit da al emisor una forma firmada de negar que una interpretación incompleta sea aceptable, y obliga al receptor a reconocer los límites de su propio conocimiento.

Fuentes