Кратко

  • RFC 9908 делает ответ /csrattrs точным шаблоном последующего запроса на сертификат, а не расплывчатым списком допустимых типов атрибутов.
  • Документ проясняет кодирование OID вместе со значением, особенно для расширений X.509, и вводит CertificationRequestInfoTemplate, который сервер может заполнить лишь частично.
  • Клиент по-прежнему формирует ключевую пару и CSR; шаблон не заменяет аутентификацию и не означает одобрения со стороны центра сертификации.

RFC 9908 получил статус IETF Proposed Standard в январе 2026 года и обновляет RFC 7030 и RFC 9148. В обычной процедуре EST клиент получает через /csrattrs сведения о том, каким должен быть следующий CSR. Прежние правила допускали разночтения в кодировании атрибутов и их значений. Новая редакция связывает идентификатор объекта OID с требуемым значением однозначно и отдельно устраняет путаницу вокруг значений расширений X.509.

Главное добавление — CertificationRequestInfoTemplate. Сервер может частично заполнить структуру CertificationRequestInfo, включая различающиеся требования к имени субъекта. Поле subject необязательно: оно присутствует, если сервер задаёт требования к RDN. При этом RDN может содержать тип имени без значения — это явная пустая позиция, которую должен заполнить клиент. Если значение RDN передал сервер, клиент должен использовать именно его. Подставлять вместо него удобное локальное значение нельзя.

Такой механизм делает наличие и отсутствие ASN.1 значимыми. Отсутствующее поле нельзя автоматически объявлять неограниченным. subjectPKInfo отсутствует, когда сервер не предъявляет требований к ключу. Если поле есть, его алгоритм указывает ожидаемый тип ключевой пары. subjectPublicKey обычно отсутствует; специальный случай допускает заполнить его маркером, когда требуется выразить длину модуля RSA. Маркер не является окончательным открытым ключом клиента и не должен переноситься в CSR как таковой.

Причина практической важности — оформление идентичности при начальной загрузке ACP и BRSKI. Серверу нужно передать через /csrattrs конкретный subjectAltName; этот сценарий опирается на контекст RFC 8994 и RFC 8995. RFC 9908 уточняет форму запроса, которую должен построить клиент, но не подписывает и не утверждает CSR. Он также не заменяет аутентификацию EST и не определяет политику центра сертификации. Шаблон задаёт ограничение запроса, а не решение о выдаче сертификата.

Проверки совместимости на уровне байтов

Для приёмки нужно сохранить исходный ответ /csrattrs и проверить его ASN.1-представление побайтно: длины, порядок полей, каждый OID, тип и кодировку значения. Затем шаблон следует декодировать и повторно закодировать, сравнив результат с ожидаемым представлением. Отдельно проверяются отсутствие subject, наличие subject с RDN без значения и RDN со значением, заданным сервером. Нужно также проверить отсутствие subjectPKInfo, алгоритм при его наличии и специальный маркер длины RSA. Маркер нельзя принимать за ключ клиента. После этого сравниваются CSR, его расширения X.509 и полученная цепочка сертификатов с тем, что требовал шаблон. Одной успешной расшифровки ASN.1 недостаточно.

Решение оператора о приёмке

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

Источники