Кратко

  • RFC 9925, опубликованный в феврале 2026 года как Proposed Standard IETF, определяет id-alg-unsigned — алгоритм X.509 с отсутствующими параметрами и нулевой длиной значения подписи.
  • Профиль переносит сведения о субъекте, но не доказательство от издателя. Заполненное поле issuer может сохраняться для совместимости, однако объект не становится ни самоподписанным, ни самовыпущенным.
  • Приложение вправе принять объект там, где оно не проверяет подпись X.509. Валидатор сертификационного пути обязан отвергать id-alg-unsigned вместо подписи.
  • Удаление декоративной самоподписи сокращает размер постквантовых данных, уменьшает межпротокольное использование ключа и поддерживает KEM-ключи, которые не умеют подписывать. Стандарт не открывает обход: он обозначает отсутствующее ребро.
  • Доверие, целостность и полномочия должны поступать по другому механизму. Квитанция происхождения и области доверия должна связать точные байты, внешнее доказательство, установщика, хранилище, разрешённые применения, историю изменений и путь удаления.

Сертификат с намеренно пустым полем доказательства

Самое выразительное число в RFC 9925 — ноль.

Неподписанный сертификат применяет идентификатор 1.3.6.1.5.5.7.6.36 для id-alg-unsigned. Параметры алгоритма опускаются, а signatureValue представляет собой BIT STRING нулевой длины. Структура X.509 остаётся удобным совместимым контейнером для имени субъекта, открытого ключа и расширений. Но она больше не предлагает парсеру изображать, будто издатель криптографически подтвердил эти поля.

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

Граница ясна: объект может быть синтаксически полезен и одновременно непригоден как криптографическое ребро. Именно здесь начинается управление. Интерфейсы безопасности часто заимствуют авторитет у знакомой формы. Файл под названием «сертификат» показывает издателя, срок действия и зелёный значок. Реестр активов ставит его рядом с удостоверениями, выпущенными CA. Оператор помнит, что файл пришёл из доверенного образа устройства, но уже не может найти, кто одобрил этот образ. RFC 9925 не требует таких ошибок. Его точность делает их видимыми.

Узел остался, ребро исчезло

RFC 9925 предлагает собственную графовую модель. Обычный сертификат X.509 связывает сведения о субъекте с доказательством издателя. В графе инфраструктуры открытых ключей субъект и издатель — узлы, а подписанный сертификат — ребро между ними.

Некоторым системам нужен лишь узел. Якорь доверия начинает путь, а не получает полномочие от сертификата выше. В закреплённом TLS-развёртывании открытый ключ или отпечаток может быть известен по отдельному каналу. Устройство может нуждаться в контейнере X.509 для KEM-ключа, который вообще не способен формировать подписи. Самоподпись в таких случаях удовлетворяет синтаксис, но не создаёт нового факта доверия.

Неподписанный профиль удаляет вымышленное ребро. Представление становится правдивее, зато наружу выходит вопрос, который мог скрывать самоподписанный конверт: почему именно этот узел обладает полномочием именно здесь?

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

Самоподпись никогда не была конечным источником полномочия. Она могла показать, что обладатель закрытого ключа подписал тот же объект, а в некоторых приложениях — помочь выявить случайное повреждение при хранении. Но она не доказывала, что администратору следует установить ключ, что имя субъекта верно или что ключ должен действовать повсюду. RFC 9925 убирает двусмысленность. Узел виден, отсутствующее ребро видно, а внешнее решение теперь должно предъявить собственное основание.

Заполненный issuer всё равно может быть заполнителем

Сложнее всего интерпретировать не пустую подпись, а непустое имя издателя.

Синтаксис X.509 требует поля issuer и не разрешает оставить его пустым. Существующие приложения могут также ожидать совпадения имён subject и issuer в представлении якоря доверия. Поэтому RFC 9925 позволяет скопировать имя субъекта в поле издателя либо использовать короткое специальное имя-заполнитель.

Ни один вариант не создаёт издателя. Без подписи объект не самоподписан; без отношения выпуска он не самовыпущен. Если экран без оговорки показывает заполнитель как «Кем выдан», обязательный слот синтаксиса превращается в институциональное утверждение. Если визуализатор рисует петлю от субъекта к самому себе, он заново создаёт ребро, которое стандарт удалил.

Так проявляется принцип Policy Mirror Лу Хэна: запись должна отражать существующую власть и событие, а не то, что подразумевает унаследованная грамматика. Расширения authority key identifier и issuer alternative name описывают издателя и обычно должны отсутствовать. Key usage и basic constraints могут описать способности субъекта, в том числе способность CA, но не дают разрешения установить его как якорь. Способность — не полномочие.

Регистрация не равна проверке

IANA зарегистрировала id-alg-unsigned. Благодаря распределённому коду разные системы распознают значение и находят спецификацию. Но реестр не делает пустую подпись действительной, не удостоверяет субъект и не одобряет изменение хранилища доверия.

Реестры нередко читают как списки признания, поэтому различие принципиально. В этом случае запись скорее помогает программам точно узнать не-подпись и отвергнуть её в контексте проверки. Без специальной поддержки обычный валидатор увидит алгоритм, который не способен проверить, и безопасно завершится отказом. Особая обработка нужна лишь узкому потребителю, который изначально был готов принять сведения о субъекте без проверки самоподписи.

RFC 9925 прямо описывает опасность: если приложение допускает неподписанный идентификатор в сертификационном пути или там, где подпись X.509 обязательна, проверка обойдена. RFC 8725 формулирует тот же широкий принцип для другой системы токенов: вызывающая сторона выбирает допустимые алгоритмы, а объявленный алгоритм должен быть связан с реально выполненной операцией. Реестр способен определить состояние, но не способен доказать правильный переход в каждом продукте. Для этого нужны тесты, конфигурация и эксплуатационные свидетельства.

Почему удаление подписи может усилить безопасность

Сочетание «неподписанный сертификат» звучит как ослабление. В предусмотренном контексте верно обратное.

Многие самоподписи в представлениях якорей не проверяются. Они существуют потому, что у X.509 есть поле подписи и программы ожидают форму сертификата. В постквантовых алгоритмах неиспользуемая подпись может быть крупной. Если субъект является конечным объектом, создание самоподписи применяет один ключ и в контексте X.509, и в его настоящем протоколе, расширяя межпротокольную поверхность. KEM-ключ вообще может не обладать операцией подписи.

Замена игнорируемого криптографического жеста именованным пустым значением уменьшает театр. Реализация не должна выводить доверие из поля. Валидатор может безопасно отказать. Ключ не принуждают выполнять чужую функцию. Сильная сторона RFC 9925 — в сужении утверждений: контейнер не притворяется доказательством издателя, а приложение не проверяет самоподпись, которая никогда не была причиной доверия.

Но защита работает лишь тогда, когда реальный внешний механизм понятен ответственным людям. «Вне полосы» — описание границы, а не объяснение. Это может быть лично сверенный отпечаток, подписанный образ прошивки, защищённый репозиторий, транзакция управления устройствами, производственная церемония или ручное решение администратора. У каждого пути свои владельцы, границы и свойства восстановления.

Право доверять перешло к установщику

RFC 6024 даёт словарь для недостающего слоя. Якорь представляет авторитетный субъект через открытый ключ и ограничения. Менеджер контролирует одно или несколько хранилищ. Хранилище может быть связано с приложением, устройством или общей платформой, а признание можно ограничить группой пользователей и целями. Операции управления добавляют, удаляют и заменяют якоря; надёжный протокол удостоверяет и источник, и полномочие стороны на такую поставку.

Так выглядит сдвиг управления. Когда в файле нет доказательства издателя, установщик совершает не канцелярский импорт, а действующее решение о доверии.

Он должен ответить минимум на четыре вопроса. Одобрены ли именно эти байты? Уполномочен ли поставщик предложить этот якорь? Вправе ли исполнитель изменить это хранилище? Для каких приложений, имён, политик и сроков ключ признаётся?

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

Квитанция происхождения и области доверия

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

Затем фиксируется происхождение. Из какого репозитория, образа устройства, пакета, церемонии или от какого администратора получен объект? Какой внешний хеш, подпись, защищённый канал или физическое сравнение обеспечили целостность? Как удостоверен источник и каким правилом подтверждено его право поставлять сведения о доверии?

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

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

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

Граница доказательств

Проверенные источники не показывают, насколько широко внедрён RFC 9925, какие продукты его поддерживают и ошибся ли какой-либо разработчик. Утверждённый устав LAMPS подтверждает работу над постквантовыми механизмами PKIX и S/MIME, но не является телеметрией внедрения. Реестр IANA доказывает выделение значения, а не правильную обработку.

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

Доказуемый вывод уже и достаточен. RFC 9925 намеренно отделяет данные субъекта от доказательства издателя, требует отказа в валидаторе пути и помещает целостность и доверие вне объекта. Это ясная техническая граница. Внешняя половина должна быть столь же проверяемой.

Источники

  1. Lu Heng, «The Policy Mirror»
  2. RFC 9925, «Unsigned X.509 Certificates»
  3. RFC 5280, «Internet X.509 Public Key Infrastructure Certificate and CRL Profile»
  4. RFC 4158, «Internet X.509 Public Key Infrastructure: Certification Path Building»
  5. RFC 5914, «Trust Anchor Format»
  6. RFC 6024, «Trust Anchor Management Requirements»
  7. RFC 8446, «The Transport Layer Security (TLS) Protocol Version 1.3»
  8. RFC 8725, «JSON Web Token Best Current Practices»
  9. IANA, «Structure of Management Information (SMI) Numbers»
  10. IETF, устав рабочей группы LAMPS