Кратко

  • RFC 9810 различает accepted, когда заявитель получил именно запрошенное, и grantedWithMods, когда получен похожий результат, а выяснение различий возложено на заявителя.
  • Защита CMP-сообщения подтверждает источник и связность транзакции, но не доказывает, что субъект, SAN, срок, Key Usage, EKU, ограничения и политика сохранили утверждённый замысел.
  • Локальная квитанция намерения сертификата может связать запрос, выданный объект, дельту полей, полномочие на изменение и решение принять или отклонить, не сохраняя закрытые ключи. Это редакционное предложение Daniel Kade, а не поле RFC.

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

grantedWithMods не означает сбой или злоупотребление. УЦ может сократить срок, нормализовать имя, назначить серийный номер, удалить неподдерживаемое расширение или применить утверждённый профиль. УЦ отвечает за то, что подписывает. Заявитель отвечает за то, что принимает и разворачивает.

Шаблон выражает намерение, а не командует подписью

RFC 9810 опубликован в июле 2025 года как документ Standards Track IETF. Он описывает CMP для создания и управления сертификатами X.509 во взаимодействии конечных сущностей, центров регистрации RA и удостоверяющих центров CA. Документ заменяет RFC 4210 и вместе с RFC 9811 заменяет RFC 9480.

Заявитель указывает желаемое содержание через CertTemplate. Структура похожа на подписываемую часть сертификата, а её поля необязательны или зависят от ситуации. В запросе можно назвать открытый ключ, субъект, срок и расширения. До подачи запроса можно получить шаблон, показывающий ожидания УЦ.

Полное заполнение не превращает шаблон в обязательный приказ. RFC 9810 прямо разрешает УЦ менять поля фактически выданного сертификата. Поэтому accepted означает точное получение запрошенного, а grantedWithMods — получение похожего объекта, различия в котором обязан определить заявитель.

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

Разница поля способна изменить полномочие

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

Key Usage различает цифровую подпись, шифрование, согласование ключей, подпись сертификатов и CRL. Extended Key Usage задаёт назначения. Basic Constraints отделяет конечную сущность от CA и ограничивает путь. SAN может задавать идентичность сервиса. Certificate Policies помогает полагающейся стороне оценивать область применения.

Не всякая дельта материальна. Серийный номер УЦ ожидаем. Более короткий срок может снижать риск. Эквивалентная нормализация имени может следовать профилю. Но иной открытый ключ, неожиданный SAN, расширенная EKU, способность подписывать сертификаты или неизвестное критическое расширение меняют оперативное полномочие.

RFC 9810 подчёркивает особый случай: выдача определённых EKU для ролей управления PKI делегирует авторизацию, первоначально находящуюся в сертификате CA. Это чувствительное действие, требующее проверки законности получателя. Сравнение полей здесь становится сравнением власти.

Хеш показывает только неравенство объектов. Нормализованный анализ должен объяснить, какой срок, EKU, идентификатор или constraint изменился. Затем локальная политика определяет: ожидаемое преобразование, именованное согласование, новый запрос или отказ.

Подлинность ответа не равна соответствию замыслу

CMP связывает сообщения защитой, идентификатором транзакции и nonce. Профиль может применять общий секрет или подпись. Proof-of-Possession показывает владение соответствующим закрытым ключом. RA может проверять, авторизовать, дополнительно защищать, пересылать или изменять запрос.

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

Если RA изменила запрос, след должен разделять первоначальные значения, преобразования RA, подписанные CA значения и основание каждого существенного изменения. Фраза «проверено RA» не объясняет место, где изменились доказательство, идентичность или использование.

Подтверждение принимает конкретный объект

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

Это не формальность завершения. Это последняя ясно обратимая точка, прежде чем сертификат станет обычным состоянием системы. Решение должно относиться к реально выданному объекту, а не только к ID запроса или наличию положительного ответа.

Лёгкий профиль RFC 9483 показывает поток: после accepted или grantedWithMods конечная сущность посылает certConf, а PKI отвечает pkiConf, если не согласовано неявное подтверждение. Отсутствие ожидаемого подтверждения должно трактоваться как отказ.

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

Политика объясняет законность изменения

RFC 3647 различает Certificate Policy, устанавливающую требования для сообщества или класса приложений, и Certification Practice Statement, описывающую практику и контроли конкретного УЦ. Один CMP-статус не может вместить институциональное основание каждого поля.

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

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

Прозрачность выпуска не означает принятия

Certificate Transparency делает выпуск наблюдаемым. RFC 9162 описывает проверяемые журналы добавления, позволяющие обнаруживать подозрительные сертификаты и контролировать активность CA. Но сами журналы не предотвращают ошибочную выдачу.

Запись в CT не доказывает принятие заявителем или разрешение на эксплуатацию. В одном сценарии косвенного Proof-of-Possession RFC 9810 запрещает публиковать окончательный сертификат в CT до получения certConf с его хешем, завершающего доказательство. Выпуск, подтверждение и публикация — разные состояния.

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

Квитанция намерения сохраняет дельту решения

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

Нормализованное сравнение охватывает открытый ключ, субъект, SAN, срок, Key Usage, EKU, Basic Constraints, политики, применимые Name Constraints, критичность и нужные приложению расширения. Каждая существенная дельта получает исход: ожидается профилем, одобрена компетентной ролью, отклонена или не разрешена. Сохраняются версии оценщика и правил.

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

Запись должна быть локальной и ограниченной по доступу. Внутренние имена, идентификаторы устройств, исключения и метаданные могут раскрыть чувствительную карту даже рядом с публичным сертификатом. CT обеспечивает ограниченную публичную видимость; квитанция хранит происхождение внутреннего решения.

Работающий код обязан сохранить различие протокола

Разделение Heng Lu между спецификацией, локальным решением, принятием, исполнением и наблюдаемым результатом не позволяет превратить протокольный успех во всеобщий мандат. RFC задаёт статусы, CA выдаёт, заявитель принимает, владелец развёртывает, а полагающаяся сторона доверяет или отказывает.

Running-Code Primacy не означает, что автоматически установленное становится легитимным. Реальный переход должен оставаться сравнимым с заявленным правилом. Клиент, объединяющий accepted и grantedWithMods, удаляет информацию управления, уже предоставленную протоколом.

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

Источники