Кратко

  • RFC 9420 описывает переход MLS-группы между эпохами через Proposals и Commit, который обрабатывают аутентифицированные клиенты.
  • Такой переход подтверждает ограниченное состояние протокола, но не осведомлённость людей, консенсус, полномочия организации, полноту доставки или совершившийся внешний результат.

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

Messaging Layer Security решает более узкую, но важную задачу: непрерывное установление общего аутентифицированного ключевого состояния между клиентами. В RFC 9420 группа — это логическое множество клиентов с общим секретом. Её история представляет линейную последовательность эпох. В каждой эпохе определённое множество аутентифицированных клиентов владеет общим криптографическим состоянием.

Слово «клиент» здесь является границей смысла. RFC определяет клиента по криптографическим ключам, которыми он владеет. Это не определение человека, сотрудника, подразделения, юридического лица или носителя властных полномочий. Authentication Service способен проверить credentials согласно своей политике и связать ключ с допущенным участником в данном контексте. Но из этого не следует, что человек прочёл Proposal, представляет организацию или уполномочен принять обязательство.

Механика перехода состояния конкретна. Proposal предлагает изменение группы — например, добавить, обновить или удалить участника. Commit реализует изменения, предложенные набором Proposals. Когда клиент создаёт или обрабатывает Commit, ratchet tree и GroupContext переходят из старого состояния в состояние новой эпохи. GroupContext содержит, среди прочего, идентификатор группы, номер эпохи, tree hash и confirmed transcript hash. При добавлении клиентов создатель Commit одновременно формирует соответствующий Welcome, чтобы они могли установить свою копию результирующего состояния.

Это позволяет сделать сильное, но ограниченное утверждение: при соблюдении правил проверки MLS клиент обработал конкретный переход состояния. Механизмы transcript и confirmation связывают определённый материал протокола между эпохами; эволюция ключей даёт описанные в RFC свойства защиты. Commit — не просто строка в интерфейсе. Но он также не является протоколом совещания, итогом голосования, договором, разрешением бюджета или подтверждением исполнения операционного изменения. Это сообщение протокола, включающее Proposals в криптографическое состояние группы.

Модель доставки в RFC делает это ограничение практически важным. MLS предполагает доверенный Authentication Service для проверки credentials и Delivery Service для маршрутизации сообщений, который в значительной степени не считается доверенным. Скомпрометированный Delivery Service не может подделать действительное MLS-сообщение. Однако он может выборочно задерживать или удалять сообщения, постоянно блокировать обмен с участником и, если приложение поручает ему разрешать конфликт одновременных Commits, влиять на то, какой Commit будет применён.

Следовательно, действительный Commit не является квитанцией о полной доставке. Он может подтвердить обработанный переход состояния, не подтверждая, что все необходимые клиенты получили информацию вовремя. За исключением значения generation в данных отправителя, RFC оставляет обнаружение потерь приложению. Системе, которой важны охват доставки, сроки или пробелы, следует сохранять соответствующие факты на уровне доставки и приложения. Отсутствие подделки не равно доказанной осведомлённости всех адресатов.

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

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

Проверяемая контрольная запись должна хранить уровни отдельно: идентификатор MLS-группы и эпоху, Commit и Proposals, контекст credentials, наблюдения доставки, правило/порог/срок подтверждений, локальное решение и исполненное действие. Тогда последующая проверка сможет раздельно установить, что изменилось в протоколе, какие конечные точки обработали переход, что приняло приложение и что действительно произошло вне него.

Разделение представления, локального решения и выполненного результата у Lu Heng полезно здесь как аналитическая дисциплина. Эпоха MLS — точное и проверяемое техническое представление. Именно поэтому ей не следует приписывать полномочия решения или реальность результата, принадлежащие другим уровням.

Sources