Resumen

  • El 6 de septiembre, el grupo JOSE remitió al IESG la revisión 05 del borrador que pretende declarar obsoletos none y RSA1_5. La solicitud de publicación no equivale a aprobación, RFC ni cambio ya aplicado en IANA.
  • La propuesta obliga a desactivar ambos algoritmos por defecto y los cierra a nuevas especificaciones, pero conserva la posibilidad de habilitarlos para objetos u operaciones concretos. Esa excepción local necesita una caducidad verificable.

Un relevo de autoridad todavía abierto

El historial del Datatracker registra cinco hechos distintos el 6 de septiembre de 2026: el grupo entregó el documento, el estado del Working Group pasó a “Submitted to IESG for Publication”, el estado IESG quedó en “Publication Requested”, Deb Cooley asumió como Area Director responsable y se incorporó el informe del document shepherd.

Nada de ello convierte el texto en norma vigente. La revisión 05 está fechada el 23 de junio y sigue siendo un Internet-Draft. En la fecha de corte, el registro JOSE de IANA continuaba mostrando none como Optional y RSA1_5 como Recommended-. Es el estado esperable antes de una eventual aprobación; no permite hablar de demora ni resistencia institucional.

El borrador actualizaría el RFC 7518 mediante cuatro instrucciones que no deben mezclarse. Quienes mantienen bibliotecas JOSE DEBERÍAN deprecar el soporte. Quienes desarrollan aplicaciones DEBEN desactivarlo por defecto. Una aplicación con una necesidad específica PUEDE habilitar un algoritmo solo para los objetos u operaciones que lo exigen, nunca de forma global. Las nuevas especificaciones sobre JOSE NO DEBEN permitir ninguno de los dos.

La categoría propuesta es Deprecated, no Prohibited. Las aplicaciones y especificaciones existentes pueden seguir funcionando, aunque se las anima a adoptar alternativas. El texto también evita una confusión frecuente: las firmas RS256, RS384 y RS512 no cambian; RSA1_5 identifica aquí la gestión de claves RSAES-PKCS1-v1_5 para JWE.

Por eso una única frase —“JOSE lo prohibió”— sería falsa y operativamente inútil. Estado del registro, disponibilidad en una biblioteca, configuración de una aplicación y aceptación observada en una transacción son capas distintas.

La razón de seguridad y el coste de compatibilidad

none genera un JWS sin firma ni MAC. Aunque el RFC 7518 ya decía que no debía aceptarse por defecto, el borrador enumera vulnerabilidades donde una implementación lo hizo por error. RSA1_5 usa cifrado RSA con relleno PKCS #1 v1.5, afectado por una familia de problemas conocida desde Bleichenbacher en 1998. La propuesta menciona OAEP y mecanismos de curva elíptica entre las alternativas, y cita la guía federal de transición de NIST.

La compatibilidad, sin embargo, no es inventada. OpenID Connect Core conserva casos históricos de ID Tokens sin firma protegidos por TLS y request objects sin firma. El informe del shepherd cuenta que la discusión de IETF 124 desembocó en una consulta de consenso de dos semanas en febrero de 2026. El compromiso reconoció esos usos, pero mantuvo la conclusión de que el beneficio de seguridad justificaba la deprecación.

El mismo informe habla de apoyo y ninguna oposición durante un Working Group Last Call que se amplió para recibir más comentarios. Una encuesta en IETF 126 sumó 27 apoyos, cero rechazos y ocho personas sin opinión. Es evidencia del juicio procesal del grupo; no es un censo de productos, usuarios o dependencias.

Un registro fino y una responsabilidad cercana

IANA puede publicar el nombre del algoritmo, su significado, controlador, referencia y nivel de recomendación. El borrador también endurecería las instrucciones para registros futuros: EUF-CMA para firmas y MAC de JWS, IND-CCA2 para el proceso JWE completo al valorar una gestión de claves y AEAD para cifrado de contenido. Esos criterios no se aplicarían a algoritmos registrados desde el inicio como Deprecated o Prohibited.

Lo que IANA no puede observar es el interruptor local. No sabe si un servicio acepta none para un tipo de objeto heredado o si un socio todavía envía RSA1_5. El borrador no define telemetría, inventario de excepciones ni protocolo de migración, y el shepherd recalca que no crea un mecanismo nuevo que implementar.

Eso no es una invitación a centralizar configuraciones privadas. La aplicación conoce su objeto, su contraparte y el daño de una ruptura. La evidencia debe quedarse cerca de esa decisión, pero no puede ser informal.

Cada excepción debería registrar algoritmo y uso JWS/JWE, objeto u operación autorizados, servicio, responsable, dependencia bloqueante, controles compensatorios, prueba de que el valor global sigue apagado, primera y última utilización, destino de migración, fecha de revisión y caducidad. Esta ficha es una recomendación editorial, no una exigencia del borrador, RFC 7518, IANA, NIST u OpenID Connect.

La deprecación tiene un reloj público y otro privado

El reloj público pasa por revisión del Area Director, posible IETF Last Call, evaluación del IESG, publicación eventual como RFC y ejecución posterior de IANA. La ficha principal del Datatracker todavía indica Internet Standard, mientras el shepherd solicita Proposed Standard y dice que la primera metadata es incorrecta. Es una discrepancia documental abierta, no una decisión final.

El reloj privado empieza cuando una aplicación vuelve a habilitar el algoritmo. Sin vencimiento, una necesidad concreta se convierte en herencia. Sin medición del último uso, nadie sabe si la dependencia sigue viva. Sin propietario, actualizar una biblioteca fuerza una falsa alternativa entre interrupción y permiso global.

La especificación inicial mínima de Heng Lu ayuda a separar funciones: el estándar común fija el valor seguro y limita futuras especificaciones; la aplicación conserva decisiones posteriores. Su primacía del código en funcionamiento impide confundir publicación con ejecución: la configuración y las transacciones prueban qué camino sigue abierto.

El proyecto acierta al no convertir IANA en policía de despliegues. Para completar ese diseño, cada operador debe hacer que sus excepciones sean limitadas, atribuibles, observables y temporales.

Fuentes

  1. IETF Datatracker — deprecación de none y RSA1_5
  2. Historial y document shepherd write-up
  3. Internet-Draft, revisión 05
  4. RFC 7518 — JSON Web Algorithms
  5. IANA — registro JOSE
  6. RFC 5116 — cifrado autenticado
  7. RFC 8017 — PKCS #1 versión 2.2
  8. NIST SP 800-131A, revisión 2
  9. OpenID Connect Core 1.0
  10. Repositorio fuente del borrador
  11. Heng Lu — Minimum Initial Specification
  12. Heng Lu — Running-Code Primacy