Resumen

  • La versión 05 del proyecto sucesor de HPKE se presentó el 25 de septiembre; el día 26 el IESG emitió una papeleta de aprobación y la incluyó en su reunión del 8 de octubre. Está en evaluación, no convertida en RFC.
  • Frente a los cuatro modos de RFC 9180, el proyecto mantiene Base 0x00 y PSK 0x01, mientras reserva 0x02 y 0x03, correspondientes antes a Auth y AuthPSK. La versión 04 ya tenía esa configuración.
  • IANA seguiría mostrando el campo Auth de los KEM para compatibilidad con RFC 9180, aunque el texto nuevo no lo usa. Ese registro no informa qué aplicación depende realmente de un modo anterior.

La cifra que se ve en un registro no resuelve la pregunta que importa en una integración: ¿qué comprueba el destinatario sobre quien envía el mensaje? En HPKE, el cifrado hacia la clave pública del receptor y la autenticación basada en la clave privada estática del emisor son prestaciones distintas. La propuesta para reemplazar RFC 9180 acaba de entrar en la evaluación del IESG y obliga a mantener esa diferencia a la vista, precisamente porque se presenta como sucesora de una especificación muy utilizada.

En RFC 9180 aparecen Base, PSK, Auth y AuthPSK con los valores 0x00 a 0x03. La tabla de la propuesta conserva los dos primeros y reserva los otros dos. El apéndice de diferencias declara retirados Auth y AuthPSK, pero también precisa que toda función descrita en ambos textos debería comportarse igual. No hay contradicción: una garantía de compatibilidad para el conjunto común no convierte a los modos omitidos en funciones del nuevo documento. Tampoco permite llamar al PSK un sustituto automático de la comprobación de una clave asimétrica de emisor. PSK acredita la posesión de un secreto compartido y plantea un contrato de identidad diferente.

La noticia del fin de semana no es que alguien haya tachado Auth a última hora. La versión 04 ya reservaba esos valores. El cambio fechado es el avance de la versión 05: presentación el 25 de septiembre, apertura de la papeleta y paso a IESG Evaluation el 26, con teleconferencia prevista para el 8 de octubre. El expediente aún muestra votos pendientes y una revisión de IANA necesaria tras el cambio de versión. RFC 9180 no ha sido sustituido por una decisión ya firme.

La propia documentación del proceso desaconseja simplificarlo como una prohibición. El responsable de acompañar el proyecto explicó en marzo que el grupo retiró los modos autenticados por su uso limitado y porque faltaba una vía poscuántica adecuada para su diseño actual. También reconoció que algunas personas dependen de ellos y calificó la decisión de aplazamiento, no de desaprobación definitiva. No se aporta un censo comprobado de instalaciones, ni una declaración de vulnerabilidad de los modos antiguos.

El apartado de IANA conserva otra pista. Si la propuesta se aprueba, cambiarían las referencias de los registros, pero las inscripciones e identificadores KEM existentes permanecerían. Su plantilla seguiría incluyendo un campo booleano Auth para las operaciones AuthEncap() y AuthDecap() de RFC 9180, aunque la propuesta dice que no emplea ese campo. Esto evita borrar información necesaria para la interfaz anterior; no demuestra que los clientes actuales la llamen. La referencia de un algoritmo, su capacidad y la exigencia de una aplicación son tres datos separados.

Una evaluación prudente debe partir de cada protocolo que incorpora HPKE. Daniel Kade propone documentar la versión citada, el modo invocado, la propiedad de identidad prometida, la capacidad del par y el resultado de pruebas entre extremos, antes de decidir si conservar la vía de RFC 9180 o rediseñar la autenticación en otra capa. Es una recomendación editorial, no una obligación nueva del IETF ni prueba de una interrupción real. Lo que no basta es dar por concluida la transición porque una dependencia cambió de nombre o una prueba de cifrado devolvió un texto legible.

Fuentes