Résumé

  • ELA associe l’autorisation tierce à une session EDHOC précise : W examine U, V prouve la maîtrise de CRED_V et le bon est lié à H_12, ID_CRED_I et au justificatif de V.
  • L’identité de U est néanmoins communiquée à V, puis utilisée auprès de W, avant que U sache si l’enrôlement sera autorisé. Un arrêt du protocole ne vaut ni effacement ni interdiction de corrélation.
  • Un reçu de divulgation d’identité devrait consigner finalité, destinataires, durée de conservation, traitement d’un refus et activation d’une identité opérationnelle distincte. Il s’agit d’une proposition éditoriale, non d’une exigence de l’IETF.

La chronologie crée le vrai périmètre

Le projet draft-ietf-lake-authz-08, publié le 6 juillet 2026 puis entré en dernière relecture du groupe LAKE le 8 septembre 2026, traite un problème concret. À la date d’arrêt de la recherche, le 9 septembre 2026, il restait un Internet-Draft visant le statut Proposed Standard, et non un RFC publié; son état peut progresser par la suite. Un appareil U doit rejoindre un domaine administré par V, alors que sa confiance initiale pointe vers un serveur d’enrôlement W. U connaît à l’avance la clé publique statique et l’emplacement de W. Celui-ci peut appartenir au fabricant, mais ce n’est pas une obligation.

U engage EDHOC avec V et réutilise ID_CRED_I, suffisamment précis pour que W le reconnaisse. V emploie cette identité dans son dialogue protégé avec W. En parallèle, V s’authentifie auprès de W au moyen du même CRED_V présenté à U, et doit démontrer le lien avec la clé correspondante. W consulte sa politique locale pour décider si cet appareil peut être enrôlé par cet authentificateur.

Le résultat revient sous forme de bon. Pour U, ce bon affirme que W a autorisé V. Sa liaison au hachage de transcription H_12, à l’identité de U et au justificatif de V empêche de traiter l’autorisation comme un objet interchangeable. Une portée opaque peut l’accompagner. L’échange avec W doit réussir pour que le protocole continue, et l’achèvement par le message_4 marque l’autorisation d’interagir.

La solidité de cette construction ne modifie pas son ordre temporel. V a reçu l’identité avant le verdict. Le texte de sécurité le reconnaît : EDHOC protège l’identité de l’initiateur contre l’observation passive et les pairs non authentifiés dans son modèle, tandis qu’ELA la révèle volontairement à un V authentifié avant de savoir si l’autorisation aboutira.

La différence entre « authentifié » et « autorisé » devient alors décisive. Le premier terme indique quel justificatif contrôle V. Le second exprime la décision de W pour ce U, ce V et cette session. Aucun des deux ne détermine automatiquement ce que l’organisation derrière V peut conserver d’une tentative refusée.

Le bon ne gouverne pas les traces du refus

Un bon valide répond à une question étroite et utile. Il relie une décision au bon échange et contrarie les substitutions. Il ne certifie pas que la politique de W est légitime, à jour ou contestable. Le projet laisse d’ailleurs la définition de cette politique hors de son champ.

La même limite vaut pour les données. Lier une décision à H_12 ne fixe pas la durée d’un journal. Lier U à ID_CRED_I ne dit pas si W peut rapprocher cette identité d’un dossier fabricant. Prouver CRED_V ne décrit pas les sous-traitants de V. Une erreur chiffrée, éventuellement assortie d’autres authentificateurs possibles, peut aider l’appareil sans rendre compte du devenir des informations déjà reçues.

Il serait tout aussi simpliste d’exiger un effacement immédiat en toutes circonstances. Un délai court peut servir à limiter les tentatives abusives. Une trace mise en quarantaine peut être nécessaire pour corriger un faux refus. La règle défendable n’est pas « tout garder » ou « tout détruire », mais une disposition déclarée : quelle donnée, pour quelle finalité, sous quelle autorité, jusqu’à quelle date et avec quelle preuve de clôture.

L’obligation de disponibilité de W ajoute un cas révélateur. Une consultation en ligne apporte une décision fraîche. En panne, le système doit choisir entre refuser, attendre ou employer une solution de repli. Admettre sans W transforme la sécurité; mettre les demandes en file transforme la conservation. L’incident de disponibilité devient donc également une décision sur l’identité.

Une identité d’enrôlement doit avoir une fin

Le projet permet à U d’utiliser une identité réservée à l’enrôlement, puis une autre identité en exploitation. Cette faculté réduit la corrélation si la première identité est effectivement limitée dans le temps et dans son domaine. Elle n’est ni obligatoire ni accompagnée d’un calendrier de suppression.

Une identité dite temporaire peut rester très durable : même valeur réutilisée dans plusieurs réseaux, journaux de refus conservés, rapprochement avec un compte de production. Changer de justificatif après l’enrôlement n’annule pas les associations déjà constituées.

Il faut donc documenter deux passages. Le premier autorise la divulgation avant l’envoi de ID_CRED_I : catégorie du destinataire, W consulté, finalité, destinataires ultérieurs et durée. Le second clôt l’enrôlement : instant d’activation de l’identité opérationnelle, retrait des pouvoirs de l’identité initiale et sort des traces.

Cette documentation peut rester économe. Un reçu n’a pas besoin de publier l’identifiant brut. Il peut employer une référence pseudonymisée à la session, les empreintes des éléments de confiance et des codes de décision limités. L’audit ne devrait pas devenir un nouveau fichier de pistage.

Le reçu de divulgation

Le reçu de divulgation d’identité proposé ici n’est pas un second bon. Le bon porte l’assertion cryptographique de W. Le reçu porte l’engagement institutionnel autour de l’information nécessaire pour obtenir cette assertion.

Il consignerait la version de l’ancre connue par U, l’identité et l’emplacement de W, l’empreinte du justificatif de V, la classe et la règle de rotation de l’identité d’enrôlement, ainsi qu’une référence protectrice à H_12. Il nommerait ensuite la version de politique examinée, le domaine demandé, la finalité, les destinataires, la limite de conservation et la règle de retransmission.

La décision formerait une section distincte : acceptation ou refus, portée et expiration du bon, catégorie de motif, effacement ou quarantaine requis. Après succès, le reçu daterait l’activation de l’identité opérationnelle et la fin des pouvoirs de l’identité d’enrôlement. Un contact de correction permettrait de contester une politique périmée ou une mauvaise attribution.

Ce mécanisme peut rester hors du lien contraint. V ou W conserve le document vérifiable et U n’en reçoit qu’une référence compacte. La proposition ne prétend pas modifier ELA; elle empêche seulement que la qualité du protocole serve de substitut à une politique de données.

Une institution complète ce que le protocole ne promet pas

ELA a le mérite de rendre son compromis visible. Il protège l’identité contre une audience large, authentifie le destinataire immédiat et relie l’autorisation à la session. Il indique aussi le moment où l’identité est communiquée avant le résultat. Cette franchise permet de placer le contrôle au bon endroit.

RFC 9528 laisse déjà aux applications l’évaluation de la confiance et de l’autorisation des justificatifs. BRSKI et la famille de bons de RFC 8366 montrent pareillement qu’une assertion signée ne gère pas à elle seule les ancres, leur cycle de vie ou les pratiques d’un domaine. L’infrastructure légère ne supprime pas l’institution; elle rend ses décisions plus précises.

Le bon ELA peut démontrer que W a autorisé V dans cet échange. Il ne peut démontrer que la divulgation antérieure avait la bonne finalité, qu’un refus n’a laissé aucune trace ou qu’une identité ultérieure ne sera pas corrélée. C’est au reçu, et aux organisations qui l’assument, de rendre ces promesses inspectables.

Sources