Кратко

  • Proof-of-Possession в RFC 10002 показывает, что конечный субъект владеет соответствующим закрытым ключом и способен им пользоваться. Это не доказывает автоматически личность, право на имя или разрешение выпустить сертификат.
  • CMC передаёт доказательство личности и доказательство владения отдельно и требует связать их с одним субъектом. Регистрирующий центр добавляет свои изменения снаружи подписанного запроса, а удостоверяющий центр применяет собственную политику и принимает решение.
  • Полная квитанция хранит исходный запрос, метод владения, личность, защитную привязку, оболочки каждого посредника, решение CA, ответ CMC, точный сертификат, доставку, установку, проверку цепочки и отзыв как самостоятельные состояния.

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

RFC 10002 описывает Certificate Management over CMS и роли участников. RFC 10003 задаёт перенос сообщений по HTTP, через файлы, почту и TCP. RFC 10004 формулирует требования соответствия для классов агентов CMC. Все три документа опубликованы в июле 2026 года под редакцией Joseph Mandel и Sean Turner. Это коллективное развитие CMS, PKCS #10, CRMF и X.509, а не личное изобретение Turner.

Публичный профиль IETF на 1 сентября 2026 года указывал его участие с IETF 34, авторство или соавторство более чем в 50 RFC, работу Security Area Director в 2007–2014 годах и ряд прошлых и текущих председательских ролей. Биография объясняет опыт в стандартах безопасности, но не даёт ему полномочий над конкретным заявителем, регистрирующим или удостоверяющим центром.

POP отвечает только за владение ключом

Запрос PKCS #10 связывает открытый ключ, субъект и атрибуты подписью. Проверка обнаруживает изменение и не позволяет незаметно заменить открытый ключ. Подписавшая сторона тем самым демонстрирует способность использовать соответствующий закрытый ключ.

В RFC 10002 эта группа механизмов называется Proof-of-Possession, POP. Возможны подпись, прямой вызов-ответ, косвенное доказательство, публикация и аттестация; не все способы применяются в каждой операции. Их общий результат ограничен ключом.

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

RFC 2986 прямо оставляет удостоверяющему центру дополнительные действия: аутентифицировать заявителя, проверить подпись и, если запрос действителен, сформировать сертификат. Условие действительности включает политику, принадлежность имени, профиль, назначение и достаточность доказательств.

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

Между личностью и ключом требуется проверяемая связь

Proof-of-Identity определён отдельно. Если доказательство личности надо включить, Simple PKI Request применять нельзя. Full PKI Request может использовать witness, вычисленный из общего секрета, существующий сертификат либо другой согласованный способ.

Раздельность защищает смысл доказательств, но допускает подмену при соединении. Нельзя взять действительную личность одного участника и действительный POP другого. RFC 10002 требует гарантировать, что оба материала предоставил один субъект. Для этого служат соответствие секрета имени subject, witness и связь с ранее выданным сертификатом.

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

Общий секрет также зависит от предшествующего процесса. RFC 10002 не определяет его внеполосную передачу. Если секрет попал не на то устройство, был скопирован между активами или повторно использовался, правильный witness доказывает знание секрета, но не исправляет исходную регистрацию. Ограничение метода должно оставаться видимым.

RA добавляет оболочку, а не редактирует подписанный запрос

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

Изменение подписанного PKCS #10 или CRMF сделало бы подпись и POP недействительными. Если RA предлагает изменить поле или добавить расширение, это помещается во внешний управляющий элемент CMC. Несколько RA создают несколько вложенных оболочек.

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

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

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

HTTP 2xx не закрывает решение CMC

По RFC 10003 HTTP-клиент отправляет POST с предусмотренным типом содержимого. HTTPS может защитить канал, но спецификация не требует HTTP-аутентификации от каждого CMC-клиента. Защита канала, HTTP-аутентификация, Proof-of-Identity и POP относятся к разным вопросам.

Код 2xx сообщает об успешной обработке HTTP. Вложенный ответ CMC может оставаться в ожидании или содержать badIdentity, popRequired, popFailed и неподдерживаемое расширение. Успешная доставка сообщения не равна выпуску.

Даже ответ об успехе проверяется по объекту. Совпадает ли открытый ключ? Какие subject, альтернативные имена, назначения, политики и срок действительно выданы? Доставлен ли сертификат нужному субъекту? Без точных байтов итоговый ярлык слаб.

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

После выпуска меняются объект и часы

RFC 5280 задаёт проверку цепочки, доверенные корни, ограничения имён, политики, срок и отзыв. Доставка, установка, соответствие закрытому ключу и локальное разрешение сервиса появляются позже.

Правильный сертификат может не попасть на устройство. Установленный сертификат может не совпасть с ключом. Действительная цепочка может вести к корню, которому приложение не доверяет. Установленная личность может не иметь права выполнить операцию. Отзыв меняет результат во времени.

Принцип приоритета работающего кода Heng Lu требует сохранять материал для повторения каждой проверки. Для регистрации это запрос, POP, личность, связь, оболочки RA, политика CA и ответ. Для эксплуатации — сертификат, соответствие ключу, цель установки, результат цепочки, источник статуса и решение сервиса.

Минимальная квитанция отдельно фиксирует заявителя и время; ключ и поля; метод и результат POP; метод и границы личности; связь; изменения RA и подписи; CA и версию политики; статус CMC; сертификат; доставку и установку; отзыв, замену и исправление.

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

Источники