OCSP задаёт подписанное состояние и его проверку; вложение определяет способ доставки в TLS. У этих уровней разные нормативные документы.
Почему это важно
Доставка сообщения и пригодность его содержания — разные проверки. Версия TLS меняет место передачи; подлинный, но устаревший или относящийся к другому сертификату ответ не становится пригодным из-за вложения.
Что подтверждено
В механизме RFC 6066 клиент может запросить сведения о статусе расширением status_request. Для TLS 1.2 и более ранних версий согласованный ответ передаётся отдельным сообщением CertificateStatus сразу после сообщения Certificate.
Граница применимости: RFC 6066, раздел 8; форма доставки для TLS до версии 1.3. Возможность запроса клиентом не означает обязательность проверки отзыва всеми приложениями.
В TLS 1.3 сервер передаёт ответ OCSP в расширении записи CertificateEntry, содержащей соответствующий сертификат. Отдельное сообщение CertificateStatus из прежней формы доставки для этого не используется.
Граница применимости: RFC 8446, 4.4.2.1: доставка согласованного ответа OCSP в TLS 1.3.
Вложение позволяет получить пригодный ответ о статусе при рукопожатии и тем самым обойтись без отдельного обращения клиента к службе OCSP. Этот способ доставки не запрещает клиенту самостоятельные обращения.
Граница применимости: Назначение расширения в RFC 6066, раздел 8; выгода относится к получению используемого ответа, а не к универсальному запрету сетевых запросов.
Полученный через TLS ответ всё равно связывают с нужным сертификатом, проверяют его подпись, полномочия ответчика и временную применимость. Доставка внутри рукопожатия не превращает старый или чужой ответ good в доказательство допустимости сертификата.
Граница применимости: Доставка по RFC 6066 и проверка OCSP по RFC 6960; решение приложения при отсутствии пригодного статуса определяется отдельно.
RFC 6960 описывает сообщения и проверку OCSP, а RFC 6066 и RFC 8446 — перенос сведений о статусе в соответствующих версиях TLS. Ссылки только на протокол OCSP недостаточно для объяснения места ответа в рукопожатии.
Граница применимости: Сопоставление роли RFC 6960 и механизмов доставки RFC 6066, раздел 8, и RFC 8446, 4.4.2.1. Обязательное вложение по дополнительному расширению здесь не рассматривается.
Не путать
Вложение доставляет сведения о статусе, а проверка пути применяет подписи, сроки и ограничения. Даже пригодный ответ OCSP не подменяет проверку пути.
Что проверить
- Укажите версию TLS.
- Проверьте согласование передачи статуса.
- Найдите ответ в сообщении или записи, предусмотренной этой версией.
- Сопоставьте ответ с нужным сертификатом.
- Проверьте подпись, подписанта и свежесть.
- Зафиксируйте политику при отсутствии пригодного ответа.
- Не приписывайте протоколу OCSP правила переноса в TLS.
Первоисточники
Transport Layer Security (TLS) Extensions: Extension Definitions
Internet Engineering Task Force · RFC 6066, January 2011
Раздел 8: согласование status_request и доставка ответа OCSP в CertificateStatus для TLS до версии 1.3; прочитан редактором и передан в выписке.
Открыть первоисточникRFC 8446: The Transport Layer Security Protocol Version 1.3
Internet Engineering Task Force · RFC 8446, August 2018
Определяет TLS 1.3, включая encrypted channel, PSK authentication, PSK identity и PSK+(EC)DHE modes.
Открыть первоисточникX.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP
Internet Engineering Task Force · RFC 6960, June 2013
Определяет signed per-certificate status responses good, revoked и unknown и их validity interval.
Открыть первоисточникInternet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile
Internet Engineering Task Force · RFC 5280, May 2008
Определяет Internet X.509 certificate и CRL profiles, PKI entities, extensions и certification path validation.
Открыть первоисточник