Résumé

  • Dans la RFC 6376, l= limite facultativement le hash à un préfixe du corps après canonisation. Tout octet canonisé situé au-delà reste hors validation DKIM, même si la signature passe.
  • La portée des en-têtes est indépendante : h= désigne, dans un ordre précis, les instances signées. Un corps entièrement couvert ne rend pas automatiquement Subject, Content-Type ou les autres champs authentiques.
  • Le reçu utile conserve la signature choisie, la canonisation, les longueurs et hash du préfixe et de la fin, la clé DNS observée, le vérificateur et la frontière de confiance d’Authentication-Results.

Une réussite à laquelle il manque son unité

Dans un tableau d’incident, la ligne dkim=pass ressemble à un résultat complet. À côté, une autre donnée change sa portée : corps canonisé de 18 600 octets, l=14 000. La signature a réussi sur les 14 000 premiers octets. Les 4 600 suivants n’ont pas échoué ; ils n’ont tout simplement pas participé au contrôle.

La distinction est fondamentale. Une erreur cryptographique invaliderait la matière couverte. Une fin hors périmètre ne fait aucune promesse. Elle peut provenir d’une liste de diffusion qui ajoute ses consignes de désabonnement, d’une passerelle d’archivage, d’une modification MIME ou d’un ajout hostile. Le seul bit « pass » ne permet pas de choisir le récit.

La RFC 6376 définit exactement ce mécanisme. Sans l=, le corps canonisé entier est inclus. Avec ce tag, le Signer annonce le nombre d’octets à prendre depuis le début du corps canonisé. La valeur ne peut dépasser la longueur réelle. l=0 pousse la logique à sa limite : aucun octet du corps n’est signé.

Le vérificateur garde le droit d’appliquer une politique plus stricte. Il peut refuser un corps partiellement couvert ou signaler le contenu supplémentaire. Cela ne modifie pas la portée du calcul. Il faut donc séparer « signature mathématiquement valide dans son périmètre » et « message admis par la politique locale ».

Murray Kucherawy intervient ici par des documents précis. La RFC 6376 le cite avec Dave Crocker et Tony Hansen ; attribuer DKIM à une seule personne serait faux. La RFC 8601, consacrée à Authentication-Results, le cite comme auteur. Son profil IETF affichait 34 RFC dans son tableau le 2 septembre 2026, tandis que son texte biographique en disait encore 33. Cette petite divergence rappelle qu’une source officielle reste un ensemble de champs datés, pas une vérité sans horloge.

La longueur commence après la canonisation

Soustraire l= de la taille brute d’un fichier mail produit souvent un faux calcul. Le tag compte le résultat de la canonisation du corps déclarée dans c=. Les modes simple et relaxed ne traitent pas de la même façon espaces, fins de ligne et lignes vides terminales. La frontière visible dans le fichier source n’est donc pas nécessairement la frontière cryptographique.

Une reproduction disciplinée suit l’algorithme : conserver le message brut ; sélectionner une instance exacte de DKIM-Signature ; lire c= ; canoniser le corps ; mesurer ce flux d’octets ; le tronquer à l= si le tag existe ; calculer le hash et le comparer à bh=. La signature d’en-tête est ensuite vérifiée avec la clé obtenue à partir de d= et s=.

Le reçu doit rendre le calcul contrôlable. Il inscrit la longueur totale canonisée, la longueur du préfixe couvert et celle de la fin non couverte. Il calcule un hash pour le corps canonisé entier, un autre pour le préfixe et un troisième pour la fin. Un suffixe positif établit une différence de périmètre, pas une intention malveillante.

La clé possède également un temps d’observation. Le DNS peut changer : rotation, révocation ou remplacement du sélecteur. Relire s=._domainkey.d= plusieurs semaines plus tard ne reconstitue pas nécessairement la clé utilisée. Il faut préserver la réponse observée, l’heure, les erreurs et l’état DNSSEC seulement si celui-ci a réellement été mesuré.

Le même espace sert la liste et l’attaquant

l= a été prévu pour un problème réel. Une liste de diffusion ajoute souvent une signature de pied de page ou un lien de gestion. Une signature portant sur la totalité du corps casserait. En limitant le hash au contenu initial, le Signer permet au Verifier de reconnaître ce préfixe après transformation.

Mais cette tolérance ne sait pas distinguer l’opérateur attendu d’un intermédiaire hostile. La section de sécurité de la RFC 6376 avertit qu’un ajout peut profiter à l’attaquant et, par une structure MIME modifiée, un parseur HTML permissif ou un mécanisme de déduplication contourné, dominer ce que voit le destinataire.

Deux erreurs symétriques sont à éviter. La première consiste à qualifier toute fin supplémentaire d’attaque. La seconde consiste à étendre la signature du préfixe à cette fin. Une analyse correcte identifie l’intermédiaire, compare sa transformation à une règle déclarée, reconstruit l’arbre MIME et observe la partie effectivement rendue.

La norme définit les octets. Le code en exécution révèle ce qu’un vérificateur a calculé et ce qu’un client a montré. Une icône de sécurité qui efface cette jointure transforme une réussite technique en promesse éditoriale qu’aucun composant n’a faite.

h= dessine un autre contour

Le corps n’est qu’une moitié de DKIM. Le tag h= contient la liste ordonnée des noms d’en-têtes couverts. Lorsqu’un nom apparaît plusieurs fois, les occurrences de la liste sont résolues depuis le bas du message. Stocker un simple ensemble — « From et Subject signés » — détruit cette information d’ordre.

From doit être signé. La RFC recommande fortement Date, Subject, Reply-To, Sender et les champs MIME susceptibles d’influencer l’affichage ou le traitement. Si l= est présent, Content-Type devient critique : une valeur non couverte peut modifier l’interprétation du même préfixe d’octets.

Pour chaque signature, le journal devrait présenter tous les en-têtes bruts dans l’ordre, marquer l’instance effectivement sélectionnée et signaler les champs importants laissés hors périmètre. Plusieurs signatures sur un même message ne doivent jamais être fondues : domaine d’origine, liste et passerelle peuvent signer des surfaces différentes.

Un domaine signe ; il ne certifie pas tout le récit

Un succès DKIM signifie qu’une signature donnée correspond à une clé publiée sous un domaine et un sélecteur, pour la matière qu’elle a choisie. Il ne prouve pas qu’une personne nommée a écrit le texte, que la clé a été utilisée conformément à une autorisation interne, que les affirmations sont vraies, que la pièce jointe est sûre ou que le message sera remis.

La RFC 5585 limite la propriété à l’intégrité du message ou de la portion signée. La RFC 5863 demande aux assessors de ne considérer authentique que ce qui se trouve dans le périmètre ; son exemple l= est explicite. La RFC 8301 modernise les algorithmes et tailles de clé. Une clé acceptable est nécessaire, mais elle n’allonge pas un préfixe court.

DMARC répond à une autre question, celle de l’alignement entre identités SPF ou DKIM et le domaine visible de From, puis fournit un signal de politique. Il n’ajoute aucun octet à la portée DKIM. « Aligné », « cryptographiquement valide », « entièrement couvert », « digne de confiance » et « accepté » doivent rester des colonnes distinctes.

Le résultat transmis doit avoir un producteur digne de confiance

RFC 8601 permet à un vérificateur d’écrire Authentication-Results pour des consommateurs en aval. Le champ n’est généralement pas auto-authentifié. Sa valeur dépend de la frontière administrative : le consommateur doit reconnaître authserv-id et savoir que les faux champs venus de l’extérieur sont supprimés avant insertion du résultat local.

Un expéditeur peut écrire les caractères dkim=pass. Cela ne devient pas une mesure du destinataire. Le reçu conserve le champ brut, sa position, son producteur, la règle de confiance et la signature exacte qu’il décrit. Si une passerelle réduit trois signatures à un seul pass sans identifiant, elle rend toute vérification ultérieure impossible.

Résultat de méthode et disposition restent séparés. Un Verifier peut confirmer la cryptographie tout en refusant l=. Un autre peut livrer avec avertissement. Le journal doit garder la raison de chacun au lieu de construire une causalité à partir d’un seul mot.

Un ledger de portée minimal

Le noyau commence par le message brut, adressé par hash, puis chaque champ DKIM-Signature dans son ordre original. Pour chacun : d=, s=, i= s’il existe, a=, c=, h=, l=, bh=, la signature et les temps facultatifs. Viennent ensuite la clé DNS observée, les instances d’en-tête résolues, les longueurs et hash des trois régions, le logiciel de vérification, son résultat et sa raison.

Le ledger ajoute la provenance d’Authentication-Results et la frontière qui autorise sa consommation. Enfin, il garde une observation proportionnée du rendu : arbre MIME, partie choisie, version du client et indication que la zone visible tire ou non des octets situés après l=.

Le principe d’agency de Heng Lu maintient les autorités séparées. Les auteurs de la norme définissent la grammaire. Le détenteur de clé choisit la portée. L’intermédiaire transforme. Le vérificateur calcule. Le domaine administratif garantit son canal de résultat. Le client rend. Aucun acteur ne peut prêter son autorité à tous les suivants.

La conclusion probante devient : cette instance de signature a validé ces en-têtes ordonnés et ce préfixe canonisé avec cette clé observée ; cette fin est restée hors validation ; ce producteur de confiance a transmis le résultat ; le client a rendu telles parties ; auteur humain, sécurité et intention exigent d’autres éléments.

Sources