Résumé
- Le 8 septembre 2026, le Datatracker a fait passer
draft-ietf-lake-edhoc-pskà l’étatWG Consensus: Waiting for Write-Up, puis la révision 09 a été publiée. Le texte reste un Internet-Draft, sans approbation de l’IESG ni numéro de RFC. - Une valeur
ID_CRED_PSKpeut maintenant correspondre à plusieurs ensembles candidats : PSK,CRED_I,CRED_Ret informations de traitement. Le répondant essaie les candidats jusqu’au succès ou à l’épuisement. - Le même identifiant reçu peut donc aboutir à des contextes acceptés différents selon la table locale du répondant. Un journal qui ne conserve que cet identifiant ne suffit plus.
- Daniel Kade propose d’enregistrer la version de l’ensemble candidat, la version non secrète du justificatif retenu et le résultat des essais. Cette proposition éditoriale ne figure pas dans le projet.
Le changement tient dans une recherche locale, pas dans une liste envoyée sur le réseau. L’initiateur place ID_CRED_PSK dans la partie protégée du troisième message EDHOC. Le répondant déchiffre ce premier niveau, lit l’identifiant et consulte sa propre base. C’est cette base — et elle seule — qui transforme une petite valeur en un ou plusieurs contextes d’authentification.
La révision 09 décrit le parcours sans détour. Le répondant récupère les candidats, choisit le premier, calcule K_3 et IV_3, puis vérifie CIPHERTEXT_3B avec l’algorithme AEAD de la suite EDHOC. Si cette vérification échoue, il prend un autre candidat. L’échec global n’arrive qu’après épuisement ; le succès atteste la possession de la PSK correspondant au candidat retenu.
L’ancienne singularité devient un cas efficace
La révision 08 parlait encore de retrouver « la bonne PSK ». Elle recommandait un identifiant unique ou stochastique, notamment pour éviter l’ambiguïté et plusieurs essais de clés. La comparaison officielle montre le déplacement : la version 09 conserve la recommandation d’un contexte unique ou stochastique, mais précise qu’une valeur peut désigner plusieurs candidats. L’absence d’ambiguïté devient la voie rapide recommandée, non une condition absolue du traitement.
Cette évolution répond à une remarque concrète du dernier appel. Dans la discussion archivée, les étapes « sélectionner le premier candidat » puis « réessayer avec un nouveau candidat » apparaissent déjà sous forme de proposition de clarification. Le 8 septembre, l’historique Datatracker enregistre la sortie de l’état de dernier appel, la désignation de Marco Tiloca comme document shepherd et le dépôt de la nouvelle révision.
Il faut garder la séquence institutionnelle exacte. L’état WG Consensus: Waiting for Write-Up signifie que le groupe prépare l’étape suivante. Il ne signifie pas que l’IESG a approuvé le document, qu’un RFC a été publié ou que le texte ne changera plus. La fiche courante le présente comme projet actif du groupe LAKE, destiné à la voie normative.
Le candidat contient davantage qu’une clé
Le mot « PSK » peut réduire abusivement l’objet essayé. La valeur retrouvée associe une clé à CRED_I, CRED_R et aux informations utiles au traitement EDHOC. Les deux justificatifs d’identité doivent être distincts afin de limiter les attaques par réflexion et les mauvaises liaisons d’identité. Le contexte doit aussi correspondre à l’algorithme de hachage de la suite négociée. Changer de candidat, c’est donc changer un ensemble cohérent, pas seulement remplacer une suite d’octets dans une opération cryptographique.
RFC 9528, qui définit EDHOC, sépare déjà la référence compacte du justificatif qu’elle permet de retrouver. RFC 9052 traite kid comme un identifiant exploité par l’application, non comme un nom universellement unique. RFC 8392 fournit, avec CWT et CCS, un format possible pour les informations associées. Aucun de ces étages ne transforme le petit identifiant en preuve autonome de l’identité.
Les essais multiples ne sont pas non plus une recherche de mots de passe. Le projet impose aux PSK externes au moins 128 bits d’entropie et une longueur minimale de 128 bits ; il exclut les mots de passe et autres sources de faible entropie. Il s’agit de contextes provisionnés qui partagent une clé de recherche, pas de suppositions fabriquées par le répondant.
Le chevauchement a un coût de preuve
Le texte ne donne pas de cas obligatoire pour la pluralité. On peut néanmoins identifier des usages plausibles, en les maintenant au rang d’analyse : rotation avec ancienne et nouvelle clé simultanément valides, convergence lente de bases de provisionnement, identifiant compact réutilisé dans plusieurs partitions, ou secours conservé pendant la confirmation d’un remplacement.
Ces mécanismes peuvent éviter une interruption. Ils rendent aussi décisifs l’ordre local, la taille de la liste et la date de retrait d’un candidat. Deux répondants recevant le même message peuvent aboutir à la même réponse positive après un nombre d’essais différent, voire sélectionner des versions différentes si leurs tables ont divergé. Si le journal affiche seulement ID_CRED_PSK, il masque précisément l’état qui explique le résultat.
La réponse proportionnée n’est pas de publier la PSK ni l’identité d’un appareil. Pour chaque succès ou épuisement, le répondant peut conserver une empreinte de l’identifiant reçu, une version ou une empreinte de l’ensemble candidat, le nombre de candidats, la version non secrète du justificatif retenu, la suite et le hachage EDHOC, le nombre d’essais, le résultat, la version de politique et l’heure. Des agrégats par tranche de taille permettent d’observer la latence sans exposer une trajectoire individuelle.
Ce reçu aurait une utilité immédiate lors d’une rotation. Si les succès passent progressivement du premier au deuxième candidat, le déplacement devient mesurable. Après la date de retrait, la même courbe révèle au contraire un état périmé. Si des répondants censés partager la même politique publient des versions d’ensemble différentes, l’écart apparaît avant que « la PSK a échoué » ne devienne la seule explication disponible.
Cette structure de journal est une proposition de Daniel Kade, non une exigence de la révision 09. Le projet décrit le traitement cryptographique. Il reste aux profils et aux opérateurs à empêcher qu’une sélection désormais plurielle laisse une mémoire artificiellement singulière.
Sources
- IETF Datatracker — EDHOC avec clés prépartagées
- Historique du document
- Révision 09
- Révision 08
- Comparaison officielle des révisions 08 et 09
- Discussion du dernier appel sur les PSK candidates
- RFC 9528 — EDHOC
- RFC 9052 — structures COSE
- RFC 8392 — CBOR Web Token
- RFC 9668 — emploi d’EDHOC avec OSCORE
- Groupe de travail IETF LAKE
- Avis et revue du dernier appel du groupe
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

