Résumé

  • Le groupe COSE a déposé le 24 septembre 2026 la version 21 de son projet de certificat C509. L'IESG avait approuvé la version 20 en juillet ; aucun RFC définitif n'en découle encore.
  • Le nouveau texte délimite la séquence CBOR soumise à signature, impose une chaîne d'octets pour le numéro de série et réserve la forme abrégée de l'émetteur à une identité octet par octet avec le sujet.
  • Une conversion réversible d'un certificat signé en DER et un certificat signé directement en CBOR n'empruntent pas le même chemin de vérification. La validation de la chaîne X.509 reste requise.

Le gain de place n'est pas une preuve de continuité cryptographique. Un équipement peut recevoir une représentation raccourcie d'un certificat sans que son vérificateur sache nécessairement reconstituer le message original soumis à signature. La question n'est donc pas seulement de savoir combien d'octets ont disparu, mais lesquels seront présentés à l'algorithme de vérification.

Le projet C509 répond à cette question par deux types de certificat. Le type 3 réencode de manière réversible un X.509 en DER : la signature reste celle de l'objet DER et il faut pouvoir retrouver cet objet pour la contrôler. Le type 2 est signé sur la représentation CBOR elle-même. Il évite certains traitements ASN.1 dans un environnement qui le prend en charge, mais ne devient pas pour autant lisible par un vérificateur qui n'accepte que le DER. L'équivalence de sémantique revendiquée par le projet ne promet pas une compatibilité universelle des logiciels installés.

La version 21 resserre maintenant plusieurs points où une conversion pourrait être interprétée de deux façons. Elle décrit le certificat comme un tableau CBOR dont les éléments forment une séquence, puis identifie le groupe TBSCertificate, sans la valeur finale de signature, comme séquence à signer. Le numéro de série demeure une chaîne d'octets CBOR même s'il est assez petit pour tenir dans un entier ordinaire. Pour reconstruire le DER du type 3, le zéro initial est restitué si le bit de poids fort l'exige. Le champ émetteur ne peut devenir null que si émetteur et sujet sont identiques octet par octet, et non simplement semblables à l'écran.

Ces précisions sont pertinentes pour des essais d'interopérabilité. Elles ne constituent ni un rapport de vulnérabilité ni la preuve qu'un convertisseur existant aurait mal fonctionné. La version précédente avait déjà reçu l'approbation de l'IESG le 20 juillet et rejoint la file de l'éditeur des RFC. La nouvelle soumission du 24 septembre intervient dans cette file. À la date de consultation, le suivi indique encore une contribution des auteurs attendue par l'éditeur et une action IANA en attente ; le texte n'a pas de numéro RFC final.

Le lieu de la décision de confiance ne change pas non plus. Le projet maintient la validation du chemin de certification définie par le RFC 5280 et traite les en-têtes de certificat COSE comme des données non fiables tant qu'un mécanisme approprié ne les a pas vérifiées. Un identifiant dans un registre IANA n'est pas une recommandation d'algorithme. La taille réduite peut aider des liaisons contraintes, mais les exemples chiffrés du projet ne démontrent ni adoption générale ni sûreté d'une flotte précise.

Un dossier d'essai utile rattacherait chaque certificat au type C509 employé, à la version du convertisseur, aux octets exacts signés, au résultat de reconstruction et aux catégories de vérificateurs réellement testées. C'est une méthode de revue proposée ici, non une obligation décidée par l'IETF. Elle évite surtout de faire porter à un changement de format une décision que seul le responsable du chemin de confiance peut prendre.

Sources