Кратко

  • 28 сентября IETF перевела Key Transparency Architecture в состояние AD Evaluation::Revised I-D Needed: директор области безопасности потребовала отделить владельца метки от стороны, которая полагается на неё.
  • Корректные поиск, подпись вершины дерева и доказательство согласованности не отвечают сами по себе, кто разрешил запрос, кто мог изменить привязку и кто обязан следить дальше.
  • Эксплуатации нужен ролевой чек проверки: владелец, роль запрашивающего, решение доступа, режим, подписант, временные пределы, предыдущее состояние и незавершённый мониторинг.

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

Запрашивающий был владельцем метки или стороной, которой нужен чужой открытый ключ? Какая политика разрешила раскрытие? Кто имел право внести новое значение? Кто должен вернуться позже и проверить, что свежая версия не исчезла до того, как её заметил владелец? Ответ valid=true этого не содержит.

28 сентября 2026 года директор области безопасности IETF Deb Cooley опубликовала замечания к редакции 09 Key Transparency Architecture. История Datatracker фиксирует переход к AD Evaluation::Revised I-D Needed. Документ остаётся Internet-Draft, рассчитанным на информационный RFC; он не стал стандартом и не доказывает существование внедрения.

Главное замечание выглядит терминологическим. Редакция определяет User / Account, но затем назначает разные задачи «владельцу метки» и пользователю, который ищет чужую метку. Cooley предлагает назвать второго relying party. Владелец является субъектом привязки; доверяющая сторона принимает решение на её основе. Их права и последующие обязанности различны.

Прозрачность ключей защищает вход в сквозное шифрование. Сервис часто распространяет открытые ключи участников. Если он незаметно свяжет учётную запись с ключом злоумышленника, шифрование сработает, но защитит неверное отношение. Архитектура помещает привязки идентичности к ключу в криптографически защищённый журнал только для добавления. Search, Update и Monitor возвращают доказательства, а следующие ответы должны согласовываться с предыдущей картиной клиента.

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

Три режима по-разному распределяют эту работу.

В Contact Monitoring владелец регулярно проверяет последнее значение, а сторона, увидевшая недавно добавленную версию, позже убеждается, что та не была скрыта. Необходимый Monitor должен оставаться доступным даже после запрета прежнего Search или Update. Отзыв нынешнего доступа не отменяет доказательную обязанность, возникшую из прежнего законного наблюдения.

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

В Third-Party Management внешний управляющий ведёт хранение и работу, а оператор сервиса контролирует доступ и аутентифицирует новые версии. Модель предполагает отсутствие сговора. Проверка просит добавить в схему допустимый поиск: операции Alice только со своей записью скрывают путь стороны, которая ищет чужой ключ.

Key Transparency Protocol делает различия параметрами конфигурации: режим, ключи подписи и VRF, разумное окно мониторинга, а при аудите — ключ аудитора, начальная позиция и максимальное отставание. Фраза «подпись верна» без этих сведений теряет смысл доверия.

Локальное состояние клиента тоже является контролем. Предыдущая картина ограничивает следующую; её потеря ухудшает обнаружение развилки или позднего сокрытия данных. Для эфемерного состояния веб-страницы или потери, которую может вызвать противник, редакция 09 рекомендует внешнее управление. Проверка просит примеры и ясное объяснение «постоянно недействительного состояния», которое может проявиться лишь при сохранении связи в течение ограниченного времени.

Политика доступа остаётся у приложения. Оно может разрешать поиск только контактам, требовать вход или ограничивать частоту. Доказательство показывает обработку запроса журналом, но не право приложения раскрыть метку этому человеку. Поэтому смешение слов «друзья» и «доступ» предлагается заменить последовательной терминологией ACL.

У конфиденциальности и удаления свой календарь. Пользовательские данные можно удалить после истечения срока или постоянной недоступности, тогда как криптографический материал может требоваться до максимального срока жизни. Проверяемая случайная функция скрывает метки. Проверка предлагает сделать RFC 9381 нормативной ссылкой, если понимание VRF необходимо, и объединить разделы о приватности.

Есть и зависимость документов. Shepherd называет архитектуру основанием протокола; при её ранней публикации ссылки на протокол должны оставаться примерами. Также нужно объяснить сравнение с внедрённой версией Certificate Transparency RFC 6962 рядом с RFC 9162. MLS даёт контекст учётных данных, но не свидетельствует о внедрении KT.

Эксплуатационный ответ — не новый хеш, а ролевой чек. Вместе с доказательством и версией метки надо сохранить роль, владельца, политику и её версию, режим, подписанта, размер и время дерева, допустимое отставание, прежнее состояние и ожидаемый Monitor. Тогда можно отличить неверное доказательство, неразрешённое раскрытие с корректным доказательством, устаревшую картину аудитора, пропущенный мониторинг и потерю состояния.

Редакция 10 может предложить иной текст. Граница уже видна: журнал только для добавления делает обман обнаружимым; явные роли назначают того, кто обязан его обнаружить.

Источники