Прозрачность сертификатов 2.0

При проверке метки важно выбрать правильные структуры, ключ журнала и правила клиента. Разбор CT 1.0 нельзя без изменений применять к данным CT 2.0.

1. 01

   RFC 9162 опубликован в декабре 2021 года как Experimental и прямо помечен Obsoletes: 6962. Это экспериментальная спецификация CT 2.0, а не документ Internet Standards Track; её публикация сама не устанавливает поддержку CT 2.0 конкретным браузером.

   Граница применимости: Заголовок и Status of This Memo RFC 9162; Appendix A описывает сосуществование версий. Текущий список реализаций и политика браузера здесь не проверяются.

2. 02

   В CT 2.0 структура TransItem отмечает тип данных и версию протокола общим полем versioned_type. Записи, SCT, подписанные состояния дерева и доказательства имеют разные типы; TransItemList объединяет такие объекты, а не только метки SCT.

   Граница применимости: RFC 9162, 4.5 и 6.3. Старый формат SignedCertificateTimestampList не является универсальным декодером списка TransItemList.

3. 03

   Предварительный сертификат CT 2.0 — подписанный объект CMS с будущим TBSCertificate внутри. Его подписывает тот же CA, который намерен выпустить сертификат; схема CT 1.0 с предварительным сертификатом X.509 и poison extension на этот объект не переносится.

   Граница применимости: RFC 9162, 1.3 и 3.2. Профиль CMS связывает подпись с содержимым и подписанными атрибутами: её нельзя просто использовать как подпись готового X.509-сертификата.

4. 04

   Для проверки SCT типа precert_sct_v2 клиент восстанавливает TBSCertificate предварительного сертификата, удаляя из TBSCertificate выданного сертификата расширение Transparency Information и встроенные SCT версии 1. Для x509_sct_v2 используется неизменённый TBSCertificate.

   Граница применимости: RFC 9162, 8.1.2. Это точное правило реконструкции входа SCT, а не разрешение менять другие поля или подпись выданного сертификата.

5. 05

   Идентификатор журнала CT 2.0 — OID; он больше не является хешем открытого ключа. Чтобы проверить SCT, клиенту нужны соответствующие параметры журнала, включая ключ и алгоритм подписи. Без параметров он не может проверить эту SCT и не учитывает её при оценке соответствия.

   Граница применимости: RFC 9162, 1.3, 4.1, 4.4 и 8.1.3. OID выделяет оператор либо получает через реестр; способ доверенной доставки параметров не задаётся этим RFC.

6. 06

   Проверенная SCT 2.0 связывает подпись журнала с конкретной записью и обещает её включение в пределах MMD этого журнала. MMD входит в параметры журнала; RFC 9162 не задаёт одно числовое значение для всех журналов. Одна SCT ещё не доказывает состоявшееся включение.

   Граница применимости: RFC 9162, 4.1, 4.8, 8.1.3 и 8.3. Для подписи восстанавливают соответствующий TransItem записи, включая время, TBSCertificate, хеш ключа издателя и расширения SCT.

7. 07

   Журнал CT 2.0 обязан применять минимальные критерии приёма, но после их выполнения вправе принять не полностью допустимый по RFC 5280 сертификат, например просроченный. Ни принятие журналом, ни проверка SCT не заменяют обычную проверку серверного сертификата и его цепочки.

   Граница применимости: RFC 9162, 4.2.1, 4.2.2 и 8.1.3. Это не отменяет обязательные минимальные критерии и не разрешает клиенту принять просроченный сертификат.

8. 08

   CT 2.0 предусматривает доставку через расширение TLS transparency_info, расширение сертификата X.509 либо расширение вложенного ответа OCSP. Передаваемый при рукопожатии TransItemList обязан содержать SCT; если сервер может получить доказательство включения и STH, их также рекомендуется передать.

   Граница применимости: RFC 9162, 6, 6.3–6.5 и 7.1. Для доказательств и STH используется SHOULD при возможности получить их; обязательным элементом каждого передаваемого TransItemList остаётся SCT.

9. 09

   Количество и вид CT-доказательств, а также реакцию на несоответствие определяет локальная политика клиента. По RFC 9162 клиент не вправе оценивать такое соответствие, если не включил в ClientHello оба расширения transparency_info и status_request, дав серверу возможность передать сведения предусмотренными способами.

   Граница применимости: RFC 9162, 8.1.1 и 8.1.6. Запрет относится к оценке CT compliance по этому протоколу, а не к обычной проверке сертификата или запрету иных оснований отказа.

10. 10

    Структуры CT 1.0 и CT 2.0 несовместимы: журнал версии 2 не выдаёт действительную SCT версии 1. Клиент при этом может поддерживать обе версии для одного сертификата, поскольку они используют разные расширения TLS, X.509 и OCSP.

    Граница применимости: RFC 9162, Appendix A — информативное описание сосуществования. Это возможность реализации, а не утверждение, что каждый существующий клиент поддерживает обе версии.

1. Назовите версию CT и проверьте тип каждого объекта.
2. Установите поддержку и отдельную политику нужного клиента.
3. Получите доверенные параметры журнала; одного OID недостаточно.
4. Восстановите точный вход проверки SCT с учётом её типа.
5. Различайте обещание SCT и доказательство включения.
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; не источник текущей политики браузеров. Сетевой запрос в этом выпуске не выполнялся.

  Открыть первоисточник ↗
• Первичная спецификация

  Certificate Transparency

  Internet Engineering Task Force · RFC 6962, June 2013

  Модель журналов и SCT из разделов 1, 3, 3.3 и 7 в редакторской выписке. Не описывает актуальную политику браузеров или протокол RFC 9162.

  Открыть первоисточник ↗