Кратко

  • В draft-ietf-keytrans-architecture-09 tombstone в старом журнале отправляет поиск метки в новый и не даёт принять прежнее значение лишь из-за недоступности нового журнала.
  • Тот же проект отдельно требует наблюдать оба журнала и сохранять старый доступным достаточно долго, чтобы пользователи, в том числе долго находившиеся офлайн, завершили наблюдение.
  • Для остановки нужен акт вывода журнала: финальная вершина дерева, каналы её доставки, группы клиентов, доказательства завершения, исключения, ответственный за решение и условие восстановления. Такой акт предлагает статья; это не требование KEYTRANS.

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

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

Значит, завершённая запись данных и завершённая цепочка доказательств — разные события. Tombstone упорядочивает поиск, но не принимает решение об уничтожении прошлого.

Защита от возврата к устаревшему ключу

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

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

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

При постепенном переходе Search сначала обращается к старому журналу. Новый используется только тогда, когда последняя версия метки в старом стала определённым приложением tombstone. Обычные Update идут в новый журнал; старый принимает лишь недостающий указатель. Недоступность нового журнала тем самым не превращается в разрешение использовать ключ до миграции.

Но указатель подтверждает только место поиска. Он не подтверждает правильность перенесённого значения, проверку владельцем, доставку всем клиентам или завершение контроля старой истории.

Два журнала оставляют две незакрытые обязанности

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

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

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

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

Финальная вершина не исполняет решение сама

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

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

Проект протокола включает max_ahead, max_behind, обязательное reasonable_monitoring_window и необязательное maximum_lifetime. Окно задаёт ожидаемую периодичность проверки и общие опорные записи. Оно не измеряет реальную аудиторию. Максимальный срок облегчает ограничение хранения, но не превращается автоматически в срок поддержки.

Акт вывода журнала

Документ может быть компактным и не раскрывать пользователей.

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

Правило перехода. Идентификаторы журналов, направления Search, Update и Monitor, смысл tombstone и версии клиентов. Перенаправление нельзя смешивать с отказом от истории.

Доставка. Аутентифицированные каналы финальной вершины и результаты по версии, платформе, управляемому парку, спящим учётным записям и восстановленным копиям. Общего числа загрузок недостаточно.

Завершение. Контакт с новым журналом, проверка перенесённой метки, финальный Monitor старого и испытание восстановления учитываются раздельно.

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

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

Продвинутый проект всё ещё не RFC

Редакция 09 остаётся Internet-Draft с предполагаемым статусом Informational, поданным в IESG на публикацию. Отчёт shepherd фиксирует согласие и отсутствие существенных возражений в сравнительно небольшой профессиональной группе. Это зрелость процесса, а не опубликованный RFC или доказательство внедрения.

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

Минимальная общая гарантия невелика: сбой нового журнала не должен воскрешать старый ключ; закрытие старого не должно без основания уничтожать путь проверки истории. Конкретный срок обязан назвать и принять оператор, а не tombstone.

Источники

  1. Архитектура KEYTRANS, редакция 09
  2. История документа и отчёт shepherd
  3. Протокол KEYTRANS, редакция 05
  4. Устав рабочей группы KEYTRANS
  5. Протокол KEYTRANS на IETF 126
  6. Lu Heng, «Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption»
  7. Lu Heng, «Running Code Primary»