1. Introduction

DomainKeys Identified Mail (DKIM) permet à une personne, un rôle ou une organisation de revendiquer une certaine responsabilité pour un message en associant un nom de domaine [RFC1034] au message [RFC5322], qu'ils sont autorisés à utiliser. Il peut s'agir de l'organisation de l'auteur, d'un relais opérationnel ou de l'un de leurs agents. L'assertion de responsabilité est validée par une signature cryptographique et en interrogeant directement le domaine du signataire pour récupérer la clé publique appropriée. Le transit des messages de l'auteur au destinataire s'effectue via des relais qui n'apportent généralement aucune modification substantielle au contenu du message et préservent ainsi la signature DKIM. Un message peut contenir plusieurs signatures, provenant de la même organisation ou d'organisations différentes impliquées dans le message.

L'approche adoptée par DKIM diffère des approches précédentes de signature de messages (par exemple, Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751], OpenPGP [RFC4880]) en ce que:

• la signature du message est écrite en tant que champ d'en-tête de message afin que ni les destinataires humains ni les logiciels MUA (Mail User Agent) existants ne soient confus par le contenu lié à la signature apparaissant dans le corps du message;

• il n'y a aucune dépendance vis-à-vis des paires de clés publiques et privées émises par des autorités de certification connues et de confiance;

• il n'y a aucune dépendance vis-à-vis du déploiement de nouveaux protocoles ou services Internet pour la distribution ou la révocation de clés publiques;

• l'échec de la vérification de la signature ne force pas le rejet du message;

• aucune tentative n'est faite pour inclure le chiffrement dans le mécanisme; et

• l'archivage des messages n'est pas un objectif de conception.

DKIM:

• est compatible avec l'infrastructure de messagerie existante et transparent dans toute la mesure du possible;

• nécessite une infrastructure nouvelle minimale;

• peut être implémenté indépendamment des clients afin de réduire le temps de déploiement;

• peut être déployé de manière incrémentale; et

• permet la délégation de la signature à des tiers.

1.1. DKIM Architecture Documents (Documents d'architecture DKIM)

Il est conseillé aux lecteurs de se familiariser avec le matériel de [RFC4686], [RFC5585] et [RFC5863], qui fournissent respectivement le contexte du développement de DKIM, un aperçu du service et des conseils de déploiement et d'exploitation.

1.2. Signing Identity (Identité de signature)

DKIM sépare la question de l'identité du signataire du message de celle de l'auteur présumé du message. En particulier, une signature inclut l'identité du signataire. Les vérificateurs peuvent utiliser les informations de signature pour décider comment ils veulent traiter le message. L'identité de signature est incluse dans le champ d'en-tête de signature.

JUSTIFICATION INFORMATIVE: L'identité de signature spécifiée par une signature DKIM n'est pas tenue de correspondre à une adresse dans un champ d'en-tête particulier en raison des méthodes d'interprétation larges par les systèmes de messagerie des destinataires, y compris les MUA.

1.3. Scalability (Évolutivité)

DKIM est conçu pour prendre en charge les exigences d'évolutivité extrêmes qui caractérisent le problème d'identification des e-mails. Il existe de nombreux millions de domaines et un nombre beaucoup plus important d'adresses individuelles. DKIM cherche à préserver les aspects positifs de l'infrastructure de messagerie actuelle, tels que la capacité pour quiconque de communiquer avec quiconque sans introduction.

1.4. Simple Key Management (Gestion simple des clés)

DKIM diffère des systèmes de clés publiques hiérarchiques traditionnels en ce qu'aucune infrastructure d'autorité de certification n'est requise; le vérificateur demande la clé publique à un référentiel dans le domaine du signataire revendiqué directement plutôt qu'à un tiers.

Le DNS est proposé comme mécanisme initial pour les clés publiques. Ainsi, DKIM dépend actuellement de l'administration DNS et de la sécurité du système DNS. DKIM est conçu pour être extensible à d'autres services de récupération de clés à mesure qu'ils deviennent disponibles.

1.5. Data Integrity (Intégrité des données)

Une signature DKIM associe le nom "d=" au hachage calculé de tout ou partie du message (voir Section 3.7) afin d'empêcher la réutilisation de la signature avec différents messages. La vérification de la signature affirme que le contenu haché n'a pas changé depuis qu'il a été signé et n'affirme rien d'autre sur la "protection" de l'intégrité de bout en bout du message.