Résumé
- RFC 9964 définit le type générique Algorithm Key Pair et enregistre ML-DSA-44, ML-DSA-65 et ML-DSA-87 pour JOSE et COSE afin de rendre l’expression des clés cohérente.
- La forme d’une clé, son
alget une signature vérifiée ne constituent ni une provenance de clé, ni une autorité d’émetteur, ni une règle d’acceptation des assertions.
Dans un système de confiance, une description exacte est souvent prise pour une justification. C’est le glissement à éviter. Lire alg permet de savoir quel calcul vérifier. Lire pub permet de localiser le matériau public. Ces propriétés sont indispensables, surtout lorsqu’un objet cryptographique traverse des bibliothèques, des produits et des organisations. Elles ne répondent pourtant pas à la question qui gouverne l’action: pour quelle raison cette clé mérite-t-elle de produire un effet ici?
RFC 9964 organise la première partie du problème. Michael Prorock et Orie Steele y spécifient l’usage des clés et signatures ML-DSA dans JOSE et COSE. Le document introduit Algorithm Key Pair, AKP, une structure générique qui n’est pas enfermée dans les seuls algorithmes enregistrés par cette RFC. Chaque AKP doit comporter alg et pub; priv désigne l’information privée et ne doit jamais figurer dans une clé publique. C’est une discipline de représentation: elle rend visible le type de matériel reçu et les contrôles de paramètres attendus.
Cette discipline apparaît nettement dans le choix du secret ML-DSA. FIPS 204 prévoit une graine et une forme développée de clé privée. RFC 9964 retient seulement la graine afin que JOSE et COSE partagent une représentation compacte: priv doit être une graine de 32 octets. Cette décision réduit une source de divergence et clarifie la gestion de clé. Elle ne renseigne pas l’origine de la graine, sa conservation, le canal qui a porté la clé publique ni la légitimité de l’émetteur qui l’utilise.
Les identifiants enregistrés — ML-DSA-44, ML-DSA-65 et ML-DSA-87 — ont le même statut limité. Ils permettent à deux extrémités de nommer les mêmes choix de paramètres dans les registres JOSE et COSE. Ils ne choisissent pas une ancre de confiance, ne relient pas une clé à une identité, ne contrôlent pas le sujet d’une assertion et n’énoncent pas ce qu’un service peut autoriser après une vérification réussie. Ces décisions exigent des preuves distinctes et un propriétaire de politique identifiable.
Le texte signale aussi que les clés et signatures ML-DSA sont grandes et peuvent être mal adaptées à des contraintes de bande passante, de mémoire ou de traitement. Ce n’est pas un jugement sur un déploiement précis; c’est une séparation entre conformité de format et possibilité d’exploitation. RFC 9964 renvoie l’analyse détaillée de sécurité à FIPS 204 et RFC 9881. La norme ne se donne donc pas l’autorité qu’elle ne possède pas.
La contribution durable de Prorock, dans cette œuvre coécrite, est cette retenue technique: rendre l’expression d’une clé et de son algorithme plus déterminée sans transformer la syntaxe en permission. Le vérificateur qui décide de se fier à une clé doit toujours pouvoir expliquer son canal de distribution, son ancre de confiance, ses règles sur les assertions et la conséquence qu’il a choisie.
Sources
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
