Кратко

  • 11 сентября 2026 года draft-ietf-ocm-mls-federated-groups-00 стал рабочим документом группы Open Cloud Mesh. Это меняющийся Internet-Draft, а не RFC и не свидетельство действующей системы.
  • Remove Commit исключает пользователя из новой эпохи MLS. Однако необязательный режим повторного использования оставляет прежние файловый ключ и шифротекст, поэтому отзыв доступа к ресурсу опирается на доверие к удалению старых ключей.
  • Серверный транспортный реквизит отзывается отдельным действием. Daniel Kade предлагает защищённую квитанцию последствий, где членство, ключ ресурса и транспорт не подменяют друг друга; IETF и OCM её не требуют.

Рабочая группа приняла текст в работу

История Datatracker датирует первую WG-версию 11 сентября и указывает индивидуальную серию, которую она сменила. В сообщении председателей оба принятых документа названы отправными точками для дальнейшей дискуссии. Теперь за развитие отвечает рабочая группа OCM, но из этого не следует окончательное одобрение IETF.

На текущей странице документа указаны предполагаемый Standards Track и срок до марта 2027 года. В версии 00 остаются открытыми потоковое расшифрование, пакетирование сообщений с ключами и повторная передача пропущенных Commits. Запрошенные имена ocm-group-key и ocm_federated_group отсутствуют в зафиксированном реестре IANA для MLS, а значение расширения в проекте ещё обозначено TBD. Будущая регистрация не является действующим назначением.

WG-проект 00 позволяет считать получателем общего ресурса группу, распределённую между серверами OCM. У каждого пользователя одна ветвь-лист MLS. Клиенты администраторов создают Commits, Group Owner Server выбирает один на эпоху, а каждый Member Server проверяет полномочия подписанта в соответствующем состоянии. Индивидуальная версия 02 уже содержала основной выбор между ротацией и сохранением ключа. Переименование передало выбор коллективной редакции, а не устранило его.

Сначала меняется криптографическая группа

По RFC 9420, Remove Commit вводит в следующую эпоху новую энтропию, неизвестную удалённому участнику. Кто вправе исключать других, решает приложение. В OCM добавление или удаление другого пользователя требует явного одобрения администратора; самостоятельный выход и повторное присоединение с прежней идентичностью устроены иначе.

После принятия Commit удалённого листа нет в актуальном дереве, и через него нельзя получить секреты новой эпохи. Каждый сервер заново определяет локальных пользователей, которым соответствует адресованная группе публикация. На уровне членства удаление состоялось и имеет проверяемое значение.

Но файл защищён отдельным секретом. Случайный File Key — FK — шифрует ресурс. Производный от MLS Group Key шифрует обёртку с FK для доставки. При смене эпохи обёртку нужно обновить; содержимое обёртки может остаться прежним.

Новая обёртка не означает новый ключ

Re-wrap заново упаковывает существующий FK под Group Key следующей эпохи. Полная ротация создаёт другой FK, повторно шифрует ресурс, формирует обёртку для каждой по-прежнему допущенной группы и доставляет её. Успешный Remove Commit не доказывает выполнение этой цепочки хранения.

Версия 00 рекомендует — SHOULD — ротировать FK после удаления участника из группы с доступом. Это не безусловный MUST. Один шифротекст и один FK могут обслуживать несколько групп, каждая со своей обёрткой. После смены FK все остающиеся группы должны получить новое значение; иначе законные участники не откроют текущую версию.

Удалённый из группы A пользователь может оставаться в группе B, которой доступен тот же ресурс. Его доступ через B правомерен. Проект разрешает сравнить уникальный набор допущенных пользователей до и после эпохи и не ротировать FK, если набор не изменился. Исключение из одного списка ещё не равно отзыву самого файла.

Повторное использование превращает отзыв в обязательство доверия

Повторно шифровать большие и часто изменяемые файлы бывает непрактично. Поэтому формальная федерация с явным управлением и взаимным доверием может включить key-reuse mode. Эпоха меняется, оставшиеся участники получают новую обёртку прежнего FK, но сам FK и шифротекст сохраняются.

Бывший Member Server может иметь старый Group Key и старую обёртку. Нативное устройство могло заранее извлечь FK. Любой из этих наборов продолжает открывать неизменившийся шифротекст. Соответствие доступа членству обеспечивается обещанием удалить больше не положенный материал, а не криптографической невозможностью его применить.

Проект ограничивает такое предположение формальными федерациями и не советует переносить его на открытый или разовый обмен. Решение принимает отправляющий сервер в рамках собственной политики, причём протокол его не сигнализирует. Получатель новой эпохи не может по ней определить, произошла ли ротация ресурса.

Из этого не следует, что бывший сервер обязательно нарушит соглашение. Это описание типа гарантии. Ошибка появится, если точный статус членства станет доказательством криптографического результата, который он не наблюдал.

Транспортный доступ закрывается отдельно

У зашифрованного общего ресурса две двери. Реквизит конкретного Member Server разрешает скачать шифротекст. Group Key и FK позволяют расшифровать его. Когда у сервера удалён последний участник группы, отправитель должен отозвать его транспортный реквизит и послать SHARE_UNSHARED. Remove Commit не выполняет эти действия сам.

До отзыва сервер вне новой эпохи способен продолжать загрузку шифротекста. После отзыва он всё ещё может располагать прошлой копией и ключами. Подтверждения двух защитных слоёв усиливают друг друга, но не заменяют.

В незашифрованной публикации транспортный реквизит — единственный барьер у отправителя. Тогда актуальное разрешение членства на принимающей стороне и быстрый отзыв реквизита непосредственно обеспечивают доступ. Базовый проект OCM 06 задаёт публикации и уведомления; расширение MLS не объединяет их жизненный цикл с группой в одну транзакцию.

Уже полученную копию нельзя отозвать

Есть предел, который не устраняет даже полная ротация. MLS не может запретить законному участнику сохранить или раскрыть полученные открытый текст, Group Key либо FK. Новый FK закрывает старому материалу текущий повторно зашифрованный шифротекст. Он не удаляет ранее выгруженный файл и не уничтожает офлайн-пару из старых шифротекста и ключа.

Архитектура MLS в RFC 9750 отделяет криптографический протокол от политики приложения и вспомогательных сервисов. MLS Virtual Clients 01 позволяет нескольким устройствам действовать как один логический клиент и разделять секретное состояние. Удаление этого состояния происходит в нескольких местах и остаётся операционной обязанностью.

Ротация всё равно создаёт важную границу для версии, которую теперь обслуживает отправитель. Публичная формулировка должна говорить именно об этом, а не обещать ретроспективное стирание.

Квитанция сохраняет три последствия

Daniel Kade предлагает защищённую квитанцию последствий удаления. Её заголовок связывает адрес группы, прежнюю и новую эпохи, удалённый OCM Address, одобрение администратора, принятый Commit и время вступления в силу. Затем перечисляются затронутые ресурсы и все группы с сохраняющимся правом.

Для каждого ресурса квитанция фиксирует ротацию или повторное использование, непрозрачные номера версий FK, завершение повторного шифрования, версию шифротекста и доставку новых обёрток. Отдельная запись хранит версию транспортного реквизита бывшего сервера, отзыв и доставку SHARE_UNSHARED. При key reuse заявление об удалении старых ключей остаётся организационной аттестацией, а не криптографическим доказательством.

Постоянное ограничение напоминает, что уже переданные открытые тексты и офлайн-копии не возвращаются. Квитанция не содержит секретных ключей и не даёт полномочий. Наружу можно вывести лишь непрозрачный идентификатор, классы последствий, времена и проверенные состояния; личности и топология остаются закрытыми.

Это редакционное предложение Daniel Kade, а не требование IETF, MLS или OCM. Policy Mirror Хэн Лу не позволяет актору, правилу и доказательству говорить друг за друга. Minimum Initial Specification совмещает небольшой общий протокол с более содержательными локальными записями. Why BTW Media Exists требует показать действительный компромисс без агитации за проект или против него.

Источники

  1. OCM MLS Federated Groups, WG-версия 00
  2. Текущая запись Datatracker
  3. История документа
  4. Индивидуальный предшественник, версия 02
  5. Сообщение о результате принятия
  6. Рабочая группа Open Cloud Mesh
  7. RFC 9420 — Messaging Layer Security
  8. RFC 9750 — Архитектура MLS
  9. MLS Virtual Clients, версия 01
  10. Базовый протокол Open Cloud Mesh, WG-версия 06
  11. Реестры IANA для Messaging Layer Security
  12. Heng Lu — The Policy Mirror
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Why BTW Media Exists