PKI и жизненный цикл сертификатов · проверено по источникам

Доказательство включения в CT

Доказательство включения в CT — набор узлов дерева Меркла, позволяющий проверить присутствие конкретного листа в дереве с заданным размером и корневым хешем. В CT 2.0 результат связывают с проверенным подписанным состоянием этого журнала.

Также ищут: Merkle inclusion proof · CT inclusion proof · путь включения Меркла

Практический смысл

Почему это важно

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

Доказательная часть

Что подтверждено

  1. Проверенное доказательство включения CT 2.0 подтверждает конкретный лист в дереве с заданными tree_size и root_hash. Когда этот корень взят из проверенного STH нужного журнала, вывод относится именно к этому подписанному состоянию; он не удостоверяет правильность выпуска сертификата или отсутствие других представлений журнала.

    Граница применимости: RFC 9162, 2.1.3, 4.12, 8.1.5 и 11.2–11.3. Нужна проверка входа и связи с STH; произвольный присланный корень не становится доверенным только из-за совпадения вычисления.

  2. Лист CT 2.0 хешируется как HASH(0x00 || TransItem) для x509_entry_v2 либо precert_entry_v2. В запись входят время, хеш ключа издателя, TBSCertificate и расширения SCT. Хеш целого файла сертификата не является заменой этого входа.

    Граница применимости: RFC 9162, 4.7 и 8.1.3. Используется хеш-алгоритм журнала и точная сериализация; хеш ключа издателя берётся по DER SubjectPublicKeyInfo.

  3. По алгоритму RFC 9162 проверка включения отклоняет leaf_index, который не меньше tree_size, а также лишний или недостаточный путь и несовпадение вычисленного корня. Совпадения только индекса или отдельных промежуточных хешей недостаточно.

    Граница применимости: RFC 9162, 2.1.3.2. Условия относятся к алгоритму проверки для заданных leaf hash, tree_size и root_hash; свежесть и подпись STH проверяются отдельно.

  4. Проверяя исполнение обещания SCT, аудитор может запросить включение относительно STH с временем позже суммы timestamp SCT и MMD журнала. Более раннее дерево могло ещё законно не содержать запись; отсутствие пригодного доказательства до этой границы само не устанавливает нарушение срока.

    Граница применимости: RFC 9162, 8.3. Проверяется конкретная SCT и соответствующая запись. Сетевой тайм-аут сам по себе не равен подписанному доказательству проступка журнала.

  5. Прямой запрос клиента к журналу за доказательством включения раскрывает журналу, с каким TLS-сервером общался клиент. Передача доказательства самим TLS-сервером предпочтительна для приватности и уменьшает нагрузку на журнал; полученные данные всё равно нужно проверить.

    Граница применимости: RFC 9162, 8.1.4–8.1.5 и 6.4. Это снижение конкретного раскрытия при запросе доказательства, а не обещание полной анонимности соединения.

Перед спецификацией

Что проверить

  1. Восстановите точную запись и её leaf hash.
  2. Сопоставьте идентификатор и параметры журнала.
  3. Проверьте подпись STH, размер дерева и корневой хеш.
  4. Проверьте индекс, весь путь и итоговый корень.
  5. Для аудита срока сравните время STH с timestamp SCT плюс MMD.
  6. Учитывайте раскрытие посещённого сервера при прямом запросе в журнал.
  7. Не переносите локальный результат на правильность выпуска или все представления журнала.
Открытые основания

Первоисточники

  • Первичная спецификация

    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; не источник текущей политики браузеров. Сетевой запрос в этом выпуске не выполнялся.

    Открыть первоисточник
Сообщить об ошибке

Опишите проблему — постараемся исправить как можно скорее.

Спасибо!

Получили ваше сообщение.
Подтвердите действие