Почему это важно
Успешное сравнение двух состояний защищает конкретную проверенную историю от незаметного переписывания. Для обнаружения разных историй у разных наблюдателей нужны сведения за пределами этой пары.
Что подтверждено
STH версии 2 содержит подписанное состояние дерева: время, число записей, корневой хеш и расширения. Действительная подпись STH удостоверяет это состояние от имени журнала, но без доказательства включения ещё не показывает, что выбранная запись присутствует в дереве.
Граница применимости: RFC 9162, 4.9–4.10 и 2.1.3. Ключ и алгоритм подписи берутся из параметров нужного журнала, а не выводятся из одного корневого хеша.
Для старого дерева из m записей и большего дерева из n записей проверенное доказательство согласованности подтверждает совпадение первых m записей в обоих деревьях. При проверенных STH одного журнала это доказывает сохранение префикса между этими двумя состояниями, а не во всех возможных ветках журнала.
Граница применимости: RFC 9162, 2.1.4, 2.1.4.2, 4.11 и 11.3. Здесь m положительно и меньше n; равные и пустые деревья не подставляются в алгоритм для строго возрастающих размеров.
Доказательство согласованности связывает старый и новый корни дерева и сохранённый префикс. Само по себе оно не подтверждает, что конкретная SCT исполнена или выбранный сертификат включён: для этого проверяют соответствующую запись и доказательство её включения.
Граница применимости: RFC 9162, 2.1.3–2.1.4 и 8.3. Уже отдельно доказанное включение может использоваться вместе с сохранением префикса, но из одной пары корней принадлежность записи не выводится.
Даже корректная цепочка доказательств согласованности у одного наблюдателя не исключает другую, противоречащую ей историю для других наблюдателей. Выявление такого split view требует обмена ответами журнала между участниками; RFC 9162 обсуждает gossip, но не задаёт его протокол.
Граница применимости: RFC 9162, 1, 8.3 и 11.3. Локальная проверка остаётся полезной, но не доказывает единственность глобального представления журнала.
Монитор обязан просматривать каждую новую запись каждого наблюдаемого им журнала. Рекомендуемый обход проверяет подпись STH и связывает полученные записи с его корнем; при хранении не всего журнала проверяют согласованность и соответствие новых записей элементам доказательства. Одних подписей STH для такого обхода недостаточно.
Граница применимости: RFC 9162, 8.2. MUST относится к просмотру новых записей; описанная последовательность обхода дана как SHOULD. Монитор может искать интересующие домены, но реакция на ошибочный выпуск организуется отдельно.
Что проверить
- Зафиксируйте два STH одного журнала и проверьте их подписи.
- Выберите алгоритм для соответствующего отношения размеров деревьев.
- Проверьте восстановление обоих корней и полноту пути.
- Для конкретной записи отдельно установите включение.
- Свяжите новые полученные записи с проверенным состоянием.
- Для поиска скрытых веток сравнивайте сведения разных наблюдателей.
- Не называйте локальную согласованность доказательством отсутствия глобального обмана.
Первоисточники
RFC 9162 — Certificate Transparency Version 2.0
IETF · RFC 9162, December 2021; Experimental; Obsoletes RFC 6962
Прочитан сохранённый полный текст: 1.3, 2.1.3–2.1.4, 3.2, 4, 6–8, 11, Appendix A. Experimental, не Internet Standards Track; не источник текущей политики браузеров. Сетевой запрос в этом выпуске не выполнялся.
Открыть первоисточник