3. L'enregistrement de ressource RRSIG (The RRSIG Resource Record)
DNSSEC utilise la cryptographie à clé publique pour signer et authentifier les ensembles d'enregistrements de ressources DNS (RRsets). Les signatures numériques (digital signatures) sont stockées dans des enregistrements de ressources RRSIG et sont utilisées dans le processus d'authentification DNSSEC décrit dans [RFC4035]. Un validateur (validator) peut utiliser ces RR RRSIG pour authentifier les RRsets de la zone. Le RR RRSIG DOIT uniquement être utilisé pour transporter du matériel de vérification (signatures numériques) utilisé pour sécuriser les opérations DNS.
Un enregistrement RRSIG contient la signature pour un RRset avec un nom, une classe et un type particuliers. Le RR RRSIG spécifie un intervalle de validité (validity interval) pour la signature et utilise l'Algorithm, le Signer's Name et le Key Tag pour identifier le RR DNSKEY contenant la clé publique qu'un validateur peut utiliser pour vérifier la signature.
Étant donné que chaque RRset faisant autorité dans une zone doit être protégé par une signature numérique, des RR RRSIG doivent être présents pour les noms contenant un RR CNAME. Il s'agit d'un changement par rapport à la spécification DNS traditionnelle [RFC1034], qui stipulait que si un CNAME est présent pour un nom, c'est le seul type autorisé pour ce nom. Dans une zone signée, un RRSIG et un NSEC (voir section 4) DOIVENT exister pour le même nom qu'un enregistrement de ressource CNAME.
La valeur Type pour le type RR RRSIG est 46.
Le RR RRSIG est indépendant de la classe.
Un RR RRSIG DOIT avoir la même classe que le RRset qu'il couvre.
La valeur TTL d'un RR RRSIG DOIT correspondre à la valeur TTL du RRset qu'il couvre. Ceci est une exception aux règles [RFC2181] pour les valeurs TTL des RR individuels au sein d'un RRset : les RR RRSIG individuels avec le même nom de propriétaire auront des valeurs TTL différentes si les RRsets qu'ils couvrent ont des valeurs TTL différentes.
3.1. Format de transmission RDATA RRSIG (RRSIG RDATA Wire Format)
Le RDATA pour un RR RRSIG se compose d'un champ Type Covered de 2 octets, d'un champ Algorithm de 1 octet, d'un champ Labels de 1 octet, d'un champ Original TTL de 4 octets, d'un champ Signature Expiration de 4 octets, d'un champ Signature Inception de 4 octets, d'un Key Tag de 2 octets, du champ Signer's Name et du champ Signature.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1. Le champ Type Covered (The Type Covered Field)
Le champ Type Covered identifie le type du RRset couvert par cet enregistrement RRSIG.
3.1.2. Le champ Algorithm Number (The Algorithm Number Field)
Le champ Algorithm Number identifie l'algorithme cryptographique utilisé pour créer la signature. Une liste des types d'algorithmes DNSSEC se trouve dans l'annexe A.1.
3.1.3. Le champ Labels (The Labels Field)
Le champ Labels spécifie le nombre d'étiquettes dans le nom du propriétaire du RR RRSIG original. L'importance de ce champ est qu'un validateur l'utilise pour déterminer si la réponse a été synthétisée à partir d'un générique (wildcard). Si tel est le cas, il peut être utilisé pour déterminer quel nom de propriétaire a été utilisé pour générer la signature.
Pour valider une signature, le validateur a besoin du nom de propriétaire original qui a été utilisé pour créer la signature. Si le nom de propriétaire original contient une étiquette générique ("*"), le nom de propriétaire peut avoir été étendu par le serveur pendant le processus de réponse, auquel cas le validateur devra reconstruire le nom de propriétaire original afin de valider la signature. [RFC4035] décrit comment utiliser le champ Labels pour reconstruire le nom de propriétaire original.
La valeur du champ Labels NE DOIT PAS compter ni l'étiquette null (racine) qui termine le nom de propriétaire, ni l'étiquette générique (si présente). La valeur du champ Labels DOIT être inférieure ou égale au nombre d'étiquettes dans le nom de propriétaire RRSIG. Par exemple, "www.example.com." a une valeur de champ Labels de 3, et "*.example.com." a une valeur de champ Labels de 2. La racine (".") a une valeur de champ Labels de 0.
Bien que l'étiquette générique ne soit pas incluse dans le compte stocké dans le champ Labels du RR RRSIG, l'étiquette générique fait partie du nom de propriétaire du RRset lorsque la signature est générée ou vérifiée.
3.1.4. Champ Original TTL (Original TTL Field)
Le champ Original TTL spécifie le TTL du RRset couvert tel qu'il apparaît dans la zone faisant autorité.
Le champ Original TTL est nécessaire car un résolveur de mise en cache décrémente la valeur TTL d'un RRset mis en cache. Pour valider une signature, un validateur a besoin du TTL original. [RFC4035] décrit comment utiliser la valeur du champ Original TTL pour reconstruire le TTL original.
3.1.5. Champs Signature Expiration et Inception (Signature Expiration and Inception Fields)
Les champs Signature Expiration et Inception spécifient une période de validité pour la signature. L'enregistrement RRSIG NE DOIT PAS être utilisé pour l'authentification avant la date d'inception et NE DOIT PAS être utilisé pour l'authentification après la date d'expiration.
Les valeurs des champs Signature Expiration et Inception spécifient une date et une heure sous la forme d'un nombre non signé de 32 bits de secondes écoulées depuis le 1er janvier 1970 00:00:00 UTC, en ignorant les secondes intercalaires, dans l'ordre des octets réseau. L'intervalle le plus long pouvant être exprimé par ce format sans bouclage est d'environ 136 ans. Un RR RRSIG peut avoir une valeur de champ Expiration numériquement inférieure à la valeur du champ Inception si la valeur du champ d'expiration est proche du point de bouclage 32 bits ou si la signature est de longue durée. Pour cette raison, toutes les comparaisons impliquant ces champs DOIVENT utiliser "l'arithmétique des numéros de série" (Serial number arithmetic), telle que définie dans [RFC1982]. En conséquence directe, les valeurs contenues dans ces champs ne peuvent pas faire référence à des dates de plus de 68 ans dans le passé ou dans le futur.
3.1.6. Le champ Key Tag (The Key Tag Field)
Le champ Key Tag contient la valeur d'étiquette de clé (key tag value) du RR DNSKEY qui valide cette signature, dans l'ordre des octets réseau. L'annexe B explique comment calculer les valeurs Key Tag.
3.1.7. Le champ Signer's Name (The Signer's Name Field)
La valeur du champ Signer's Name identifie le nom du propriétaire du RR DNSKEY qu'un validateur est censé utiliser pour valider cette signature. Le champ Signer's Name DOIT contenir le nom de la zone du RRset couvert. Un émetteur NE DOIT PAS utiliser la compression de nom DNS sur le champ Signer's Name lors de la transmission d'un RR RRSIG.
3.1.8. Le champ Signature (The Signature Field)
Le champ Signature contient la signature cryptographique qui couvre le RDATA RRSIG (à l'exclusion du champ Signature) et le RRset spécifié par le nom de propriétaire RRSIG, la classe RRSIG et le champ RRSIG Type Covered. Le format de ce champ dépend de l'algorithme utilisé, et ces formats sont décrits dans des documents compagnons séparés.
3.2. Format de présentation RR RRSIG (The RRSIG RR Presentation Format)
Le format de présentation de la partie RDATA est le suivant :
Le champ Type Covered est représenté comme un mnémonique de type RR. Lorsque le mnémonique n'est pas connu, la représentation TYPE comme décrite dans [RFC3597], section 5, DOIT être utilisée.
La valeur du champ Algorithm DOIT être représentée soit comme un entier décimal non signé, soit comme un mnémonique d'algorithme, tel que spécifié dans l'annexe A.1.
La valeur du champ Labels DOIT être représentée comme un entier décimal non signé.
La valeur du champ Original TTL DOIT être représentée comme un entier décimal non signé.
Les valeurs des champs Signature Expiration et Inception DOIVENT être représentées soit comme un entier décimal non signé indiquant les secondes depuis le 1er janvier 1970 00:00:00 UTC, soit sous la forme YYYYMMDDHHmmSS en UTC, où :
- YYYY est l'année (0001-9999)
- MM est le numéro du mois (01-12)
- DD est le jour du mois (01-31)
- HH est l'heure, en notation 24 heures (00-23)
- mm est la minute (00-59)
- SS est la seconde (00-59)
Les implémentations qui présentent ces champs aux humains DEVRAIENT utiliser le format YYYYMMDDHHmmSS.
Le champ Key Tag DOIT être représenté comme un entier décimal non signé.
La valeur du champ Signer's Name DOIT être représentée comme un nom de domaine.
Le champ Signature DOIT être représenté comme un encodage Base64 de la signature. Des espaces sont autorisés dans le texte Base64. Pour une définition de l'encodage Base64, voir [RFC3548].
3.3. Exemple de RR RRSIG (RRSIG RR Example)
Le RR RRSIG suivant stocke la signature pour le RRset A de host.example.com.
host.example.com. 86400 IN RRSIG A 5 3 86400 20050322173103 (
20050220173103 2642 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
Les quatre premiers champs spécifient le nom du propriétaire, le TTL, la classe et le type RR (RRSIG). Le "A" représente le champ Type Covered. La valeur 5 est le champ Algorithm. La valeur 3 est le champ Labels. La valeur 86400 est le champ Original TTL, qui était la valeur TTL utilisée pour le RRset A. Les valeurs temporelles 20050322173103 et 20050220173103 sont respectivement les dates Signature Expiration et Inception. La valeur 2642 est le Key Tag, et example.com. est le Signer's Name. Le texte restant est un encodage Base64 du champ Signature.
Navigation des chapitres connexes :