Кратко

  • draft-ietf-opsawg-yang-provenance-07 позволяет проверить происхождение и целостность канонизированных YANG-данных на момент подписи, но не превращает подписанное желаемое состояние в разрешённую производственную команду.
  • Отдельные квитанции нужны для ключа и его назначения, всех преобразований, свежести, аналитического вывода, действующего принципала, команды контроллера, фактической конфигурации и результата сервиса.

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

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

Подпись доказала происхождение предложения. Система превратила её в мандат, которого в данных не было.

Редакция 07 Applying COSE Signatures for YANG Data Provenance опубликована 6 июля 2026 года и истекает 7 января 2027 года. Это активный Internet-Draft рабочей группы OPSAWG; в заголовке указана цель Standards Track. Это не RFC, не завершённая регистрация IANA, не результат совместимости, не отчёт о внедрении и не сертификат безопасности. Datatracker показывал четыре ошибки YANG и ноль предупреждений 25 августа 2026 года. Упомянутые Java-реализация и демонстрации на хакатонах не доказывают производственную эксплуатацию.

Подпись ограничена выбранным объектом

Механизм использует COSE_Sign1 с пустой встроенной нагрузкой. Выбранное содержимое YANG передаётся как external data после канонизации. Для CBOR применяется length-first deterministic encoding, для JSON — JCS, для XML — Exclusive XML Canonicalization 1.0.

Алгоритм, kid и метод сериализации защищены. Успешная проверка означает, что эти канонизированные байты подписаны владельцем соответствующего закрытого ключа и после подписи не менялись.

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

Ключ подтверждает роль только по внешнему правилу

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

Ключ устройства может подписывать наблюдение. Ключ аналитического сервиса — рекомендацию. Ключ change authority — разрешение. Если система смешивает эти назначения, математически верная подпись становится пропуском не в ту область полномочий.

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

Countersignature не описывает новое содержимое

Дополнительные участники могут добавить полные countersignatures RFC 9338 к существующему объекту COSE. Первичный input и значение подписи не меняются; новые подписанты связываются с тем же канонизированным содержимым.

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

Проверяющий может валидировать первичную подпись, часть countersignatures или все. Поэтому статус обязан показывать обязательный набор и реально проверенные элементы. Зелёная иконка без policy version скрывает существенное решение.

Пропущенный участник не создаёт ошибку проверки

Проект прямо говорит: provenance trail полон лишь настолько, насколько полон набор присутствующих подписей. Механизм не гарантирует непрерывность и не замечает сам по себе, что посредник не подписал.

Организация должна хранить ожидаемый workflow graph: источник, broker, нормализация, модель, 승인ение и controller. Для каждой стадии задаются вход, выход и обязательный signer. Только сравнение ожидания с фактом обнаруживает пустое место.

Подпись укрепляет предъявленное звено. Она не создаёт отсутствующую цепочку и не представляет принципала, которого в ней нет.

Старое состояние может быть целым и недействующим

Свежесть не встроена. Ранее подписанный объект можно воспроизвести, если timestamp, nonce, request ID или эквивалентный контекст не связан с подписью.

Для desired state нужны policy epoch, окно применения, максимальный возраст, надёжный источник времени, состояние revocation и защита от повторного использования. Вчерашнее разрешение не продлевается сохранением байтов.

Schema validation добавляет структурную проверку, но не утверждает, что значение верно. Вывод AI/ML из подписанных данных — новый claim. Требуются model ID, версия, признаки, input set, output digest, uncertainty и approval.

Доказательство ограничивает решение, но не принимает его

Практический принцип из заметок Heng Lu особенно важен для closed loop: доказательство и участие не создают полномочий. Оператор, который несёт ответственность за клиентов, доступность и убыток, должен оставаться владельцем решения либо явно делегировать его ограниченной политике.

Поэтому цепочка должна иметь отдельный authorization receipt с principal, scope, временем, policy и условиями отмены. Подпись телеметрии не может заменить этот документ.

После разрешения остаётся исполнение. Controller может принять, device — отказать; часть флота может измениться, datastore — обновиться без нужного forwarding outcome. Нужны readback и независимое наблюдение сервиса.

Переносимость доказательства не равна завершению процесса

Проект предлагает четыре способа включения: provenance leaf, расширение YANG-Push notification, metadata instance data и annotation. Они помогают сохранить доказательство, когда исходный защищённый транспорт уже не доступен.

Но operational record должен продолжаться: подписанный источник, преобразования, анализ, авторизация, команда, состояние устройства и результат. Каждый шаг имеет собственного субъекта.

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

Источники