Кратко

  • RFC 9908 позволяет серверу EST передать фиксированные значения, требуемые типы полей и места, которые клиент заполнит в последующем запросе PKCS #10.
  • Ответ удостоверяет инструкцию по построению запроса; подпись CSR, владение ключом, аутентификация, авторизация УЦ, выданный сертификат, установка и фактическое использование остаются отдельными фактами.

Устройство только получило /csrattrs, а панель уже сообщила: «личность одобрена». В ответе были зафиксированы подразделение организации и P-256, клиенту оставили common name и одно незаполненное значение в subjectAltName. Сервер подробно сформулировал желаемый запрос. Но подписанного CSR ещё не существовало, клиент не прошёл проверку для зачисления, а удостоверяющий центр ничего не решил и не подписал.

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

Документ обновляет EST из RFC 7030 и вариант EST поверх CoAP из RFC 9148. Клиент и раньше мог узнать, какие атрибуты сервер или УЦ ожидает в запросе. Разночтения касались передачи не только OID, но и конкретных значений, особенно значений расширений X.509.

Новый CertificationRequestInfoTemplate похож на информационную часть запроса PKCS #10, однако не содержит оболочки подписи и допускает осмысленное отсутствие некоторых полей. Это частично заполненная форма будущего CSR, а не готовый запрос и не сертификат.

Отсутствие поля тоже несёт смысл. Если у сервера нет требований к distinguished name субъекта, subject отсутствует. Если нужен определённый RDN, его тип включают в шаблон. Тип со значением требует использовать это значение; тип без значения поручает клиенту подобрать подходящее. Отсутствующий subjectPKInfo означает, что здесь сервер не предъявил требований к ключу. При наличии поле алгоритма задаёт ожидаемый тип, а заполнитель открытого ключа может выразить требуемую длину модуля RSA.

Атрибут id-aa-extensionReqTemplate применяет то же различие к расширениям. Сервер указывает идентификатор и может передать значение полностью, не передать его или заполнить частично. В SAN возможно совместить имя от сервера и адрес, который добавит клиент. Практическую потребность показывает Autonomic Control Plane из RFC 8994, где через EST нужно сообщить определённый subjectAltName.

Ради совместимости структура CsrAttrs на проводе сохраняется. Версия шаблона — v1; нельзя повторять id-aa-extensionReqTemplate или сочетать его с прежним id-ExtensionReq. То же уточнение действует для CoAP. Это правила синтаксиса и совместимости, а не доказательства прав на идентичность.

RFC 7030 отделяет запрос атрибутов от зачисления. Получение /csrattrs необязательно, и для одного лишь ответа сервер обычно не должен требовать аутентификации либо авторизации клиента. Независимо от ответа сервер EST и УЦ вправе затем отклонить заявку по любой причине. Знание требований к форме не создаёт права на сертификат.

С подписанным CSR появляются другие проверки. Сервер аутентифицирует клиента и устанавливает, разрешено ли ему пользоваться запрошенной услугой. Подпись CSR при применимом механизме доказывает владение закрытым ключом. EST может связать этот факт с аутентифицированной сессией TLS. RFC 5272 задаёт более широкий контекст CMC для доказательства владения и управления сертификатами.

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

Выдачей всегда управляет локальная политика УЦ. RFC 7030 допускает ручную проверку и HTTP 202, пока решение отложено. В PKCS #10 УЦ аутентифицирует заявителя, проверяет подпись и, если признаёт запрос действительным, создаёт сертификат, используя также собственный выбор и иную информацию. Корректный CSR можно отклонить, задержать или преобразовать.

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

Выдача ещё не доказывает эксплуатацию. RFC 5280 определяет профиль X.509 и проверку пути доверяющими сторонами. Сертификат может остаться в очереди, попасть не на тот узел, сосуществовать с прежним или быть отвергнут политикой контрагента. Реестр установок и наблюдаемые рукопожатия — более поздние слои.

Поэтому минимальная запись аудита — связанная цепочка, а не один зелёный флаг. Сохраняются точные байты /csrattrs, идентичность сервера, время, срок кэширования и хеш шаблона. Фиксированные значения, места клиента и отсутствующие поля отмечаются отдельно. Готовый CSR привязывается к использованной версии; затем фиксируются проверка подписи, владение, аутентифицированная личность, входы и версия политики, решение УЦ, отпечаток сертификата, цель установки и окно наблюдения.

Если поля нет в шаблоне, сервер лишь не выразил через него требование. Это не означает, что последующее значение разрешено. Фиксированный SAN доказывает указание сервера запросить имя, но не доказывает основание права на его авторизацию. Происхождение такого права должно находиться вне ASN.1 в записи решения.

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

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

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

Слои реальности разделяют инструкцию, запрос, владение, идентичность, авторизацию, подписанный объект и наблюдаемую работу. Разбор технической и практической суверенности данных добавляет: техническая возможность не равна юридическому или организационному полномочию. Возможность записать имя в CSR не создаёт права на него.

RFC 9908 улучшает EST тем, что сервер точнее описывает ожидаемый запрос. Надёжная архитектура сохраняет предел этого действия. Шаблон инструктирует, клиент заполняет и подписывает, сервер аутентифицирует, политика разрешает, УЦ выдаёт, оператор устанавливает, контрагент проверяет. Доверие появляется, когда доказуем каждый переход.

Источники