Summary

  • En bref. Le registre SFrame d'IANA, daté du 5 mai 2026, présente les colonnes Nh, Nka, Nk, Nn et Nt. Il attribue 0x0006 à 0x0008 aux suites AES-256-CTR/HMAC-SHA512, toutes marquées « Y » et liées à une référence provisoire à la révision 06 du projet.
  • Le suivi IETF place toujours cette révision dans la file de l'éditeur des RFC. Le tableau public renseigne les codes et les tailles ; il ne montre ni publication finale, ni logiciel en service, ni suite effectivement choisie lors d'un appel.

Une table plus précise que son ancienne version

Le RFC 9605 avait ouvert le registre avec cinq renseignements de base : valeur, nom, recommandation, référence et responsable des modifications. Pour retrouver les tailles cryptographiques, il fallait parcourir le texte du protocole. Le projet suivant fait entrer cinq dimensions dans le registre lui-même. Nh désigne la longueur de sortie du hachage, Nka celle de la clé du chiffrement sous-jacent quand la construction composée s'applique, Nk la longueur de clé, Nn le nonce et Nt le surcoût du chiffrement, généralement celui du tag.

La table en ligne a déjà pris cette forme. Les anciennes lignes ont reçu leurs valeurs. Les trois nouvelles lignes décrivent une construction AES-256-CTR avec HMAC-SHA512. Pour chacune, on lit 64 octets pour Nh, 32 pour Nka, 96 pour Nk et 12 pour Nn. Le tag varie : 10, 8 ou 4 octets. Le projet explique le passage de 48 à 96 octets de matériau interne dérivé par rapport à AES-128-CTR/HMAC-SHA256, ainsi que le passage de 32 à 64 octets pour la valeur initiale du tag. Il fournit aussi des vecteurs d'essai. Ces chiffres permettent un contrôle de conformité beaucoup plus concret qu'une étiquette « 256 bits ».

L'autre colonne décisive est « Recommended ». Un Y n'est pas apposé par simple convenance : le RFC 9605 réserve cette recommandation, ou sa modification, à une Standards Action, alors que les enregistrements ordinaires sous Specification Required reçoivent N par défaut. L'historique IETF montre qu'une discussion d'avril a précisément poussé à accorder le statut Standards Track du document avec les nouvelles lignes recommandées. Le registre expose donc une décision institutionnelle sur des noms et des paramètres. Il ne juge pas chaque emploi futur de ces suites.

Le provisoire écrit en toutes lettres

Les lignes 0x0006 à 0x0008 citent RFC-barnes-sframe-iana-256-06. C'est un renvoi provisoire, visible dans la table qui circule déjà. La révision 06 est datée du 4 mai ; IANA affiche une mise à jour au 5 mai. À la vérification du 28 octobre, le document se trouvait encore dans la file de l'éditeur des RFC, avec l'état IANA RFC-Ed-Ack. Aucun numéro de RFC final n'y était associé. Les deux dates racontent le rythme du registre et de l'édition, sans dire quand une application a commencé à utiliser les trois codes.

Le choix opérationnel commence plus loin. Le RFC 9605 confie à l'application le moment où SFrame s'applique et la suite à utiliser. Il avertit aussi que les tags d'authentification courts réclament des défenses contre la falsification ; un tag de pleine taille simplifie souvent la tâche. Les nouvelles lignes offrent 10, 8 et 4 octets. Pour une équipe qui prépare un service de visioconférence, ce choix change le dossier à présenter avant la mise en service : la longueur du tag réellement configurée, la politique de clés et les défenses contre les tentatives de falsification décrites par RFC 9605. Lire Y comme un feu vert masquerait cette vérification. Le tableau permet de demander le bon numéro et le bon Nt ; l'équipe doit prouver que son application les emploie avec des protections adaptées.

Les documents cités ne nomment aucun produit utilisant ces identifiants ; une configuration publiée et des essais en service changeraient ce constat. En attendant, le registre donne déjà un contrôle concret : si un fournisseur affirme choisir 0x0008, le lecteur peut vérifier que cette ligne signifie Nt=4, puis demander quelles défenses accompagnent ces quatre octets.