4. Semantics of Multiple Signatures (Sémantique des signatures multiples)

4.1. Example Scenarios (Scénarios d'exemple)

Il existe de nombreuses raisons pour lesquelles un message peut avoir plusieurs signatures. Par exemple, supposons que SHA-256 soit à l'avenir jugé insuffisamment fort et que l'utilisation de DKIM passe à SHA-1024. Un Signer pourrait immédiatement signer en utilisant le nouvel algorithme mais aussi continuer à signer en utilisant l'ancien algorithme pour l'interopérabilité avec les Verifiers qui n'ont pas encore été mis à niveau. Le Signer ferait cela en ajoutant deux champs d'en-tête DKIM-Signature, un pour chaque algorithme. Les anciens Verifiers qui ne reconnaissent pas SHA-1024 comme un algorithme acceptable sauteraient cette signature et utiliseraient l'ancien algorithme; les nouveaux Verifiers pourraient utiliser l'une ou l'autre signature à leur choix et, toutes choses égales par ailleurs, pourraient même ne pas tenter de vérifier l'autre signature.

De même, un Signer pourrait signer un message incluant tous les champs d'en-tête et aucun tag "l=" (pour satisfaire les Verifiers stricts) et une deuxième fois avec un ensemble limité de champs d'en-tête et un tag "l=" (en prévision de modifications possibles du message en route vers d'autres Verifiers). Les Verifiers pourraient alors choisir la signature qu'ils préfèrent.

Bien sûr, un message peut également avoir plusieurs signatures parce qu'il est passé par plusieurs Signers. Un cas courant devrait être celui d'un message signé qui passe par une liste de diffusion qui signe également tous les messages. En supposant que ces deux signatures se vérifient, un destinataire pourrait choisir d'accepter le message si l'une de ces signatures est connue pour provenir de sources fiables.

En particulier, les destinataires peuvent choisir de mettre sur liste blanche les listes de diffusion auxquelles ils se sont abonnés et qui ont des politiques anti-abus acceptables afin d'accepter les messages envoyés à cette liste même d'auteurs inconnus. Ils peuvent également s'abonner à des listes de diffusion moins fiables (par exemple, celles sans protection anti-abus) et être disposés à accepter tous les messages d'auteurs spécifiques mais insister pour effectuer un scan anti-abus supplémentaire pour d'autres messages.

Un autre exemple connexe de Signers multiples pourrait être les services de transfert, tels que ceux couramment associés aux sites d'anciens élèves académiques. Par exemple, un destinataire pourrait avoir une adresse à members.example.org, un site qui dispose d'une protection anti-abus quelque peu moins efficace que ce que le destinataire préférerait. Un tel destinataire pourrait avoir des auteurs spécifiques dont les messages seraient totalement fiables, mais les messages d'auteurs inconnus qui ont passé l'examen du transitaire n'auraient qu'une confiance moyenne.

4.2. Interpretation (Interprétation)

Un Signer qui ajoute une signature à un message crée simplement un nouvel en-tête DKIM-Signature, en utilisant la sémantique habituelle de l'option "h=". Un Signer PEUT signer des champs d'en-tête DKIM-Signature précédemment existants en utilisant la méthode décrite dans la Section 5.4 pour signer les champs d'en-tête de trace.

Notez que les Signers doivent être conscients que la signature de champs d'en-tête DKIM-Signature peut entraîner des échecs de signature avec des intermédiaires qui ne reconnaissent pas que les champs d'en-tête DKIM-Signature sont des champs d'en-tête de trace et les réorganisent involontairement, brisant ainsi ces signatures. Pour cette raison, la signature de champs d'en-tête DKIM-Signature existants est déconseillée, bien que légale.

NOTE INFORMATIVE: Si un champ d'en-tête avec plusieurs instances est signé, ces champs d'en-tête sont toujours signés de bas en haut. Ainsi, il n'est pas possible de signer uniquement des champs d'en-tête DKIM-Signature spécifiques. Par exemple, si le message en cours de signature contient déjà trois champs d'en-tête DKIM-Signature A, B et C, il est possible de signer tous, B et C uniquement, ou C uniquement, mais pas A uniquement, B uniquement, A et B uniquement, ou A et C uniquement.

Un Signer PEUT ajouter plus d'un champ d'en-tête DKIM-Signature en utilisant des paramètres différents. Par exemple, pendant une période de transition, un Signer pourrait vouloir produire des signatures en utilisant deux algorithmes de hachage différents.

Les Signers NE DEVRAIENT PAS supprimer les champs d'en-tête DKIM-Signature des messages qu'ils signent, même s'ils savent que les signatures ne peuvent pas être vérifiées.

Lors de l'évaluation d'un message avec plusieurs signatures, un Verifier DEVRAIT évaluer les signatures indépendamment et selon leurs propres mérites. Par exemple, un Verifier qui par politique choisit de ne pas accepter les signatures avec des algorithmes cryptographiques dépréciés considérerait ces signatures comme non valides. Les Verifiers PEUVENT traiter les signatures dans n'importe quel ordre de leur choix; par exemple, certains Verifiers pourraient choisir de traiter les signatures correspondant au champ From dans l'en-tête du message avant d'autres signatures. Voir Section 6.1 pour plus d'informations sur les choix de signature.

NOTE D'IMPLÉMENTATION INFORMATIVE: Les tentatives de Verifier de corréler des signatures valides avec des signatures non valides pour tenter de deviner pourquoi une signature a échoué sont mal avisées. En particulier, il n'existe aucun moyen général pour un Verifier de déterminer qu'une signature non valide a déjà été valide.

Les Verifiers DEVRAIENT continuer à vérifier les signatures jusqu'à ce qu'une signature se vérifie avec succès à la satisfaction du Verifier. Pour limiter les attaques potentielles par déni de service, les Verifiers PEUVENT limiter le nombre total de signatures qu'ils tenteront de vérifier.

Si un module Verifier signale des signatures dont les évaluations ont produit des résultats PERMFAIL, les Identity Assessors DEVRAIENT ignorer ces signatures (voir Section 6.1), agissant comme si elles n'étaient pas présentes dans le message.