Кратко

  • RFC 9646 помещает HTTP 400 между двумя вызовами get-bootstrapping-data: возможности клиента, выбор сервера и возвращённый CSR подтверждают разные этапы.
  • Подпись CSR доказывает владение соответствующим закрытым ключом, но сама по себе не доказывает происхождение устройства, одобрение CA, доставку, установку или разрешённое использование.
  • Поскольку csr-request находится в HTTP-ошибке, которую нельзя подписать как данные начальной настройки RFC 8572, механизм неприменим через недоверенный сервер.

Конец жизненного цикла раскрыл пробел в начале

RFC 9646 расширяет Secure Zero Touch Provisioning: при вводе в эксплуатацию устройство может получить сертификат личности для производственной среды. Обмен состоит из двух запросов и промежуточного указания.

Сначала SZTP-клиент отправляет csr-support: умеет ли он создавать новую асимметричную пару, какие алгоритмы и форматы CSR поддерживает. Если серверу нужен запрос, он отвечает HTTP 400 и помещает csr-request в RESTCONF error-info. Там выбираются алгоритм, формат и, при необходимости, содержимое запроса.

После этого клиент делает второй get-bootstrapping-data с p10-csr, cmc-csr или cmp-csr. Сервер, регистрационный центр или CA проверяет запрос. Только после одобрения ответ с данными ввода может содержать подписанный сертификат.

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

Перечень возможностей не равен факту выполнения

csr-support сообщает возможное. Он не подтверждает создание ключа, качество случайности или хранение секрета в TPM. Выбор сервера сужает варианты, но остаётся командой. Факт выполнения появляется лишь после генерации или выбора ключа и второго запроса.

Минимальная начальная спецификация Лу Хэна предлагает верную границу: общий стандарт задаёт необходимую передачу управления, а локальные решения не маскируются под универсальную схему. RFC 9646 не определяет единую политику CA, единственный способ доставки или права приложения.

Один статус «CSR готов» не позволяет установить, выбирал ли сервер заявленный алгоритм, был ли ключ действительно новым и относились ли два запроса к одной попытке.

Владение и происхождение — разные доказательства

Проверка владения использует открытый ключ из CSR для проверки подписи. Успех означает, что создатель запроса контролировал соответствующий закрытый ключ. Это точный, но узкий результат.

Происхождение отвечает, какое устройство или уполномоченный субъект создал запрос. В чистом PKCS #10 нет встроенной аутентификации происхождения. Её может дать личность клиента на уровне TLS или HTTP. Тогда контекст сессии должен храниться вместе с CSR. Отдельный файл не наследует утраченный контекст.

CMC и CMP поддерживают аутентификацию происхождения через PKI или общий секрет и допускают обработку в RA перед CA. Это расширяет доказательства, но не превращает запрос в разрешение. Нужно проверить путь IDevID, ссылку на секрет или защиту протокола, а затем применить политику выдачи.

При повторном использовании заводского ключа проверяют сертификационный путь IDevID и совпадение пары ключей. При новом локальном ключе CMC или CMP может связать запрос с заводской личностью или общим секретом. Эти маршруты нельзя скрывать под одной отметкой «подпись верна».

Новый ключ создаёт условную свежесть

RFC рекомендует новый закрытый ключ для каждого CSR. Если ключ действительно создан после указания сервера, случайные данные играют nonce-подобную роль. Возвращённый сертификат с этим открытым ключом связывает ответ с текущим обменом.

Но флаг key-generation не доказывает свежесть при повторяющемся отпечатке. Новый ключ не всегда безопаснее: если его нельзя защищать на уровне встроенного заводского ключа, RFC рекомендует использовать лучше защищённый старый ключ. Свежесть уменьшает отдельные риски повтора, а сильное хранение — риски раскрытия.

Динамический ключ следует держать в HSM или TPM. Без такой защиты срок его жизни разумно сокращать. Сертификат развёртывания и новый ключ считаются пользовательскими данными и должны удаляться при заводском сбросе. Именно этот этап отсутствовал в исходном инциденте.

Неподписанная команда задаёт границу доверия

RFC 8572 допускает контакт с пока недоверенным сервером, если клиент полагается на подписанные данные начальной настройки. У csr-request такой защиты нет: команда находится в HTTP-ошибке, которую нельзя подписать как эти данные.

Поэтому через недоверенный сервер механизм CSR применять нельзя. Клиент не должен отправлять ему csr-support; следует предпочесть signed-data-preferred. Это граница полномочий.

Её нарушение позволяет неаутентифицированной стороне выбрать алгоритм, формат и содержание будущей производственной личности. Корректный CSR позже докажет, что устройство исполнило указание, но не что указание исходило от законного субъекта.

После выдачи остаются доставка и работа

Получив CSR, сервер, RA или CA проверяет владение, происхождение, учётные данные и атрибуты, затем принимает решение. Подпись CSR не заменяет это решение.

RFC 9646 не определяет точный способ помещения сертификата в данные ввода. Примеры показывают варианты, включая привязку к хранилищу RFC 9642. Выдача и доставка остаются отдельными результатами.

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

Первичность работающего кода требует оценивать исполненные переходы и эффекты. YANG описывает обмен; CA, хранилище и служба создают собственные факты.

Замкнуть квитанцию жизненного цикла

Сначала фиксируются личность сервера, путь доверия, аутентификация TLS и HTTP и выбор csr-support либо signed-data-preferred. В первом запросе сохраняются nonce, данные устройства, алгоритмы и форматы.

HTTP 400 сохраняется как переход с полным csr-request, выбором, содержимым, временем и идентификатором корреляции. Для ключа фиксируют создание или повторное использование, открытый отпечаток, источник случайности или HSM, границу хранения и вывод о свежести.

Во втором запросе сохраняются формат и хэш CSR. Владение и происхождение получают отдельные вердикты с указанием IDevID, секрета, TLS- или HTTP-личности. Затем присоединяются решение RA/CA, отпечаток сертификата, доставка, установка, первое использование, ротация и удаление при сбросе.

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

Sources