Кратко

  • RFC 9814 задаёт два варианта: без подписанных атрибутов Pure SLH-DSA подписывает контент, а с ними — канонический DER(SignedAttributes).
  • Во втором варианте message-digest связывает подпись с байтами объекта, content-type — с их смыслом в CMS; журнал HSM не заменяет доказательства этих связей.
  • Малый вход удобен для потоковой обработки и аппаратных модулей, однако это не режим HashSLH-DSA. Для долговременного архива нужны отдельные квитанции контента, digest, DER, алгоритмов, ключа и политики.

Миграция проверяет не алгоритм, а память системы

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

RFC 9814 опубликован в июле 2025 года как Standards Track. Он определяет Pure SLH-DSA с пустым контекстом для CMS SignedData. Режим HashSLH-DSA в этом профиле не задаётся. Тем не менее CMS может предварительно вычислить digest контента для подписанных атрибутов, поэтому на вход HSM попадает малая структура. Важен не размер, а точное значение сообщения.

Если signedAttrs отсутствует

При отсутствии подписанных атрибутов сообщением Pure SLH-DSA служит сам контент. Поле SignerInfo.digestAlgorithm не означает, что контент нужно заменить внешним хэшем. RFC 9814 говорит, что в этом варианте поле не участвует в вычислении подписи.

Следовательно, сервис, принимающий только digest, не реализует этот путь автоматически. Передать Hash(content) под именем сообщения — значит изменить операцию. Наличие SHA-256 в контейнере также не доказывает применение HashSLH-DSA.

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

Если signedAttrs присутствует

CMS вычисляет digest контента выбранным алгоритмом и помещает результат в обязательный атрибут message-digest. Обязательный content-type фиксирует тип вложенного или внешнего содержимого. Затем весь набор атрибутов кодируется по DER, и Pure SLH-DSA подписывает полученные байты.

В будущем требуется восстановить цепочку:

  1. неизменяемая версия объекта дала конкретные байты и длину;
  2. конкретный алгоритм дал конкретный digest;
  3. digest, тип и остальные атрибуты составили полный логический набор;
  4. набор дал точную DER-последовательность;
  5. ключ указанного набора параметров подписал DER;
  6. сертификат и версия политики допустили применение ключа.

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

Проверяющий заново вычисляет digest по полученному контенту и сравнивает его с message-digest. Кроме того, он сопоставляет подписанный content-type с encapContentInfo.eContentType. Тип может выбирать парсер, права, срок хранения и автоматический процесс. Одинаковые байты в другом типе не всегда означают то же деловое решение.

DER нужно сохранять как первичный факт

Пользователь видит список атрибутов, но подпись относится к байтам. DER определяет теги, длины, типы значений и канонический порядок элементов множества. Экспорт в JSON или таблицу может потерять неизвестный атрибут либо восстановить значение другим ASN.1-типом.

Минимум — хранить исходный CMS-объект. Для значимых решений следует сохранять точные DER-байты, отправленные подписывающему модулю, их контрольный digest, версию построителя и результат независимой реконструкции. Если воспроизвести вход способна только закрытая библиотека поставщика, архив зависит от неё на уровне доказательства.

Построитель атрибутов — самостоятельный доверенный компонент. Защищённый ключ не мешает приложению прочитать неверный объект, взять тип из изменяемого HTTP-заголовка или перестроить атрибуты после согласования. Защита ключа и честность сообщения — разные контуры.

Согласованность идентификаторов

При наличии атрибутов SignerInfo.digestAlgorithm указывает хэш для message-digest, а SignedData.digestAlgorithms отражает алгоритмы подписантов. RFC 9814 требует, чтобы длина результата обеспечивала нужную стойкость к коллизиям для выбранного параметрического набора SLH-DSA. Проверять нужно сочетание, а не отдельные названия.

RFC определяет двенадцать идентификаторов подписи Pure SLH-DSA, причём параметры должны отсутствовать. Проверяющий сопоставляет алгоритм подписи с алгоритмом открытого ключа. RFC 9909 описывает связанную X.509-часть, однако верная цепочка сертификатов не исправляет digest от другой версии файла.

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

Это не prehash-режим SLH-DSA

Схема внешне похожа на prehash: большой объект проходит хэширование, в HSM поступает малый ввод. Но Pure SLH-DSA подписывает не digest отдельно, а DER, содержащий digest, тип и другие атрибуты. FIPS 205 различает Pure и prehash, у HashSLH-DSA другая операция и другие идентификаторы.

Запись «SLH-DSA prehash» в реестре недостаточна. Она может привести к выбору неверного OID и попытке проверить подпись над одним digest. Корректное описание длиннее: «Pure SLH-DSA над SignedAttributes; контент связан через message-digest».

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

С атрибутами получатель может считать digest по мере приёма, освобождать блоки и затем проверить небольшую DER-структуру. Отправителю не нужно пропускать гигабайты через HSM. Стандарт не обещает конкретной производительности, но делает такой интерфейс возможным.

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

Квитанция транзакции включает неизменяемые ID и версию контента, длину, алгоритм и digest, тип CMS, все атрибуты, точный DER, параметрический набор, ID ключа и сертификата, подпись, время, версию политики и отдельные результаты чтения, digest, типа, атрибутов, защиты алгоритмов, подписи и доверительной цепочки.

В приёмочных тестах поочерёдно меняют байт контента, digest, тип, дополнительный атрибут, DER, OID, ключ и сертификат. Каждый отказ должен указывать этап. Общая ошибка «invalid signature» не позволяет установить владельца проблемы.

RFC 9814 не подтверждает распространённость, скорость HSM или квантовую безопасность всей CMS-системы. Шифрование, сертификатные цепочки, случайность, боковые каналы, отказы и хранение ключей остаются отдельными вопросами. Лимит менее 2^64 подписей на ключ SLH-DSA требует счётчиков и ротации.

Принцип минимальной начальной спецификации Heng Lu здесь означает компактный проверяемый договор. Слой реальности — не надпись о соответствии, а возможность другой стороны повторить переход от байтов к digest, от атрибутов к DER и от DER к подписи и решению политики.

Источники