Résumé

  • RFC 9563 attribue le numéro d’algorithme DNSSEC 17 à SM2 avec SM3 et le type de condensat DS 6 à SM3 : les valeurs ont désormais un sens univoque sur le réseau.
  • Le document est un RFC Informational de l’Independent Stream, et non une norme de l’IETF ; il précise que ni l’IETF ni l’IRTF n’ont analysé l’aptitude de ces algorithmes à cet usage.
  • Entre l’inscription au registre et une réponse DNS authentifiée se trouvent encore l’implémentation, la délégation, les capacités du validateur, sa politique et le résultat de l’application.

Un résolveur validant reçoit une réponse signée et lit la valeur 17. Le nombre n’est plus inconnu : le registre de l’IANA l’associe à SM2SM3. Pourtant, ce résolveur peut ne pas disposer du code SM2, ignorer le type de condensat utilisé dans la délégation ou refuser ce chemin au titre de sa politique locale. Même une signature mathématiquement valide ne raconte pas comment la clé privée a été gardée. Le registre ouvre l’enquête ; il ne la clôt pas.

Publié le 4 décembre 2024, RFC 9563 définit l’encodage de SM2 et de SM3 dans DNSSEC. Il attribue le numéro 17 à l’algorithme de signature et le type 6 au condensat DS. Le texte formule aussi sa limite d’autorité avec une rare netteté : il relève de l’Independent Stream, n’est pas le produit d’un consensus de la communauté IETF et ne se trouve pas sur le Standards Track. Ni l’IETF ni l’IRTF n’ont étudié l’aptitude cryptographique de SM2 ou SM3 pour cette fonction ; des faiblesses voulues ou non peuvent exister.

Cette réserve n’est pas une formalité. Elle empêche qu’un acte de publication soit transformé en homologation.

Le registre tranche un nom, pas une controverse

Sans code commun, deux logiciels ne peuvent signaler de façon fiable le même algorithme dans DNSKEY, RRSIG ou DS. L’allocation produit donc une valeur opérationnelle réelle : un format reçoit un nom stable et les collisions d’interprétation deviennent évitables.

Au 27 septembre 2026, le registre IANA des algorithmes DNSSEC indiquait MAY pour l’usage et l’implémentation du numéro 17 en signature comme en validation. Le registre DS indiquait également MAY pour le type 6. Il s’agit d’un constat daté sur l’état du registre, pas d’un recensement des résolveurs, d’une règle d’achat ou d’un verdict cryptanalytique.

RFC 6014 organise précisément cette fonction d’allocation. Il répond à des questions de gouvernance du namespace : selon quelle procédure une valeur est-elle accordée et que désigne-t-elle ? Un registre peut être exact alors qu’aucune machine d’un parc donné ne prend la valeur en charge. Une implémentation peut, à l’inverse, exister sans adoption large. La liste et le terrain sont deux objets différents.

RFC 7841 permet aussi de lire correctement l’étiquette. L’en-tête et le boilerplate signalent le flux éditorial et le statut du document. Le numéro RFC rend la publication durablement repérable ; il n’efface pas la mention Independent Stream et ne lui prête pas le consensus de l’IETF.

La validation DNSSEC est un parcours complet

DNSSEC ne se réduit pas à vérifier une équation. RFC 4033 distingue serveurs faisant autorité, résolveurs sensibles à la sécurité et ancres de confiance. RFC 4034 spécifie DNSKEY, RRSIG, DS et les preuves de non-existence. RFC 4035 demande ensuite au validateur de construire un chemin d’authentification, de choisir un algorithme pris en charge, de retrouver la clé correspondante, de reconstruire les données canoniques, de contrôler la fenêtre temporelle et de vérifier la signature.

Il est possible de décoder le nombre 17 sans savoir calculer SM2. Un produit peut valider SM2 sans reconnaître le condensat DS 6. Une zone enfant peut publier DNSKEY alors que la délégation parente ne fournit aucun DS utilisable. Toutes les primitives peuvent être présentes et la politique locale refuser encore la voie.

RFC 6840 décrit un résultat souvent mal compris : un condensat DS non pris en charge est écarté comme un algorithme DNSKEY inconnu. S’il ne reste aucun DS utilisable, la délégation peut être considérée comme insecure plutôt que bogus. La zone est signée, le registre est exact, mais ce validateur ne possède pas de chemin d’authentification pris en charge.

RFC 8624 maintient des recommandations d’usage et d’implémentation justement parce que l’agilité algorithmique exige une période de recouvrement entre signataires et validateurs. Sa table est antérieure à RFC 9563 ; elle ne peut donc établir le support actuel du numéro 17 ou du type 6. Celui-ci doit être mesuré dans les produits, versions, bibliothèques cryptographiques, options de compilation et configurations réelles.

Une signature valide reste une preuve bornée

RFC 9563 décrit les encodages nécessaires au calcul. Une vérification réussie montre que, pour une clé, des règles et une période données, les données DNS canoniques correspondent à la signature. Elle ne dit pas qui détenait la clé privée, si son usage était autorisé, si une rotation a maintenu la continuité ou si l’application a accepté l’adresse retournée.

RFC 7583 traite la génération, le stockage, la rotation, la compromission et le retrait comme des opérations à part entière. RFC 9563 impose lui aussi l’agilité : si une faiblesse apparaît, DS, DNSKEY, RRSIG et NSEC3 peuvent devoir être renouvelés selon un calendrier respectueux des caches. Aucun changement de registre n’exécute ce travail.

La preuve défendable relie donc la provenance du RFC, l’état courant du registre, le build du signataire, les DNSKEY/DS/RRSIG observés, les capacités du résolveur, ses ancres et sa politique, le journal de validation, la continuité de rotation et enfin le résultat de l’application. Chaque élément conserve son propre champ de vérité.

La primauté du code en fonctionnement défendue par Heng Lu fournit la règle de lecture : symbole, configuration, capacité exécutable et observation sont quatre réalités, mais aucune n’a le droit de parler au nom des autres. RFC 9563 permet de nommer SM2 et SM3 dans DNSSEC. Seuls les systèmes exécutés et observés peuvent dire ce qui s’est produit ensuite.