5. Signer Actions (Actions du signataire)

Les étapes suivantes sont effectuées dans l'ordre par les Signers.

5.1. Determine Whether the Email Should Be Signed and by Whom (Déterminer si l'e-mail doit être signé et par qui)

Un Signer ne peut évidemment signer des e-mails que pour les domaines pour lesquels il possède une clé privée et les connaissances nécessaires de la clé publique correspondante et des informations de sélecteur. Cependant, il existe un certain nombre d'autres raisons au-delà du manque de clé privée pour lesquelles un Signer pourrait choisir de ne pas signer un e-mail.

NOTE INFORMATIVE: Un Signer peut être implémenté dans n'importe quelle partie du système de messagerie jugée appropriée, y compris un MUA, un serveur SUBMISSION ou un MTA. Où qu'il soit implémenté, les Signers doivent se méfier de signer (et donc d'assumer la responsabilité de) des messages qui peuvent être problématiques. En particulier, dans une enclave de confiance, le domaine de signature peut être dérivé de l'en-tête selon la politique locale; les serveurs SUBMISSION peuvent uniquement signer les messages des utilisateurs correctement authentifiés et autorisés.

CONSEIL INFORMATIVE AUX IMPLÉMENTEURS: Les serveurs SUBMISSION ne doivent pas signer les champs d'en-tête Received si le MTA de passerelle sortant obscurcit les champs d'en-tête Received, par exemple, pour masquer les détails de la topologie interne.

Si un e-mail ne peut pas être signé pour une raison quelconque, c'est une décision de politique locale de savoir quoi faire avec cet e-mail.

5.2. Select a Private Key and Corresponding Selector Information (Sélectionner une clé privée et les informations de sélecteur correspondantes)

Cette spécification ne définit pas la base sur laquelle un Signer doit choisir quelle clé privée et quelles informations de sélecteur utiliser. Actuellement, tous les sélecteurs sont égaux en ce qui concerne cette spécification, donc la décision devrait largement être une question de commodité administrative. La distribution et la gestion des clés privées sont également en dehors de la portée de ce document.

CONSEIL INFORMATIVE AUX OPÉRATIONS: Un Signer ne doit pas signer avec une clé privée lorsque le sélecteur contenant la clé publique correspondante est censé être révoqué ou supprimé avant que le Verifier ait l'occasion de valider la signature. Le Signer doit anticiper que les Verifiers peuvent choisir de différer la validation, peut-être jusqu'à ce que le message soit effectivement lu par le destinataire final. En particulier, lors de la rotation vers une nouvelle paire de clés, la signature doit commencer immédiatement avec la nouvelle clé privée, et l'ancienne clé publique doit être conservée pendant un intervalle de validation raisonnable avant d'être supprimée du serveur de clés.

5.3. Normalize the Message to Prevent Transport Conversions (Normaliser le message pour éviter les conversions de transport)

Certains messages, en particulier ceux utilisant des caractères 8 bits, sont sujets à modification pendant le transit, notamment la conversion en forme 7 bits. De telles conversions briseront les signatures DKIM. Afin de minimiser les chances d'une telle rupture, les Signers DEVRAIENT convertir le message en un encodage de transfert de contenu MIME approprié tel que quoted-printable ou base64 comme décrit dans [RFC2045] avant de signer. Une telle conversion est en dehors de la portée de DKIM; le message réel DEVRAIT être converti en MIME 7 bits par un MUA ou MSA avant la présentation à l'algorithme DKIM.

Si le message est soumis au Signer avec un encodage local qui sera modifié avant la transmission, cette modification en forme canonique [RFC5322] DOIT être effectuée avant la signature. En particulier, les caractères CR ou LF nus (utilisés par certains systèmes comme convention de séparateur de ligne locale) DOIVENT être convertis en séquence CRLF standard SMTP avant que le message ne soit signé. Toute conversion de ce type DEVRAIT être appliquée au message réellement envoyé au(x) destinataire(s), pas seulement à la version présentée à l'algorithme de signature.

Plus généralement, le Signer DOIT signer le message tel qu'il est censé être reçu par le Verifier plutôt que sous une forme locale ou interne.

5.3.1. Body Length Limits (Limites de longueur du corps)

Un comptage de longueur de corps PEUT être spécifié pour limiter le calcul de signature à un préfixe initial du texte du corps, mesuré en octets. Si le comptage de longueur de corps n'est pas spécifié, le corps entier du message est signé.

JUSTIFICATION INFORMATIVE: Cette capacité est fournie car il est très courant que les listes de diffusion ajoutent des remorques aux messages (par exemple, des instructions sur la façon de quitter la liste). Jusqu'à ce que ces messages soient également signés, le comptage de longueur de corps est un outil utile pour le Verifier car il peut, en tant que question de politique, accepter des messages ayant des signatures valides avec des données superflues.

La longueur réellement hachée doit être insérée dans la balise "l=" du champ d'en-tête DKIM-Signature. (Voir Section 3.5.)

Le comptage de longueur de corps permet au Signer d'un message de permettre l'ajout de données à la fin du corps d'un message signé. Le comptage de longueur de corps DOIT être calculé après l'algorithme de canonicalisation; par exemple, tout espace blanc ignoré par un algorithme de canonicalisation n'est pas inclus dans le comptage de longueur de corps.

Un comptage de longueur de corps de zéro signifie que le corps est complètement non signé.

Les Signers souhaitant s'assurer qu'aucune modification d'aucune sorte ne peut se produire doivent spécifier l'algorithme de canonicalisation "simple" pour l'en-tête et le corps et omettre le comptage de longueur de corps.

Voir Section 8.2 pour plus de discussion.

5.4. Determine the Header Fields to Sign (Déterminer les champs d'en-tête à signer)

Le champ d'en-tête From DOIT être signé (c'est-à-dire, inclus dans la balise "h=" du champ d'en-tête DKIM-Signature résultant). Les Signers NE DEVRAIENT PAS signer un champ d'en-tête existant susceptible d'être légitimement modifié ou supprimé en transit. En particulier, [RFC5321] permet explicitement la modification ou la suppression du champ d'en-tête Return-Path en transit. Les Signers PEUVENT inclure tout autre champ d'en-tête présent au moment de la signature à la discrétion du Signer.

NOTE INFORMATIVE AUX OPÉRATIONS: Le choix des champs d'en-tête à signer n'est pas évident. Une stratégie consiste à signer tous les champs d'en-tête existants non répétables. Une autre stratégie consiste à signer uniquement les champs d'en-tête susceptibles d'être affichés ou susceptibles d'affecter le traitement du message au niveau du récepteur. Une troisième stratégie consiste à signer uniquement les en-têtes "bien connus". Notez que les Verifiers peuvent traiter les champs d'en-tête non signés avec un scepticisme extrême, y compris refuser de les afficher à l'utilisateur final ou même ignorer la signature si elle ne couvre pas certains champs d'en-tête. Pour cette raison, il est fortement conseillé de signer les champs présents dans le message tels que Date, Subject, Reply-To, Sender et tous les champs d'en-tête MIME.

Le champ d'en-tête DKIM-Signature est toujours implicitement signé et NE DOIT PAS être inclus dans la balise "h=" sauf pour indiquer que d'autres signatures préexistantes sont également signées.

Les Signers PEUVENT prétendre avoir signé des champs d'en-tête qui n'existent pas (c'est-à-dire que les Signers PEUVENT inclure le nom du champ d'en-tête dans la balise "h=" même si ce champ d'en-tête n'existe pas dans le message). Lors du calcul de la signature, le champ d'en-tête inexistant DOIT être traité comme la chaîne nulle (y compris le nom du champ d'en-tête, la valeur du champ d'en-tête, toute la ponctuation et le CRLF de fin).

JUSTIFICATION INFORMATIVE: Cela permet aux Signers d'affirmer explicitement l'absence d'un champ d'en-tête; si ce champ d'en-tête est ajouté plus tard, la signature échouera.

NOTE INFORMATIVE: Un nom de champ d'en-tête n'a besoin d'être répertorié qu'une seule fois de plus que le nombre réel de ce champ d'en-tête dans un message au moment de la signature afin d'empêcher tout ajout supplémentaire. Par exemple, s'il y a un seul champ d'en-tête Comments au moment de la signature, lister Comments deux fois dans la balise "h=" est suffisant pour empêcher l'ajout d'un nombre quelconque de champs d'en-tête Comments; il n'est pas nécessaire (mais légal) de lister Comments trois fois ou plus dans la balise "h=".

Reportez-vous à Section 5.4.2 pour une discussion de la procédure à suivre lors de la canonicalisation d'un en-tête avec plus d'une instance d'un nom de champ d'en-tête particulier.

Les Signers doivent faire attention à signer des champs d'en-tête qui pourraient voir des instances supplémentaires ajoutées plus tard dans le processus de livraison, car de tels champs d'en-tête pourraient être insérés après l'instance signée ou autrement réorganisés. Les champs d'en-tête de trace (tels que Received) et les blocs Resent-* sont les seuls champs interdits par [RFC5322] d'être réorganisés. En particulier, comme les champs d'en-tête DKIM-Signature peuvent être réorganisés par certains MTA intermédiaires, la signature de champs d'en-tête DKIM-Signature existants est sujette aux erreurs.

AVERTISSEMENT INFORMATIVE: Malgré le fait que [RFC5322] n'interdise pas la réorganisation des champs d'en-tête, la réorganisation des champs d'en-tête signés avec plusieurs instances par les MTA intermédiaires brisera les signatures DKIM; un tel comportement antisocial devrait être évité.

NOTE DE L'IMPLÉMENTEUR INFORMATIVE: Bien que non requis par cette spécification, tous les champs d'en-tête visibles par l'utilisateur final doivent être signés pour éviter un possible "spam indirect". Par exemple, si le champ d'en-tête Subject n'est pas signé, un spammeur peut renvoyer un courrier précédemment signé, en remplaçant le sujet légitime par un spam d'une ligne.

5.4.1. Recommended Signature Content (Contenu de signature recommandé)

Le but de l'algorithme cryptographique DKIM est d'apposer un identifiant au message d'une manière à la fois robuste contre les changements normaux liés au transit et résistante aux types d'attaques par rejeu. Un aspect essentiel pour satisfaire ces exigences est de choisir quels champs d'en-tête inclure dans le hachage et quels champs exclure.

La règle de base pour choisir les champs à inclure est de sélectionner ceux qui constituent le "noyau" du contenu du message. Par conséquent, toute attaque par rejeu devra les inclure pour que la signature réussisse; cependant, avec ces inclus, le noyau du message est valide, même s'il est envoyé à de nouveaux destinataires.

Des exemples courants de champs avec des adresses et de champs avec du contenu textuel lié au corps sont:

From (REQUIS; voir Section 5.4)
Reply-To
Subject
Date
To, Cc
Resent-Date, Resent-From, Resent-To, Resent-Cc
In-Reply-To, References
List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

Si la balise de signature "l=" est utilisée (voir Section 3.5), le champ Content-Type est également un candidat à inclure car il pourrait être remplacé d'une manière qui provoque le rendu d'un contenu complètement différent à l'utilisateur récepteur.

Il y a des compromis dans la décision de ce qui constitue le "noyau" du message, ce qui pour certains champs est un concept subjectif. Inclure des champs tels que "Message-ID", par exemple, est utile si l'on considère qu'un mécanisme permettant de distinguer des instances séparées du même message est un contenu de base. De même, "In-Reply-To" et "References" pourraient être souhaitables à inclure si l'on considère que le threading des messages est une partie essentielle du message.

Une autre classe de champs qui peut être d'intérêt sont ceux qui transmettent des informations liées à la sécurité sur le message, telles que Authentication-Results [RFC5451].

La règle de base pour choisir les champs à exclure est de sélectionner ceux pour lesquels il existe plusieurs champs avec le même nom et les champs qui sont modifiés en transit. Des exemples de ceux-ci sont:

Return-Path
Received
Comments, Keywords

Notez que le champ DKIM-Signature est également exclu du hachage d'en-tête car sa gestion est spécifiée séparément.

En règle générale, il est préférable d'exclure d'autres champs facultatifs en raison du potentiel que des champs supplémentaires du même nom soient légitimement ajoutés ou réorganisés avant la vérification. Il est probable qu'il y ait des exceptions légitimes à cette règle en raison de la grande variété de champs d'en-tête spécifiques aux applications qui pourraient être appliqués à un message, dont certains sont peu susceptibles d'être dupliqués, modifiés ou réorganisés.

Les Signers DEVRAIENT choisir des algorithmes de canonicalisation en fonction des types de messages qu'ils traitent et de leur aversion au risque. Par exemple, les sites de commerce électronique envoyant principalement des reçus d'achat, qui ne sont pas censés être traités par des listes de diffusion ou d'autres logiciels susceptibles de modifier les messages, préféreront généralement la canonicalisation "simple".

Les sites envoyant principalement des e-mails de personne à personne préféreront probablement être plus résilients à la modification pendant le transport en utilisant la canonicalisation "relaxed".

À moins que le courrier ne soit traité par des intermédiaires, tels que des listes de diffusion qui pourraient ajouter des instructions de "désabonnement" au bas du corps du message, la balise "l=" est susceptible de ne transmettre aucun avantage supplémentaire tout en fournissant une avenue pour l'ajout non autorisé de texte à un message. L'utilisation de "l=0" pousse cela à l'extrême, permettant une altération complète du texte du message sans invalider la signature. De plus, un Verifier serait dans son droit de considérer un corps de message partiellement signé comme inacceptable. Une utilisation judicieuse est conseillée.

5.4.2. Signatures Involving Multiple Instances of a Field (Signatures impliquant plusieurs instances d'un champ)

Les Signers choisissant de signer un champ d'en-tête existant qui apparaît plus d'une fois dans le message (tel que Received) DOIVENT signer la dernière instance physique de ce champ d'en-tête dans le bloc d'en-tête. Les Signers souhaitant signer plusieurs instances d'un tel champ d'en-tête DOIVENT inclure le nom du champ d'en-tête plusieurs fois dans la balise "h=" du champ d'en-tête DKIM-Signature et DOIVENT signer ces champs d'en-tête dans l'ordre du bas du bloc de champ d'en-tête vers le haut. Le Signer PEUT inclure plus d'instances d'un nom de champ d'en-tête dans "h=" qu'il n'y a de champs d'en-tête correspondants réels afin que la signature ne se vérifie pas si des champs d'en-tête supplémentaires de ce nom sont ajoutés.

EXEMPLE INFORMATIVE:

Si le Signer souhaite signer deux champs d'en-tête Received existants, et que l'en-tête existant contient:
Received: <A>
Received: <B>
Received: <C>
alors le champ d'en-tête DKIM-Signature résultant devrait lire:
DKIM-Signature: ... h=Received : Received :...
et les champs d'en-tête Received <C> et <B> seront signés dans cet ordre.

5.5. Compute the Message Hash and Signature (Calculer le hachage et la signature du message)

Le Signer DOIT calculer le hachage du message comme décrit dans Section 3.7, puis le signer en utilisant l'algorithme de clé publique sélectionné. Cela aboutira à un champ d'en-tête DKIM-Signature qui inclura le hachage du corps et une signature du hachage d'en-tête, où cet en-tête inclut le champ d'en-tête DKIM-Signature lui-même.

Les entités telles que les gestionnaires de listes de diffusion qui implémentent DKIM et qui modifient le message ou un champ d'en-tête (par exemple, en insérant des informations de désabonnement) avant de retransmettre le message DEVRAIENT vérifier toute signature existante en entrée et DOIVENT effectuer de telles modifications avant de re-signer le message.

5.6. Insert the DKIM-Signature Header Field (Insérer le champ d'en-tête DKIM-Signature)

Enfin, le Signer DOIT insérer le champ d'en-tête DKIM-Signature créé à l'étape précédente avant de transmettre l'e-mail. Le champ d'en-tête DKIM-Signature DOIT être le même que celui utilisé pour calculer le hachage comme décrit ci-dessus, sauf que la valeur de la balise "b=" DOIT être le hachage correctement signé calculé à l'étape précédente, signé en utilisant l'algorithme spécifié dans la balise "a=" du champ d'en-tête DKIM-Signature et en utilisant la clé privée correspondant au sélecteur donné dans la balise "s=" du champ d'en-tête DKIM-Signature, comme choisi ci-dessus dans Section 5.2.

Le champ d'en-tête DKIM-Signature DOIT être inséré avant tout autre champ DKIM-Signature dans le bloc d'en-tête.

NOTE D'IMPLÉMENTATION INFORMATIVE: Le moyen le plus simple d'y parvenir est d'insérer le champ d'en-tête DKIM-Signature au début du bloc d'en-tête. En particulier, il peut être placé avant tout champ d'en-tête Received existant. Ceci est cohérent avec le traitement de DKIM-Signature comme un champ d'en-tête de trace.