Resumen

  • draft-ietf-cose-hpke-27 permite transportar ct fuera de COSE_Encrypt o COSE_Encrypt0, dejando nil en la posición del cifrado. Una firma o MAC posterior sobre el objeto COSE no abarca esos bytes separados.
  • La etiqueta de un AEAD puede proteger la integridad del cifrado externo, pero no equivale a autenticar públicamente al remitente, autorizar la acción ni probar su ejecución.
  • La revisión 27 seguía en evaluación del IESG el 1 de octubre de 2026. Las tres implementaciones citadas por el shepherd validaron ejemplos, no toda la cadena de custodia de un sistema real.

Imaginemos dos identificadores que parecen uno. El primero nombra una estructura COSE firmada. El segundo, escondido en la capa de almacenamiento, resuelve un objeto de varios gigabytes. Mientras la relación sea correcta, el sistema funciona. Cuando el alias apunta a otra versión, la firma continúa siendo válida porque nunca vio el objeto sustituido.

La revisión 27 de COSE-HPKE convierte ese riesgo en una obligación explícita. Si COSE_Encrypt o COSE_Encrypt0 usa texto cifrado separado, la protección añadida después mediante COSE_Sign, COSE_Sign1, COSE_Mac o COSE_Mac0 no lo cubre. El implementador debe asegurar integridad para esos bytes por otra vía.

Separar contenido cambia la unidad auditada

RFC 9052 define que el contenido puede viajar fuera de la estructura COSE. Su posición se representa con nil; la aplicación aporta el contenido al cálculo cuando corresponde. Esto evita copiar grandes cargas y permite distintos ciclos de almacenamiento, pero crea una unión que debe ser demostrable.

En el modo integrado, HPKE devuelve ct. Según el texto del borrador, puede entrar directamente en COSE_Encrypt0 o viajar por separado. En el modo de cifrado de clave, la capa 0 cifra el contenido con una CEK y la capa 1 cifra esa CEK para cada destinatario. El XML normativo de trabajo mantiene esa misma arquitectura.

Por eso no basta registrar blob_id=42. Hay que conservar versión inmutable, longitud y hash de los bytes leídos para la operación. Un CDN que recompone rangos, un descompresor, un alias reutilizado o una reparación silenciosa pueden cambiar la entrada efectiva sin alterar el sobre firmado.

Seis resultados, no un “válido”

La firma externa comprueba la estructura que entró en Sig_structure. El MAC hace lo mismo bajo una clave compartida y su estructura correspondiente. Ninguno adquiere por proximidad los bytes omitidos.

El AEAD de la capa 0 sí puede verificar el cifrado separado. Si la etiqueta se valida con la CEK y los datos asociados correctos, la modificación se detecta. Esa prueba no dice públicamente quién envió el mensaje. Tampoco demuestra que la aplicación deba obedecerlo.

HPKE añade otro resultado: apertura para la clave destinataria. Recipient_structure vincula el algoritmo de la siguiente capa y los encabezados protegidos a la derivación. Después llegan identidad, autorización y efecto. Cada fase responde a una pregunta distinta:

Resultado Pregunta respondida Pregunta pendiente
Firma/MAC externo ¿Es válido el objeto cubierto bajo esta clave? ¿Incluyó el cifrado separado?
AEAD ¿Son íntegros el cifrado y AAD bajo la CEK? ¿Quién posee autoridad pública?
Apertura HPKE ¿Puede este destinatario procesar la encapsulación? ¿Está autorizado el remitente?
Identidad ¿A qué principal corresponde la clave? ¿Puede ordenar esta acción?
Autorización ¿La política permite la operación ahora? ¿Se ejecutó?
Efecto ¿Cambió el estado externo? ¿Está enlazado a las pruebas previas?

El kid selecciona; la política reconoce

El borrador recomienda kid para identificar la clave pública estática del destinatario. En el modo de cifrado de clave puede incorporarse como encabezado protegido y, mediante Recipient_structure, influir en la configuración de HPKE. Eso evita sustituciones ambiguas dentro de la construcción. No convierte un identificador en una identidad jurídica u operativa.

La evidencia necesita espacio de nombres, propietario, versión, propósito, vigencia y estado de revocación. Un caché puede resolver una clave retirada. Dos clientes pueden usar el mismo kid corto. Una clave de recuperación puede abrir el mensaje sin representar a quien aprueba una operación.

recipient_extra_info permite ligar contexto que no se transmite: tenant, sesión, canal o propósito. Su eficacia depende de que ambos extremos posean exactamente el mismo valor y no hagan fallback silencioso. El recibo debe registrar origen, versión y hash de ese contexto.

El determinismo de Recipient_structure, exigido mediante RFC 8949, impide que representaciones equivalentes produzcan entradas diferentes. Es una solución de codificación. No es una solución de autorización ni de custodia del blob.

Cifrar para alguien no identifica por sí solo a quien envía

RFC 9180 estableció el marco de HPKE. El sucesor activo pretende reemplazarlo si llega a aprobarse, pero aún es trabajo en curso. El inventario debe anotar revisión y suite, no una casilla genérica “HPKE”.

En modo Base, el KEM no autentica al remitente. COSE puede añadir firma o MAC, siempre que la aplicación conozca su cobertura. RFC 9338 añade una cautela útil: una contrafirma sobre datos cifrados atestigua esos datos, no necesariamente el texto claro. Aprobar semántica exige una construcción que cubra semántica.

RFC 9053 define algoritmos COSE. El registro COSE de IANA y el registro HPKE coordinan códigos. Un registro no prueba que una biblioteca rechace algoritmos desconocidos, que una organización rote claves o que un verificador use el contexto correcto.

El borrador está avanzado, no terminado

El Datatracker mostraba la revisión 27 como documento del grupo COSE, destinado a Proposed Standard, enviado al IESG y en AD Evaluation::AD Followup el 1 de octubre. El historial registra la publicación de esa revisión el 12 de septiembre. Todavía no era un RFC.

El informe del shepherd describe debate amplio y tres implementaciones independientes usadas para validar ejemplos en IETF 125. Es evidencia valiosa de interoperabilidad puntual. No acredita que un producto preserve el hash del blob, use correctamente recipient_extra_info, resuelva claves sin ambigüedad o aplique autorización después del descifrado.

Un manifiesto de cobertura por decisión

La trazabilidad mínima incluye: bytes COSE; tipo y tag; encabezados exactos; estado integrado o separado; localizador inmutable, longitud y hash del cifrado; hash de la entrada de firma o MAC; algoritmo AEAD, hash de AAD y resultado de etiqueta; modo y suite HPKE; hash de ek y Recipient_structure; procedencia de información extra; versión de clave resuelta; resultado de apertura; hash del texto claro dentro del límite confiable; decisión de identidad; autorización; commit; efecto observado.

No es necesario guardar secretos ni contenido claro en logs. La cadena se demuestra con hashes, referencias versionadas y recibos de decisión. La ausencia también importa: si la firma externa no cubre el blob, el sistema debe decirlo aunque el AEAD lo proteja correctamente.

Minimum Initial Specification sugiere estandarizar este manifiesto pequeño y dejar local la política de negocio. Running-Code Primacy obliga a mirar los buffers reales. The Policy Mirror revela la autoridad de almacenes, cachés y resolutores. Reality Layers mantiene separados sintaxis, bytes, criptografía, identidad, permiso y efecto.

Fuentes