RFC 6960¶

RFC 6960 — это запрос комментариев (Request for Comments) под номером 6960, опубликованный в июне 2013 года и устанавливающий протокол OCSP (Online Certificate Status Protocol). Протокол предназначен для оперативной проверки статуса цифрового сертификата X.509, в частности его отзыва (аннулирования) удостоверяющим центром (УЦ). RFC 6960 является стандартом Интернета (Internet Standard STD 83), заменившим более раннюю версию протокола, описанную в RFC 2560.

¶История и предпосылки создания

До появления OCSP основным механизмом проверки статуса сертификата были списки отзыва сертификатов (CRL — Certificate Revocation List). CRL представляет собой периодически публикуемый УЦ файл, содержащий серийные номера отозванных сертификатов. Этот подход имел ряд недостатков:

• Размер списка: CRL могли быть очень большими, особенно для крупных УЦ, что создавало нагрузку на сеть и клиентские устройства.
• Задержка актуальности: CRL публикуются с определённой периодичностью (например, раз в сутки). Между моментом отзыва сертификата и публикацией нового CRL существовало «окно уязвимости».
• Отсутствие оперативности: Клиент не мог получить информацию о статусе конкретного сертификата в реальном времени без загрузки всего списка.

Протокол OCSP, впервые стандартизированный в RFC 2560 (1999 год), был разработан для решения этих проблем. Он позволял клиенту отправлять запрос о статусе конкретного сертификата и получать мгновенный ответ от специализированного сервера (OCSP-респондера). RFC 6960, опубликованный в 2013 году, стал результатом накопленного опыта эксплуатации OCSP и внёс ряд уточнений и расширений в протокол, сохранив обратную совместимость.

¶Основные положения протокола

Протокол OCSP, определённый в RFC 6960, работает по модели «запрос-ответ» (request-response) на основе протокола HTTP. Он использует кодировку ASN.1 (Abstract Syntax Notation One) и формат DER (Distinguished Encoding Rules) для представления данных.

¶Запрос (OCSPRequest)

Запрос к OCSP-респондеру содержит следующие основные элементы:

• tbsRequest (To-Be-Signed Request): Основная часть запроса, которая может быть подписана. Включает:
• версия (version): Версия протокола (по умолчанию 0).
• идентификатор запроса (requestorName): Необязательное поле, идентифицирующее запрашивающую сторону (например, через сертификат).
• список запросов (requestList): Список из одного или нескольких объектов Request, каждый из которых содержит:
• certID (CertID): Идентификатор проверяемого сертификата. Включает хеш-функцию (например, SHA-1 или SHA-256), хеш от имени издателя сертификата, хеш от открытого ключа издателя и серийный номер проверяемого сертификата.
• расширения (requestExtensions): Необязательные расширения, такие как указание на желаемый тип ответа (например, с подписью или без) или запрос на включение дополнительной информации.

¶Ответ (OCSPResponse)

Ответ OCSP-респондера содержит:

• статус ответа (responseStatus): Указывает на успешность обработки запроса. Возможные значения:
• successful (0) — запрос обработан успешно.
• malformedRequest (1) — запрос имеет неверный формат.
• internalError (2) — внутренняя ошибка респондера.
• tryLater (3) — респондер временно недоступен.
• sigRequired (4) — запрос должен быть подписан (если респондер требует аутентификации).
• unauthorized (5) — запрос не авторизован.
• основной ответ (responseBytes): Содержит тип ответа (например, id-pkix-ocsp-basic) и сами данные. Основные данные включают:
• tbsResponseData (To-Be-Signed Response Data): Часть ответа, которая подписывается. Содержит:
• версия (version): Версия ответа.
• идентификатор респондера (responderID): Идентификатор OCSP-респондера (по имени или по хешу от ключа).
• время создания (producedAt): Время формирования ответа.
• список ответов (responses): Список объектов SingleResponse, каждый из которых соответствует одному запросу. Каждый SingleResponse включает:
• certID: Идентификатор сертификата.
• статус сертификата (certStatus): Может быть good (действителен), revoked (отозван) или unknown (статус неизвестен). В случае отзыва указывается время отзыва и, опционально, причина.
• thisUpdate: Время, к которому относится данный статус.
• nextUpdate: Необязательное время, до которого ответ считается актуальным.
• расширения (singleExtensions): Необязательные расширения.
• подпись (signatureAlgorithm): Алгоритм подписи ответа.
• значение подписи (signature): Цифровая подпись, удостоверяющая подлинность ответа.
• сертификаты (certs): Необязательный список сертификатов, необходимых для проверки подписи респондера (обычно это сертификат самого респондера и сертификаты УЦ).

¶Расширения, введённые в RFC 6960

RFC 6960 внёс несколько важных расширений по сравнению с RFC 2560:

• Поддержка SHA-256 и других хешей: RFC 2560 по умолчанию использовал SHA-1, который к 2013 году считался устаревшим. RFC 6960 явно разрешил использование более сильных хеш-функций, таких как SHA-256, в CertID.
• Расширение «OCSP Nonce»: Позволяет клиенту включить в запрос уникальное случайное число (nonce), которое респондер должен включить в ответ. Это защищает от атак повторного воспроизведения (replay attacks).
• Расширение «Preferred Signature Algorithms»: Позволяет клиенту указать, какие алгоритмы подписи он предпочитает для ответа.
• Расширение «Acceptable Response Types»: Позволяет клиенту указать, какие типы ответов (например, подписанные или неподписанные) он готов принять.

¶Применение и архитектура

OCSP широко используется в инфраструктуре открытых ключей (PKI) для проверки статуса сертификатов в реальном времени. Основные сценарии применения:

• Веб-браузеры: При установке HTTPS-соединения браузер может отправить OCSP-запрос для проверки сертификата сервера. Это позволяет быстро выявить отозванные сертификаты, например, в случае компрометации закрытого ключа.
• Электронная подпись (ЭП): При проверке подлинности электронной подписи OCSP используется для подтверждения того, что сертификат подписанта не был отозван на момент подписания.
• Корпоративные системы: Внутренние PKI-системы организаций используют OCSP для управления сертификатами сотрудников и устройств.

Архитектура OCSP включает три основные роли:

1. Клиент (OCSP Client): Устройство или приложение, которое запрашивает статус сертификата (например, веб-браузер или почтовый клиент).
2. Респондер (OCSP Responder): Сервер, который отвечает на OCSP-запросы. Респондер может быть как частью УЦ, так и независимым сервером, которому УЦ делегировал полномочия по выдаче ответов.
3. Удостоверяющий центр (CA): Организация, которая выпускает и отзывает сертификаты. УЦ предоставляет респондеру информацию о статусе сертификатов.

¶OCSP Stapling

Одним из ключевых улучшений, связанных с OCSP, является техника OCSP Stapling (стандартизирована в RFC 6066). Она решает проблему нагрузки на OCSP-респондеры и повышает конфиденциальность. Вместо того чтобы клиент отправлял запрос респондеру, сервер (например, веб-сервер) периодически сам запрашивает у респондера подписанный OCSP-ответ для своего сертификата и «прикрепляет» (staples) его к своему сертификату во время TLS-рукопожатия. Клиент, получив такой ответ, может проверить статус сертификата без обращения к респондеру. Это снижает задержки и нагрузку на инфраструктуру.

¶Критика и ограничения

Несмотря на преимущества, OCSP имеет ряд недостатков:

• Нагрузка на респондеры: Каждый клиент, проверяющий сертификат, отправляет запрос респондеру. Для крупных УЦ, обслуживающих миллионы сертификатов, это создаёт значительную нагрузку.
• Проблемы конфиденциальности: OCSP-запросы содержат информацию о том, какие сертификаты проверяет клиент, что позволяет респондеру отслеживать активность пользователей. OCSP Stapling частично решает эту проблему, но не полностью.
• Зависимость от доступности: Если OCSP-респондер недоступен, клиент может либо заблокировать соединение (строгая проверка), либо разрешить его (мягкая проверка), что снижает безопасность. RFC 6960 предусматривает механизм «мягкого отказа» (soft-fail), но это может быть использовано злоумышленниками.
• Сложность реализации: Реализация OCSP требует поддержки ASN.1, DER и криптографических операций, что усложняет разработку клиентского и серверного ПО.

¶Влияние на отрасль

RFC 6960 является одним из наиболее цитируемых стандартов в области PKI. Он заменил устаревший RFC 2560 и стал основой для современных систем проверки сертификатов. Протокол OCSP, определённый в этом RFC, используется в большинстве современных веб-браузеров, почтовых клиентов и других приложений, работающих с цифровыми сертификатами. Несмотря на появление альтернативных подходов, таких как CRLite и Certificate Transparency, OCSP остаётся ключевым механизмом оперативной проверки статуса сертификатов.

¶Источники

1. RFC 6960 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP (IETF, 2013).
2. RFC 2560 — X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP (IETF, 1999).
3. RFC 6066 — Transport Layer Security (TLS) Extensions: Extension Definitions (IETF, 2011).
4. Стандарт X.509 — ITU-T Recommendation X.509 (2019).
5. «Understanding OCSP» — автор: Peter Gutmann (статья в журнале «IEEE Security & Privacy», 2004).