Resumen

  • draft-ietf-hpke-hpke-05 conserva Base 0x00 y PSK 0x01, mientras marca 0x02 y 0x03 como reservados; RFC 9180 asignaba esos valores a Auth y AuthPSK.
  • Una norma puede cerrar su núcleo. Para cerrar el uso real hacen falta recibos separados de perfil, compilación, configuración, tráfico, datos persistentes, contraparte y resultado.

Una migración criptográfica suele empezar por el emisor y terminar, si se hace bien, mucho más tarde en el último lector. El emisor puede dejar de crear objetos con un modo antiguo hoy. Una copia de seguridad, un trabajo diferido o un socio desconectado puede exigir el camino de lectura dentro de meses.

La revisión 05 del nuevo borrador HPKE vuelve visible esa diferencia. Su tabla contiene dos modos y dos reservas. La infraestructura que rodea la tabla no aparece en ella.

Por eso “el modo ya no está en el borrador” y “el modo ya no existe en nuestra operación” son afirmaciones distintas. La primera se demuestra citando el texto. La segunda requiere una cadena de evidencia.

Aún es un Internet-Draft

Datatracker fecha la revisión 05 el 26 de septiembre de 2026. Es un documento activo del grupo HPKE, dirigido a Proposed Standard, enviado al IESG y actualmente en evaluación. Figura en la teleconferencia del 8 de octubre; la revisión de IANA vuelve a estar pendiente por cambio de versión.

El encabezado dice que, si se aprueba, dejaría obsoleto RFC 9180. No puede borrarse esa condición. El corpus congelado no contiene la aprobación final ni un RFC nuevo.

La tabla de dos modos tampoco apareció por primera vez en septiembre. Ya estaba en la revisión 04 de julio. La noticia pertinente es la madurez procesal del diseño actual, no una supuesta modificación recién introducida.

RFC 9180 es un RFC informativo de la corriente IRTF. El borrador pretende convertir el núcleo actualizado en un Proposed Standard de la IETF. El proceso puede fijar el próximo punto de coordinación. No observa los despliegues que deben alcanzarlo.

Lo común sigue siendo común; lo retirado queda fuera

El apéndice A promete compatibilidad con RFC 9180 para el comportamiento que ambos documentos especifican. Base y PSK permanecen en esa zona compartida.

Auth y AuthPSK no. RFC 9180 define 0x02 y 0x03 y las funciones de configuración que usan una clave estática del emisor. El nuevo borrador reserva los valores y elimina esas variantes. La promesa de compatibilidad no cubre lo que el documento decidió retirar.

Este matiz debe llegar al plan de pruebas. Un vector idéntico para Base confirma una propiedad útil, pero no prueba que un servicio carezca de la función Auth ni que un objeto antiguo pueda abrirse. Un resultado genérico “HPKE OK” mezcla comportamientos compartidos y comportamientos suprimidos.

Cada prueba debe nombrar modo, suite, API, rol de clave, perfil de aplicación, versión de biblioteca y par. De lo contrario, la compatibilidad declarada es demasiado imprecisa para autorizar una eliminación.

El modo no siempre viaja como un rótulo visible

HPKE depende del protocolo que lo incorpora. El borrador deja a la aplicación el transporte de enc, psk_id y otros parámetros no privados. También deja fuera la selección de la clave del destinatario cuando existen varias.

El modo forma parte del contexto con el que la aplicación invoca HPKE. No hay una envoltura universal que permita buscar un byte visible en cualquier producto y obtener un censo completo. Un perfil puede fijar el modo; una API puede expresarlo mediante una función diferente; un formato propietario puede depender de una versión externa.

El inventario debe empezar por esos perfiles. Después tiene que seguir la dependencia hasta el binario cargado, la configuración efectiva, el objeto persistente y la observación del intercambio. Buscar nombres de función es útil, pero sólo prueba que el texto o el símbolo existe en el alcance examinado.

También hay falsos negativos. El código puede estar incorporado en una biblioteca estática, una appliance, una imagen de recuperación o un worker que sólo se activa ante errores. La ausencia en el repositorio principal no equivale a ausencia en la flota.

Una cadena de recibos para cerrar la deuda

El recibo normativo identifica revisión y estado del borrador. El recibo de perfil explica cómo una aplicación selecciona modo y suite. El recibo de binario demuestra qué artefacto se ejecuta. El recibo de configuración registra qué caminos están permitidos. El recibo de uso muestra qué camino se eligió. El recibo de contraparte prueba interoperabilidad con el sustituto. El recibo de datos cubre objetos en cola o archivo. El recibo de resultado demuestra que la aplicación terminó su trabajo.

Una actualización de paquete no sustituye esa cadena. Puede instalarse una versión nueva mientras el proceso viejo sigue en memoria. El proceso puede reiniciar con una excepción heredada. La excepción puede no usarse, pero seguir disponible. El emisor puede estar limpio mientras el receptor necesita leer años de objetos.

La cadena evita también exagerar evidencia positiva. Encontrar una llamada Auth no prueba que se ejecute. Aceptar un ciphertext no prueba que el emisor tuviera autoridad empresarial. Superar un canario PSK no prueba que todos los socios hayan migrado.

La frase correcta debe ser cuantificada: qué se midió, durante cuánto tiempo, en qué puntos y con qué horizonte máximo de retención o retraso.

La propuesta de extensión no es una decisión del IETF

Existe otro texto: draft-ms-hpke-auth-modes-01. Propone restaurar AuthPSK como extensión estricta. Recupera la mecánica de Auth para construir AuthPSK, pero no reintroduce el modo Auth por separado porque no ofrecería resistencia cuántica.

Datatracker advierte que es un borrador individual, sin respaldo del IETF ni posición formal en el proceso. No es correcto presentarlo como reemplazo aprobado.

Su valor para el análisis es otro. Demuestra que retirar una función del núcleo y prohibir cualquier extensión futura son decisiones diferentes. Si esa rama prosperara, crearía otro conjunto de compatibilidad, con dependencias, pruebas y adopción propias.

Los mensajes de las listas HPKE y JOSE documentan argumentos sobre firmas, mezcla de roles, Key Encryption y autenticación implícita. Son evidencia de debate, no de consenso, explotación o prevalencia. La autoridad de una fuente debe viajar con cada afirmación.

PSK no resuelve por sí solo la identidad de negocio

El borrador atribuye al modo PSK autenticación del emisor en sentido criptográfico: quien construye correctamente el contexto posee la clave precompartida.

Queda fuera quién recibió la clave, cuántos procesos la comparten, para qué servicio es válida y qué decisión puede autorizar. La misma posesión puede representar un par único, un clúster entero o una excepción mal segmentada. La operación debe aportar distribución, rotación, alcance y vínculo con la identidad.

HPKE tampoco suministra prevención de replay o downgrade de la aplicación, orden de mensajes, ocultación de longitud ni protección frente a mala aleatoriedad efímera. Tampoco da forward secrecy frente a una futura pérdida de la clave privada del destinatario. Abrir el ciphertext es sólo un recibo dentro de la cadena.

Migrar Auth a PSK sin redefinir esa cadena puede conservar el cifrado y perder el significado que la aplicación atribuía al emisor. La propiedad requerida debe escribirse antes de escoger el sustituto.

El último objeto decide cuándo puede morir el lector

La retirada del envío y la retirada de la lectura tienen relojes distintos. Un nuevo productor puede adoptar Base o PSK inmediatamente. Las copias históricas, colas, reintentos y archivos pueden necesitar el camino anterior hasta que sean migrados, caduquen o se destruya su valor de forma deliberada.

El registro de objetos debe incluir perfil, ventana de creación, identificador de clave, política de retención y última lectura de prueba. Si el sistema antiguo no guardó suficiente metadato para identificar el modo, el riesgo no desaparece: se vuelve desconocido.

Borrar claves y decodificadores antes de resolverlo puede causar pérdida irreversible. Mantenerlos sin dueño, segmentación ni fecha de expiración convierte la compatibilidad en superficie permanente. El cierre necesita una decisión explícita en ambos casos.

Una norma propone; el código observado confirma

La especificación mínima y la primacía del código en funcionamiento, formuladas por Heng Lu, separan publicación de adopción. Una regla nueva se vuelve real para un participante cuando se implementa, valida, despliega y utiliza. Quien no la adopta queda en otro conjunto de compatibilidad; no desaparece por decreto documental.

La lectura no desacredita al estándar. Permite usarlo correctamente. La IETF puede reducir el núcleo y coordinar nuevas implementaciones. Los operadores deben probar su transición con hechos locales y de contraparte.

Un cierre defendible enumera perfiles, binarios, excepciones, objetos, pares, resultados y ventanas de observación. Fuera de esa lista, la respuesta profesional sigue siendo “no medido”.

Fuentes