Resumen

  • El IESG aprobó el 24 de septiembre de 2026 draft-ietf-jose-hpke-encrypt-22 para su publicación como Proposed Standard. Sigue siendo un Internet-Draft, no un RFC publicado ni una constatación de uso real.
  • Integrated Encryption cifra directamente el contenido para exactamente un receptor. Key Encryption cifra una CEK compartida y permite combinar receptores HPKE, ECDH o RSA en la serialización JSON de JWE.
  • El protocolo exige que al menos una ruta valide, pero la aplicación decide si basta una o deben funcionar todas. La seguridad del contenido queda limitada por el algoritmo más débil que proteja la CEK.

Tres rutas y un único texto claro

Una organización prepara un JWE para el servicio que lo consumirá hoy, para una custodia reglamentaria y para un sistema de recuperación. La ruta del servicio abre la CEK. El cifrado del contenido valida. La biblioteca devuelve el mensaje. Nada de ello es un falso positivo.

Sin embargo, la recuperación quizá fuera obligatoria y su clave ya no exista. La custodia podría depender de un algoritmo retirado por la política interna. O el sobre podría incluir un cuarto receptor que nunca figuró en la autorización. “Se obtuvo el texto” no responde qué conjunto debía obtenerlo ni con qué garantías.

Ese es el ángulo operativo de la decisión anunciada el 24 de septiembre. El IESG aprobó la revisión 22 del trabajo JOSE sobre HPKE con JWE para publicación como Proposed Standard. La aprobación confirma una decisión del proceso de estándares. No demuestra que una biblioteca esté conforme, que un producto lo haya desplegado, que las claves estén bien administradas o que una política empresarial se haya aplicado. El documento aún tampoco es un RFC.

Integrated no es Key Encryption abreviado

La especificación añade dos modos de gestión de claves con estructuras distintas.

En Integrated Encryption, HPKE cifra el mensaje directamente. No aparece una clave separada de contenido y, por tanto, enc está prohibido. El encabezado protegido contiene un alg que fija la suite HPKE completa; ek no debe existir y solo puede haber un receptor. El JWE Encrypted Key contiene el secreto encapsulado de HPKE. Los campos de IV y tag de JWE quedan vacíos porque el AEAD pertenece a la propia operación HPKE.

Key Encryption conserva la arquitectura de contenido de JWE. Se genera una CEK aleatoria, el contenido se cifra según enc y HPKE cifra esa CEK para cada receptor HPKE. El JWE Encrypted Key de ese receptor contiene el ciphertext de la CEK; ek transporta el secreto encapsulado. Recipient_structure incorpora al calendario de claves el contexto JOSE, el algoritmo de contenido y una información adicional opcional de la aplicación.

La separación permite múltiples receptores. En la serialización JSON, una ruta HPKE puede convivir con ECDH-ES+A128KW o RSA-OAEP-256. Cada receptor recibe su propio acceso cifrado a una CEK que protege un único cuerpo.

Esto sirve para migraciones graduales y copias de recuperación. También significa que el control no vive en una sola cifra. Vive en la composición completa del sobre.

El protocolo entrega hechos; la aplicación pone la regla

La sección de descifrado es explícita. Cuando hay varios receptores, corresponde a la aplicación decidir cuáles deben validar. Un caso puede aceptar cualquiera; otro puede exigir que todos los receptores obligatorios funcionen. La norma común solo establece un suelo: si ninguno valida, el JWE es inválido.

Además, en JWE JSON el procesamiento debe devolver a la aplicación la relación de éxitos y fracasos. Ese detalle evita que la biblioteca aplaste un resultado plural en un booleano demasiado pobre.

Si A funciona con HPKE, B falla por una rotación incompleta y C funciona mediante un algoritmo heredado, el protocolo puede recuperar el mensaje. Una aplicación que exige solo A puede aceptarlo. Otra que necesita A y B debe rechazarlo. Una tercera puede invalidarlo porque el algoritmo de C ya no está permitido. El evento criptográfico es uno; los tres controles no son equivalentes.

El borrador añade otra salvaguarda: aunque el descifrado tenga éxito, la aplicación debería considerar inválido el JWE si los algoritmos empleados no son aceptables en ese contexto. El estándar no pretende ser la política local. Proporciona los puntos de observación para que la política sea verificable.

Una CEK común hereda la ruta más débil

Cada receptor de Key Encryption puede llegar a la misma CEK. Por eso las consideraciones de seguridad dicen que, en un escenario con varios receptores, la seguridad del contenido está limitada por el algoritmo más débil usado para cifrar la CEK.

No es una prohibición general de mezclar tecnologías. Es una advertencia contra medir el conjunto por su rama más moderna. Si una ruta menos resistente sigue autorizada para recuperar la misma CEK, determina una parte del riesgo del mensaje entero.

La historia de la revisión 22 muestra que las diferencias de modo importan. Un segundo Last Call del grupo JOSE revisó únicamente la retirada de HPKE-4-KE y HPKE-6-KE. Esos identificadores de Key Encryption ya no están en la revisión 22, mientras HPKE-4 y HPKE-6 permanecen para Integrated Encryption. Registrar solo la palabra “HPKE” perdería el dato que cambió.

La especificación también desaconseja reutilizar un par KEM entre distintos modos o suites HPKE, y compartir la misma clave entre algoritmos HPKE y no HPKE. La evidencia operacional debe unir receptor, modo, suite, clave y finalidad; un nombre aislado no basta.

La lectura de Heng Lu sobre capas de realidad evita una confusión frecuente. La aprobación es evidencia institucional. El encabezado es evidencia de formato. El éxito de una ruta es evidencia criptográfica. La lista autorizada y el cuantificador “uno” o “todos” pertenecen al control local. El resultado de la aplicación es una quinta observación y no puede deducirse de las cuatro anteriores sin registro.

Fuentes