Кратко

  • RFC 9641 описывает именованные наборы сертификатов и открытых ключей, центральные ссылки и встроенные определения; достижение настроенного якоря не завершает проверку личности.
  • Центральный набор координирует обновление многих потребителей, но увеличивает радиус ошибки и требует фиксировать точные байты, происхождение и версию, разрешённые в момент решения.
  • Полная квитанция связывает конфигурацию с объектом партнёра, путём, временем, именем сервиса, назначением, алгоритмами, отзывом, мотивированным результатом проверки и последующей авторизацией.

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

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

RFC 9641 задаёт ietf-truststore: общую модель именованных наборов сертификатов и сырых открытых ключей, на которые могут ссылаться другие YANG-модули. Потребитель может также хранить материал inline. Стандарт делает вход проверки совместимым, но оставляет локальному коду решение о личности и действии.

Якорь — вход проверки, а не её итог

RFC 9641 опубликован в октябре 2024 года как Standards Track документ рабочей группы NETCONF IETF. Наборы сертификатов и открытых ключей группируют объекты общего назначения. Назначение набора сертификатов следует описывать, а набора открытых ключей — необходимо описывать.

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

Набор «production servers» сам не сравнит DNS-имя, Extended Key Usage или certificate policy. TLS-группировки RFC 9645 могут указать, откуда брать доверие, но развернутая реализация должна показать выполненные проверки. Для сырого открытого ключа процедура отличается от X.509.

Разрешённая ссылка должна стать точным объектом

Leafref доказывает, что цель существует в модели. Он не доказывает, что последующая сессия выбрала эту цель или увидела ту же версию. Имя центрального набора способно пережить несколько ротаций, а процесс — продолжать использовать кэш.

Событийная квитанция фиксирует идентификатор набора и объекта, точные байты или отпечаток, хеш содержимого, происхождение datastore, путь потребителя и время разрешения. «Использован центральный truststore» описывает архитектуру. «Использован этот якорь в этой сессии» описывает наблюдаемое событие.

Этот переход важен для приоритета работающего кода. Intended-состояние может быть правильным, но ещё не попасть в operational или конкретный процесс. Результат нельзя выводить только из желаемого дерева.

Центральная и inline-модели по-разному распределяют власть

При наличии соответствующих features группировки inline-or-truststore требуют выбора между встроенным материалом и центральной ссылкой. Сегодня варианты могут содержать одинаковые DER-байты. Завтра центральный объект обновится, а inline-копия останется прежней.

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

Поэтому архитектурный выбор требует владельца, инвентаря потребителей, оценки радиуса и независимого отката. Для центрального изменения нужны сравнения до и после по каждому зависимому сервису. Для inline-объекта — срок пересмотра и проверка против актуального решения организации.

Происхождение system не заменяет цепочку поставки

Устройство может иметь встроенные якоря для сервиса производителя, безопасной начальной настройки или публичных центров сертификации. RFC 9641 ожидает их в operational и, если поддерживается, system datastore, с системным происхождением, отличным от операторской intended-конфигурации.

Разделение не даёт приписать оператору решение производителя. Однако способ установки и изменения встроенных якорей остаётся вне области стандарта. system не сообщает, кто одобрил заводской образ, какой build добавил объект, как проверено обновление и был ли якорь выбран в спорной сессии.

В безопасной zero-touch настройке из RFC 8572 начальное доверие может определить будущего контроллера. Сведение intended, system и operational к одному списку стирает доказательства этой передачи полномочий.

NACM защищает управление, но не весь покой данных

Узлы и ссылки truststore используют nacm:default-deny-write. По RFC 8341 запись без специального разрешения должна начинаться с отказа. Даже открытый сертификат критичен: его замена может перенаправить доверие.

Но аннотация не является журналом. Нужны личность NETCONF или RESTCONF-сессии, защищённый канал, версия правил NACM, совпавшее правило, путь и операция, значения до и после, деловое одобрение, commit и operational-проекция. RFC 8342 разделяет datastores, а не доказывает их причинную связь.

YANG также не определяет защиту данных в покое. Локальный привилегированный процесс, пакет, восстановление резервной копии или повреждение хранилища могут миновать NACM. Реализация обязана предотвращать несанкционированное изменение, а аудит — иметь отдельное свидетельство целостности.

Уведомление об истечении не подтверждает замену

При поддержке feature запись сертификата может отправить certificate-expiration. Сигнал не доказывает доставку, подтверждение, одобрение замены, переключение ссылок и следующую успешную проверку.

Замкнутый процесс связывает поддержку, подписку, событие, получателя, подтверждение, новый объект, развертывание, разрешение и первое успешное использование. Центральный набор может быть свежим, а inline-потребитель — старым. Неистёкший сертификат способен провалиться по имени, назначению, алгоритму или отзыву.

От пути к имени, затем к праву действия

RFC 5280 определяет проверку X.509-пути. Верификатор выбирает кандидатные пути, обрабатывает ограничения и локальную политику. RFC 6125 отделяет ожидаемую сервисную идентичность от валидности пути. RFC 8446 задаёт контекст TLS-сессии.

Воспроизводимое решение хранит сертификат или ключ партнёра, сессию, разрешённый набор и якорь, кандидатный и принятый путь, время и источник часов, сроки, reference identity, правило сопоставления, Key Usage, Extended Key Usage, name constraints, policies, алгоритмы, требуемую информацию об отзыве, версию верификатора и мотивированный результат.

Затем приложение авторизует действие. Партнёр может быть правильно аутентифицирован для чтения телеметрии и не иметь права менять маршрутизацию. Идентичность bootstrap не обязана иметь повседневную административную власть. Второе решение сохраняется отдельно.

Собрать квитанцию приёма

Сначала указать revision модуля, features, точный путь и режим: inline, центральный или встроенный. Сохранить intended-, system- и operational-происхождение, автора изменения, одобрение, решение NACM и доказательство целостности хранения.

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

Так RFC 9641 остаётся минимальным общим языком автономных систем. Общая модель сообщает, какой материал доступен. Работающий потребитель решает, кого и для чего принять. Квитанция не позволяет превратить действительный путь в неограниченные полномочия.

Источники