Résumé

  • Le 11 septembre 2026, draft-ietf-ocm-mls-federated-groups-00 est devenu un document de travail du groupe Open Cloud Mesh. Il reste un Internet-Draft évolutif, et non une RFC ou la preuve d’un déploiement.
  • Un Commit de retrait ferme l’accès au nouvel epoch MLS. Le mode facultatif de réutilisation conserve pourtant la même clé de fichier et le même chiffré : la révocation de la ressource repose alors sur la confiance accordée aux anciens participants.
  • Le droit de récupérer le chiffré utilise encore une troisième commande, l’identifiant de transport par serveur. Daniel Kade propose un bordereau protégé des conséquences du retrait ; cette proposition éditoriale ne vient ni de l’IETF ni d’OCM.

L’adoption ouvre le chantier

L’historique Datatracker inscrit la version de groupe 00 au 11 septembre et la relie au texte individuel qu’elle remplace. Dans son message de résultat, la présidence parle de deux bons points de départ appelés à évoluer. Le fait institutionnel est donc limité mais important : le groupe OCM a pris la responsabilité du texte.

La fiche courante indique une ambition Standards Track. Elle n’atteste ni consensus final, ni publication RFC, ni usage en production. La section des questions ouvertes mentionne encore le déchiffrement en flux, le regroupement des messages de clés et la retransmission des Commits manqués. Le registre IANA consacré à MLS ne contient pas les noms exacts ocm-group-key et ocm_federated_group demandés par le projet ; la valeur de l’extension reste TBD dans cette version. C’est l’état normal d’une proposition inachevée, pas une anomalie de l’IANA.

Le projet de groupe 00 fait d’un groupe réparti sur plusieurs nuages la partie destinataire d’un partage OCM. Chaque utilisateur occupe une feuille MLS. Des clients administrateurs signent les Commits ; le serveur propriétaire du groupe en arbitre un par epoch ; chaque serveur membre vérifie localement que le signataire figurait dans l’ensemble des administrateurs. L’ancienne version individuelle 02 portait déjà l’essentiel du compromis sur les clés. Le nouveau nom place ce compromis dans la file de travail collective, il ne le tranche pas.

Le retrait modifie d’abord l’appartenance

La mécanique de RFC 9420 apporte au nouvel epoch une entropie que le membre retiré ne reçoit pas. MLS laisse à l’application le soin de dire qui peut évincer qui. Ici, un ajout ou le retrait d’autrui doit obtenir l’approbation explicite d’un administrateur avant d’être intégré par un client administrateur. Le départ volontaire et la reconnexion qui conserve l’identité suivent des chemins différents.

Une fois le Commit accepté, la feuille visée n’appartient plus à l’état courant. À chaque Commit, le serveur membre doit recalculer quels utilisateurs locaux reçoivent les partages adressés au groupe. Ce résultat est vérifiable : l’utilisateur sorti ne bénéficie plus de la nouvelle clé de groupe par cette feuille.

Il serait néanmoins faux d’en déduire que le fichier possède une nouvelle clé. OCM emploie une clé aléatoire propre à la ressource, la FK. Cette clé chiffre le contenu. La clé de groupe dérivée de MLS ne chiffre que l’enveloppe qui transporte la FK. Un changement d’epoch impose une nouvelle enveloppe ; il n’impose pas toujours un nouveau contenu chiffré.

Réemballer n’est pas renouveler

Le vocabulaire technique évite ici une confusion de gouvernance. Réemballer la FK consiste à conserver cette clé et à l’envelopper avec la clé du nouvel epoch. Renouveler la FK crée un autre secret, chiffre à nouveau la ressource, produit une enveloppe pour chaque groupe encore autorisé, puis distribue toutes ces enveloppes.

La version 00 recommande ce renouvellement lorsqu’un membre quitte l’un des groupes qui voient la ressource. Elle ne le rend pas absolu. Si le même fichier appartient à plusieurs groupes, une seule copie chiffrée et une seule FK peuvent les servir tous. Un changement réel de FK doit alors être propagé à chaque groupe restant ; oublier l’un d’eux lui laisserait une enveloppe incapable d’ouvrir le contenu courant.

Le retrait d’un groupe ne supprime d’ailleurs pas nécessairement l’accès de la personne. Elle peut être encore membre d’un autre groupe autorisé. Le projet considère ce maintien comme correct. Le serveur expéditeur peut même comparer l’ensemble unique des utilisateurs avant et après l’epoch et éviter une rotation si cet ensemble n’a pas changé. L’objet de décision n’est donc pas seulement le groupe : c’est le couple entre ressource, groupes et utilisateurs effectifs.

Le mode de réutilisation est un engagement de confiance

Lorsque rechiffrer de gros fichiers fréquemment modifiés serait impraticable, une fédération formelle dotée de règles explicites et de confiance mutuelle peut retenir le mode facultatif de réutilisation. Le Commit de retrait avance normalement. Les membres restants reçoivent une nouvelle enveloppe sous la clé du nouvel epoch. Mais la FK et le chiffré ne changent pas.

Un ancien serveur membre peut avoir conservé l’ancienne clé de groupe et l’ancienne enveloppe. Un appareil natif peut déjà détenir la FK en clair dans son espace cryptographique. Ces éléments continuent à ouvrir le chiffré inchangé. La conformité au nouvel état dépend alors de la suppression volontaire des secrets devenus indus, et non d’une impossibilité cryptographique.

Le texte limite ce pari aux fédérations formelles et déconseille de l’étendre aux partages ouverts ou ponctuels. Il ajoute un détail décisif : le serveur expéditeur choisit son mode selon sa politique, mais ce choix n’est pas signalé dans le protocole. Un partenaire qui observe le nouvel epoch ne sait donc pas si une rotation de ressource a eu lieu.

Dire cela n’accuse aucun serveur de conserver abusivement une clé. Le projet décrit un modèle de confiance assumé. Le risque éditorial serait au contraire de transformer le statut exact « membre absent du groupe » en affirmation plus large « ancien matériel devenu inutilisable ».

Le droit de transport peut rester actif

Pour une ressource chiffrée, deux barrières coexistent. Un identifiant propre au serveur membre donne le droit de récupérer le chiffré. Les clés MLS et la FK donnent le pouvoir de le déchiffrer. Elles ne changent pas dans la même opération.

Quand le dernier utilisateur rattaché à un serveur quitte le groupe, le projet recommande au serveur expéditeur de réconcilier l’état du partage, de révoquer l’identifiant de transport de ce serveur et d’envoyer SHARE_UNSHARED. Tant que cette étape n’est pas achevée, le serveur sorti peut encore télécharger le chiffré même s’il n’appartient plus au nouvel epoch. Et une révocation de transport réussie ne prouve pas que ses caches ne contiennent plus de FK.

Le cas non chiffré rend cette distinction encore plus visible : l’identifiant de transport et la résolution locale de l’appartenance constituent alors toute la barrière d’accès. Le protocole OCM de base fournit la trame des partages et notifications ; l’extension MLS y ajoute un cycle de groupe, sans rendre ces commandes atomiques.

Une copie déjà remise ne revient pas

La limite ne tient pas seulement au mode réutilisation. Le projet rappelle que MLS ne peut empêcher un membre autorisé de conserver ou divulguer un texte clair, une clé de groupe ou une FK reçue légitimement. Même une rotation parfaite protège le nouveau chiffré servi par l’expéditeur. Elle ne détruit ni une exportation antérieure ni un couple ancien chiffré-clé stocké hors ligne.

L’architecture MLS répartit les responsabilités entre le groupe cryptographique, l’application et les services de support. Le projet sur les clients virtuels MLS montre aussi qu’un seul client logique peut regrouper plusieurs appareils. La suppression d’état doit donc être observée sur plusieurs lieux de garde. Aucun événement de groupe ne peut être honnêtement nommé « effacement de toutes les copies ».

Le renouvellement garde une valeur forte : l’ancien matériel ne permet plus d’ouvrir la version courante rechiffrée. La formulation exacte doit suivre la preuve disponible et ne pas lui attribuer un pouvoir rétroactif.

Un bordereau pour chaque conséquence

Daniel Kade propose un bordereau des conséquences du retrait conservé sous contrôle d’accès. La première ligne relierait adresse du groupe, epochs ancien et nouveau, utilisateur retiré, référence d’approbation, Commit accepté et heure d’effet. Une deuxième ligne, par ressource, indiquerait le mode choisi, les versions opaques de FK, l’achèvement du rechiffrement, la version du chiffré et la remise de l’enveloppe à chacun des groupes autorisés.

Une troisième ligne suivrait l’identifiant de transport de l’ancien serveur, sa révocation et la remise de SHARE_UNSHARED. En mode réutilisation, une attestation de suppression de clés resterait clairement qualifiée de déclaration organisationnelle. Le bordereau conserverait enfin une limite permanente : les textes clairs et copies hors ligne déjà remis ne sont pas rappelables.

Cette construction est une proposition éditoriale de Daniel Kade, pas une obligation de l’IETF, de MLS ou d’OCM. Elle ne stocke aucune clé brute et n’accorde aucun droit. Une preuve publique éventuelle peut se limiter à un identifiant opaque, aux classes de conséquence, aux heures et aux résultats ; identités, serveurs et topologie demeurent protégés.

Le Policy Mirror de Heng Lu conduit à ne pas confondre l’acteur autorisé, la règle et la preuve. La Minimum Initial Specification permet à un noyau interopérable de cohabiter avec des pièces locales plus riches. Enfin, Why BTW Media Exists impose de présenter le compromis tel qu’il est, sans transformer le journalisme en plaidoyer.

Sources

  1. Groupes fédérés OCM avec MLS, version WG 00
  2. Fiche Datatracker courante
  3. Historique Datatracker
  4. Version individuelle précédente 02
  5. Message de résultat de l’adoption
  6. Groupe de travail Open Cloud Mesh
  7. RFC 9420 — Messaging Layer Security
  8. RFC 9750 — Architecture MLS
  9. Clients virtuels MLS, version 01
  10. Protocole OCM de base, version WG 06
  11. Registres IANA de MLS
  12. Heng Lu — The Policy Mirror
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Why BTW Media Exists