Кратко

  • BRSKI-AE соединяет доказательство владения новым ключом с доказательством происхождения на основе заводского IDevID; удалённая RA может проверить оба после хранения и пересылки.
  • Подписанный объект поддерживает решение об авторизации, но не принимает его. Даже если функции RA вынесены в backend, RFC 9733 оставляет регистратора домена участником решения о присоединении устройства.
  • Voucher, согласие регистратора, решение RA, выпуск CA, подтверждение сертификата, телеметрия enrollment и производственный доступ — разные записи. Единый статус «устройство подключено» стирает их смысл.

Новый контроллер прибыл на площадку, где связь с центральной PKI появляется ненадолго. Локальный регистратор принял запрос, но удалённая служба была недоступна. Сообщение легло в очередь и ушло позднее. К тому времени TLS-сессия, в которой устройство впервые предъявило себя, закончилась. Удалённой RA всё равно требовалось проверить: этот ли контроллер запросил сертификат именно для этого ключа?

RFC 9733 переносит доказательство из краткоживущего соединения в сам объект. BRSKI with Alternative Enrollment использует аутентифицированный самодостаточный запрос. В нём отдельно подтверждаются владение будущим закрытым ключом LDevID и происхождение запроса от pledge с производственным IDevID.

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

Новый ключ доказывает владение, а не личность

Proof of possession проверяет связь с ключом. PKCS #10 обычно подписывает запрос тем новым закрытым ключом, чей открытый ключ должен попасть в сертификат. CRMF поддерживает и другие способы, в том числе для ключей без возможности подписи. Положительный результат показывает управление секретом.

Он не сообщает, кому принадлежит это управление. Любой участник способен создать пару ключей и доказать владение. Поэтому proof of identity, или proof of origin в терминологии RFC, связывает запрос с ранее аутентифицированным удостоверением. В BRSKI-AE это обычно подпись секретом IDevID, охватывающая запрос и устойчивый идентификатор pledge.

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

Операционный журнал должен разделять владение, происхождение и авторизацию. Отметка «подпись верна» слишком широка для разрешения выпуска и слишком бедна для объяснения отказа.

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

В обычном BRSKI протокол EST может привязать PKCS #10 к клиентской аутентификации TLS между pledge и регистратором. Ближайший узел получает полезное свидетельство. Но вторая RA за регистратором может не видеть той сессии и не способна повторить временную проверку.

BRSKI-AE применяет протокол, чьи сообщения аутентифицируют себя. Нормативный вариант использует CMP по облегчённому профилю. Защита PKIMessage несёт происхождение IDevID, а CRMF или PKCS #10 — владение ключом LDevID. Регистратор пересылает оригинал, а не пересказывает исчезнувшую сессию.

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

Независимость доказательства от транспорта не делает транспорт безразличным. Между pledge и регистратором сохраняется TLS или DTLS. Обмен между регистратором и backend PKI находится вне области RFC. CMP даёт целостность и подлинность, но не шифрует сообщения автоматически. Без дополнительной конфиденциальности наблюдатель может узнать, какие устройства вводятся, или избирательно мешать им.

Voucher закрепляет доверенный домен, но не выдаёт LDevID

До альтернативного enrollment pledge выполняет BRSKI-обмен voucher через регистратора и MASA. Voucher передаёт якорь доверия целевого домена, часто pinned-domain-cert. Благодаря ему устройство понимает, чьи доменные материалы можно принимать.

Voucher не является сертификатом LDevID. Он не доказывает, что RA разрешила новый ключ, CA выпустила сертификат или сеть впустила устройство. Он отвечает, какому домену доверять, а не какие права домен уже предоставил.

После imprint pledge создаёт секрет LDevID и отправляет самодостаточный запрос. В CMP ответ проверяется от якоря, установленного voucher. Две цепочки соединяются, но не сливаются: одна определяет доверенный домен, другая решает судьбу конкретного ключа и набора атрибутов.

Если панель называет принятый voucher «одобренным устройством», последующий отказ политики выглядит необъяснимой аварией. Если хранить только сертификат, исчезает основание, по которому pledge доверял издателю.

Делегирование RA не даёт обойти регистратора

RFC 9733 разрешает регистратору передать часть или всю RA-функцию отдельной системе. Но он обязан участвовать в решении, принимать ли pledge в домен. Архитектура не должна позволять устройству обратиться к CA в обход локальной двери.

Согласие может быть неявным в строго управляемой связи, заранее записанным в базе, переданным отдельным сообщением или явно подписанным. Для CMP рекомендуется вложить исходный запрос pledge в сообщение, подписанное регистратором. Backend видит два утверждения: устройство создало этот запрос; домен согласен, чтобы его рассмотрели.

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

Разделение указывает и владельца сбоя: IDevID относится к происхождению, отсутствие согласия — к регистратору, неподходящий профиль — к RA, неверный сертификат — к CA. Общий ярлык «ошибка PKI» не даёт такого маршрута исправления.

Асинхронная очередь не замораживает мандат

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

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

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

Ответ CA не завершает все процессы

Успешный ответ содержит сертификат и может включать промежуточные сертификаты или дополнительные якоря. CMP допускает необязательный Certificate Confirm. После проверки pledge сообщает, удалось ли зарегистрировать сертификат и подходит ли он; PKI или регистратор подтверждает получение этого сообщения.

Отдельно остаётся обязательная BRSKI-телеметрия состояния между pledge и регистратором. RFC 9733 выделяет её в самостоятельную финальную фазу. CMP-подтверждение сообщает PKI оценку сертификата устройством; BRSKI-телеметрия сообщает регистратору исход enrollment. Подтверждение приёма не доказывает применение сертификата.

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

Честный статус перечисляет границы: voucher принят; владение и происхождение проверены; согласие зарегистрировано; RA одобрила; CA выпустила; pledge подтвердил; телеметрия пришла; рабочий допуск ещё не наблюдался.

Имя сервиса находит возможность, а не законную власть

RFC 9733 обобщает URI до /.well-known/<enrollment-protocol>/<request> и регистрирует brski-reg-cmp для минимального обнаружения CMP-регистратора. Pledge может обратиться к endpoint и по HTTP-статусу понять поддержку операции.

Это обнаружение функции, не полномочия. Найденный сервис может не быть правильным регистратором для устройства. Запись IANA не доказывает развёртывание или соответствие. Успех HTTP может означать лишь принятие внешнего конверта, пока CMP-транзакция ждёт или отклонена.

След должен связывать endpoint, TLS-peer, якорь домена, протокол, внутреннюю транзакцию и владельца решения. Замороженные источники не подтверждают внедрение RFC 9733 конкретным производителем, железной дорогой, подстанцией, зданием или зарядной сетью. Примеры объясняют архитектуру, а не сообщают о production.

Источники