3.7 Computing the Message Hashes (Calcul des hachages de message)

3.7. Computing the Message Hashes (Calcul des hachages de message)

La signature et la vérification des signatures de message commencent toutes deux par une étape de calcul de deux hachages cryptographiques sur le message. Les Signers choisiront les paramètres de la signature comme décrit dans "Signer Actions" (Section 5); les Verifiers utiliseront les paramètres spécifiés dans le champ d'en-tête DKIM-Signature en cours de vérification. Dans la discussion suivante, les noms des tags dans le champ d'en-tête DKIM-Signature qui existe (lors de la vérification) ou sera créé (lors de la signature) sont utilisés. Notez que la canonisation (Section 3.4) est uniquement utilisée pour préparer l'e-mail pour la signature ou la vérification; elle n'affecte en aucun cas l'e-mail transmis.

Le Signer/Verifier DOIT calculer deux hachages: un sur le corps du message et un sur les champs d'en-tête sélectionnés du message.

Les Signers DOIVENT les calculer dans l'ordre indiqué. Les Verifiers PEUVENT les calculer dans n'importe quel ordre pratique pour le Verifier, à condition que le résultat soit sémantiquement identique à la sémantique qui serait le cas s'ils avaient été calculés dans cet ordre.

À l'étape de hachage 1, le Signer/Verifier DOIT hacher le corps du message, canonisé en utilisant l'algorithme de canonisation du corps spécifié dans le tag "c=" puis tronqué à la longueur spécifiée dans le tag "l=". Cette valeur de hachage est ensuite convertie en forme base64 et insérée dans (Signers) ou comparée à (Verifiers) le tag "bh=" du champ d'en-tête DKIM-Signature.

À l'étape de hachage 2, le Signer/Verifier DOIT transmettre ce qui suit à l'algorithme de hachage dans l'ordre indiqué.

1. Les champs d'en-tête spécifiés par le tag "h=", dans l'ordre spécifié dans ce tag, et canonisés en utilisant l'algorithme de canonisation d'en-tête spécifié dans le tag "c=". Chaque champ d'en-tête DOIT être terminé par un seul CRLF.

2. Le champ d'en-tête DKIM-Signature qui existe (vérification) ou sera inséré (signature) dans le message, avec la valeur du tag "b=" (y compris tous les espaces blancs environnants) supprimée (c'est-à-dire traitée comme la chaîne vide), canonisée en utilisant l'algorithme de canonisation d'en-tête spécifié dans le tag "c=", et sans CRLF de fin.

Tous les tags et leurs valeurs dans le champ d'en-tête DKIM-Signature sont inclus dans le hachage cryptographique à la seule exception de la partie valeur du tag "b=" (signature), qui DOIT être traitée comme la chaîne nulle. Tous les tags DOIVENT être inclus même s'ils pourraient ne pas être compris par le Verifier. Le champ d'en-tête DOIT être présenté à l'algorithme de hachage après le corps du message plutôt qu'avec le reste des champs d'en-tête et DOIT être canonisé comme spécifié dans le tag "c=" (canonisation). Le champ d'en-tête DKIM-Signature NE DOIT PAS être inclus dans son propre tag "h=", bien que d'autres champs d'en-tête DKIM-Signature PEUVENT être signés (voir Section 4).

Lors du calcul du hachage sur les messages qui seront transmis en utilisant l'encodage base64 ou quoted-printable, les Signers DOIVENT calculer le hachage après l'encodage. De même, le Verifier DOIT incorporer les valeurs dans le hachage avant de décoder le texte base64 ou quoted-printable. Cependant, le hachage DOIT être calculé avant les encodages au niveau du transport tels que le "dot-stuffing" SMTP (la modification des lignes commençant par un "." pour éviter la confusion avec le marqueur de fin de message SMTP, comme spécifié dans [RFC5321]).

À l'exception de la procédure de canonisation décrite dans la Section 3.4, le processus de signature DKIM traite le corps des messages comme simplement une chaîne d'octets. Les messages DKIM PEUVENT être en texte brut ou au format MIME; aucun traitement spécial n'est accordé au contenu MIME. Les pièces jointes aux messages au format MIME DOIVENT être incluses dans le contenu qui est signé.

Plus formellement, le pseudo-code de l'algorithme de signature est:

body-hash    =  hash-alg (canon-body, l-param)
data-hash    =  hash-alg (h-headers, D-SIG, body-hash)
signature    =  sig-alg (d-domain, selector, data-hash)

où:

• body-hash: est la sortie du hachage du corps, en utilisant hash-alg.
• hash-alg: est l'algorithme de hachage spécifié dans le paramètre "a".
• canon-body: est une représentation canonisée du corps, produite en utilisant l'algorithme de corps spécifié dans le paramètre "c", tel que défini dans la Section 3.4 et excluant le champ DKIM-Signature.
• l-param: est la valeur de longueur du corps du paramètre "l".
• data-hash: est la sortie de l'utilisation de l'algorithme hash-alg, pour hacher l'en-tête incluant l'en-tête DKIM-Signature, et le hachage du corps.
• h-headers: est la liste des en-têtes à signer, comme spécifié dans le paramètre "h".
• D-SIG: est le champ DKIM-Signature canonisé lui-même sans la partie valeur de signature du paramètre, c'est-à-dire une valeur de paramètre vide.
• signature: est la valeur de signature produite par l'algorithme de signature.
• sig-alg: est l'algorithme de signature spécifié par le paramètre "a".
• d-domain: est le nom de domaine spécifié dans le paramètre "d".
• selector: est la valeur du selector spécifiée dans le paramètre "s".

NOTE: De nombreuses API de signature numérique fournissent à la fois le hachage et l'application de la clé privée RSA en utilisant une primitive "sign()" unique. Lors de l'utilisation d'une telle API, les deux dernières étapes de l'algorithme seraient probablement combinées en un seul appel qui effectuerait à la fois le "a-hash-alg" et le "sig-alg".