Questions ouvertes

Label 309 v1 est gelé. Le format de sérialisation (wire format) sous le label de métadonnées 309, l’encodage en CBOR canonique, les registres d’algorithmes, l’enveloppe de la PoE scellée et la construction de la signature sont arrêtés : un vérificateur v1 conforme lit chaque enregistrement v1, et un producteur v1 conforme émet des enregistrements que tout vérificateur v1 accepte. Cette page ne vise pas à modifier cela. Elle constitue le registre de ce qui est confirmé dans le standard aujourd’hui et de ce qui reste prospectif — des constructions cryptographiques candidates réservées à une éventuelle révision future, ainsi que la procédure rigoureuse pour modifier une constante cryptographique lorsque l’une d’elles se concrétise.

Rien de ce qui figure ici n’est une feuille de route produit. Chaque entrée est une décision technique au niveau du protocole : un identifiant d’algorithme, une dérivation, une politique du vérificateur ou une règle de versionnage. Quiconque implémente le standard a besoin de la moitié arrêtée pour construire une implémentation v1 aujourd’hui, et de la moitié prospective pour la construire de façon qu’un futur successeur post-quantique ou fondé uniquement sur des RFC soit une entrée de registre additive, jamais une réécriture.

Constructions arrêtées

Ces décisions sont prises. Elles sont énoncées ici sans détour parce qu’elles constituent les choix structurants que quiconque implémente souhaite le plus souvent voir confirmés en un seul endroit ; les pages liées développent la construction complète.

Le KEM post-quantique est inclus dans la v1

Le KEM hybride X-Wing (ML-KEM-768 composé avec X25519) est enregistré sous l’identifiant mlkem768x25519 dans le registre enc.kem dès la première publication. Ce n’est pas un candidat futur : il réside dans enc.scheme: 1 aux côtés du KEM classique x25519, et le champ enc.kem présent dans la sérialisation sélectionne, pour chaque enregistrement, le KEM par emplacement, la forme de l’emplacement et la dérivation de la clé de chiffrement de clé.

X-Wing est consommé comme une boîte noire : la construction n’utilise que son interface publique — encapsuler, décapsuler et le secret partagé de 32 octets — et ne formule aucune hypothèse sur le hachage interne du combinateur. Les deux KEM dérivent la KEK par emplacement sous une unique forme de sel à hachage étiqueté, SHA-256(label || enc.nonce || <matériel KEM de l’emplacement> || pub_R), calculée sur les octets de sérialisation propres à l’emplacement : sur le chemin hybride, SHA-256("cardano-poe-xwing-kek-salt-v1" || enc.nonce || kem_ct || pub_R). Hacher vers une taille fixe de 32 octets lie le nonce de l’enveloppe, le texte chiffré et la clé publique du destinataire dans la KEK, tout en dissolvant l’ambiguïté d’analyse qu’un texte chiffré post-quantique de longueur variable créerait avec un sel à simple concaténation. Seule la variante hybride est exposée — le ML-KEM pur est délibérément écarté afin que la branche X25519 préserve la sécurité classique si ML-KEM-768 venait à être cassé. Voir PoE scellée et Registres d’algorithmes.

L’engagement de clé scellée lie l’en-tête et l’affirmation de hachage

Les deux chemins scellés engagent la clé de chiffrement du contenu dans une transcription fermée, sérialisée avec la même fonction de CBOR canonique qu’utilise le reste de l’enveloppe, qui fixe les champs d’en-tête et l’affirmation de hachage du texte en clair de l’élément (hashes_hash). Sur le chemin adressé au destinataire (enc.slots), l’engagement est sur la chaîne : slots_mac est un HMAC à clé dérivée de la CEK sur une transcription qui transporte les identifiants de scheme, path, AEAD et KEM, le nonce, l’ensemble d’emplacements mélangé et hashes_hash — de sorte qu’un relais ne peut greffer un texte chiffré sur un ensemble d’emplacements différent ni sur une affirmation de hachage différente sans faire échouer la vérification du MAC sur la chaîne, avant même toute récupération du texte chiffré. Le chemin par phrase secrète (enc.passphrase) transporte un engagement équivalent dans un en-tête de 32 octets à l’intérieur du blob de texte chiffré, sur une transcription qui ajoute le sel et les paramètres d’Argon2id — de sorte qu’altérer les entrées du KDF fait échouer la vérification de l’engagement. Le contenu lui-même est ensuite scellé dans un STREAM segmenté sous une clé de contenu dérivée de la CEK ; l’AAD par segment est vide, parce que chaque champ d’en-tête est déjà lié à cette clé de manière transitive. Construction complète sur PoE scellée.

La profondeur de confirmation relève de la politique du vérificateur

Un enregistrement est ancré dès l’instant où sa transaction est incluse, mais un vérificateur qui décide du degré de règlement à exiger avant de rendre un verdict applique un seuil de profondeur de confirmation. Label 309 en fait une politique du vérificateur, et non un MUST normatif. Le standard définit la surface lisible par machine — une transaction en deçà du seuil est signalée pending (le code typé INSUFFICIENT_CONFIRMATIONS), jamais failed, et peut se résoudre en valid lors d’une nouvelle tentative — tandis que le seuil lui-même (RECOMMANDÉ ≥ 15 blocs) est un paramètre configuré au déploiement, et non une constante gravée dans le format de sérialisation. Un vérificateur qui exige un règlement plus profond pour des affirmations de forte valeur est pleinement conforme. Voir Vérification.

La vérification Ed25519 est stricte

Les signatures au niveau de l’enregistrement DOIVENT être vérifiées selon les règles strictes de RFC 8032 §5.1.7, et non selon la tolérance plus permissive de la vérification par lots de ZIP-215. La vérification stricte rejette les encodages non canoniques et les points d’ordre petit qu’un vérificateur tolérant accepterait, de sorte que deux vérificateurs conformes parviennent toujours au même verdict sur une même signature. Quiconque implémente doit confirmer que sa bibliothèque Ed25519 est en mode strict ; certaines bibliothèques adoptent par défaut la variante tolérante. Voir Signatures.

Le CBOR canonique est le contrat de déterminisme

Chaque enregistrement est encodé en CBOR canonique conformément à RFC 8949 §4.2.1 : formes entières préférées, tableaux et maps de longueur définie, clés de map triées octet par octet, aucune clé dupliquée, aucune balise. Le déterminisme est ce qui permet qu’une signature calculée sur le corps par une implémentation se vérifie sous une autre, et ce qui permet à deux producteurs du même enregistrement logique d’émettre des octets identiques. Cette exigence est non négociable dans toute implémentation conforme et constitue le fondement du contrat de parité entre langages.

Candidats prospectifs

Les éléments ci-dessous sont des candidats, et non des constructions publiées. Aucun n’est un défaut de la v1 ; aucun n’est engagé. Ils sont consignés pour qu’une implémentation construite aujourd’hui leur laisse de la place en tant qu’entrées de registre additives, et pour qu’un futur relecteur puisse voir quelles évolutions la conception agile à l’égard des algorithmes anticipe déjà.

Un profil d’AEAD de contenu alternatif réservé

La couche de contenu de la PoE scellée en v1 est chacha20-poly1305-stream64k — le ChaCha20-Poly1305 de RFC 8439 dans la disposition STREAM segmentée — qui est elle-même adossée à une RFC, de sorte qu’il n’y a aucune question ouverte sur le statut formel du chiffrement de contenu actuel. Ce qui reste réservé est une voie vers un AEAD de contenu différent si un contexte de déploiement venait à en exiger un. L’identifiant aes-256-gcm (NIST SP 800-38D) est réservé dans le registre des AEAD à cette fin et ne fait pas partie de enc.scheme: 1 : un enregistrement qui le nomme suit aujourd’hui la règle de l’enveloppe inconnue.

Son introduction serait une future construction enc.scheme: 2 qui préserve les modèles existants slots[] + slots_mac et d’engagement par phrase secrète, mais remplace la couche de contenu, en fixant pour ce chiffrement la nouvelle taille de segment, la dérivation de la clé de contenu, la construction du nonce par segment, l’AAD par segment et l’authentification du segment final. Il s’agit d’un profil de repli, et non d’un remplacement : les enregistrements enc.scheme: 1 existants restent valides, et le profil ne doit pas être implémenté avant qu’une définition normative de enc.scheme: 2 et ses vecteurs de test existent.

Algorithmes de signature post-quantiques réservés

La moitié KEM de la trajectoire post-quantique est incluse dans la v1 (ci-dessus). La moitié relative à la signature est réservée mais pas encore implémentée. Deux familles sont candidates pour s’insérer dans le registre des signatures existant une fois que l’IETF COSE aura stabilisé les identifiants d’algorithmes post-quantiques :

Parce que l’algorithme de signature est un identifiant nommé dans l’en-tête protégé COSE, enregistrer un successeur est purement additif : les enregistrements Ed25519 existants continuent de se vérifier, et un vérificateur qui ne reconnaît pas un nouvel algorithme de signature émet un signal d’algorithme non pris en charge plutôt que de rejeter l’affirmation de contenu. Une signature non reconnue n’invalide jamais la preuve d’existence sous-jacente. Voir Signatures.

Une voie de publication v: 2 possible

Les ajouts individuels — un nouveau KEM, un nouvel AEAD de contenu, un nouvel algorithme de signature — sont des entrées de registre qui ne modifient pas le schéma de l’enregistrement de niveau supérieur. L’ajout d’un KEM en particulier est une entrée de registre sous enc.scheme: 1, et non un incrément de scheme ; un incrément de enc.scheme est réservé à un changement de construction transversal aux KEM (un nouveau slots_mac ou un nouvel AEAD de contenu qui s’applique à tous les KEM à la fois).

Si suffisamment de candidats modifiant le schéma de l’enregistrement s’accumulent, le changement cumulé peut justifier un enregistrement v: 2 de niveau supérieur publié aux côtés de la v1. Les deux versions resteraient des schémas de métadonnées valides sous le label 309 ; un vérificateur sélectionne selon le discriminateur v à l’intérieur de l’enregistrement. Les étapes du chemin vers la standardisation se répètent pour la nouvelle révision. C’est l’évolution de plus grande portée et elle n’est déclenchée que par accumulation — rien de ce qui figure ici n’est planifié.

Résolution optionnelle de la substitution à un seul saut

Le champ optionnel supersedes d’un enregistrement pointe vers un enregistrement antérieur par le hachage de transaction. Résoudre ce pointeur est optionnel pour un vérificateur. Un vérificateur qui confirme que supersedes est structurellement un hachage de 32 octets mais ne récupère pas la transaction antérieure est conforme, mais il manque l’occasion de faire apparaître la chaîne de substitution. Orientation : un vérificateur PEUT résoudre un seul saut — interroger à nouveau le résolveur de transactions pour le hachage référencé et signaler son existence et l’heure du bloc — sans pousser la récursion plus loin. Un saut suffit ; le parcours plus profond relève de la responsabilité de l’appelant, et la substitution ne révoque jamais l’enregistrement antérieur, que la chaîne maintient vérifiable de manière autonome pour toujours.

Migrer une constante cryptographique

Chaque construction arrêtée ci-dessus dépend de constantes nommées : identifiants d’algorithmes, chaînes info de HKDF, sels de KDF, longueurs de nonce d’AEAD, étiquettes de séparation de domaine. Modifier le sens de l’une d’elles est une rupture du format de sérialisation, et le standard prescrit exactement un chemin rigoureux pour cela. La règle directrice : utilisez le changement de plus petite portée qui résout le problème, et ne modifiez jamais en silence le sens d’une constante existante sous le même espace de noms.

La procédure est additive et rétrocompatible — les anciens enregistrements continuent de se vérifier sous les constantes avec lesquelles ils ont été publiés — et progresse par portée :

1. Versionner l’espace de noms, pas la valeur. Une dérivation modifiée incrémente le suffixe -vN sur chaque chaîne de séparation de domaine qu’elle touche : chaînes info de HKDF (…-v1 → …-v2), préfixes de message HMAC, sels et étiquettes. Une nouvelle constante réside sous le nouveau suffixe ; l’ancienne constante reste valide sous l’ancien suffixe. Les vérificateurs plus anciens rejettent proprement les enregistrements plus récents dès le discriminateur, au lieu de les interpréter de travers.

2. Incrémenter le discriminateur qui correspond au rayon d’impact. Un changement confiné à une seule famille d’emplacements est sélectionné par enc.kem ; un changement transversal aux KEM portant sur la couche de contenu ou l’engagement de l’ensemble d’emplacements est un incrément de enc.scheme ; un changement au schéma de l’enregistrement lui-même est un incrément v de niveau supérieur. Chaque discriminateur circonscrit la rupture à la plus petite couche qui a effectivement changé.

3. Maintenir les prédécesseurs vérifiables. Les versions plus anciennes des enregistrements restent lisibles en tant que schémas gelés. Un vérificateur sélectionne la construction d’après les propres discriminateurs de version de l’enregistrement, de sorte qu’une seule implémentation peut vérifier la v1 et un futur successeur côte à côte. Aucun enregistrement ne cesse jamais de se vérifier parce qu’un successeur a été publié.

Pages connexes

• Registres d’algorithmes — les identifiants nommés dont les espaces de noms se versionnent lors d’une migration.
• PoE scellée — le KEM hybride X-Wing, la liaison à la transcription d’engagement de clé et les discriminateurs enc.scheme / enc.kem.
• Signatures — la vérification stricte d’Ed25519 et le registre des signatures auquel se joindraient les algorithmes post-quantiques réservés.