Résumé

  • RFC 9964 définit AKP pour ML-DSA dans JOSE et COSE : alg et pub sont requis, tandis que priv n’appartient jamais à une clé publique.
  • FIPS 204 admet une graine et une clé privée étendue ; RFC 9964 ne transporte que la graine de 32 octets afin d’obtenir un format unique. La graine et la clé étendue exigent pourtant le même niveau de protection.
  • Une empreinte, une clé bien formée et une signature valide apportent des preuves cryptographiques. La garde, la demande de signature, l’autorisation, le renouvellement et l’effet métier nécessitent d’autres décisions.

Une règle de format ne devient pas un titre de garde

JOSE et COSE doivent pouvoir reconnaître une même clé ML-DSA sans que chaque mise en œuvre invente sa propre convention. AKP fournit cette surface minimale : l’algorithme choisi, les informations publiques et privées, et les paramètres permettant de valider une clé ou de calculer son empreinte publique. La clé JWK encode les octets en base64url ; COSE peut transporter les octets directement. Le résultat est comparable et reproductible.

Cette reproductibilité est une force, mais elle a un objet limité. L’empreinte AKP est calculée à partir de kty, alg et pub. Elle exclut volontairement l’information privée. Elle peut donc répondre à la question : « est-ce la même clé publique sous le même algorithme ? » Elle ne peut pas répondre à « qui conserve la graine ? », « qui a demandé cette signature ? » ou « quel système devait accepter le document signé ? ».

FIPS 204 distingue une graine et une expression de clé privée obtenue par expansion. RFC 9964 choisit la première pour priv, exige 32 octets et refuse de définir l’autre format dans AKP. Ce choix réduit les variantes entre JOSE et COSE et facilite un contrôle de longueur clair. Il ne réduit pas la sensibilité du matériau. Qu’un tiers obtienne la graine ou la clé étendue, il peut produire des signatures et compromettre authenticité et intégrité.

Dire « nous ne stockons qu’une graine » ne signifie donc pas « nous n’avons pas de problème de garde ». Cela signifie qu’une forme compacte capable de produire la clé de signature a été choisie. La RFC peut vérifier cette forme ; elle ne décide pas si la graine réside dans un module, une procédure de reprise, un service logiciel, une copie de secours ou une délégation. Ces choix sont locaux parce qu’ils portent les coûts locaux d’une erreur.

La signature ne doit pas absorber les décisions qui l’entourent

L’erreur fréquente est la compression sémantique. Une équipe reconnaît un AKP, trouve l’empreinte attendue et vérifie une signature ML-DSA. Elle en déduit alors que le bon acteur a signé, que la demande était permise, que la politique de rotation a été respectée et que l’objet doit modifier un système. La RFC ne produit aucune de ces conclusions.

Elle fournit des contraintes techniques nécessaires : les paramètres associés doivent être validés avant usage lorsque l’algorithme le requiert ; l’algorithme et les octets publics doivent correspondre ; la clé privée ne doit pas apparaître dans une représentation publique. Ces faits sont suffisamment communs pour l’interopérabilité. Les autres faits — délégation, sauvegarde, révocation, séparation des tâches et acceptation par un service — doivent demeurer visibles dans une décision locale.

La taille de ML-DSA confirme cette nécessité. Les clés publiques et les signatures sont sensiblement plus grandes que les alternatives traditionnelles. RFC 9964 avertit que certains environnements à mémoire, traitement ou bande passante limités peuvent ne pas convenir. Une inscription IANA ne force pas l’adoption réelle. Chaque opérateur peut tester un chemin, adopter un profil, refuser une taille et conserver un chemin compatible. La publication est une possibilité d’interopérer, non une obligation universelle.

Une chaîne divisible rend l’incident réparable

Conserver cinq preuves séparées : le registre public AKP et l’empreinte ; l’arrangement de garde de la graine ; la demande précise de signature ; l’autorisation locale de cette demande ; enfin la vérification et l’effet accepté ou refusé par le système destinataire. Une clé peut être valide tandis qu’une demande est bloquée. Une signature peut vérifier tandis qu’un vérificateur refuse son type de message. Une révocation peut interrompre l’avenir sans effacer le fait qu’une signature passée a vérifié.

Cette séparation suit la règle de Heng Lu : ne placer dans la couche commune que les invariants déterministes dont les participants ont besoin. AKP rend des clés comparables, pas un registre souverain. La portabilité de la représentation doit faciliter la sortie et l’audit, non concentrer la garde et l’autorisation dans un détenteur d’identifiants.