Кратко

  • RFC 9563 присваивает SM2 с SM3 номер алгоритма DNSSEC 17, а SM3 — тип дайджеста DS 6; значения получили однозначный смысл в протоколе.
  • Это информационный RFC независимого потока, а не документ Standards Track. В нём прямо сказано, что IETF и IRTF не анализировали пригодность алгоритмов для такого применения.
  • За строкой реестра остаются реализация подписывающей стороны, делегирование, возможности валидатора, локальная политика, проверка подписи и результат приложения.

Валидирующий резолвер получает подписанный ответ и видит номер 17. Теперь это не неизвестное значение: реестр IANA объясняет его смысл. Но в программе может не быть SM2, дайджест делегирования может не поддерживаться, а локальная политика может отвергнуть путь. Даже корректное уравнение подписи не показывает, кто хранил закрытый ключ. Номер позволяет начать проверку, но не завершает её.

RFC 9563 опубликован 4 декабря 2024 года и описывает представление SM2 и SM3 в DNSSEC. Алгоритм получил номер 17 и мнемонику SM2SM3, дайджест DS — тип 6. Одновременно документ чётко ограничивает свои полномочия: категория Informational, Independent Stream, не результат консенсуса сообщества IETF. Ни IETF, ни IRTF не проводили анализа пригодности SM2 или SM3 для указанной задачи; возможны намеренные и ненамеренные слабости.

Это не формальная оговорка. Она запрещает выдавать публикацию за экспертное одобрение.

Реестр устраняет неоднозначность, а не неопределённость

Без общего номера две реализации не смогут надёжно обозначить один алгоритм в DNSKEY, RRSIG или DS. Поэтому распределение номера полезно: формат получает совместимое имя, а частные трактовки перестают конфликтовать.

На 27 сентября 2026 года реестр IANA помечал использование и реализацию алгоритма 17 для подписи и проверки как MAY. Для типа DS 6 соответствующие рекомендации также имели значение MAY. Это датированный факт о реестре, а не измерение распространённости, разрешение на закупку или криптоаналитическое заключение.

RFC 6014 описывает именно управление пространством значений: кто и по какой процедуре получает номер, что этот номер обозначает. Реестр может быть полностью верным, даже если ни один резолвер конкретной сети не реализует запись. И наоборот, код может существовать задолго до широкого принятия. Каталог нельзя подменять телеметрией.

RFC 7841 помогает читать статус. Заголовок и стандартный текст указывают поток публикации и категорию. Номер RFC надёжно находит документ, но не стирает слова Independent Stream и не создаёт консенсус IETF.

DNSSEC проверяет путь, а не одну операцию

DNSSEC задаёт не только вопрос о верности одного криптографического уравнения. RFC 4033 разделяет авторитативные серверы, резолверы с поддержкой безопасности и якоря доверия. RFC 4034 определяет DNSKEY, RRSIG, DS и записи доказательства отсутствия. RFC 4035 требует построить путь аутентификации: выбрать поддерживаемый алгоритм, найти ключ, восстановить канонические данные, проверить срок действия и подтвердить подпись по принятой цепочке.

Продукт может разобрать номер 17, но не выполнять SM2. Он может поддерживать SM2 и не знать дайджест DS 6. Дочерняя зона может публиковать DNSKEY, когда родитель не даёт применимого DS. Все примитивы могут присутствовать, а политика всё равно не принимать путь.

RFC 6840 описывает важное следствие. Неподдерживаемый дайджест DS отбрасывается так же, как неизвестный алгоритм DNSKEY. Если поддерживаемых DS не осталось, делегирование может считаться insecure, а не bogus. Зона подписана, реестр точен, но у данного валидатора нет исполнимого пути аутентификации.

Поэтому RFC 8624 ведёт рекомендации по использованию и реализации. Смена алгоритма требует перекрытия возможностей подписывающих и проверяющих систем. Таблица RFC 8624 появилась раньше RFC 9563 и не доказывает сегодняшнюю поддержку номера 17 или типа 6. Её нужно измерять для конкретного продукта, версии, криптобиблиотеки, сборки, конфигурации и популяции резолверов.

Корректная подпись отвечает на ограниченный вопрос

RFC 9563 задаёт кодировки открытого ключа и подписи. Успешная проверка показывает, что канонические DNS-данные соответствуют подписи для выбранного ключа, правил и временного окна. Она не доказывает, кто контролировал закрытый ключ, было ли использование санкционировано, сохранил ли rollover непрерывность и приняло ли приложение возвращённый адрес.

RFC 7583 рассматривает генерацию, хранение, смену, компрометацию и вывод ключей как отдельную эксплуатационную работу. RFC 9563 также требует криптографической гибкости: при обнаружении слабости может понадобиться обновление DS, DNSKEY, RRSIG и NSEC3 с учётом кэшей. Строка реестра не выполняет этот переход.

Надёжная цепочка доказательств соединяет происхождение публикации, текущее состояние IANA, сборку и настройки подписывающей стороны, наблюдаемые DNSKEY/DS/RRSIG, возможности резолвера, якоря и политику, журнал проверки, непрерывность смены ключей и результат приложения. Каждый документ подтверждает только своё событие.

Принцип Heng Lu о первичности работающего кода даёт правило: символический авторитет, настроенное намерение, исполнимая способность и наблюдаемый результат — разные уровни реальности. RFC 9563 позволяет точно назвать SM2 и SM3 в DNSSEC. Что произошло после, покажут только конкретные системы.