Кратко

  • SignatureValue удостоверял каноническое SignedInfo, а его Reference связывали подпись с хешами данных после упорядоченных преобразований.
  • Успех основной проверки не доказывал защиту всего исходного XML, совпадение с экраном пользователя, доверие к KeyInfo, проверку каждого пункта Manifest или право приложения выполнить действие.

RFC 3075 вышел в марте 2001 года как стандарт XMLDSIG для XML и произвольных цифровых данных. Объект мог находиться внутри Signature, окружать её или жить по внешнему адресу. Поэтому область подписи определялась не файлом как зрительной рамкой, а ссылками и вычислениями.

Один итог складывался из двух проверок

При проверке ссылок программа получала объект для каждого Reference в SignedInfo, формировала вход хеш-функции и сравнивала вычисленное значение с DigestValue. При проверке подписи она канонизировала SignedInfo и проверяла SignatureValue выбранным ключом и методом.

Верная подпись над SignedInfo не исправляла неверный хеш ссылки. Совпавшие хеши сами не удостоверяли список, где были записаны. Только оба результата связывали ключ с конкретными обязательствами и идентификаторами обработки. Соседние узлы, дополнительные ресурсы и последующее деловое решение в эту связь не входили автоматически.

Для воспроизводимости требовалось хранить канонические байты SignedInfo и точный поток, поданный каждой хеш-функции. Булево значение библиотеки сообщало исход, но не сохраняло доказательную трассу.

Подписанным объектом становился выход Transforms

XPath мог выбрать часть дерева, XSLT построить другое представление, Base64 восстановить двоичный объект, а канонизация сериализовать набор узлов. Хеш относился к выходу цепочки. Отброшенная информация могла измениться, не нарушив подпись.

Такая избирательность была нужна. Форма оставляла поля для ввода; enveloped signature исключала собственное значение из вычисления; XML-контейнер мог защищать декодированный файл вместо оболочки. Ошибка возникала, когда интерфейс называл частичную защиту подписью всего источника. Исключённая сумма, получатель или инструкция могли измениться, а проверка выбранного объекта оставалась корректной.

RFC также отделял описанную цепочку от свежего исполнения. Основная проверка не обязана была доказывать, что URI только что разрешили и каждый Transform выполнили заново. Одно приложение могло принять кэшированный преобразованный объект, другое — потребовать новое получение. Одинаковый хеш не раскрывал происхождение и время данных.

Канонизация фиксировала вычисление, а не смысл

XML-парсер нормализует переводы строк и атрибуты, раскрывает сущности и распределяет пространства имён. DOM и SAX теряют некоторые свойства исходной записи. Каноническая сериализация позволяла подписанту и проверяющему получить один поток октетов.

Она не удостоверяла schema, экранный смысл, полномочия пространства имён или безвредность исключённого узла. Canonical XML 1.1 позднее сохранил эту границу: прикладная эквивалентность не выводится из универсальной канонической формы.

Увиденное следовало связать с подписанным

Если подпись должна была выражать суждение человека или автомата, раздел безопасности советовал как можно точнее защищать представленную информацию. Можно было подписать изображение экрана, но его трудно обрабатывать. Другой путь — включить данные, фильтры, стили, профиль клиента и всё, что формирует показ.

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

Это не делало XML Signature автоматическим доказательством личности или согласия. Спецификация связывала ключ с октетами. Отношение ключа к организации, значение материала и разрешение действия определяло приложение.

KeyInfo помогал найти ключ, но не создавал доверие

Необязательный KeyInfo мог содержать ключ, сертификат, имя или способ получения. Он мог отсутствовать, если ключ известен из контекста. В основной структуре KeyInfo лежал вне SignedInfo; при необходимости его содержимое связывали отдельным Reference.

Даже связанный KeyInfo не завершал проверку полномочий. Настоящий сертификат мог не разрешать нужную операцию, а точное имя быть лишь локальным индексом. RFC 2807 оставлял общие семантики доверия и утверждений прикладным профилям.

Подписанный Manifest не означал проверку каждого объекта

Manifest группировал ссылки с прикладной политикой ошибок. Если SignedInfo ссылался на Manifest, ядро проверяло хеш самого элемента. Какие внутренние ссылки проверить и как обработать недоступность или несовпадение, решало приложение.

Подлинный список и полностью проверенная коллекция были разными состояниями. Отчёт должен был перечислять результаты по каждому члену. Зелёная рамка контейнера не заменяла эти квитанции.

Последующая практика сузила исполняемую поверхность

RFC 3275 заменил RFC 3075 в марте 2002 года после опыта совместимости и изменил несколько структур. XML Signature 1.1 и рекомендации W3C сохранили архитектуру, но явнее потребовали сначала удостоверять SignedInfo, отдельно устанавливать доверие к ключу, ограничивать XPath, XSLT, RetrievalMethod, число преобразований и внешние URI, а также проверять, что приложение использует действительно защищённые элементы.

Эти документы не доказывают конкретную атаку на реализацию RFC 3075. Они показывают, почему исполняемое описание подписи нуждается в более узком локальном профиле.

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

Источники

Lu Heng не писал и не утверждал RFC 3075, RFC 3275 или рекомендации W3C. Его эссе используются только как раскрытые поздние аналитические рамки.