Кратко

  • RFC 9909 назначает разные OID режимам Pure SLH-DSA и HashSLH-DSA; ключ одного режима нельзя использовать для создания или проверки подписи другого.
  • Для разбора расхождений нужны исходный DER, отсутствие parameters, длины и обёртки, keyUsage и раздельные результаты профиля, подписи, сертификационного пути и политики.

Два валидатора получили один сертификат. Оба распознали семейство SLH-DSA. Один остановился сразу, другой дошёл до криптографической функции. Запись «алгоритм поддерживается» не объяснила расхождение.

Это лабораторная модель, а не сообщение об уязвимости. В первом варианте открытый ключ имел OID Pure, а подпись — OID HashSLH-DSA. Во втором идентификаторы совпадали, но AlgorithmIdentifier содержал NULL. RFC 9909 не разрешает ни перекрёстный режим, ни присутствующий parameters.

Документ вышел в декабре 2025 года в Standards Track IETF и подготовлен группой LAMPS. Он описывает SLH-DSA в сертификатах X.509, CRL, открытых ключах и контейнерах закрытых ключей. Алгоритм стандартизован NIST в FIPS 205. Прежнее имя SPHINCS+ не означает совместимость с окончательным SLH-DSA.

RFC перечисляет двенадцать OID Pure и двенадцать HashSLH-DSA. Они кодируют уровень 128, 192 или 256 бит, вариант small или fast, внутреннюю функцию SHA-2 или SHAKE, а для Hash — ещё и функцию предварительного хеширования. Те же ветви опубликованы в NIST CSOR.

Один и тот же OID обозначает открытый ключ, закрытый ключ и алгоритм подписи. Поэтому ключ Pure не допускается к подписи или проверке Hash, и наоборот, хотя математически операцию можно было бы собрать. Это запрет на неоднозначность. Локальная библиотека способна быть терпимее, но её решение не меняет общий формат.

parameters должен отсутствовать. DER NULL — существующее значение, а не отсутствие. Старые профили сформировали разные привычки, поэтому генератор может добавить NULL, а один парсер — проигнорировать. Без сохранённого DER невозможно понять, исполнился стандарт или частное исключение.

Открытый ключ равен PK.seed || PK.root, имеет 2*n байт при n 16, 24 или 32 и помещается непосредственно в BIT STRING SubjectPublicKeyInfo без дополнительной ASN.1-обёртки. Закрытый ключ SK.seed || SK.prf || PK.seed || PK.root занимает 4*n байт в OCTET STRING OneAsymmetricKey.

OneAsymmetricKey может содержать и открытый ключ, что помогает сверить пару. Но RFC предупреждает: некоторые функции импорта не принимают контейнер с publicKey. Контроль согласованности и широта импорта конфликтуют. Проверять нужно фактическую цепь генерации, экспорта, резервного копирования, восстановления и загрузки в HSM.

При наличии keyUsage требуется хотя бы digitalSignature, nonRepudiation, keyCertSign или cRLSign. Запрещены keyEncipherment, dataEncipherment, keyAgreement, encipherOnly и decipherOnly. SLH-DSA создаёт подписи, а не общий секрет. Даже правильное назначение не завершает проверки имени, срока, отзыва и пути из RFC 5280.

Выбор Pure/Hash затрагивает ресурсы до выпуска CA-сертификата. Pure получает подготовленное сообщение целиком; HashSLH-DSA уменьшает вход определённым pre-hash. Внутреннее M' обрабатывается дважды и хранится в памяти. Большая CRL или сертификат со множеством SAN может превысить лимит передачи или памяти HSM.

Валидатору тоже нужен объект целиком: randomizer из подписи поступает в digest раньше сообщения, тогда как X.509 размещает подпись после подписываемой части. Простого однопроходного потока нет. Hash уменьшает M', но не доказывает поддержку конкретной CA, ОС или библиотеки.

RFC 9814 задаёт соседний профиль CMS SignedData: только Pure, а signed attributes могут уменьшить значение для устройства. Этот приём нельзя автоматически приписывать сертификатам и CRL. Совпадение алгоритма не объединяет прикладные контракты.

Stateless не отменяет предел. Одно дерево нельзя применять более чем для 2^64 подписей; при реальной возможности приблизиться нужны счётчик, досрочное уничтожение ключа или ограниченный Not After. Независимая генерация пар, качественная случайность, защита ключа, противодействие сбоям и побочным каналам остаются обязанностями.

На дату фиксации доказательств официальная страница errata содержала две записи. Обе имели статус Reported, а не Verified. Сообщение, проверка, изменение текста и обновление кода — разные события; первое нельзя выдавать за последнее.

Приёмный журнал хранит DER и хеш, OID ключа и подписи, состояние parameters, длины, обёртки, keyUsage, пустой context, издателя, субъект, trust anchors, данные отзыва, версии валидатора и криптопровайдера. Затем отдельно фиксируются профиль, подпись, путь и решение приложения. Fallback — другая ветвь, а не успех SLH-DSA.

Running-Code Primacy Хэн Лу требует наблюдаемого выполнения. Minimum Initial Specification удерживает общий слой минимальным. Reality Layers не позволяет зарегистрированному имени присвоить доверие и полномочие.

RFC 9909 не выдаёт готовый знак постквантовой безопасности. Он даёт координаты расследования: OID обозначает, DER воплощает, парсер узнаёт, профиль ограничивает, криптография проверяет, путь устанавливает доверие, приложение принимает решение. Расхождение валидаторов разбирается только при сохранении каждого перехода.

Источники