Resumen

  • l= cuenta cuántos octetos del cuerpo canonizado entran en el hash DKIM. Si el cuerpo continúa, esa cola queda fuera de la validación aunque la firma obtenga un resultado correcto.
  • h= define otro límite: la lista ordenada de campos de cabecera cubiertos. No basta con afirmar que From o Subject “aparecen” en la lista cuando existen instancias repetidas.
  • La prueba reproducible conserva mensaje, firma exacta, clave observada, canonización, mapa de cabeceras, tamaños y hashes de prefijo y cola, verificador y procedencia confiable de Authentication-Results.

Dos longitudes, un solo icono verde

Un operador recibe un mensaje de 21.000 octetos tras canonizarlo. La firma contiene l=15.000. El verificador calcula el hash de ese prefijo, resuelve las cabeceras indicadas y devuelve éxito. La interfaz reduce todo el proceso a un escudo verde.

Faltan 6.000 octetos en la explicación. No están “mal firmados”; no están firmados por esa instancia. Podrían ser el pie añadido por una lista, un marcador interno, una continuación MIME inesperada o texto insertado para desplazar visualmente el contenido original. El resultado criptográfico no clasifica la cola.

RFC 6376 hace explícito el contrato. La ausencia de l= incluye todo el cuerpo canonizado. Su presencia limita el cálculo a un prefijo medido desde el inicio del cuerpo. La especificación advierte que todo lo posterior no es validado por DKIM. Con l=0, el cuerpo queda completamente fuera.

La política del receptor puede negarse a aceptar esa firma parcial. Eso es una decisión posterior. Conviene guardar dos campos: validez del cálculo y tratamiento local. Si se fusionan, un cambio de política parecerá un fallo de criptografía, y un éxito matemático parecerá aprobación del contenido.

El nombre de Murray Kucherawy se vincula a esta frontera por documentos concretos. RFC 6376 acredita en conjunto a Dave Crocker, Tony Hansen y Murray S. Kucherawy. RFC 8601, sobre Authentication-Results, lo acredita como autor. El perfil oficial de IETF mostraba 34 RFC en su tabla al capturarlo, aunque el texto autobiográfico conservaba la cifra 33. Ni la autoría colectiva ni una tabla cambiante convierten a una persona en operador de un mensaje real.

El contador no mide el archivo bruto

l= no señala una posición simple dentro del archivo recibido. Antes de contar, DKIM aplica la canonización de cuerpo declarada en c=. Los modos simple y relaxed normalizan de forma distinta espacios y líneas vacías. Por eso restar l= al tamaño del mensaje bruto puede inventar una cola inexistente o ignorar una real.

El procedimiento auditable empieza guardando el mensaje original. Se elige una instancia concreta de DKIM-Signature; se extraen a=, c=, d=, s=, h=, l= y bh=; se canoniza el cuerpo; se mide el resultado; se corta en el límite; se compara el hash; y después se verifica la firma de cabeceras con la clave DNS observada.

El registro anota tres longitudes y tres huellas: cuerpo canonizado completo, prefijo cubierto y cola no cubierta. Una cola de longitud positiva solo demuestra diferencia de alcance. Para saber quién la añadió hace falta comparar capturas en los saltos o vincularla a una transformación declarada.

La clave no debe consultarse como si fuera eterna. d= y s= conducen a un registro DNS que puede rotar o desaparecer. El recibo necesita la respuesta utilizada, la hora de observación, el resolver y cualquier estado DNSSEC medido. La clave actual no sustituye a la clave con la que se tomó la decisión anterior.

La tolerancia útil también crea capacidad de inserción

Las listas de correo explican el diseño. Muchas añaden información de baja o identificación al final. Si el emisor firmara hasta el último octeto, ese cambio rompería la firma. l= permite que el prefijo original sobreviva y deja al receptor decidir si tolera el añadido.

Pero un límite no reconoce buenas intenciones. La seguridad de RFC 6376 señala que un intermediario hostil puede añadir material y hacer que domine la experiencia del destinatario. Una estructura MIME alterada o un parser HTML permisivo puede lograr que lo añadido parezca reemplazar el original; también puede interferir con la detección de duplicados.

No hay que criminalizar todo pie de lista. Hay que negarse a autenticarlo por contagio. El análisis separa prefijo y cola, identifica al intermediario, reconstruye el árbol MIME y observa qué parte seleccionó el cliente. La diferencia entre bytes y pantalla no puede resolverse desde dkim=pass.

Aquí encaja la primacía del código en ejecución de Heng Lu. La norma fija una transformación de octetos. La implementación concreta produce un flujo canonizado, una selección de cabeceras y una vista para el usuario. Citar el estándar sin esos rastros no demuestra que el sistema lo ejecutó ni qué mostró.

h= obliga a preguntar qué cabecera fue elegida

El alcance del cuerpo no resuelve el de las cabeceras. h= es una secuencia, no un conjunto. Cuando hay campos repetidos, DKIM selecciona desde abajo para cada aparición del nombre. Dos listas visualmente parecidas pueden cubrir instancias distintas.

From debe estar incluido. RFC 6376 recomienda firmar Date, Subject, Reply-To, Sender y campos MIME relevantes. Con l=, Content-Type merece atención especial porque una sustitución no cubierta puede cambiar cómo se interpreta el mismo prefijo.

El mapa de cobertura coloca todas las cabeceras en orden y marca las instancias realmente usadas. También muestra nombres “sobre-firmados” que no existían pero cuya inclusión dificulta una inserción posterior. Si el mensaje contiene varias firmas, cada una necesita su propio mapa: firma del dominio, de la lista y de una pasarela no son una sola autoridad.

Validar identidad de dominio no valida el significado

El pass pertenece a una firma, una clave y una materia concreta. No prueba que la persona mostrada en From redactó el correo, que la clave se usó con permiso, que una afirmación es cierta, que el adjunto es seguro o que el receptor lo entregará.

RFC 5585 limita el efecto a la integridad del mensaje o porción firmada. RFC 5863 pide considerar auténtico solo lo que cae dentro del alcance y usa l= como ejemplo. RFC 8301 actualiza algoritmos y tamaños de clave: una verificación con clave débil puede ser inaceptable, pero una clave fuerte tampoco amplía el cuerpo.

DMARC opera en otra capa. Examina la alineación de SPF o DKIM con el dominio visible de From y comunica una preferencia de política. No modifica el contador l= ni la lista h=. Un pass alineado puede seguir dejando cola; una firma completa puede existir sin que DMARC apruebe.

Authentication-Results necesita una frontera administrativa

En muchas arquitecturas el filtro posterior no repite DKIM: lee Authentication-Results. RFC 8601 define ese canal entre productor y consumidor, generalmente dentro de una frontera de confianza. El campo no lleva por sí solo una garantía de integridad.

Antes de añadir un resultado propio, el sistema de borde debe eliminar o neutralizar campos que aparenten venir de dentro pero llegaron de fuera. El consumidor acepta solo authserv-id configurados. De lo contrario, un remitente puede escribir su propio dkim=pass y disfrazarlo de medida local.

Conservar el resultado exige más que copiar el texto. Hay que guardar posición, productor, regla de confianza, versión y enlace a la firma exacta. Si una pasarela resume varias firmas en un pass anónimo, elimina d=, s=, h= y l= de la cadena de evidencia.

El recibo mínimo describe el perímetro

Primero se conserva el mensaje bruto con hash. Después, cada DKIM-Signature en orden y sus parámetros; la clave DNS y su hora; los bytes canonizados o una receta reproducible; las instancias resueltas de cabeceras; las longitudes y huellas de cuerpo completo, prefijo y cola; el software verificador, resultado y motivo.

El segundo bloque documenta Authentication-Results y su frontera confiable. El tercero describe presentación: árbol MIME, parte elegida, versión del cliente y si la vista principal dependió de bytes posteriores a l=. Puede hacerse con retención proporcional y hashes, sin copiar indefinidamente el buzón del usuario.

El principio de agencia asigna cada afirmación. Los autores de RFC definen sintaxis; el custodio de clave elige alcance; el intermediario transforma; el verificador calcula; el dominio administrativo avala su canal; el cliente renderiza. La frase final no debe conceder a ninguno el poder de hablar por todos.

Una conclusión exacta sería: esta firma validó estas instancias de cabecera y este prefijo canonizado con la clave observada; esta cola quedó fuera; este verificador confiable produjo el resultado; esta representación se mostró. Autoría humana, seguridad, intención y entrega siguen abiertas.

Fuentes