Résumé

  • La révision 03 d’un Internet-Draft du groupe LAMPS, publiée le 14 septembre, mettrait à jour le RFC 5652 et interdirait id-data pour les nouveaux usages de CMS SignedData.
  • Elle classe un usage selon la date où une spécification définit pour la première fois l’application, à compter de la future publication du document, et non selon la mise en œuvre ou le déploiement du logiciel.
  • Les usages existants reçoivent des recommandations de migration et de vérification plutôt que la même interdiction absolue, car une modification générale peut rompre l’interopérabilité avec des émetteurs déjà déployés.
  • Le texte vise le statut Best Current Practice mais reste un projet actif : ce n’est ni un RFC, ni une règle adoptée, ni la preuve d’une exploitation ou d’un produit vulnérable.

Une date qui n’existe pas encore

La révision 03 ajoute une proposition explicite à son en-tête et à son résumé. Si elle était approuvée, elle mettrait à jour le RFC 5652, norme actuelle de Cryptographic Message Syntax, en interdisant le type id-data aux nouveaux usages de CMS SignedData.

La définition ajoutée porte l’essentiel de la décision. Est nouveau tout usage qu’une spécification définit pour la première fois, à partir de la date de publication du futur document, en indiquant comment SignedData doit être produit ou traité pour une application. Peu importe que cette spécification ultérieure soit un RFC ou qu’elle inscrive un identifiant auprès de l’IANA. Ce qui précède la publication devient un usage existant.

La ligne est claire, mais prospective. La fiche Datatracker montre un Internet-Draft actif d’un groupe de travail, dont le statut visé est BCP. Le RFC 2026 rappelle qu’un Internet-Draft est un document de travail. La révision peut orienter l’examen ; son dépôt ne modifie pas à lui seul STD 70.

L’âge du texte n’est pas l’âge du déploiement

La comparaison officielle fait apparaître deux horloges qu’il faut conserver séparément.

La définition classe le protocole par la première spécification. Une autre phrase précise que l’interdiction applicable aux nouveaux usages ne remet pas rétroactivement en cause la conformité des implémentations déjà déployées. Les deux propositions sont compatibles, mais ne prouvent pas la même chose. Un protocole peut être spécifié avant tout déploiement significatif. Un logiciel peut être livré longtemps après son texte fondateur. Un émetteur ancien peut continuer à fonctionner après l’apparition d’une version de remplacement.

Le projet ne publie pas de recensement reliant ces états, et ne prétend pas le faire. Ses annexes citent des RFC utilisant id-data et examinent l’applicabilité, mais une référence normative ne mesure pas un parc installé. Une ligne IANA identifie un objet et sa source ; elle ne démontre ni le chemin de code réellement emprunté, ni le contrôle de signedAttrs par le destinataire, ni la réutilisation d’une même clé entre plusieurs protocoles.

Le problème de sécurité dépend du comportement. Le RFC 5652 autorise l’absence de signedAttrs lorsque le type encapsulé est id-data. Le projet explique comment une signature peut alors être valide pour une structure que le signataire n’avait pas explicitement voulu signer. Il décrit aussi les limites : certains protocoles imposent les attributs signés, une vérification correcte peut bloquer l’attaque, la structure du message réduit parfois son applicabilité et des mesures compensatoires existent. « Existant » ne signifie donc pas « vulnérable », pas plus que « nouveau » ne prouve une implémentation sûre.

La compatibilité fait partie de la décision

Pour un nouvel usage, le texte dit que id-data MUST NOT être utilisé. Si le contenu est MIME, le nouveau type mimeData SHOULD être choisi, sauf motif en faveur d’un identifiant plus spécifique. Le projet demande trois opérations à l’IANA, mais les numéros restent TBD. Les registres actuels des numéros SMI et des types internes CMS ne transforment pas ces variables en allocations.

Pour un usage existant, l’itinéraire change. Lors d’une mise à jour du protocole, id-data devrait être abandonné. S’il est conservé, la révision demande un motif permettant aux relecteurs d’évaluer le compromis de sécurité. Une extension compatible peut être un mauvais moment pour imposer une rupture ; une version majeure ou un changement déjà incompatible peut offrir la fenêtre adéquate.

Ce n’est pas une échappatoire dissimulée. C’est le jugement d’interopérabilité exposé par le projet. Des émetteurs en service peuvent ne pas produire signedAttrs comme l’exigerait une règle durcie. Un MUST général ferait rejeter un trafic ancien légitime avant l’existence d’un chemin de migration. La question de gouvernance consiste donc à rendre traçable l’usage de cette marge et les éléments qui la justifient.

Clés, bibliothèques et applications

La révision 03 ajoute une section sur la séparation des clés. Imposer les attributs signés dans un protocole ne suffit pas si la même clé signe aussi dans un autre protocole ou une ancienne version où ils ne sont pas obligatoires. Le texte évoque des clés distinctes ou une mesure appliquée uniformément à toutes les opérations de signature de la clé.

Il fixe également une limite aux bibliothèques CMS génériques. Pour les nouveaux usages, le destinataire doit vérifier le type attendu et la présence requise des attributs. Si la bibliothèque ne connaît pas la règle du protocole, elle doit exposer le type reçu à l’application afin que celle-ci décide.

La surface de contrôle dépasse donc une phrase normative. Les auteurs de protocoles choisissent type et transition. Les mainteneurs de bibliothèques préservent l’information et les points de contrôle. Les applications font appliquer l’attente locale. Les responsables de clés décident de leur portée. L’IANA enregistre les identifiants. Aucun acteur ne peut, isolément, certifier la migration complète d’un déploiement.

Un inventaire de transition sans verdict global

Un inventaire public et compact rendrait la frontière vérifiable. Chaque usage connu de CMS SignedData pourrait indiquer : la première spécification et sa date ; le type de contenu et la règle signedAttrs ; la classe de preuve de déploiement, sans inventer de volume ; une éventuelle clé partagée ; la prochaine occasion de rupture coordonnée ; le motif de conservation ou de remplacement ; le propriétaire de la spécification, la prochaine revue et l’historique des corrections.

Ce registre est une proposition de Daniel Kade, pas une exigence du projet. Il ne déclarerait pas dangereux tout usage ancien. Il distinguerait une ancienne spécification dont les attributs sont contrôlés, un déploiement ancien au comportement inconnu et une nouvelle spécification tenue par la règle prospective.

La publication peut rester la frontière formelle. L’inventaire fournirait la carte opérationnelle qui l’entoure.

Sources