"Р 1323565.1.059-2024. Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе получения актуальных статусов сертификатов (OCSP)"
(утв. и введены в действие Приказом Росстандарта от 10.10.2024 N 1427-ст)

1 РАЗРАБОТАНЫ Обществом с ограниченной ответственностью "КРИПТО-ПРО" (ООО "КРИПТО-ПРО")

2 ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 26 "Криптографическая защита информации"

3 УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 10 октября 2024 г. N 1427-ст

4 ВВЕДЕНЫ ВПЕРВЫЕ

В настоящих рекомендациях представлен протокол получения актуального статуса сертификата (протокол OCSP).

Протокол получения актуальных статусов сертификатов используется различными службами, информационными системами, приложениями и другими участниками какого-либо информационного взаимодействия для получения статуса сертификата вместо или в дополнение к проверке по списку отозванных сертификатов (CRL), указанному в Р 1323565.1.023. Данный протокол позволяет получать информацию об изменении статуса сертификата раньше, чем при использовании CRL.

Информация о статусе сертификата, полученная с использованием протокола OCSP, может быть включена в электронные подписи в качестве данных для проверки, если того требует используемый формат подписи.

Настоящие рекомендации подготовлены на основе стандарта Интернета "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", IETF RFC 6960, 2013 и устанавливают требования к использованию описанного протокола в соответствии с законодательством Российской Федерации и нормативными документами по стандартизации.

Настоящие рекомендации устанавливают требования к использованию протокола OCSP, предназначенного для получения актуального статуса сертификата вместо или в дополнение к проверке по списку отозванных сертификатов (CRL).

Дополнительно настоящие рекомендации устанавливают требования к содержимому сообщений, передаваемых с использованием протокола OCSP при использовании российских криптографических алгоритмов подписи и хэширования.

В настоящих рекомендациях использованы нормативные ссылки на следующие стандарты:

ГОСТ Р ИСО/МЭК 8824-93 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии один (АСН.1)

ГОСТ Р 34.10 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи

ГОСТ Р 34.11 Информационная технология. Криптографическая защита информации. Функция хэширования

Р 1323565.1.020-2020 Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)

Р 1323565.1.023-2022 Информационная технология. Криптографическая защита информации. Использование алгоритмов ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012 в сертификате, списке аннулированных сертификатов (CRL) и запросе на сертификат PKCS #10 инфраструктуры открытых ключей X.509

Р 1323565.1.025-2019 Информационная технология. Криптографическая защита информации. Форматы сообщений, защищенных криптографическими методами

Р 1323565.1.030-2020 Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.3)

Примечание - При пользовании настоящими рекомендациями целесообразно проверить действие ссылочных документов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный документ, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого документа с учетом всех внесенных в данную версию изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то рекомендуется использовать версию этого документа с указанным выше годом утверждения (принятия). Если после утверждения настоящих рекомендаций в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

В настоящих рекомендациях применены следующие термины с соответствующими определениями.

3.1.1

3.1.2

3.1.3

3.1.4

3.1.5 удостоверяющий центр; УЦ: Центр доверия, которому один или несколько участников взаимодействия доверили создание сертификатов.

Примечание - См. также [1], статья 3.58.

3.1.6 список отозванных сертификатов; CRL: Подписанный электронный документ, содержащий сведения о сертификатах открытых ключей, которые выдавший их удостоверяющий центр более не признает действительными.

3.1.7 точка распределения списка отозванных сертификатов; CDP: Источник данных, служащий для распространения списков отозванных сертификатов.

3.1.8 служба получения актуального статуса сертификата; служба OCSP: Центр доверия, предоставляющий сведения об актуальных статусах сертификатов.

3.1.9

3.1.10

Примечание - В настоящих рекомендациях в целях сохранения терминологической преемственности с действующими отечественными нормативными документами и опубликованными научно-техническими изданиями установлено, что термины "хэш-функция", "хеш-функция", "криптографическая хэш-функция", "криптографическая хеш-функция", "функция хэширования", "функция хеширования", "криптографическая функция хэширования" и "криптографическая функция хеширования" являются синонимами.

3.1.11

В настоящих рекомендациях применены следующие сокращения:

AIA - расширение сертификата, используемое для указания дополнительных способов проверки статуса сертификата (Authority Information Access);

CDP - точка распределения списков отозванных сертификатов (Certificate (Revocation List) Distribution Point);

CRL - список отозванных сертификатов (Certificate Revocation List);

DER - отличительные правила кодирования (Distinguished Encoding Rules);

FTP - протокол передачи файлов (File Transfer Protocol);

HTTP - протокол передачи гипертекста (HyperText Transfer Protocol);

MIME - многоцелевое расширение возможностей почты в сети Интернет (Multipurpose Internet Mail Extensions);

OCSP - протокол получения актуального статуса сертификата (Online Certificate Status Protocol);

URI - универсальный идентификатор ресурсов (Uniform Resource Identifier);

URL - универсальный указатель ресурсов (Uniform Resource Locator);

УЦ - удостоверяющий центр.

Протокол OCSP предназначен для получения статуса сертификата вместо или в дополнение к проверке по списку отозванных сертификатов (CRL). Для этого в рамках данного протокола осуществляется взаимодействие службы получения актуального статуса сертификата (службы OCSP) и запрашивающей стороны (C). Взаимодействие перечисленных участников заключается в формировании запроса к службе OCSP и проверке ее ответа (см. рисунок 1).

В первом сообщении обмена в рамках протокола OCSP запрашивающая сторона посылает в службу OCSP запрос актуального статуса сертификата (сертификатов), который содержит OCSPRequest, как это описано в 7.2. Во втором сообщении служба OCSP отправляет запрашивающей стороне ответ OCSPResponse (см. 7.3), который содержит информацию о статусе сертификата (сертификатов) или сведения об ошибке.

Порядок формирования запроса описан в 5.1. Порядок формирования ответа службой OCSP описан в 5.2. Порядок обработки данного ответа запрашивающей стороной описан в 5.3.

Примечание - Ответы службы OCSP могут быть использованы повторно при проверке действительности сертификата. Например, если сертификат проверяется на момент подписи некоторого документа (при наличии достоверной информации о моменте подписания электронного документа).

Ответы службы OCSP подписаны закрытым ключом данной службы. Соответствующий открытый ключ содержится в сертификате службы OCSP. Требования к указанному сертификату и особенности его отзыва описаны в разделе 6.

Форматы запроса и ответа описаны в разделе 7.

Требования к содержимому запроса к службе OCSP и ее ответа при использовании российских криптографических алгоритмов подписи и хэширования описаны в разделе 8.

Способы передачи запроса к службе OCSP и получения ответа описаны в разделе 9.

Идентификатор сертификата (или сертификатов, если их несколько), для которого требуется получить актуальный статус, помещается в запрос к службе OCSP. Для последующей проверки актуальности ответа службы в запрос может быть помещен одноразовый код, представляющий собой большое случайное число (см. 7.4.2). Дополнительно запрос к службе OCSP может быть подписан. Сформированный запрос отправляется в службу OCSP.

Удостоверяющий центр, предоставляющий возможность проверки статуса выпущенных им сертификатов по протоколу OCSP, должен включать в данные сертификаты расширение AuthorityInfoAccess (см. [2], подпункт 4.2.2.1). При этом в поле accessLocation должно быть включено значение uniformResourceIndicator (URI, см. [3]), определяющее способ обращения к службе OCSP и дополнительную информацию (например, URL со схемой HTTP).

В поле accessMethod расширения AuthorityInfoAccess должен быть включен следующий объектный идентификатор:

id-ad-ocsp, "1.3.6.1.5.5.7.48.1".

Дополнительно URI для обращения к службе OCSP может быть задан в настройках запрашивающей стороны.

Служба OCSP формирует ответ, содержащий актуальный статус запрашиваемого сертификата (сертификатов) только при условии, что полученный запрос корректен (см. 7.2) и соответствует политике безопасности (регламенту) службы.

В случае успешной обработки запроса службой OCSP в ответе содержится следующее:

- время формирования ответа службой OCSP;

- сведения о службе OCSP, сформировавшей данный ответ;

- идентификатор используемого алгоритма подписи;

- подпись данных ответа;

- необязательная дополнительная информация, передаваемая в виде набора расширений (см. 7.4). При этом если в запросе для проверки актуальности ответа был указан одноразовый код, он должен также присутствовать в ответе в соответствующем расширении (см. 7.4.2), если только служба OCSP не использует заранее сформированные ответы;

- статус для каждого из сертификатов в запросе.

Для каждого из сертификатов, который был указан в запросе к службе OCSP, в ответе содержится следующее:

- идентификатор данного сертификата;

- статус сертификата и причина отзыва, если данный сертификат был отозван (см. 5.2.2);

- время, в течение которого статус сертификата можно считать актуальным (см. 5.2.3);

- необязательная дополнительная информация о данном сертификате, результатах его проверки, источниках информации и т.п., передаваемая в виде набора расширений (см. 7.4).

В случае возникновения во время обработки запроса каких-либо ошибок ответ службы OCSP должен содержать только информацию о возникшей ошибке (см. 7.3.2).

В ответе службы OCSP для каждого из указанных в запросе сертификатов могут содержаться следующие статусы:

- good (положительный ответ). Положительный ответ означает, что службе OCSP неизвестно о факте отзыва или приостановки данного сертификата в пределах его срока действия. В то же время данный статус не означает, что сертификат выдавался или что время, когда служба OCSP сформировала ответ, находится между датами начала и окончания срока действия сертификата. Расширения, присутствующие в ответе рядом с данным статусом, могут использоваться для передачи запрашивающей стороне дополнительной информации о сертификате - сведения о его выдаче, сроке действия и т.д. Некоторые возможные расширения и их идентификаторы приведены в 7.4;

- revoked (отозван). Данный статус означает, что сертификат был отозван или приостановлен. Данный статус также может означать, что удостоверяющий центр не выдавал сертификат, который указан в запросе. Подробная информация о случаях, в которых ответ службы OCSP содержит данный статус сертификата, приведена в 7.3.3.5;

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

Примечания

1 Выбор службой OCSP статуса "отозван" или "неизвестен" для случая, когда служба не имеет сведений о сертификате, определяется регламентом данной службы. Если в ответе указан статус "неизвестен", запрашивающей стороне предоставляется возможность самостоятельно определить статус сертификата при помощи другого источника информации (например, при помощи CRL).

2 Если службе OCSP известно, что закрытый ключ определенного удостоверяющего центра был скомпрометирован, она может возвращать статус "отозван" для всех сертификатов, выпущенных данным УЦ.

Ответ службы OCSP может содержать следующие значения времени:

- producedAt: время, когда служба OCSP сформировала данный ответ (см. 7.3.3.2);

- thisUpdate: момент времени, на который было известно, что указанный статус сертификата является актуальным (см. 7.3.3.4). Данное значение указывается для каждого сертификата в ответе службы OCSP;

- nextUpdate: время, не позднее которого будет доступна более новая информация о статусе сертификата (см. 7.3.3.4);

- revocationTime: время, когда сертификат был отозван или приостановлен (см. 7.3.3.5).

Поля thisUpdate и nextUpdate определяют рекомендуемый интервал действительности ответа службы OCSP. Данный интервал должен интерпретироваться аналогично интервалу от thisUpdate до nextUpdate в списках отозванных сертификатов, как это описано в [2]. Отсутствие поля nextUpdate означает, что новая информация о статусе сертификата может быть доступна в любой момент времени.

Служба OCSP может заранее формировать подписанные ответы, информирующие о статусе сертификата (или сертификатов, если их несколько). Время, когда было известно, что состояние является корректным, вносится в поле ответа thisUpdate. Время, не позже которого будет доступна новая информация, вносится в поле nextUpdate, а время, когда был сформирован ответ, вносится в поле producedAt.

При получении ответа запрашивающая сторона должна проверить ответ на ошибки о состоянии и, если их нет, проверить различные поля в полученном ответе в соответствии с 7.3.3 настоящих рекомендаций. В частности, запрашивающая сторона должна убедиться в следующем:

- в ответе содержится информация о статусе именно того сертификата, который необходимо проверить;

- подпись в ответе действительна;

- ответ подписан именно той службой OCSP, к которой направлялся запрос. Данная проверка выполняется только при условии, что ее возможно осуществить;

- данная служба OCSP уполномочена предоставлять информацию о статусе проверяемого сертификата (см. 6.1);

- время, прошедшее с момента, когда был точно известен статус сертификата (поле thisUpdate, см. 5.2.3), не превышает допустимого времени, установленного регламентом запрашивающей стороны;

- время, когда был точно известен статус сертификата (поле thisUpdate, см. 5.2.3), не превышает локального системного времени запрашивающей стороны;

- если указано время, не позже которого информация о статусе сертификата обновится (поле nextUpdate, см. 5.2.3), следует убедиться, что оно еще не наступило. Данная проверка не должна выполняться в случаях, когда OCSP-ответ, полученный и использовавшийся ранее, используется повторно, как это описано в разделе 4;

- если в запросе к службе OCSP был передан одноразовый код, следует убедиться, что его значение совпадает с одноразовым кодом в ответе, кроме случаев, когда служба OCSP использует заранее сформированные ответы и данные ответы могут быть приняты запрашивающей стороной в соответствии с ее регламентом.

Если любая из вышеперечисленных проверок завершилась неудачей, ответ службы OCSP следует отклонить.

Примечание - Настоящие рекомендации не устанавливают строгую последовательность проверок полученного от службы OCSP ответа. Данные проверки могут выполняться в произвольном порядке.

Ключ, которым подписывается ответ службы OCSP, может совпадать с ключом, которым подписан проверяемый сертификат. Если для подписи был использован другой ключ, запрашивающей стороне необходимо убедиться в том, что служба OCSP, подписавшая ответ, обладает соответствующими полномочиями. Указание полномочий на подпись службой OCSP ответов может быть установлено регламентом запрашивающей стороны либо произведено путем выдачи сертификата специального вида службе OCSP.

В случае указания полномочий путем выдачи сертификата в расширение extendedKeyUsage данного сертификата должен быть включен следующий идентификатор, как это описано в [2], подпункт 4.2.1.12:

id-kp-OCSPSigning, "1.3.6.1.5.5.7.3.9".

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

Системы или приложения, проверяющие OCSP-ответы, должны иметь возможность проверить полномочия службы OCSP по значению id-kp-OCSPSigning, как это описано выше. Они также могут предусматривать способы указания одной или нескольких служб OCSP и перечень УЦ, для которых каждая из служб OCSP является уполномоченной в соответствии с регламентом.

Службы или приложения принимают OCSP-ответ, если для сертификата, используемого при подписи данного ответа, выполняется по крайней мере одно из следующих условий:

- сертификат содержит значение id-kp-OCSPSigning в расширении ExtendedKeyUsage и подписан тем же ключом УЦ, который выдал проверяемый сертификат.

Примечание - В целях обеспечения возможности долговременного (архивного) хранения подписанных документов допускается применять сертификат службы OCSP, подписанный ключом УЦ, отличным от ключа, использованного данным УЦ при подписи проверяемого сертификата. Данный сертификат службы OCSP может применяться при невозможности выпуска сертификата службы OCSP на том же ключе УЦ в связи с окончанием срока действия этого ключа;

- полномочия службы OCSP (сертификат для подписи OCSP-ответа) на выдачу ответов о статусе сертификатов данного УЦ указаны в настройках системы или приложения;

- сертификат является сертификатом того УЦ, который выдал проверяемый сертификат.

Регламентом службы OCSP могут быть определены дополнительные проверки, применяемые непосредственно к ответу данной службы или к сертификату, используемому для проверки подписи в ответе.

Запрашивающая сторона должна уметь проверять, был ли сертификат службы OCSP отозван или нет. УЦ могут решать этот вопрос одним из следующих способов:

- УЦ может указать, что запрашивающая сторона может не проверять статус сертификата службы OCSP. Для этого в сертификат службы OCSP должно быть включено расширение id-pkix-ocsp-nocheck. Расширение не должно быть критичным. Расширение должно содержать значение NULL, заданное в соответствии с пунктом 8.7 ГОСТ Р ИСО/МЭК 8824-93. Негативные последствия от компрометации ключа службы OCSP в данном случае аналогичны компрометации ключа, используемого УЦ для подписи списка отозванных сертификатов. УЦ может выдавать сертификаты с данным расширением с коротким сроком действия и часто обновлять их. Для указания расширения должен быть использован следующий идентификатор:

id-pkix-ocsp-nocheck, "1.3.6.1.5.5.7.48.1.5".

Примечание - Критичность расширения сертификата определяется наличием флага critical (см. [2], подраздел 4.1), указывающего на важность содержащейся в расширении информации. Если запрашивающая сторона не распознает расширение, помеченное как критичное, ей следует отклонить объект, содержащий данное расширение;

- УЦ может указать, как необходимо проверять статус сертификата службы OCSP. Это можно сделать, указав точку распределения списков отозванных сертификатов (CDP), описанную в [4]. В данном случае проверка должна выполняться по спискам отозванных сертификатов (CRL). Для указания других способов проверки статуса сертификата службы OCSP допускается использовать расширение AIA, как это описано в [2], пункт 5.2.7;

- УЦ может не указывать способы проверки статуса сертификата службы OCSP, в этом случае решение о необходимости проверки статуса сертификата и о способе выполнения проверки принимается на основе регламента (политики безопасности) запрашивающей стороны.

В данном разделе приведено описание формата запроса к службе OCSP и формата ее ответа в соответствии с абстрактно-синтаксической нотацией версии 1 (АСН.1), определенной в ГОСТ Р ИСО/МЭК 8824. Формат запроса к службе OCSP описан в 7.2. Формат ответа службы OCSP описан в 7.3. Описание формата запроса к службе OCSP и ее ответа в виде модуля АСН.1 приведено в приложении A. Примеры запроса и ответа приведены в приложении B.

Запрос к службе OCSP представляет собой структуру OCSPRequest и выглядит следующим образом.

Поле tbsRequest несет в себе содержательную часть запроса к службе OCSP и представляет собой структуру типа TBSRequest, описанную в 7.2.2. Запрос может быть подписан, в этом случае в нем присутствует поле optionalSignature.

Поле optionalSignature содержит идентификатор алгоритма подписи, используемого для подписи запроса к службе OCSP, значение подписи и представляет собой структуру типа Signature, описанную в 7.2.3. Дополнительно данное поле может содержать сертификаты, необходимые службе OCSP для проверки подписанного запроса.

Структура TBSRequest представляет собой содержательную часть запроса к службе OCSP и выглядит следующим образом.

Поля структуры TBSRequest должны быть заполнены в соответствии со следующим описанием.

7.2.2.1 Структура Request

Структура Request содержит сведения о сертификате, актуальный статус которого необходимо получить, а также дополнительные расширения. Данная структура выглядит следующим образом.

Поля структуры Request должны быть заполнены в соответствии со следующим описанием.

7.2.2.2 Структура CertID

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

Поля структуры CertID должны быть заполнены в соответствии со следующим описанием.

Структура Signature содержит идентификатор алгоритма подписи, используемого для подписи запроса к службе OCSP и значение подписи. Дополнительно данное поле может содержать сертификат (сертификаты), необходимые службе OCSP для проверки подписанного запроса.

Структура Signature выглядит следующим образом.

Поля структуры Signature должны быть заполнены в соответствии со следующим описанием.

Ответ службы OCSP представляет собой структуру OCSPResponse и выглядит следующим образом.

Поле responseStatus определяет статус ответа службы OCSP и имеет тип OCSPResponseStatus, описанный в 7.3.2.

Поле responseBytes содержит идентификатор типа ответа службы OCSP и сам ответ. Указанные данные помещаются в структуру ResponseBytes, описанную в 7.3.3. Поле responseBytes должно присутствовать в ответе службы OCSP только в случае, когда значение поля responseStatus равно 0, что означает успешный статус ответа (см. 7.3.2).

Тип OCSPResponseStatus представляет собой числовое значение, определяющее статус ответа службы OCSP. Если значение равно 0, в ответе службы OCSP присутствует поле responseBytes (см. 7.3.3). В остальных случаях поле responseBytes отсутствует, а значение OCSPResponseStatus содержит тип возникшей ошибки. В случае ошибки ответ службы OCSP не содержит подписи данной службы.

Выделяют следующие статусы ответа службы OCSP.

Примечание - Статус ответа службы OCSP предназначен для указания успеха или ошибки обработки запроса службой и не имеет отношения к статусу сертификата (см. 7.3.3.5), включаемому службой в содержательную часть ответа.

Структура ResponseBytes представляет собой содержательную часть ответа службы OCSP и выглядит следующим образом.

Поля структуры ResponseBytes должны быть заполнены в соответствии со следующим описанием.

7.3.3.1 Структура BasicOCSPResponse

Структура BasicOCSPResponse содержит ответ службы OCSP базового типа и выглядит следующим образом.

Поля структуры BasicOCSPResponse должны быть заполнены в соответствии со следующим описанием.

Содержимое структуры BasicOCSPResponse должно быть представлено в виде OCTET STRING и закодировано в DER.

7.3.3.2 Структура ResponseData

Структура ResponseData содержит данные ответа службы OCSP и выглядит следующим образом.

Поля структуры ResponseData должны быть заполнены в соответствии со следующим описанием.

7.3.3.3 Структура ResponderID

Структура ResponderID содержит сведения о службе OCSP, создавшей ответ, и выглядит следующим образом.

Поля структуры ResponderID должны быть заполнены в соответствии со следующим описанием.

7.3.3.4 Структура SingleResponse

Структура SingleResponse содержит информацию об актуальном статусе сертификата, рекомендуемый интервал действительности ответа службы OCSP и другие сведения о сертификате. Структура SingleResponse должна выглядеть следующим образом.

Поля структуры SingleResponse должны быть заполнены в соответствии со следующим описанием.

7.3.3.5 Тип CertStatus

Тип CertStatus содержит актуальный статус сертификата. Если статус сертификата отличен от good (действителен), в поле включается дополнительная информация о статусе данного сертификата.

Служба OCSP должна поддерживать только следующие возможные статусы:

В данном разделе настоящих рекомендаций определен ряд расширений на основе модели расширения, определенной в [2], раздел 4. Расширения запросов к службе OCSP и ее ответов имеют тип Extensions, описанный в [2], подраздел 4.1.

В общем виде использование расширений в протоколе OCSP выглядит следующим образом. Запрашивающая сторона может поместить одно или несколько расширений в запрос к службе OCSP (см. 5.1) в соответствии с порядком включения в запрос расширений, описанным в данном разделе. Служба OCSP обрабатывает запрос и включенные в него расширения, после чего формирует ответ (см. 5.2), который также может содержать расширения, обрабатываемые при проверке ответа (см. 5.3).

В запросе к службе OCSP допустимы следующие виды расширений:

- расширение для всего запроса, включаемое в поле requestExtensions структуры TBSRequest (см. 7.2.2);

- расширение для отдельного запроса статуса сертификата, включаемое в поле singleRequestExtensions структуры Request (см. 7.2.2.1).

В ответе службы OCSP допустимы следующие виды расширений:

- расширение для всего ответа, включаемое в поле responseExtensions структуры ResponseData (см. 7.3.3.2);

- расширение для одного ответа о статусе сертификата, включаемое в поле singleExtensions структуры SingleResponse (см. 7.3.3.4).

Поддержка всех расширений, описанных в настоящих рекомендациях, не является обязательной как при получении запроса службой OCSP, так и при проверке ее ответа. Поэтому приведенные в данном разделе расширения не должны быть критичными (см. [2], подраздел 4.1). Настоящие рекомендации также допускают использование расширений, определенных в иных нормативных документах.

В таблице 1 приведен список расширений запроса к службе OCSP и ее ответа с указанием поля, куда может включаться каждое из расширений. В случае когда расширение может быть включено в некоторое поле запроса и/или ответа, на пересечении строки с именем расширения и графы с именем поля находится знак "+", в остальных случаях - знак "-".

Расширение, содержащее одноразовый код, связывает запрос к службе OCSP и ее ответ для предотвращения атак повторного воспроизведения. Для этого данное расширение включается как в запрос, так и в ответ службы OCSP для всего запроса (поле requestExtensions структуры TBSRequest, см. 7.2.2) и для всего ответа (поле responseExtensions структуры ResponseData, см. 7.3.3.2) соответственно. Данное расширение имеет следующий объектный идентификатор:

id-pkix-ocsp-nonce, "1.3.6.1.5.5.7.48.1.2".

Значение расширения должно быть выбрано запрашивающей стороной случайно равновероятно, иметь длину не менее 64 бит и выглядеть следующим образом.

Nonce ::= OCTET STRING

Служба OCSP может указать список отозванных сертификатов (CRL), в котором найден отозванный или приостановленный сертификат. Для этого используется расширение, позволяющее включить ссылку на CRL в ответ службы OCSP о статусе каждого из сертификатов (поле singleExtensions структуры SingleResponse, см. 7.3.3.4). Ссылка на CRL может быть представлена одним из следующих способов:

- URL, указывающий расположение CRL;

- номер CRL;

- время создания CRL.

Ссылки на CRL могут применяться в случаях, когда служба OCSP использует различные источники информации о статусе сертификатов, а также когда необходимо сохранить сведения о данных источниках в целях аудита. Данное расширение имеет следующий объектный идентификатор:

id-pkix-ocsp-crl, "1.3.6.1.5.5.7.48.1.3".

Значение расширения должно выглядеть следующим образом.

Поля структуры CrlID должны быть заполнены в соответствии со следующим описанием.

Настоящие рекомендации устанавливают формат базового типа ответа службы OCSP id-pkix-ocsp-basic, описанный в 7.3.3. Дополнительно запрашивающая сторона может указать в запросе к службе OCSP типы ответов, которые она поддерживает. Для этого следует в поле requestExtensions запроса к службе OCSP (см. 7.2.2) поместить расширение со следующим объектным идентификатором:

id-pkix-ocsp-response, "1.3.6.1.5.5.7.48.1.4".

Значение расширения представляет собой структуру AcceptableResponses, содержит идентификаторы типов ответов, которые запрашивающая сторона может обработать, и должно выглядеть следующим образом.

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

Служба OCSP может хранить информацию о статусе сертификата после истечения срока его действия. Время, полученное путем вычитания интервала хранения информации о статусе сертификата из времени формирования ответа службой OCSP (поле producedAt, см. 7.3.3.2), называется временем "архивного среза" статуса сертификата. Например, интервал хранения информации о выданных ответах некоторой службы OCSP составляет 7 лет. В момент времени T данная служба OCSP сформировала ответ об актуальном статусе некоторого сертификата. В расширении архивного среза для данного сертификата в данном ответе будет указано значение времени, соответствующее T за вычетом 7 лет.

Архивный срез позволяет получить дополнительную информацию о статусе сертификата для проверки действительности подписи в момент ее создания, даже если сертификат в настоящее время уже недействителен.

Расширение архивного среза должно включаться в расширения одного ответа о статусе сертификата (поле singleExtensions структуры singleResponse, см. 7.3.3.4). Данное расширение имеет следующий объектный идентификатор:

id-pkix-ocsp-archive-cutoff, "1.3.6.1.5.5.7.48.1.6".

Значение расширения должно выглядеть следующим образом.

ArchiveCutoff ::= GeneralizedTime

Настоящие рекомендации допускают использование в ответе службы OCSP расширений записей в CRL, описанных в [2], подраздел 5.3. Данные расширения должны включаться в расширения одного ответа о статусе сертификата (поле singleExtensions структуры SingleResponse, см. 7.3.3.4).

Служба OCSP может работать в режиме, в котором она может переадресовывать полученные запросы другой службе OCSP. Информация о другой службе OCSP может быть передана в расширении для отдельного запроса статуса сертификата ServiceLocator, включаемом в поле singleRequestExtensions структуры Request (см. 7.2.2.1). Расширение ServiceLocator используется в установленных регламентом случаях, когда требуется передать запрос актуального статуса некоторого сертификата службе OCSP, наделенной полномочиями для данной проверки.

Расширение ServiceLocator имеет следующий объектный идентификатор:

id-pkix-ocsp-service-locator, "1.3.6.1.5.5.7.48.1.7".

Значение расширения представляет собой структуру ServiceLocator и должно выглядеть следующим образом.

Поля структуры ServiceLocator должны быть заполнены в соответствии со следующим описанием.

Запрашивающая сторона может указать набор предпочтительных алгоритмов подписи. Для этого в запрос к службе OCSP в поле requestExtensions структуры TBSRequest (см. 7.2.2) должно быть помещено расширение PreferredSignatureAlgorithms. Данное расширение имеет следующий объектный идентификатор:

id-pkix-ocsp-pref-sig-algs, "1.3.6.1.5.5.7.48.1.8".

Значение расширения представляет собой структуру PreferredSignatureAlgorithms, содержащую последовательность структур PreferredSignatureAlgorithm, и должно выглядеть следующим образом.

Каждая из структур PreferredSignatureAlgorithm содержит информацию об одном предпочтительном алгоритме подписи и должна выглядеть следующим образом.

Поля структуры должны быть заполнены в соответствии со следующим описанием.

При заполнении структуры PreferredSignatureAlgorithms должны выполняться следующие условия:

- запрашивающая сторона должна поддерживать каждый из предпочтительных алгоритмов подписи, указанных в расширении PreferredSignatureAlgorithms;

- алгоритмы подписи, указанные в структуре PreferredSignatureAlgorithms, должны быть расположены в порядке их предпочтения запрашивающей стороной.

При выборе службой OCSP предпочтительных алгоритмов подписи могут быть использованы правила, описанные в приложении Б.

В случае если службе OCSP известно, что удостоверяющий центр не выдавал сертификат, который указан в запросе (статус "revoked", см. 5.2.2), в поле responseExtensions структуры ResponseData (см. 7.3.3.2), должно быть включено расширение id-pkix-ocsp-extended-revoke, содержащее дополнительную информацию об отзыве.

Присутствие данного расширения означает, что служба OCSP поддерживает расширенное определение статуса сертификата "отозван" для случая, когда УЦ не выдавал данный сертификат (см. 7.3.3.5). Это позволяет определить режим работы службы OCSP, например при аудите. Расширение id-pkix-ocsp-extended-revoke может также быть включено в ответы службы OCSP, содержащие иные статусы сертификатов, если требуется оповестить получателя ответа, что служба OCSP поддерживает включение в ответ дополнительной информации об отзыве. При этом запрашивающей стороне необязательно учитывать данное расширение при определении статуса сертификата (сертификатов) в ответе службы OCSP.

Данное расширение имеет следующий объектный идентификатор:

id-pkix-ocsp-extended-revoke, "1.3.6.1.5.5.7.48.1.9".

Расширение ExtendedRevoke не должно быть критичным. Расширение должно содержать значение NULL, заданное в соответствии с пунктом 8.7 ГОСТ Р ИСО/МЭК 8824-93.

При использовании российских криптографических алгоритмов хэширования идентификатор используемого алгоритма хэширования должен быть включен в поле hashAlgorithm структуры CertID запроса к службе OCSP (см. 7.2.2.2).

Для алгоритма хэширования, определенного в ГОСТ Р 34.11, необходимо использовать следующие идентификаторы, определенные в Р 1323565.1.025:

- для алгоритма ГОСТ Р 34.11 с длиной хэш-кода 256 бит:

id-tc26-gost3411-2012-256, "1.2.643.7.1.1.2.2";

- для алгоритма ГОСТ Р 34.11 с длиной хэш-кода 512 бит:

id-tc26-gost3411-2012-512, "1.2.643.7.1.1.2.3".

При использовании российских криптографических алгоритмов подписи идентификатор используемого алгоритма подписи должен быть включен в поле signatureAlgorithm структуры BasicOCSPResponse ответа службы OCSP (см. 7.3.3.1) и может быть включен в поле optionalSignature структуры OCSPRequest запроса к службе OCSP (см. 7.2.2).

Для алгоритма подписи, определенного в ГОСТ Р 34.10, необходимо использовать следующие идентификаторы, определенные в Р 1323565.1.023-2022, подпункт 5.1.1.1:

- для алгоритма ГОСТ Р 34.10 с ключом подписи 256 бит:

id-tc26-signwithdigest-gost3410-12-256, "1.2.643.7.1.1.3.2";

- для алгоритма ГОСТ Р 34.11 с ключом подписи 512 бит:

id-tc26-signwithdigest-gost3410-12-512, "1.2.643.7.1.1.3.3".

В данном разделе описаны некоторые способы передачи запросов к службе OCSP и получения ее ответов. Настоящие рекомендации допускают и другие способы передачи указанной информации.

Для передачи запросов к службе OCSP по протоколу HTTP могут быть использованы методы GET или POST. В случае если требуется разрешить кэширование HTTP, небольшие запросы (размер которых после кодирования меньше 255 байт) могут быть переданы методом GET. В случае если кэширование HTTP не требуется обеспечивать или размер запроса больше 255 байт, то данный запрос следует передавать методом POST.

В целях обеспечения конфиденциальности взаимодействие со службой OCSP с использованием протокола HTTP может быть защищено при помощи протокола TLS или других протоколов более низкого уровня. При использовании российских криптографических алгоритмов в протоколе TLS необходимо руководствоваться Р 1323565.1.020 и Р 1323565.1.030 в зависимости от версии используемого протокола.

Запрос OCSP, отправленный с помощью метода GET, должен выглядеть следующим образом.

Компонент {Адрес службы OCSP} может быть извлечен из поля AuthorityInfoAccess проверяемого сертификата или из локальных настроек запрашивающей стороны.

Запрос OCSP, отправленный с помощью метода POST, должен быть построен следующим образом:

- заголовок Content-Type должен иметь значение application/ocsp-request;

- в теле запроса должно содержаться значение закодированной в DER структуры OCSPRequest (см. 7.2).

Ответ службы OCSP по протоколу HTTP должен содержать следующие компоненты:

- заголовок Content-Type со значением application/ocsp-response;

- заголовок Content-Length, содержащий длину ответа.

Примечание - В ответе службы OCSP могут присутствовать другие заголовки HTTP, которые могут быть проигнорированы, если они неизвестны запрашивающей стороне;

- тело ответа, содержащее значение закодированной в DER структуры OCSPResponce (см. 7.3).

Для передачи запросов к службе OCSP и получения ее ответов посредством электронной почты используются следующие объекты MIME.

Каждый из описанных объектов MIME должен содержать данные, закодированные в DER и в base64 [6].

Для MIME-типов application/ocsp-request и application/ocsp-response реализация передачи может включать в себя дополнительные параметры name (имя) и filename (название файла) с целью сохранения информации об имени, когда запросы и ответы о штампах времени сохранены в виде файлов.

Если указанные дополнительные параметры включены, необходимо использовать соответствующие расширения файлов:

Настоящие рекомендации допускают использование произвольного названия файла длиной не более восьми символов без учета трехбуквенного расширения.

Передача запросов к службе OCSP и получение ее ответов могут быть осуществлены посредством файлового протокола (например, FTP).

Файл с запросом к службе OCSP или с ее ответом должен содержать только результат DER-кодирования запроса или ответа соответственно и не должен содержать посторонних заголовков или концевых меток.

Файл с запросом к службе OCSP должен иметь расширение .ORQ.

Файл с ответом службы OCSP должен иметь расширение .ORS.

В данном приложении приведены форматы запроса к службе OCSP и ее ответа в нотации АСН.1, определенной в ГОСТ Р ИСО/МЭК 8824.

Протокол OCSP не устанавливает определенного списка разрешенных алгоритмов подписи ответа службой OCSP. В то же время протокол OCSP не предусматривает возможности для запрашивающей стороны указывать в запросе предпочтительные алгоритмы подписи. Поэтому существует риск, что служба OCSP сформирует OCSP-ответ с использованием алгоритма, который не поддерживается запрашивающей стороной.

Регламент службы OCSP может предусматривать различные правила выбора предпочтительного алгоритма подписи. Например, служба OCSP может использовать алгоритм подписи, совпадающий с алгоритмом подписи сертификатов и CRL в обслуживаемом данной службой УЦ. Данные правила не могут быть применены в следующих случаях:

- алгоритм, используемый УЦ для подписи сертификатов и CRL, неприменим к ключевой паре, используемой службой OCSP для подписи OCSP-ответов;

- запрос статуса сертификата, о котором служба OCSP не имеет сведений, не содержит достаточной информации для выбора предпочтительного алгоритма подписи ответа.

Служба OCSP может применять алгоритмы подписи ответа, отличные от используемых обслуживаемым ей УЦ, в следующих случаях:

- если алгоритм подписи OCSP-ответа требует меньшего объема вычислений, чем алгоритм подписи самого проверяемого сертификата;

- если требуется защититься от возможной компрометации алгоритма подписи при помощи использования двух различных алгоритмов подписи.

В большинстве случаев при выборе предпочтительного алгоритма подписи достаточно, чтобы данный алгоритм был не менее стойким, чем алгоритм подписи проверяемого сертификата. В то же время данное условие может быть неприменимо при долговременном архивном хранении, если статус сертификата запрашивается на момент времени в прошлом, а используемый алгоритм подписи более не считается стойким.

Порядок выбора службой OCSP предпочтительного алгоритма подписи может различаться в зависимости от следующих факторов.

- Служба OCSP не использует заранее сформированные ответы. В этом случае служба OCSP может максимизировать вероятность успешного взаимодействия по протоколу OCSP, применяя следующие правила для выбора алгоритма подписи ответа. При этом выбираемый алгоритм подписи должен соответствовать требованиям безопасности, устанавливаемыми, например регламентом службы OCSP. Правила должны применяться в порядке их перечисления. При этом переход к следующему правилу может быть осуществлен только в случае, если предыдущее правило невыполнимо:

1) Выбрать алгоритм подписи, который был указан запрашивающей стороной как предпочтительный.

2) Выбрать алгоритм подписи, который был использован для подписи CRL удостоверяющего центра, выпустившего проверяемый сертификат.

3) Выбрать алгоритм подписи, идентичный алгоритму подписи запроса к службе OCSP OCSPRequest (см. 7.2).

4) Выбрать алгоритм подписи, указанный в качестве алгоритма подписи по умолчанию в регламенте службы OCSP.

5) Выбрать алгоритм подписи, предписываемый применимыми нормами технического регулирования или другими нормативно-правовыми актами.

- Служба OCSP использует заранее сформированные ответы. В этом случае может возникнуть ситуация, когда служба OCSP не учитывает информацию, включенную в запрос запрашивающей стороной. Однако служба OCSP может использовать данные запроса для отправки подходящего/соответствующего заранее сформированного ответа. Например, служба OCSP может анализировать запросы, полученные ранее, и формировать ответы об актуальном статусе одного и того же сертификата, подписанные с использованием различных алгоритмов подписи.

В данном приложении содержатся примеры запроса к службе получения актуальных статусов сертификатов и ее ответа при использовании российских криптографических алгоритмов. Значения закрытых и открытых ключей представлены в порядке от младшего байта к старшему (little-endian).

При создании примеров были использованы следующие сертификаты.

- Сертификат, статус которого проверяется и который используется для подписи запроса к службе OCSP. Данный сертификат представлен в кодировке Base64 [6] и выглядит следующим образом.

В качестве закрытого ключа для подписи запроса к службе OCSP используется следующий ключ.

В качестве соответствующего открытого ключа используется следующий ключ.

- Сертификат, используемый для подписи ответа службы OCSP. Данный сертификат представлен в кодировке Base64 [6] и выглядит следующим образом.

В качестве закрытого ключа для подписи ответа службы OCSP используется следующий ключ.

В качестве соответствующего открытого ключа используется следующий ключ.

- Сертификат УЦ, выдавшего сертификат, используемый для подписи ответа службы OCSP, и сертификат, статус которого проверяется. Данный сертификат представлен в кодировке Base64 [6] и выглядит следующим образом.

В качестве закрытого ключа для сертификата УЦ используется следующий ключ.

В качестве соответствующего открытого ключа используется следующий ключ.

Запрос к службе OCSP в абстрактно-синтаксической нотации версии 1 (АСН.1), определенной в ГОСТ Р ИСО/МЭК 8824.

Запрос к службе OCSP в кодировке Base64 [6].

Ответ службы OCSP в абстрактно-синтаксической нотации версии 1 (АСН.1), определенной в ГОСТ Р ИСО/МЭК 8824.

Ответ службы OCSP в кодировке Base64 [6].