Техническое: poison-расширение и SCT-метки в Certificate Transparency

Ещё о пресертификатах в Certificate Transparency (CT) и странных “свойствах”, которые возникают вокруг. TLS-сертификаты превращаются в пресертификаты после того, как добавлено специальное расширение Poison. Может показаться, что с этим расширением тоже связана проблема “курицы и яйца”, поскольку нарушать процесс валидации poison-расширение должно потому, что оно помечено как Critical (критическое), но имеет тип, неизвестный валидатору – неизвестные критические типы, согласно рекомендациям, должны приводить к тому, что сертификат считается невалидным (а вот расширения неизвестного типа, которые не помечены как критические, можно игнорировать). Если же валидатор знает тип poison-расширения, то флаг Critical уже не должен препятствовать валидации. Это так, однако проблемы тут нет: в том случае, когда валидатор распознал poison-расширение, он не должен принимать сертификат на правах валидного, так как, грубо говоря, видит, что это пресертификат (ну или можно интерпретировать иначе: наличие poison-расширения означает, что сертификат не должен использоваться так же, как и сертификат без Poison). В общем, всё же появляется неплохой шанс выстроить однозначный процесс валидации.

С пресертификатами связано множество весьма неочевидных аспектов. Так, единственный смысл в пресертификатах – это создание “костыля” для получения метки времени от сервиса CT-лога, чтобы включить эту метку в сертификат. Метка (она называется SCT) связана с конкретным пресертификатом и подписывается лог-сервисом. Но включается метка уже в сертификат, который от пресертификата отличается в некоторых деталях. Напрмер, сертификат не должен содержать poison-расширение. При валидации сертификата проверяется и SCT-метка (ну, если валидирующая сторона, – скажем, браузер, – хочет проверить метку). Понятно, что если подпись вычислена для другого набора данных (пресертификат), то она не сойдётся. Как же устроены процессы подписывания и проверки подписи SCT-метки? Они устроены непросто.

При вычислении подписи для пресертификата сервис CT-лога использует в качестве входных данных не весь сертификат, а только его “содержательную часть” (некоторое зафиксированное в структуре подмножество полей), из которой, к тому же, удаляется poison-расширение. Это, что называется, первый “сюрприз”: poison-расширение должно присутствовать в составе поступающего пресертификата не только потому, что оно и делает сертификат пресертификатом, но и потому, что иначе не сойдётся подпись УЦ на пресертификате, а подпись должен проверить сервис лога. Дописать какие-то данные в сертификат не выйдет. Однако поскольку в сертификате Poison удаляется, то и подпись в SCT нужна на данных без poison-расширения. Второй “сюрприз”: при проверке подписи SCT в сертификате – нужно восстановить содержательную часть пресертификата в точно таком виде, какой передавался в сервис CT-лога, но с учётом удаления Poison – то есть, нужно удалить “лишние” расширения (SCT-метки), а те расширения, которые останутся, должны совпасть с конфигурацией пресертифката. А поскольку такое преобразование снова удаляет из состава сертификата значение подписи, к данным сертификата, перед проверкой, вместе с другими служебными параметрами SCT, нужно присоединить отпечаток открытого ключа УЦ. Понятно, что то же самое делается и на стороне CT-лога, при формировании SCT. Так что общий алгоритм местами “макаронный”, но, тем не менее, используется. Не удивительно, что в новой версии CT пресертификатов нет.

Адрес записки: https://dxdt.ru/2023/04/14/9840/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Написать комментарий

Ваш комментарий:

Введите ключевое слово "98778" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.