Summary

  • RFC 10003 стандартизирует HTTP, файловый обмен, почту и TCP как транспорт CMC. Результат транспорта говорит о перемещении сообщения, а не о решении по содержащейся в нём операции PKI.
  • Код 2XX, приём письма, появление файла или завершение записи TCP сами по себе не доказывают одобрение CA/RA, выпуск нужного сертификата или его фактическую активацию.
  • Daniel Kade предлагает квитанцию «от транспорта к решению», которая связывает ограниченные сведения о канале с проверенным ответом, ожиданием, отпечатком выпущенного сертификата и внедрением, не сохраняя секреты заявки.

Доставка и рассмотрение живут по разным часам

Автоматизированная выдача сертификата выглядит как одна операция: отправить запрос, получить ответ, развернуть результат. На деле транспортная платформа перемещает данные, регистрационный или удостоверяющий центр рассматривает заявку, а владелец системы устанавливает учётный объект.

RFC 10003 стандартизирует первую функцию. Он определяет передачу сообщений Certificate Management over CMS по HTTP, через файлы, электронную почту и TCP. RFC 10004 требует от всех сущностей CMC реализации HTTP; остальные способы можно поддерживать дополнительно. Благодаря этому стороны одинаково понимают оболочки, типы носителя и порядок обмена.

Решение определено RFC 10002. Full PKI Response может сообщать об успехе, отказе, ожидании, частичном результате, отсутствии поддержки, необходимости подтверждения или дополнительного действия. Отложенный выпуск требует нескольких циклов. Поэтому окончание HTTP-обмена не закрывает автоматически транзакцию сертификации.

Предел полномочий кода 2XX

RFC 10003 предписывает использовать POST и коды 2XX для успешных HTTP-ответов. Двоичное тело получает установленный Content-Type. Full PKI Request использует application/pkcs7-mime; smime-type=CMC-Request, а Full PKI Response — параметр CMC-Response. Для простых форм действуют отдельные обозначения.

Эти поля дают точную транспортную квитанцию: URI, метод, время, код, тип содержимого, ссылку на политику TLS и ограниченные хеши запроса и ответа. Можно подтвердить, что конкретная точка приняла запрос и вернула ответ по правилам HTTP.

Однако 2XX не толкует решение внутри тела. Такой ответ может переносить CMC-статус failed, pending или partial. Веб-сервер успешно вернул сообщение, тогда как CA отказал, отложил рассмотрение или выполнил только часть работы.

И не всякий не-2XX означает отказ CA. До логики CMC мог завершить обмен прокси, маршрутизатор, проверка HTTP-аутентификации или типа содержимого. Если решения не наблюдали, запись должна говорить именно об отсутствии наблюдаемого решения.

Ожидание — не обещанный успех

Статус pending создаёт обязанность продолжить протокол. PendInfo содержит токен и рекомендуемое время повторного запроса; заявитель должен вернуться. partial оставляет невыполненные части открытыми. Идентификатор транзакции, если он используется, хранится до завершающего Full PKI Response.

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

Повторная отправка способна создать новый факт. POST не идемпотентен, поэтому RFC 10003 запрещает 0-RTT early data реализациям CMC с TLS 1.3 или QUIC. Если ответ потерян и тело отправлено снова, возникают две доставки. Хеш, nonce и идентификатор транзакции помогают различить восстановительную попытку, повтор и новую разрешённую заявку.

У каждого носителя своя ложная определённость

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

Почтовый режим задаёт MIME-оболочку, имена, типы и примеры base64. Message-Id, принятие SMTP или доставка в ящик относятся к почтовой системе. CMC-статус остаётся в теле. RFC 10003 отдельно предупреждает: TLS до первого агента отправки не гарантирует шифрование и аутентификацию последующих ретрансляций. REQUIRETLS может запросить защищённую цепочку у совместимых узлов, но привести к недоставке при отсутствии поддержки.

TCP передаёт двоичные сообщения без дополнительной оболочки. Для pkix-cmc зарегистрирован порт 5318, а клиент обязан дождаться полного ответа перед следующим запросом на том же соединении. Установленное соединение и записанные байты не заменяют проверку ответа.

Телеметрия каналов различается, но запрет общий: ни один канал не объявляет результат от имени PKI.

Защита сообщения не отменяет управление маршрутом

Структуры CMS могут обеспечивать целостность, подлинность и конфиденциальность объекта. HTTPS защищает соединение; IPsec, EnvelopedData и AuthEnvelopedData дают другие слои. Каждый слой отвечает только за своё утверждение.

Корректный TLS не доказывает право заявителя на имена, проверку личности RA или согласие CA с профилем. Подлинное CMS-сообщение само по себе не показывает, через какую точку оно прошло, какой посредник ошибся и к какой попытке относится ответ.

RFC 10003 также не требует от CMC-клиентов поддержки HTTP-аутентификации или cookies. Сервер не вправе рассчитывать на них. Первичное установление доверия и политика выпуска остаются отдельными архитектурными решениями.

Поэтому слова «безопасно доставлено» слишком широки. Следует писать: TLS-канал проверен, объект CMS аутентифицирован, полномочия заявителя подтверждены, решение CMC получено, сертификат выпущен, отпечаток установлен. У каждого глагола своя проверка.

Квитанция от транспорта к решению

Я предлагаю квитанцию CMC от транспорта к решению. Это модель управления Daniel Kade, а не новое требование RFC 10003 или IETF.

Первый раздел хранит факт канала. Для HTTP — точку, метод, время, код, Content-Type, ссылку на политику TLS и ограниченные хеши. Для почты — идентификатор отправки, адрес назначения, наблюдаемую передачу и охват защиты ретрансляторов. Для файла и TCP — контролируемый канал, направление, время и хеш. Тела, ключи, пароли и чувствительная топология не нужны.

Второй раздел описывает прикладной разбор: простую или полную форму, идентификатор транзакции, затронутые body parts, проверку целостности и подлинности. Полученные, но не разобранные байты оставляют доказательство на транспортном уровне.

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

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

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

Управление по последнему доказанному этапу

Честная панель показывает не одно «готово», а последовательность: POST принят, ответ CMC проверен, заявка ожидает, сертификат выпущен, отпечаток установлен, новая идентичность замечена в сервисе. У каждого этапа есть владелец и срок актуальности.

Мониторинг ищет разорванные связи: 2XX с неразбираемым телом, CMC-отказ в статистике успеха, токен без повторного запроса, одинаковые тела под разными транзакциями, сертификат с другой ключевой или именной привязкой, выпуск без внедрения и сервис со старым сертификатом.

Правильный знаменатель — все начатые CMC-транзакции. Для каждой организация должна назвать последний доказанный этап и найти подтверждающую его ограниченную запись. Доля зелёных HTTP-запросов измеряет только самый быстрый слой.

RFC 10003 стандартизирует дороги CMC. Управление начинается с сохранения границы между прибытием и решением.

Источники

  1. Lu Heng — Суверенитет данных: техническая и практическая реальность
  2. Lu Heng — Зачем существует BTW Media
  3. Lu Heng — Приоритет работающего кода
  4. RFC 10003 — Транспортные протоколы CMC
  5. RFC 10002 — Certificate Management over CMS
  6. RFC 10004 — Требования соответствия CMC
  7. RFC 5273 — Предыдущая транспортная спецификация CMC
  8. RFC 5967 — Тип среды application/pkcs10
  9. RFC 8551 — Спецификация S/MIME 4.0
  10. RFC 9110 — Семантика HTTP
  11. RFC 9205 — Построение протоколов на HTTP
  12. RFC 9325 — Безопасное применение TLS и DTLS
  13. RFC 8446 — TLS 1.3
  14. RFC 9000 — QUIC
  15. RFC 8689 — Опция SMTP REQUIRETLS
  16. RFC 3207 — Защищённый SMTP поверх TLS