Кратко

  • RFC 3923 защищает объект CPIM средствами S/MIME и переносит его в оболочке XMPP ; пространство имён оболочки само по себе не задаёт смысл сообщения.
  • Шлюз XMPP-CPIM может снять или добавить оболочку сервиса, но обязан передать защищённый объект без изменений.

Что шлюзу разрешалось менять

Шлюз связывает сервисы обмена сообщениями, использующие разные протоколы. Но как только посредник начинает преобразовывать сообщение, возникает вопрос доверия: что он вправе менять, не становясь сам частью доверенной границы? Опубликованная в октябре 2004 года как стандарт IETF RFC 3923 установила намеренно узкую границу. Шлюз XMPP-CPIM может снять оболочку одного сервиса и надеть оболочку другого. Однако менять находящийся внутри подписанный или зашифрованный объект S/MIME он не вправе.

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

Защищённый объект внутри XMPP-станзы

Отправитель сначала формирует объект Message/CPIM. В него входят и заголовки, и содержимое; RFC 3923 требует защищать и то и другое подписью или шифрованием S/MIME. Полученный объект помещается в XML-секцию CDATA внутри элемента <e2e/>, который является дочерним элементом XMPP-станзы message или presence. В зависимости от применения внутри может находиться также документ присутствия PIDF или объект XMPP XML.

<e2e/> переносит данные, но не интерпретирует их. RFC подчёркивает, что у пространства имён этого элемента нет собственной семантики: смысл вложенного объекта определяют спецификации CPIM, PIDF или XMPP. Следовательно, посреднику не обязательно понимать защищённое содержимое только потому, что он способен разобрать внешнюю XMPP-станзу.

Из этого разделения вытекает правило для шлюза. При передаче из XMPP шлюз снимает XMPP-оболочку, включая теги <e2e>, извлекает составной объект S/MIME и направляет его дальше, при необходимости добавляя оболочку не-XMPP-сервиса. В обратном направлении он снимает оболочку другого сервиса, помещает тот же объект в оболочку XMPP и отправляет станзу. RFC прямо требует, чтобы вложенный объект S/MIME оставался неизменным и не модифицировался шлюзом XMPP-CPIM.

Граница, а не полная система безопасности

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

Операционный компромисс очевиден. Непрозрачная передача помогает посреднику доставить содержимое, которое опасно переписывать, но ограничивает возможности преобразования и проверки. Если сервису нужна конвертация, решающее значение приобретают место её выполнения и влияние на подпись. Изменение объекта, охваченного подписью, — не нейтральный перевод; проект оставляет это решение конечным узлам.

В 2014 году RFC 7165 отмечал, что подход S/MIME не получил широкого распространения, и называл среди частичных причин сложности управления ключами и обработки объектов S/MIME. Это историческое наблюдение документа 2014 года, а не актуальный подсчёт внедрений и не единственное объяснение. Оно, однако, показывает: чёткая граница может сохранять криптографический смысл, не упрощая продукт и управление ключами. Значение RFC 3923 не в том, что шлюзы стали заслуживать доверия. Стандарт показал, что совместимость не требует переписывать то, что защитили конечные узлы.

Источники