3. Protocol Elements (Éléments de protocole)

L'opération DKIM implique deux rôles: le Signer (signataire) et le Verifier (vérificateur). Le Signer crée le champ d'en-tête DKIM-Signature pour le message lorsqu'il quitte l'ADMD, et le Verifier le vérifie lorsque le message arrive. Le Signer et le Verifier peuvent être un MTA, MSA ou MUA, mais ils sont plus susceptibles d'être un module invoqué par l'un d'entre eux.

3.1. Selectors (Sélecteurs)

Pour prendre en charge plusieurs clés publiques simultanées sous un seul SDID et améliorer la commodité de la gestion des clés, DKIM utilise un mécanisme de "selector". Tout comme les labels sont utilisés dans les noms de domaine DNS, le selector est inséré dans la chaîne de requête.

Par exemple, supposons que l'administrateur d'example.com installe deux systèmes DKIM parallèles. Ils pourraient choisir d'utiliser "marketing.example.com" et "engineering.example.com" comme noms de domaine pour les deux systèmes. Cependant, un tel schéma présente un sérieux problème opérationnel: il nécessite d'établir et de maintenir une association technique entre les noms de domaine des deux systèmes et les domaines utilisés sous leurs noms. En revanche, un schéma plus simple consiste à utiliser un seul nom de domaine "example.com" comme source d'identité revendiquée et à distinguer les clés publiques des deux systèmes.

À cette fin, le mécanisme de selector a été introduit. L'utilisation la plus simple consiste à avoir différents enregistrements de clés, chacun utilisant un selector différent. Au lieu d'avoir deux noms de domaine différents, utilisez deux selectors différents "nyc" et "sf" pour distinguer les départements. Dans ce cas, les deux enregistrements de clés seraient référencés dans "nyc._domainkey.example.com" et "sf._domainkey.example.com" respectivement.

Plusieurs selectors permettent à un seul domaine de détenir plusieurs clés DKIM, permettant ainsi plusieurs paires de clés simultanées. Le Verifier ne se soucie pas du nombre de selectors qu'un domaine donné utilise; l'architecture DKIM garantit que l'identification des clés est unique. Des exemples de façons dont les utilisateurs peuvent utiliser plusieurs selectors incluent: maintenir des clés MSA et MTA séparées, des clés par utilisateur, des clés avant et après la mise à niveau (chevauchement de clés), et le support de signatures tierces. Dans tous les cas, le selector est une chaîne aléatoire, sans rapport avec l'opération, et ne peut donc pas être déduit. Les enregistrements de clés peuvent fournir des commentaires lisibles par l'homme (tag n=) à des fins de gestion des clés.

3.2. Tag=Value Lists (Listes Tag=Valeur)

DKIM utilise une syntaxe simple "tag=value" pour exprimer diverses structures, pour fournir des signatures et des enregistrements de clés. Chaque tag-spec consiste en un nom de tag suivi de "=" et d'une valeur. Plusieurs tag-spec sont séparés par des points-virgules. La syntaxe des noms de tags et des valeurs suit l'ABNF de [RFC2822], avec une syntaxe spécifique définie dans les sections suivantes.

tag-list  =  tag-spec *( ";" tag-spec ) [ ";" ]
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  [ tval *( 1*(WSP / FWS) tval ) ]
              ; Interdit WSP et FWS au début et à la fin
tval      =  1*VALCHAR
VALCHAR   =  %x21-3A / %x3C-7E
              ; EXCLAMATION à TILDE sauf SEMICOLON
ALNUMPUNC =  ALPHA / DIGIT / "_"

3.3. Signing and Verification Algorithms (Algorithmes de signature et de vérification)

DKIM prend en charge plusieurs algorithmes de signature numérique. Deux classes d'algorithmes sont prises en charge: (1) les algorithmes requis qui doivent être pris en charge pour garantir l'interopérabilité; (2) les algorithmes facultatifs qui permettent d'implémenter de nouveaux algorithmes lorsque cela est nécessaire.

Le Signer choisit l'algorithme à utiliser. Le Verifier doit pouvoir vérifier les signatures utilisant n'importe quel algorithme requis.

L'algorithme de signature est défini dans le tag "a=" du champ d'en-tête DKIM-Signature, avec la syntaxe suivante:

sig-a-tag-alg   = sig-a-tag-k "-" sig-a-tag-h
sig-a-tag-k     = "rsa" / x-sig-a-tag-k
sig-a-tag-h     = "sha1" / "sha256" / x-sig-a-tag-h
x-sig-a-tag-k   = ALPHA *(ALPHA / DIGIT)
                  ; pour extension future
x-sig-a-tag-h   = ALPHA *(ALPHA / DIGIT)
                  ; pour extension future

"rsa-sha1" et "rsa-sha256" doivent être pris en charge et implémentés. Les spécifications d'autres algorithmes sont laissées pour définition ultérieure.

3.4. Canonicalization (Canonisation)

Certains systèmes de transfert de courrier Internet modifient les messages, par exemple en reformatant les lignes d'en-tête ou en ajoutant/supprimant des espaces de début ou de fin. Ces modifications peuvent entraîner l'échec de la vérification de signature.

Pour résoudre ce problème, DKIM définit deux algorithmes de canonisation pour normaliser les messages: "simple" et "relaxed". "simple" permet peu ou pas de modifications; "relaxed" permet des modifications courantes telles que le reformatage des espaces. Le Signer peut choisir l'algorithme à utiliser. Les deux algorithmes sont appliqués respectivement à l'en-tête et au corps.

L'algorithme de canonisation est spécifié dans le tag "c=" du champ d'en-tête DKIM-Signature, avec la syntaxe suivante:

sig-c-tag       = "simple" / "relaxed" /
                  (sig-c-tag-h "/" sig-c-tag-b)
sig-c-tag-h     = "simple" / "relaxed" / x-sig-c-tag
sig-c-tag-b     = "simple" / "relaxed" / x-sig-c-tag
x-sig-c-tag     = hyphenated-word  ; pour extension future

3.4.1. Algorithme de canonisation d'en-tête simple

L'algorithme de canonisation d'en-tête "simple" ne modifie pas les champs d'en-tête d'une manière qui affecterait la vérification.

3.4.2. Algorithme de canonisation d'en-tête relaxed

L'algorithme de canonisation d'en-tête "relaxed" doit appliquer les étapes suivantes dans l'ordre:

Convertir tous les noms de champs d'en-tête (y compris avant le deux-points) en minuscules. Par exemple, convertir "SUBJect: AbC" en "subject: AbC".
Supprimer tous les caractères WSP après le deux-points.
Convertir toutes les séquences de caractères WSP consécutifs en un seul caractère SP. Les caractères WSP sont les caractères SP et HTAB, tels que définis dans l'annexe B.1 de [RFC5234].
Supprimer tous les WSP à la fin de la valeur du champ.
Supprimer toute séquence CRLF de fin de ligne, sans avoir besoin d'ajouter à la limite du corps.

3.4.3. Algorithme de canonisation de corps simple

L'algorithme de canonisation de corps "simple":

Ignore toutes les lignes vides à la fin du corps du message. Une ligne vide est définie comme une ligne contenant uniquement CRLF; d'autres caractères WSP ne peuvent pas apparaître seuls sur une ligne. Si le corps est complètement vide, une version canonisée d'un seul CRLF est utilisée, dans laquelle les lignes vides de fin ont été supprimées.

3.4.4. Algorithme de canonisation de corps relaxed

L'algorithme de canonisation de corps "relaxed" doit appliquer les étapes suivantes:

Réduire toutes les séquences de caractères WSP consécutifs (y compris après CRLF) à un seul SP.
Ignorer toutes les lignes où des caractères WSP apparaissent à la fin de la ligne dans le corps du message. Les implémentations ne doivent pas supprimer CRLF après le dernier caractère non-WSP.
Ignorer toutes les lignes vides à la fin du corps du message.

3.4.5. Canonicalization Examples (Exemples de canonisation)

Les exemples suivants montrent la canonisation de l'en-tête et du corps. Ici, "<SP>" représente un caractère espace, "<HTAB>" représente une tabulation horizontale, et "<CRLF>" représente une paire retour chariot/saut de ligne.

Message original:

A: \<SP\>X\<CRLF\>
B\<SP\>:\<SP\>Y\<HTAB\>\<CRLF\>
\<HTAB\>Z\<SP\>\<SP\>\<CRLF\>
\<CRLF\>
\<SP\>C\<SP\>\<CRLF\>
D\<SP\>\<HTAB\>\<SP\>\<CRLF\>

Message après canonisation simple:

En-tête:

A: \<SP\>X\<CRLF\>
B\<SP\>:\<SP\>Y\<HTAB\>\<CRLF\>
\<HTAB\>Z\<SP\>\<SP\>\<CRLF\>

Corps:

\<SP\>C\<SP\>\<CRLF\>
D\<SP\>\<HTAB\>\<SP\>\<CRLF\>

Message après canonisation relaxed:

En-tête:

a:\<SP\>X\<CRLF\>
b:\<SP\>Y\<SP\>Z\<CRLF\>

Corps:

\<SP\>C\<CRLF\>
D\<CRLF\>