3.6 Key Management and Representation (Gestion et représentation des clés)

3.6. Key Management and Representation (Gestion et représentation des clés)

Les applications de signature nécessitent un certain niveau d'assurance que la clé publique de vérification est associée au Signer revendiqué. De nombreuses applications y parviennent en utilisant des certificats de clé publique émis par un tiers de confiance. Cependant, DKIM peut atteindre un niveau de sécurité suffisant, avec une évolutivité considérablement améliorée, en faisant simplement interroger par le Verifier l'entrée DNS du Signer prétendu (ou un équivalent de sécurité) afin de récupérer la clé publique.

Les clés DKIM peuvent potentiellement être stockées dans plusieurs types de serveurs de clés et dans plusieurs formats. Le stockage et le format des clés sont sans rapport avec le reste de l'algorithme DKIM.

Les paramètres de l'algorithme de recherche de clés sont le type de recherche (tag "q="), le domaine du Signer (tag "d=" du champ d'en-tête DKIM-Signature), et le selector (tag "s=").

public_key = dkim_find_key(q_val, d_val, s_val)

Ce document définit une seule liaison, utilisant des DNS TXT RR pour distribuer les clés. D'autres liaisons peuvent être définies à l'avenir.

3.6.1. Textual Representation (Représentation textuelle)

On s'attend à ce que de nombreux serveurs de clés choisissent de présenter les clés dans un format texte non structuré (par exemple, une forme XML ne serait pas considérée comme du texte non structuré à cette fin). La définition suivante DOIT être utilisée pour toute clé DKIM représentée sous forme textuelle non structurée.

La syntaxe globale est une tag-list telle que décrite dans la Section 3.2. Les tags actuellement valides sont décrits ci-dessous. D'autres tags PEUVENT être présents et DOIVENT être ignorés par toute implémentation qui ne les comprend pas.

v= Version de l'enregistrement de clé DKIM (texte brut; RECOMMANDÉ, par défaut "DKIM1"). Si spécifié, ce tag DOIT être défini sur "DKIM1" (sans les guillemets). Ce tag DOIT être le premier tag de l'enregistrement. Les enregistrements commençant par un tag "v=" avec toute autre valeur DOIVENT être rejetés. Notez que les vérificateurs doivent effectuer une comparaison de chaînes sur cette valeur; par exemple, "DKIM1" n'est pas identique à "DKIM1.0".

ABNF:

key-v-tag    = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31

h= Algorithmes de hachage acceptables (texte brut; FACULTATIF, par défaut permet tous les algorithmes). Une liste séparée par des deux-points d'algorithmes de hachage qui pourraient être utilisés. Les algorithmes non reconnus DOIVENT être ignorés. Référez-vous à la Section 3.3 pour une discussion des algorithmes de hachage implémentés par les Signers et les Verifiers. L'ensemble des algorithmes listés dans ce tag dans chaque enregistrement est un choix opérationnel fait par le Signer.

ABNF:

key-h-tag       = %x68 [FWS] "=" [FWS] key-h-tag-alg
                  *( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg   = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word   ; pour extension future

k= Type de clé (texte brut; FACULTATIF, par défaut "rsa"). Les Signers et les Verifiers DOIVENT prendre en charge le type de clé "rsa". Le type de clé "rsa" indique qu'une RSAPublicKey encodée ASN.1 DER [ITU-X660-1997] (voir [RFC3447], Sections 3.1 et A.1.1) est utilisée dans le tag "p=". (Note: le tag "p=" encode en outre la valeur en utilisant l'algorithme base64.) Les types de clés non reconnus DOIVENT être ignorés.

ABNF:

key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type   = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word   ; pour extension future

n= Notes qui pourraient être intéressantes pour un humain (qp-section; FACULTATIF, par défaut vide). Aucune interprétation n'est faite par un programme quelconque. Ce tag doit être utilisé avec parcimonie dans tout mécanisme de serveur de clés qui a des limitations d'espace (notamment DNS). Ceci est destiné à être utilisé par les administrateurs, pas les utilisateurs finaux.

ABNF:

key-n-tag    = %x6e [FWS] "=" [FWS] qp-section

p= Données de clé publique (base64; REQUIS). Une valeur vide signifie que cette clé publique a été révoquée. La syntaxe et la sémantique de cette valeur de tag avant d'être encodée en base64 sont définies par le tag "k=".

JUSTIFICATION INFORMATIVE: Si une clé privée a été compromise ou autrement désactivée (par exemple, un contrat d'externalisation a été résilié), un Signer pourrait vouloir déclarer explicitement qu'il connaît le selector, mais tous les messages utilisant ce selector devraient échouer la vérification. Les Verifiers DEVRAIENT retourner un code d'erreur pour tout champ d'en-tête DKIM-Signature avec un selector référençant une clé révoquée. (Voir Section 6.1.2 pour plus de détails.)

ABNF:

key-p-tag    = %x70 [FWS] "=" [ [FWS] base64string]

NOTE INFORMATIVE: Un base64string est autorisé à inclure des espaces blancs (FWS) à des emplacements arbitraires; cependant, tous les CRLF doivent être suivis d'au moins un caractère WSP. Les implémenteurs et les administrateurs sont avertis de s'assurer que les TXT RR de selector sont conformes à cette spécification.

s= Type de service (texte brut; FACULTATIF; par défaut "*"). Une liste séparée par des deux-points de types de services auxquels cet enregistrement s'applique. Les Verifiers pour un type de service donné DOIVENT ignorer cet enregistrement si le type approprié n'est pas listé. Les types de services non reconnus DOIVENT être ignorés. Les types de services actuellement définis sont les suivants:

* correspond à tous les types de services
email courrier électronique (pas nécessairement limité à SMTP)

Ce tag est destiné à contraindre l'utilisation des clés à d'autres fins, si l'utilisation de DKIM est définie par d'autres services à l'avenir.

ABNF:

key-s-tag        = %x73 [FWS] "=" [FWS] key-s-tag-type
                   *( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type   = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word   ; pour extension future

t= Drapeaux, représentés comme une liste séparée par des deux-points de noms (texte brut; FACULTATIF, par défaut aucun drapeau défini). Les drapeaux non reconnus DOIVENT être ignorés. Les drapeaux définis sont les suivants:

y Ce domaine teste DKIM. Les Verifiers NE DOIVENT PAS traiter les messages des Signers en mode test différemment du courrier électronique non signé, même si la signature échoue à vérifier. Les Verifiers PEUVENT souhaiter suivre les résultats du mode test pour aider le Signer.
s Tous les champs d'en-tête DKIM-Signature utilisant le tag "i=" DOIVENT avoir la même valeur de domaine sur le côté droit du "@" dans le tag "i=" et la valeur du tag "d=". C'est-à-dire que le domaine "i=" NE DOIT PAS être un sous-domaine de "d=". L'utilisation de ce drapeau est RECOMMANDÉE sauf si le sous-domaine est requis.

ABNF:

key-t-tag        = %x74 [FWS] "=" [FWS] key-t-tag-flag
                   *( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag   = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word   ; pour extension future

3.6.2. DNS Binding (Liaison DNS)

Une liaison utilisant des DNS TXT RR comme service de clés est définie par la présente. Toutes les implémentations DOIVENT prendre en charge cette liaison.

3.6.2.1. Namespace (Espace de noms)

Toutes les clés DKIM sont stockées dans un sous-domaine nommé "_domainkey". Étant donné un champ DKIM-Signature avec un tag "d=" de "example.com" et un tag "s=" de "foo.bar", la requête DNS sera pour "foo.bar._domainkey.example.com".

3.6.2.2. Resource Record Types for Key Storage (Types d'enregistrements de ressources pour le stockage des clés)

Le type d'enregistrement de ressource DNS utilisé est spécifié par une option du tag de type de requête ("q="). La seule option définie dans cette spécification de base est "txt", indiquant l'utilisation d'un TXT RR. Une extension ultérieure de cette norme peut définir un autre type RR.

Les chaînes dans un TXT RR DOIVENT être concaténées ensemble avant utilisation sans espace blanc intermédiaire. Les TXT RR DOIVENT être uniques pour un nom de selector particulier; c'est-à-dire que s'il y a plusieurs enregistrements dans un RRset, les résultats sont indéfinis.

Les TXT RR sont encodés comme décrit dans la Section 3.6.1.