Кратко

  • RFC 10002 позволяет оставить внутренний запрос конечного субъекта неизменным, а утверждения RA о доказательствах и изменениях поместить во внешний слой PKIData.
  • Действительная подпись, доказательство владения закрытым ключом, проверка личности, свидетельство RA, обработанное изменение и выданный сертификат — разные вердикты.
  • Для расследования нужны исходный запрос, все CMS-оболочки, порядок контролей, границы полномочий RA, версия политики CA и точная разница между запросом и сертификатом.

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

Сломанная подпись здесь не обязательна. RA могла проверить личность, обернуть уже подписанный объект, добавить указание на замену поля и передать пакет дальше. Затем CA применила собственную политику. Все подписи могут быть корректны, а вопрос об ответственности всё равно останется открытым.

RFC 10002, опубликованный IETF в июле 2026 года, задаёт структуры и контроли Certificate Management over CMS и заменяет RFC 5272 и RFC 6402. RFC 10003 определяет транспорт, RFC 10004 — минимальные возможности конечных субъектов, RA и CA. Вместе они показывают: криптографическая целостность объекта и полномочие изменить результат — не одно и то же.

Что закрепляет подпись PKCS #10

По RFC 2986 запрос PKCS #10 содержит имя субъекта, открытый ключ, необязательные атрибуты и подпись над этой информацией. Проверка подтверждает неизменность защищённых байтов и использование соответствующего закрытого ключа.

Она не подтверждает право на корпоративное имя, владение отдельным ключом, который не умеет подписывать, и обязанность CA включить все запрошенные расширения. Она также не даёт RA права менять поля.

Simple PKI Request в CMC может быть обычным PKCS #10, однако не несёт расширенных контролей. Его нельзя использовать с включённым доказательством личности или с закрытым ключом без функции подписи. Full PKI Request помещает PKIData в CMS SignedData либо AuthenticatedData.

RFC 5652 разрешает вкладывать одну защищённую CMS-структуру в другую. RA не переписывает внутренний PKCS #10 или CRMF, разрушая подпись либо POP, а добавляет собственную подписанную оболочку. Несколько RA создают несколько слоёв.

Внутренняя подпись говорит, что защитил заявитель. Внешняя — кто добавил контроль. Разрешалось ли этому посреднику добавлять именно такой контроль, решает отдельная политика.

Владение ключом не равно личности

Proof of Possession отвечает на вопрос, контролирует ли участник закрытый ключ к заявленному открытому ключу. Для ключа подписи доказательством может быть подпись. Для ключа шифрования или согласования нужны вызов, последующий ответ либо подтверждение. RFC 4211 описывает такие варианты CRMF и специальное raVerified для проверки, выполненной RA в оговорённых случаях.

Доказательство личности связывает транзакцию с человеком, устройством или организацией по выбранному способу аутентификации. Identity Proof Version 2 из RFC 10002 может применять общий секрет и MAC над материалом запроса. RFC 10004 требует поддержку этой современной версии.

Можно владеть ключом и не иметь права на указанное имя. Можно проверить кадровую запись и не доказать наличие ключа в аппаратном модуле. Единый флаг verified стирает это различие.

RA POP Witness сообщает CA, что RA выполнила POP. RA Identity Proof Witness сообщает о проверке личности, в том числе вне канала или с секретом, неизвестным CA. Это новое утверждение RA, а не исходное доказательство. Нужны идентификатор RA, метод, объект проверки, объём мандата и ссылка на сохранённые материалы.

Control Processed лишь говорит об обработке контроля здесь или далее. Если важен вид проверки личности, конкретное свидетельство нельзя заменять общим статусом «обработано».

Изменить, не разрушая происхождение

Modify Certification Request позволяет RA попросить заменить или удалить поля. Подписанный внутренний запрос остаётся исходным; изменение находится во внешнем защищённом слое.

Это бывает необходимо для нормализации имени, удаления неразрешённого расширения или преобразования проверенного значения в форму CA. Но журнал должен хранить body part, старое и новое значение, правило и ответственную RA.

Вложенные изменения применяются изнутри наружу. Для нескольких контролей одного слоя RFC 10002 не задаёт порядок. Зависимость от позиции в массиве означает зависимость от реализации. Если приоритет влияет на сертификат, нужно единое недвусмысленное решение или отдельные упорядоченные слои.

CA сохраняет своё решение. Она не обязана принимать все расширения и может менять значения по политике, но не должна обращать смысл ограничения, запрошенного клиентом. Сертификат — новый объект, подписанный CA, а не заверенная копия заявки.

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

HTTP-успех не завершает транзакцию

RFC 10003 определяет передачу через файл, почту и HTTP. HTTP использует POST, HTTPS защищает канал. Ответ 2XX не доказывает, что контроли CMC поняты и сертификат окончательно выдан.

Операция может оставаться pending или завершиться частично. Query Pending продолжает запрос результата, Confirm Certificate Acceptance продлевает состояние после доставки. Если финальный сервер не узнаёт либо не может обработать обязательный контроль, весь PKIData должен завершиться ошибкой. Молчаливое удаление контроля создаёт ложный успех.

Transaction ID связывает сообщения. Nonce отправителя и получателя помогают сопоставлению и защите от повторов. Они не заменяют бизнес-идемпотентность, однако без них повторная передача легко превращается в новую заявку.

RFC 10004 требует от RA поддержку Modify Certification Request, Control Processed и RA Identity Proof Witness; CA, работающие с RA, должны принимать соответствующие контроли. Это минимальная способность роли, а не доказательство корректной работы конкретного продукта.

После выдачи RFC 5280 регулирует X.509-сертификат, который будут проверять доверяющие стороны. Он допускает специальные политики и предлагает изучать политику CA. RFC 7030 описывает EST — другую архитектуру регистрации. Выбор CMC не создаёт универсального доверия.

Цепочка, которую можно восстановить

Досье начинается с канонических байтов и хэша исходного запроса. Отдельно фиксируются формат, ключ, атрибуты, результат подписи, метод POP, метод личности, проверяющий, время и версия политики.

Для каждого слоя RA сохраняются подписанная оболочка, сертификат RA, область полномочий, добавленные контроли, снятые слои и следующий получатель. У изменения есть «до» и «после», у свидетельства — вид исходной проверки. Закрытые ключи и общие секреты в журнал не копируются.

CA добавляет решение по каждому полю и итоговый diff. Transaction ID, nonces, повторные попытки, pending, подтверждение приёма, публикация и активация остаются связанными.

При компрометации RA внутренний запрос может оставаться подлинным. Злоумышленник подписывает вредоносную внешнюю оболочку доверенным ключом RA. Отсутствие подделки заявки не означает отсутствие злоупотребления.

Running-Code Primacy переносит авторитет на реально работающий код, который проверяет слой, мандат и сохраняет решение. Minimum Initial Specification удерживает общий механизм узким, а политику — у ответственного оператора. Различие реального и символического слоя не позволяет словам «подписано», «засвидетельствовано» и «выдано» превратиться во всеобщую гарантию.