Resumen

  • HP-Outer conserva dentro de la carga cifrada un recibo de las cabeceras que el compositor decidió exponer, sin fingir que observó lo que hicieron después todos los intermediarios.
  • Las capas criptográficas MIME recibidas determinan la protección real; el parámetro hp solo ayuda a reconstruir la intención original y no puede elevar por sí mismo la confidencialidad.
  • El From interior, el From exterior, la firma y su vínculo, la autenticación del transporte, la identidad mostrada y el destinatario de una respuesta deben quedar en registros separados.

Una bandeja de entrada puede recibir el mismo correo con dos autores aparentes. El encabezado exterior identifica a remitente-exterior; el campo protegido, visible tras descifrar, identifica a remitente-protegido. El cuerpo está cifrado y el icono es verde. ¿Cuál de las dos identidades debe mostrarse? ¿A cuál debe dirigirse la respuesta?

La respuesta fácil —“usar siempre la cabecera protegida”— abre un canal para que un compositor malicioso firme bytes con una credencial que no está vinculada a la dirección proclamada. La respuesta contraria —“usar siempre la cabecera exterior”— deja que un adversario en tránsito redirija una contestación y obtenga el contenido confidencial.

RFC 9788 no concede soberanía a una sola representación. Define qué recibos debe conservar el mensaje y deja que cada decisión consuma la prueba adecuada.

El cifrado vive en una estructura

RFC 9787 parte de la estructura MIME, no de la interfaz. Una capa de firma aporta integridad y autenticidad sujetas a validación. Una capa de cifrado aporta confidencialidad y, según su forma, integridad. Las capas forman una envoltura criptográfica solo cuando son contiguas desde el tipo MIME exterior. Su orden también importa: firmado-antes-de-cifrado y cifrado-antes-de-firmado no expresan lo mismo.

La primera parte no criptográfica dentro de esa envoltura es la carga protegida. Un objeto firmado escondido dentro de una rama MIME ordinaria no transforma mágicamente todo el mensaje. Tampoco una operación de compresión se convierte en criptográfica por compartir contenedor con CMS.

Durante años, muchos correos protegieron el cuerpo y dejaron las cabeceras fuera. Eso permitía cambiar el asunto o el autor aparente sin romper necesariamente el cifrado del cuerpo. RFC 8551 propuso envolver un objeto completo message/rfc822, pero varias aplicaciones heredadas lo trataban mal. RFC 9788 reemplaza esa construcción copiando directamente las cabeceras conocidas por el compositor dentro de la carga criptográfica.

En un mensaje cifrado, el cliente puede mantener una cabecera fuera, sustituir su valor por uno opaco o eliminarla. La existencia de una segunda copia cifrada no demuestra cuál de esas opciones se eligió.

Un acta protegida de la exposición

HP-Outer responde a esa pregunta. Vive dentro de la carga cifrada y contiene el nombre y el valor exterior de cada cabecera no estructural que el compositor expuso deliberadamente. Debe existir un registro por cada valor exterior intencional.

Si el asunto exterior fue sustituido por [...], el acta conserva ese texto. Si la fecha se dejó intacta, registra la fecha clara. Si una cabecera protegida no aparece en ningún HP-Outer, el compositor afirma que no colocó fuera ninguna instancia de ella al inyectar el correo.

El límite de la prueba es tan importante como la prueba. El registro está firmado o cifrado junto al resto de la carga y puede acreditar la decisión del compositor. No observa el futuro. Un servidor puede añadir Received; una lista puede añadir campos de gestión; un atacante puede borrar o alterar una cabecera exterior; el buzón puede revelar la hora por su posición.

Sin HP-Outer, eliminar una cabecera en tránsito podría fabricar una falsa apariencia de secreto. Si el compositor dejó Cc en claro y un intermediario lo borra, un destinatario que solo compare el estado final podría pensar que siempre estuvo oculto. El registro protegido demuestra lo contrario. Para describir la confidencialidad histórica, el cliente debe respetar esa exposición; para preparar una respuesta, puede seguir aplicando la opción más prudente y no repetir el dato en claro.

No es una excepción caprichosa. Una prueba sirve al hecho que observó. El registro de composición no hereda autoridad sobre la ruta; la ruta no reescribe la intención; el estado final no permite inventar la historia.

La política se ve por sus decisiones

La Política de Confidencialidad de Cabeceras, HCP, es una función. Recibe el nombre y el valor de una cabecera no estructural y devuelve el mismo valor, una forma oscurecida o null para quitarlo de la sección exterior.

La opción recomendada hcp_baseline es deliberadamente pequeña: cambia Subject por [...], elimina Comments y Keywords y deja pasar lo demás. hcp_shy retira además los nombres visibles de From, To y Cc y normaliza Date a UTC. Es más privada frente a ciertos observadores, pero exige analizar correctamente cada campo y puede afectar entrega, presentación y uso.

El nombre de la HCP no viaja por el cable. El receptor infiere sus efectos a través de HP-Outer. El registro de IANA mantiene descripciones estables y una marca de recomendación. Esa inscripción no prueba que un programa aplique la política, que sea su valor predeterminado o que un correo concreto la haya utilizado.

La norma conserva así una capa común mínima: sintaxis, función reproducible y registro. Ocultar también To, Cc, References o In-Reply-To puede ser sensato en un entorno concreto, pero filtros, hilos, listas y diagnóstico pueden depender de ellos. La mejora local requiere pruebas locales. El nombre del mecanismo no paga su coste operativo.

hp=cipher no cifra nada por sí solo

El parámetro hp expresa lo que intentó hacer el compositor. cipher indica intención de proteger cabeceras con cifrado; clear, una construcción solo firmada. La protección recibida se calcula observando las capas reales descritas por RFC 9787.

Un mensaje solo firmado con hp=cipher sigue sin ser confidencial. La aplicación no puede convertir una intención en un hecho. También puede ocurrir lo contrario: un tercero envuelve con cifrado un mensaje que nació solo firmado. El cifrado que ve el destinatario no demuestra que el autor lo aplicara.

Cuando intención y envoltura divergen, la ausencia de registros HP-Outer no autoriza a afirmar que el compositor ocultó todo. Hay que conservar tres conjuntos: lo que el compositor declaró, lo que la estructura recibida demuestra y lo que las cabeceras exteriores finales exponen.

Reducirlos a un booleano encrypted destruye la trazabilidad. Un registro útil guarda el árbol MIME, el orden de capas, hp, todos los HP-Outer, las cabeceras exteriores recibidas y el resultado exacto del parser.

Mostrar no es responder

El desacuerdo de From activa dos amenazas. Un compositor puede colocar una identidad falsa dentro y protegerla con una firma que no está vinculada a esa dirección. Un intermediario puede cambiar la identidad exterior para desviar una respuesta.

RFC 9788 exige comparar la parte addr-spec interior con la exterior real, no con una copia histórica almacenada en HP-Outer. Si difieren y no existe una firma válida correctamente vinculada al From protegido, el cliente debería advertir como ante phishing y mostrar ambos valores.

Si la aplicación confía en el sistema de transporte para evaluar el remitente exterior, debe presentar ese exterior como respaldo cauteloso en ese caso. Protegido no significa autenticado: una firma prueba que ciertos bytes no cambiaron, pero su clave debe estar unida a la dirección reclamada.

Al contestar, la autoridad cambia. Los destinatarios deben tomarse únicamente de las cabeceras protegidas. Permitir que el From exterior controle la respuesta entregaría a un atacante en tránsito un botón para extraer la conversación.

El producto debe explicar ambas decisiones. El valor exterior puede ser el menos malo para mostrar; el protegido, la única fuente admisible para actuar. Y un nombre como “Alice García” sigue sin tener la unicidad global de una dirección. Agrandarlo en la interfaz no fortalece su vínculo criptográfico.

Cada observador ve una privacidad distinta

Una cabecera duplicada dentro y fuera no es privada para los agentes de transporte. Una cabecera eliminada fuera se revela a los destinatarios que pueden descifrar. Las claves de sesión, el sobre SMTP, los campos Received, el orden temporal del buzón y el tamaño del mensaje permiten inferencias.

El compositor también puede filtrar información al propio destinatario: versión de cliente en User-Agent, zona horaria o host en Message-ID, o un Bcc incluido en la copia incorrecta. El cifrado entrega esas filtraciones con gran fidelidad.

Las listas y servidores añaden campos no protegidos después. Una respuesta puede copiar un asunto descifrado a un mensaje claro. Un reenvío puede repetir referencias que la política original ocultaba. Ninguna de estas superficies debe heredar el candado del cuerpo.

RFC 9788 ofrece una mejora real. Pero su mejora funciona porque reduce el alcance de cada afirmación, no porque prometa una palabra absoluta.

Fuentes

  1. RFC 9788 — Header Protection for Cryptographically Protected Email
  2. RFC 9787 — Guidance on End-to-End Email Security
  3. RFC 8551 — S/MIME 4.0 Message Specification
  4. RFC 5322 — Internet Message Format
  5. RFC 3156 — MIME Security with OpenPGP
  6. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance
  7. IANA — Mail Header Confidentiality Policies
  8. IANA — Message Headers
  9. Heng Lu — Primacía del código en ejecución
  10. Heng Lu — Especificación inicial mínima y decisión futura localizada
  11. Heng Lu — Capas de realidad y poder simbólico