Кратко

  • draft-mcewan-adkm-problem-statement-00 ставит задачу сохранения проверяемой истории ключевого состояния стабильного идентификатора без нового решения административного издателя при каждом переходе и без обязательного глобального консенсуса.
  • Ключ может быть правомочен подписывать повседневные операции, но намеренно не иметь права в одиночку устанавливать произвольное будущее состояние. Иначе его компрометация наследуется всеми назначенными им ключами.
  • Для эксплуатационного решения нужны раздельные свидетельства рабочей подписи, полномочия на переход, участия восстановления, валидности истории, свежести, области поиска конфликтов, политики приложения и фактического результата.

В журнале инцидента появилась почти идеальная последовательность. В 03:07 ключ подписывал штатные запросы. В 03:11 его сочли, возможно, скомпрометированным. В 03:13 тот же ключ подписал замену, отозвал себя и передал полномочия новому ключу. Все подписи прошли проверку.

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

Индивидуальный Internet-Draft от 20 сентября 2026 года, Autonomous Decentralized Key Management Problem Statement, проводит важную архитектурную границу. Стабильный идентификатор должен переживать плановую ротацию, аварийную замену, изменение порогов, делегирование, восстановление и отзыв. Проверяющая сторона должна уметь проверить связанную историю событий. Документ не выбирает формат или готовое решение; он перечисляет вопросы, от которых решение не вправе уклониться.

У каждой подписи должна быть названа роль

Key State в терминологии проекта — это набор открытых ключей, порогов подписания, ролей и иных параметров авторизации, действующих в некоторый момент. Key Event создает или изменяет такое состояние. Controller вправе одобрять не любые изменения, а только классы переходов, разрешенные текущим состоянием и правилами протокола.

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

Свидетельство Что оно показывает Чего оно само по себе не показывает
Подпись действующего ключа Ключ подписал эти байты Его роли достаточно для данного класса перехода
Политика перехода Примененные роли, пороги и версия Входные данные свежи, а ключи не скомпрометированы
Связанная история Состояние следует допустимой цепочке Это самая новая и единственная цепочка
Одобрение восстановления Участвовала отдельная capability Все recovery-capabilities сохранили независимость
Свидетельство согласованности В заданной области замечен конфликт Неизвестной ветви нигде больше нет
Решение приложения Локальная политика приняла состояние Реальная операция завершилась успешно

Бит «подпись действительна» слишком мал для этой модели. Результат должен называть класс полномочия, версию правила и то, мог ли подписавший ключ изменить само правило, по которому его подпись признана достаточной.

Локальная проверка не создает всемирное настоящее

Local Evidence Verification позволяет проверить предъявленное состояние и аутентифицированную историю по локально доступным материалам, не обращаясь синхронно к назначенному органу. Это полезно на периферии, в нестабильной сети и в изолированной среде.

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

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

Матрица компрометации обязана иметь последнюю строку

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

Матрица должна охватить как минимум действующий ключ; одну долю порога; действующий ключ вместе с одной recovery-долей; полный контроль устройства при сохранной офлайн-способности; потерю наблюдателя во время сетевого разделения; все операционные и восстановительные секреты. Для каждой строки нужны ответ о восстановимости, требуемый субъект, задержка, область наблюдения и условие разрыва преемственности.

Фраза «система поддерживает ротацию» ничего из этого не гарантирует. Ротация, санкционированная уже похищенным ключом, может завершить закрепление атакующего.

Две валидные истории без единого мирового реестра

ADKM не требует помещать каждое событие в глобальный полный порядок. Благодаря этому непрерывность идентификатора не зависит обязательно от доступности, управления и финальности одной consensus-системы. Обратная сторона реальна: злонамеренный контроллер может показать разным сторонам разные, но валидно подписанные истории.

Проект называет независимых наблюдателей, gossip, перекрестную проверку и прозрачность возможными источниками Consistency Evidence, не отдавая предпочтения ни одному. Certificate Transparency в RFC 9162 и архитектура Key Transparency показывают, как tree heads, consistency proofs, мониторинг и обмен наблюдениями помогают обнаруживать расходящиеся представления. Отсутствие сигнала все равно не доказывает глобального единства.

Поэтому квитанция наблюдателя должна указывать границы: какое событие или commitment он видел, когда, какой предыдущий state помнил, с кем сверялся, находилась ли проверяющая сторона в изоляции. Eclipse-атака, разделение сети, задержка распространения, выборочное раскрытие и сговор меняют смысл слов «конфликт не наблюдался».

Соседние системы отвечают на соседние вопросы

RFC 5280 и RFC 6960 определяют сертификаты, CRL и OCSP в административной модели доверия с центрами сертификации и trust anchors. ADKM не объявляет их ошибкой или заменой. Certificate Transparency делает выпуск сертификатов наблюдаемым. RFC 7401 демонстрирует самосертифицирующиеся идентификаторы хостов. DID Core задает общую модель данных и framework методов, но update, recovery и versioning остаются метод-специфичными.

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

Канонические байты решают только спор о байтах

Участники должны подписывать одно и то же однозначное представление события. JSON Canonicalization Scheme в RFC 8785, детерминированное кодирование CBOR в RFC 8949 и продолжающаяся работа над dCBOR дают подходящие строительные блоки. Иначе одинаковое для человека событие даст разные дайджесты и подписи в разных реализациях.

Однако канонизация не решает, кто вправе снизить порог, действительно ли recovery-доля независима, достаточно ли свеж чекпойнт и разрешена ли платежная операция. Детерминированная форма делает разногласие воспроизводимым, но не делает решение легитимным.

Квитанция перехода без претензии на всемирный вердикт

Практическая реализация должна выдавать ограниченную квитанцию: стабильный идентификатор и inception binding; дайджест предыдущего состояния; sequence или epoch; тип события; старые и новые ключи, роли и пороги; точную версию политики; каждое одобрение с классом полномочия; участие восстановления; профиль детерминированного представления; дайджест события; ссылки на наблюдателей и время; область поиска конфликтов; источник свежести, возраст и максимально допустимый возраст.

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

Чего документ не доказывает

Первичный документ — revision 00 индивидуального Internet-Draft от 20 сентября 2026 года, предназначенного для Informational status и истекающего 24 марта 2027 года. Он не доказывает принятие рабочей группой, consensus IETF, реализацию, совместимость или безопасность названной системы. Он не выбирает сериализацию, сеть наблюдателей, ledger, recovery-алгоритм или event schema. Его ценность — в карте нерешенной территории.

Источники