Résumé

  • Le projet draft-ietf-lamps-rfc6211-update-01 remplace l’OID 1.2.840.113549.1.9.52 imprimé dans la RFC 6211 par 1.2.840.113549.1.9.16.2.52, valeur inscrite depuis l’origine dans le registre IANA des attributs S/MIME.
  • Pour sortir d’une divergence déjà incorporée dans des logiciels et des objets archivés, il faut distinguer ce qu’un système sait reconnaître, ce qu’il accepte comme preuve, ce qu’il émet encore et la date à laquelle la compatibilité prendra fin.

Une divergence parfaitement officielle

Dans le registre IANA, l’entrée 52 de la branche des attributs S/MIME porte le nom id-aa-cmsAlgorithmProtect. Son chemin complet passe par smime(16) puis aa(2). Dans la RFC 6211 publiée en 2011, la définition principale et le module ASN.1 omettaient ces deux arcs. Le résultat n’est pas une variante typographique, mais deux identifiants distincts sur le fil.

Les auteurs du nouveau projet indiquent connaître deux mises en œuvre qui n’ont pas interopéré pour cette raison. L’une avait choisi le nombre de la RFC, l’autre celui du registre. Cette observation reste circonscrite : elle ne mesure ni le parc installé, ni une attaque, ni un coût global. Elle suffit néanmoins à démontrer que la bonne valeur, présente dans un registre central, n’a pas empêché une bifurcation réelle.

Le cas dérange parce qu’il ne permet pas de désigner un acteur négligent. Copier le module normatif d’une RFC est une méthode de travail raisonnable. Vérifier une allocation dans le registre IANA l’est tout autant. Lorsque ces deux gestes mènent à des octets incompatibles, la question n’est plus seulement « quelle valeur est correcte ? », mais « comment l’autorité doit-elle circuler entre publication, outils et déploiements ? ».

Une protection qui dépend de son propre nom

La syntaxe CMS transporte des contenus signés, authentifiés ou chiffrés. La RFC 6211 a introduit un attribut destiné à contrer la substitution d’algorithme : l’expéditeur lie au message les identifiants des algorithmes employés, afin qu’un tiers ne puisse pas modifier discrètement l’algorithme ou ses paramètres avant la validation.

Or un validateur doit d’abord reconnaître l’attribut pour lui accorder ce rôle. Si le producteur l’étiquette avec un OID et le consommateur cherche l’autre, la protection peut être absente du point de vue de ce dernier. Le projet de mise à jour le dit sans extrapolation : le mécanisme ne réussit que si les implémenteurs emploient le même identifiant ASN.1.

Il serait abusif d’en déduire qu’un produit déterminé est vulnérable. Les comportements possibles diffèrent : rejet de l’objet, ignorance d’un attribut inconnu, traitement partiel ou politique locale plus stricte. L’enseignement de gouvernance demeure. Une primitive conçue pour supprimer une ambiguïté cryptographique ne peut tolérer une ambiguïté non gérée dans son propre identifiant.

Le module n’était pas une simple annexe

Pour beaucoup d’équipes, un module ASN.1 est plus proche du code que de la prose. Il est copié, compilé, transformé en structures de données ou intégré à une bibliothèque. Ce chemin donne au module une force de diffusion que n’a pas forcément une page de registre consultée séparément.

La RFC détenait une autorité normative ; le registre détenait l’autorité d’allocation ; le module détenait une autorité pratique dans les chaînes d’outillage. Dire que le registre était juste décrit la source cible. Cela ne supprime pas la constante déjà embarquée, les tests qui la consacrent, les messages déjà signés ni les équipements qu’on ne peut pas mettre à niveau immédiatement.

La révision 01 améliore aussi une autre jonction entre prose et exécution. Le texte de la RFC exigeait un seul exemplaire de l’attribut de protection dans un ensemble. La nouvelle définition ajoute COUNTS MAX 1. Une contrainte auparavant réservée au lecteur devient visible pour les compilateurs et outils qui savent l’appliquer.

Ce déplacement est salutaire, mais il ne faut pas en tirer une hiérarchie simpliste. Un schéma erroné automatise l’erreur avec une efficacité remarquable. Prose, registre, module, exemples et vecteurs de test doivent donc être livrés comme un ensemble cohérent et vérifié.

Le temps de la correction n’est pas celui du parc installé

Les errata 9144 et 9145 ont été signalés le 19 août 2026 pour l’annexe A et la section 2. Au 13 septembre, leur statut demeurait Reported. Un erratum signalé n’est pas encore un erratum vérifié. De même, le projet est un document de travail : sa version 00 est entrée en dernière lecture du groupe LAMPS le 1er septembre, puis la version 01 a été déposée le 9 septembre UTC.

Ces étapes clarifient progressivement le dossier commun. Elles ne remontent pas dans le temps. Une bibliothèque peut avoir figé la mauvaise valeur il y a dix ans ; un message signé peut devoir rester lisible pendant trente ans ; un appareil peut dépendre d’un fournisseur disparu. Le statut éditorial d’une correction et le statut opérationnel d’une migration sont deux calendriers distincts.

Un opérateur peut agir avant la conclusion du processus IETF, mais il doit nommer cette action correctement. Il applique une politique locale fondée sur des éléments publics, non une décision finale de l’IETF. Cette précision permet de réviser le choix si le projet évolue et évite de transformer une mesure de continuité en pseudo-norme.

Reconnaître n’est pas valider

Faut-il accepter les deux OID pendant une transition ? Formulée ainsi, la question mélange quatre opérations.

Un outil d’archives peut reconnaître l’ancien OID afin de décrire fidèlement un objet. Un point de contrôle peut l’observer et attribuer sa production à une version précise. Un moteur de politique peut refuser qu’il satisfasse l’exigence de protection, même s’il sait le décoder. Enfin, un générateur peut cesser immédiatement de l’émettre. Reconnaissance, télémétrie, confiance et production doivent disposer de commandes séparées.

L’acceptation double et silencieuse facilite la compatibilité mais risque de perpétuer une seconde convention. Le rejet brutal crée le risque inverse : rendre illisibles des archives ou isoler un composant dont la mise à jour exige du temps. Une bonne transition est donc asymétrique. Elle interdit d’abord la nouvelle production fautive, maintient une observation bornée, répare les producteurs identifiés, puis resserre l’acceptation selon un calendrier décidé.

Le registre de préséance et de retrait

L’instrument utile n’est pas une note vague disant « RFC 6211 prise en charge ». C’est un registre local de préséance des identifiants et de retrait de compatibilité. En tête figurent les deux OID exacts, leurs sources, la valeur cible et la décision locale qui régit l’ancien chemin.

Chaque composant reçoit ensuite une ligne : produit et version, propriétaire, identifiants reconnus, identifiants considérés comme valides pour la politique, identifiant émis, comportement lors d’une réécriture. Un lecteur d’archives, une passerelle S/MIME, un module matériel, un outil d’inspection et un service de signature n’ont pas nécessairement le même profil.

Les déclarations doivent être éprouvées par un petit corpus. Il comprend un objet avec chaque OID, un objet sans attribut de protection, un objet qui en contient deux et des cas où les algorithmes annoncés ne correspondent pas au reste de la structure CMS. Pour chaque test, on conserve la version exacte, le résultat, un hachage de l’objet et la règle de politique invoquée.

Le plan de retrait arrête d’abord les nouvelles émissions de l’ancien OID. Il mesure ensuite leur résidu par producteur. Les exceptions ont un responsable, un motif et une échéance. Les objets historiques restent inchangés ; une métadonnée externe peut expliquer leur statut sans altérer les octets signés. Le rejet final ne devient raisonnable que lorsque l’observation montre que les producteurs concernés ont été corrigés ou expressément isolés.

Préserver la provenance de la réparation

Une attestation de correction devrait indiquer la source de la valeur cible, le module ou la constante modifiée, le test démontrant les octets émis, la politique appliquée aux objets antérieurs et l’autorité qui a fixé la date de fin de compatibilité.

Sans cette provenance, « corrigé » peut signifier seulement que l’émetteur a changé, alors que le lecteur ne sait plus ouvrir des archives. Il peut aussi signifier que tout est accepté éternellement, y compris de nouveaux objets incorrects. Dans le pire cas, un système réencode un objet signé et détruit la preuve nécessaire à l’analyse de sa signature.

Le but n’est pas de conserver les messages ou les clés privées dans un registre de gouvernance. Des hachages de corpus, des versions logicielles, des résultats de validation, des exceptions bornées et des dates de décision suffisent. On documente le mouvement de l’autorité, pas le contenu confidentiel.

La norme minimale et la décision locale

Le projet IETF peut rester court. Il doit rétablir un OID commun, exprimer la cardinalité dans le module et exposer la conséquence de sécurité. Il n’a pas à choisir une durée universelle de compatibilité pour toutes les archives et tous les secteurs.

Cette séparation rejoint le principe de spécification initiale minimale de Heng Lu. Le niveau commun fixe ce qui rend l’interopérabilité possible. Les décisions futures — durée de lecture de l’ancien format, contraintes réglementaires, coût d’une mise à niveau — restent locales, à condition de ne pas redéfinir le sens partagé du protocole.

Le Policy Mirror impose alors une hygiène de vocabulaire. « Le registre IANA porte la bonne valeur », « le décodeur reconnaît l’ancienne », « la politique lui accorde une valeur probante » et « le producteur émet la nouvelle » sont quatre faits. Les réduire à une case verte appelée « conforme RFC 6211 » efface précisément la divergence qu’il faut gouverner.

Une correction publiée indique la destination. Le travail institutionnel consiste à faire converger les modules, les bibliothèques, les objets et les décisions, puis à prouver que le détour hérité peut être fermé.

Sources