Summary

  • La IETF publicó draft-ietf-cose-hpke-27 el 12 de septiembre mientras el texto seguía en seguimiento del director de área. Sigue siendo un Internet-Draft, no un RFC ni una pauta de despliegue aprobada.
  • Un psk_id protegido selecciona el modo PSK. Si falta, rige el modo Base: cifra para quien posee la clave privada receptora, pero no autentica al remitente dentro del KEM de HPKE.
  • kid permite identificar la clave del receptor, no la identidad del emisor. Daniel Kade propone un recibo de autenticación y autorización que no almacene PSK ni texto en claro; es una propuesta editorial, no una exigencia del borrador.

El dato decisivo puede ser una ausencia

La revisión 27 apareció el 12 de septiembre. El historial oficial mantiene el documento en AD Evaluation::AD Followup, después de su envío a la IESG para publicación en la vía Standards Track. La novedad visible de esta versión refuerza la regla sobre aleatoriedad: HPKE necesita una fuente criptográficamente segura y, en Key Encryption, también debe generarse así la clave de cifrado del contenido.

Es una precisión normativa, no el final del expediente. El registro actual aún puede cambiar; los valores IANA del borrador son provisionales y no existe un RFC resultante. El texto sí permite observar ahora una frontera que cualquier implementación tendrá que gobernar: abrir correctamente un objeto no equivale a conocer o autorizar a su remitente.

En modo Base, HPKE protege información para el titular de una clave privada receptora. La autenticación que ofrece el AEAD se refiere al cifrado y a los datos asociados bajo la clave derivada. No certifica por sí sola que la encapsulación de clave pública proceda de una identidad concreta. Cualquier actor que conozca la clave pública puede crear un objeto Base que el receptor abra válidamente.

La disposición del objeto y el modo de confianza son ejes distintos

El borrador describe dos disposiciones. Integrated Encryption aplica HPKE directamente al texto en claro dentro de COSE_Encrypt0 y admite un único receptor. Key Encryption cifra el contenido con una clave simétrica y usa HPKE, en la capa del receptor, para envolver esa clave; así puede atender a varios receptores.

Los nuevos identificadores de algoritmo COSE quedan ligados a una combinación completa de KEM, KDF y AEAD, y a una de las dos disposiciones. La decisión evita que una implementación mezcle componentes sin declarar o coloque un identificador de cifrado integrado en la capa equivocada.

La autenticación del remitente no se codifica en ese número. La presencia del encabezado protegido psk_id activa mode_psk; su ausencia activa mode_base. Por tanto, dos objetos con el mismo identificador de algoritmo pueden aportar garantías de autenticación diferentes.

En modo PSK, el procesamiento correcto autentica que el emisor poseía el secreto compartido suministrado fuera de COSE. En Base, el KEM no hace esa afirmación. Si la telemetría conserva únicamente el ciphersuite, se pierde justo la entrada que decidió cuál de esas garantías se aplicó.

kid elige una llave receptora, no un autor

El borrador recomienda kid para señalar qué clave pública estática del receptor utilizó el emisor. El receptor puede resolverlo a la clave privada correspondiente. Es útil durante una rotación o cuando existen varias claves simultáneas, pero su dirección es inequívoca: identifica al destinatario criptográfico.

La distribución de esa clave pública queda fuera del alcance de la especificación. La aplicación debe establecer su procedencia, su ámbito organizativo y su vigencia. Una clave copiada al tenant equivocado puede generar un objeto perfectamente válido desde el punto de vista matemático y, a la vez, equivocado desde el punto de vista operativo.

El psk_id tampoco es el secreto. Debe estar protegido, mientras que la PSK llega como entrada externa y nunca se incluye en el objeto. Su valor puede remitir a una versión de clave o a un grupo de titulares, pero no demuestra qué persona actuó ni otorga permisos. El borrador HPKE vigente exige suficiente entropía y advierte que una contraseña débil no se vuelve apta por procesarla como PSK.

El contexto protegido necesita una semántica local

COSE permite autenticar encabezados y datos externos. Para Key Encryption, la Recipient_structure integra de forma determinista el algoritmo de la capa siguiente, los encabezados protegidos del receptor y datos extra. Así vincula la capa que envuelve la clave con la que cifra el contenido y reduce el riesgo de sustitución de algoritmo.

El mecanismo vincula los campos elegidos, pero no define por la aplicación qué significan. Incluir un tenant, propósito, periodo de validez o versión de política puede ser obligatorio en un perfil y opcional en otro. Dejar vacío el contexto puede ser sintácticamente posible y operacionalmente insuficiente.

HPKE se define como una herramienta de bajo nivel. La aplicación gestiona la protección frente a repetición fuera del orden de un contexto, la negociación de algoritmos, la pérdida de mensajes y la frescura. Con operaciones de un solo uso, un receptor puede ver dos veces el mismo objeto. Evitar que una instrucción se ejecute dos veces no es una propiedad automática del descifrado.

También hay que delimitar el contenido protegido. Si el cifrado está separado del objeto, una firma o MAC COSE que se aplique después no cubre necesariamente esos bytes. La revisión exige asegurar su integridad por otra vía. Registrar «firma válida» sin mencionar el alcance deja una conclusión más grande que la evidencia.

La confidencialidad anónima puede ser la política correcta

El modo Base no es un fallo. Un buzón para denuncias, un punto de entrega público o un protocolo que autentica al emisor en otra capa pueden querer que cualquiera cifre para el receptor. El borrador menciona COSE_Sign, COSE_Sign1, COSE_Mac y COSE_Mac0 como mecanismos que pueden añadir autenticación.

Lo peligroso sería no distinguir esa elección de una vía que exige emisor conocido. Tampoco basta con cambiar a PSK: un secreto compartido puede pertenecer a un dispositivo, una flota o un turno de operadores. Su posesión no responde por sí sola a revocación, delegación y autorización de cada acción.

La frontera aparece cuando el resultado criptográfico entra en una decisión: una puerta de enlace aplica una configuración, un dispositivo ejecuta una orden o un servicio acepta un informe. Allí hacen falta tres respuestas separadas: qué se protegió, qué identidad o credencial se verificó y qué regla permitió actuar.

Un recibo para la decisión, no otra cabecera de protocolo

Daniel Kade propone un recibo de autenticación del remitente asociado a cada objeto aceptado. Guardaría la versión del perfil, Integrated o Key Encryption, la suite, el modo HPKE efectivo, una huella de la clave receptora y la procedencia de su distribución. Para PSK incluiría una huella no reversible de psk_id, la versión no secreta de la clave y su estado de vigencia. Para Base registraría la firma, el MAC, el canal o la identidad de aplicación que aportó autenticación, o indicaría que el ingreso anónimo era deliberado.

El recibo sumaría el perfil de contexto, el resultado de frescura y repetición, la cobertura de datos separados, la versión de la política de autorización y la decisión. No almacenaría la PSK, el contenido ni identidad innecesaria. Es una prueba de por qué se aceptó, no un repositorio de secretos.

Nada de esto es un requisito de COSE HPKE, RFC 9052, RFC 8937 o el registro COSE de IANA. Es la capa organizativa que separa mecanismo, regla y autoridad, como plantea The Policy Mirror. La especificación inicial mínima aconseja compartir sólo el recibo necesario; la disciplina editorial de BTW obliga a no convertir un borrador en pruebas de un incidente inexistente.

Sources

  1. COSE HPKE, revisión 27
  2. COSE HPKE, revisión 26
  3. Registro actual en Datatracker
  4. Historial del documento
  5. HPKE, revisión 04
  6. RFC 9052 — estructuras y procesamiento COSE
  7. RFC 8937 — mejoras de aleatoriedad
  8. Registro COSE de IANA
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists