Résumé

  • Le RFC 9864 crée des identifiants qui englobent les choix nécessaires à l’opération cryptographique, notamment la courbe et la fonction de hachage. Ed25519 et Ed448 remplacent ainsi l’ambiguïté du seul nom EdDSA.
  • Un identifiant complet rend la négociation et les listes d’autorisation plus précises. Il ne prouve ni la présence du code, ni son activation, ni la liaison correcte d’une clé, ni l’acceptation par le vérificateur.

La convention cachée dans la découverte

Les métadonnées OAuth, la découverte OpenID Connect, WebAuthn et CTAP annoncent des algorithmes afin que deux parties puissent choisir un mécanisme commun. Cette fonction suppose qu’un identifiant désigne une opération déterminée. Or certains enregistrements historiques désignaient une famille et laissaient la courbe ou un autre paramètre dans la clé, dans un second champ ou dans les habitudes du protocole.

EdDSA illustre le problème. Une partie qui lit ce nom ne sait pas si son interlocuteur accepte Ed25519, Ed448 ou les deux. Dans COSE, ES256 associait ECDSA à SHA-256 sans fixer la courbe. La chaîne était donc exacte comme nomenclature et incomplète comme preuve de compatibilité.

WebAuthn a dû réduire localement COSE -8, enregistré comme EdDSA, à Ed25519 avec la courbe 6. Cette règle de profil a rendu le choix praticable, mais elle a aussi créé une signification plus étroite que celle du registre général et écarté Ed448 de cette même annonce. La solution fonctionnait précisément parce qu’elle ajoutait le fait absent.

Une opération par nom

Le RFC 9864 enregistre Ed25519 et Ed448 dans JOSE et COSE, avec les valeurs COSE -19 et -53. Pour ECDSA dans COSE, ESP256, ESP384 et ESP512 lient respectivement P-256/SHA-256, P-384/SHA-384 et P-521/SHA-512. Des combinaisons Brainpool reçoivent aussi des identifiants distincts.

Le format de clé ne change pas de nature. Une clé Ed25519 conserve la représentation du RFC 8037 ; si le champ alg est présent, il peut désormais porter Ed25519 plutôt que EdDSA. L’annonce, la clé et la politique peuvent alors parler de la même opération complète.

Le changement atteint également l’avenir du registre. Les experts désignés pour JOSE et COSE ne doivent plus accepter de nouveaux identifiants polymorphes. Le minimum commun doit contenir les choix obligatoires au lieu de déléguer leur sens à chaque application.

Déprécié ne veut pas dire interdit

Le texte déprécie EdDSA dans JOSE et ES256, ES384, ES512 ainsi que EdDSA dans COSE. Mais il refuse une équivalence dangereuse. « Déprécié » signifie qu’un mécanisme préféré existe et devrait être utilisé dans les nouveaux déploiements, sauf contrainte opérationnelle ou réglementaire documentée. « Interdit » signifie que l’identifiant et la fonction ne doivent pas être utilisés.

Une inscription au registre ne désactive aucun parc. Des objets anciens peuvent devoir rester vérifiables ; des authentificateurs ou bibliothèques peuvent encore émettre l’ancien nom ; une réglementation peut imposer une période de conservation. Supprimer immédiatement toute lecture crée un risque de disponibilité. Continuer à produire sans échéance maintient l’ambiguïté. La direction vient du standard, mais le calendrier doit venir d’un inventaire réel.

Les absences font partie du contrat

Le RFC ne crée pas d’identifiants RSA par taille de clé. Il décrit la forme que pourraient prendre des variantes ECDH complètes sans les enregistrer. HSS-LMS reste polymorphe dans COSE parce que son identifiant ne fixe pas la fonction de hachage. Les algorithmes de chiffrement polymorphes sans remplacement ne sont pas dépréciés par ce texte.

Une migration honnête doit conserver ces cases ouvertes. Le tableau de bord ne peut pas passer tout JOSE/COSE au vert parce que quelques signatures disposent de nouveaux noms. Il faut distinguer les valeurs remplacées, celles déjà complètes, les familles non résolues et les exceptions conservées.

Le reçu exact

Un identifiant complet prouve ce que le champ nomme : une combinaison cryptographique déterminée. Il facilite les comparaisons de politiques, les tests et les règles de détection. Le RFC rappelle aussi qu’une clé ne doit servir qu’avec un seul algorithme, sauf preuve de sûreté, et recommande d’inscrire l’algorithme dans les clés JWK ou COSE en l’absence d’un autre mécanisme de liaison.

Il ne prouve pas qu’une bibliothèque implémente correctement l’opération, qu’elle est activée, qu’un module matériel l’autorise, que la clé choisie convient, que le vérificateur l’accepte ou que l’application approuve le résultat. Registre, annonce, liaison de clé, code actif, politique du vérificateur, résultat cryptographique et décision applicative restent sept couches différentes.

Sources