Кратко

  • RFC 3741 уменьшил зависимость подписей извлечённых XML-фрагментов от объявлений пространств имён в предках: в сериализацию в основном попадают префиксы, явно используемые в именах элементов и атрибутов.
  • Это не устраняет контекстную зависимость полностью: унаследованные атрибуты xml: и префиксы, присутствующие только в значениях, могут изменить интерпретацию после новой упаковки фрагмента.

Внешняя оболочка не должна переписывать подпись содержимого

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

Опубликованная в марте 2004 года RFC 3741 адресована именно этой проблеме. Она задаёт эксклюзивную сериализацию набора узлов XPath. Вместо импорта большей части контекста пространств имён от предков алгоритм выводит привязку, когда префикс явно используется в имени элемента или атрибута. Необязательный параметр InclusiveNamespaces PrefixList позволяет перечислить префиксы, которые следует обрабатывать инклюзивно вопреки этому правилу. Цель — дать подписанному поддокументу пережить извлечение и вставку в другую оболочку, не включая каждый транспортный слой в каноническую форму.

Это выбор границы, а не обещание независимого от контекста смысла. RFC 3741 прямо описывает ограничения. RFC 3075 рассматривает, какие данные покрывает XML Signature; RFC 3076 — канонизацию набора узлов после разбора XML. RFC 3741 отвечает на более узкий вопрос: какой контекст сохранять, когда перемещается выбранное подмножество.

«Явное использование» — полезный, но узкий критерий

Правило опирается на имена XML. Если имя элемента или атрибута использует префикс n1, его привязка должна попасть в сериализацию этого имени. Префикс, объявленный предком, но не появляющийся в таких именах, можно опустить. Это убирает лишнее: оболочка SOAP или протокола может содержать объявления, нужные внешнему сообщению, но не извлечённому содержимому. Тогда эксклюзивная канонизация способна дать одинаковые канонические байты для одного содержимого в разных оболочках.

Но смысл для приложения может зависеть от сведений, не видимых в именах узлов. Значение атрибута может содержать XPath-выражение, для которого важны префиксы. Приложение также может считать строку xsi:type="xsd:decimal" значением QName, хотя XPath видит лишь строку. Если xsd не используется явно в именах элементов или атрибутов и не включён в инклюзивный список, его привязка может быть опущена. В новой оболочке получатель может истолковать значение иначе.

RFC предлагает три способа учесть такую зависимость: сделать использование префикса видимым в структуре XML, гарантировать одну и ту же привязку во всех контекстах интерпретации либо включить префикс в InclusiveNamespaces PrefixList. Каждый способ требует решения на уровне проектирования. Список не обнаруживает скрытую семантику автоматически: приложение должно знать, какие значения зависят от пространств имён.

Контекст вне подписанных байтов всё ещё влияет на чтение

Эксклюзивная канонизация также не копирует унаследованные xml:lang, xml:space или xml:base в осиротевшие узлы подмножества. Эти атрибуты могут влиять на выбор языка, обработку пробелов и разрешение относительных ссылок. RFC требует либо поместить нужное значение внутрь подмножества, либо обеспечить эквивалентное значение в каждом контексте интерпретации.

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

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

Узкая граница подписи увеличивает интеграционную обязанность

Эксклюзивная канонизация меняет случайную зависимость от оболочки на явную обязанность учитывать семантические зависимости. При проверке пересылаемого подписанного фрагмента недостаточно убедиться в подписи. Нужно проверить, сохраняют ли префиксы, атрибуты xml:, значения QName и относительные ссылки тот же смысл в целевом контексте. Без явного контракта стабильность подписи легко принять за стабильность значения.

Это модель риска, описанная спецификацией, а не свидетельство конкретной атаки или ошибки реализации. RFC 3741 имеет статус Informational: она устанавливает замысел и ограничения алгоритма, но не распространённость реализации и не ошибку определённого сервиса. Вывод узок: исключение контекста из подписанных байтов повышает переносимость, однако только приложение знает, какой опущенный контекст продолжает определять интерпретацию.

Источники