Какую версию действительно умеет участник?
В проекте ссылаются на новый номер RFC. Проверяем отдельно статус документа, формат метки и возможности участников.
RFC 9162 — экспериментальный документ декабря 2021 года, формально заменивший RFC 6962. Это не свидетельство поддержки CT 2.0 выбранным браузером.
Журнал версии 2 не выдаёт действительную SCT 1.0. Клиент может поддерживать обе версии для одного сертификата, используя их разные расширения.
Что лежит в контейнере и что подписывает CA?
Новая версия меняет и внешний контейнер данных, и форму предварительного сертификата. Начинаем разбор с типа объекта.
TransItem идентифицирует тип и версию данных; TransItemList может содержать SCT, STH и доказательства. Старый список только SCT не заменяет этот формат.
Предварительный сертификат CT 2.0 является объектом CMS с TBSCertificate внутри и подписью будущего издателя. Старый предварительный X.509-сертификат с poison extension — другая конструкция.
Какие байты должны попасть в проверку?
Даже нужный алгоритм не поможет, если хешируется другой объект. Различаем выданный сертификат, его TBSCertificate и запись журнала.
Для precert_sct_v2 из TBSCertificate выданного сертификата удаляют Transparency Information и встроенные SCT 1.0. Для x509_sct_v2 TBSCertificate используют без такой реконструкции.
Leaf hash вычисляется по HASH(0x00 || TransItem) записи. В ней учитываются тип, время, хеш ключа издателя, TBSCertificate и расширения SCT; хеш всего файла сертификата не подходит.
Достаточно ли идентификатора журнала и подписи?
OID помогает выбрать журнал, но не снабжает клиента ключом. Проверенная метка имеет ограниченный смысл и собственный срок обещания.
OID журнала CT 2.0 не является хешем ключа. Без соответствующих параметров клиент не может проверить SCT и не учитывает её в оценке соответствия.
Проверенная SCT обещает включение точной записи в пределах MMD этого журнала. Единого числа MMD в RFC 9162 нет; SCT сама не подтверждает уже состоявшееся включение.
Что журнал разрешает, а что решает клиент?
Журнал может хранить материал, полезный для расследования нарушений. Наличие такого материала не устанавливает пригодность сертификата для соединения.
После выполнения минимальных критериев журнал вправе принять, например, просроченный сертификат. Клиент всё равно отдельно проверяет серверный сертификат и цепочку.
Вид и количество CT-доказательств задаёт политика клиента. Если ClientHello не содержит одновременно transparency_info и status_request, RFC 9162 запрещает оценивать CT compliance; обычные проверки сертификата сохраняются.
Кто доставит доказательство и что узнает журнал?
Носитель CT-данных влияет на обновление сведений и прямые обращения клиента. Он не отменяет проверку полученного доказательства.
CT 2.0 использует transparency_info в TLS, расширение X.509 либо расширение вложенного OCSP. В передаваемом TransItemList SCT обязательна; доступные серверу inclusion proof и STH также рекомендуется передавать.
Прямой запрос inclusion proof сообщает журналу, с каким сервером общался клиент. Доставка сервером уменьшает это раскрытие и нагрузку на журнал, но полученные данные требуют проверки.
В каком именно дереве найдена запись?
Путь Меркла проверяется вместе с индексом, размером и корнем. Самодельное дерево с подходящим корнем не является подписанным ответом выбранного журнала.
Проверенное включение относится к конкретному листу и дереву. Для связи с журналом нужен корень из STH с проверенной подписью; этот результат не удостоверяет правильность выпуска или отсутствие скрытых веток.
Алгоритм отклоняет индекс вне дерева, лишний или недостаточный путь и несовпадение корня. Совпадения отдельных промежуточных значений недостаточно.
Какое состояние подходит для проверки срока?
STH подписывает состояние дерева, а MMD задаёт предел обещания SCT. Для вывода об исполнении нельзя произвольно выбирать ранний снимок.
При аудите обещания SCT можно проверить включение относительно STH позже timestamp SCT плюс MMD. Более ранний снимок мог законно ещё не содержать запись; один сетевой тайм-аут не является подписанным доказательством нарушения.
STH подписывает время, число записей, корень и расширения дерева. Его действительная подпись ещё не доказывает присутствие выбранной записи.
Сохранился ли старый префикс и где нужный лист?
Две задачи требуют разных доказательств: сравнить историю и найти конкретную запись. Не выводим второе только из успешного первого.
При положительных размерах m меньше n доказательство согласованности проверяет, что первые m записей большего дерева совпадают со старым деревом. С проверенными STH вывод относится к этой паре состояний одного журнала.
Одна проверка согласованности не устанавливает исполнение конкретной SCT. Для выбранной записи нужно отдельно доказать включение; уже доказанное включение можно использовать вместе с сохранением префикса.
Мог ли другой наблюдатель увидеть другую историю?
Локальная последовательность состояний может быть согласованной даже у нечестного журнала. Отделяем проверку полученных записей от сравнения разных представлений.
Согласованная история у одного наблюдателя не исключает другую ветку у другого. Для обнаружения split view нужны сведения участников друг о друге; RFC 9162 обсуждает gossip, но не задаёт его протокол.
Монитор обязан просматривать новые записи наблюдаемых журналов. Рекомендуемый обход проверяет подпись STH, соответствие записей его корню и сохранение истории; одних подписей 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; не источник текущей политики браузеров. Сетевой запрос в этом выпуске не выполнялся.
Открыть первоисточник