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

(утв. и введены в действие Приказом Росстандарта от 10.10.2024 № 1427-ст)

ИСПОЛЬЗОВАНИЕ РОССИЙСКИХ КРИПТОГРАФИЧЕСКИХ АЛГОРИТМОВ В ПРОТОКОЛЕ ПОЛУЧЕНИЯ АКТУАЛЬНЫХ СТАТУСОВ СЕРТИФИКАТОВ (OCSP)

Information technology. Cryptographic data security. The use of the Russian cryptographic algorithms in the Online Certificate Status Protocol (OCSP)

Р 1323565.1.059-2024

ОКС 35.030

Дата введения 1 января 2025 года

Предисловие

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

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

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

Правила применения настоящих рекомендаций установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящим рекомендациям публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящих рекомендаций соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

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

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

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

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

1 Область применения

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

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

2 Нормативные ссылки

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

ГОСТ Р ИСО/МЭК 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 Термины, определения и сокращения

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

3.2 Сокращения

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

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);

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

4 Обзор протокола OCSP

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

Рисунок 1 — Схема обмена сообщениями по протоколу OCSP

В первом сообщении обмена в рамках протокола 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.

5 Порядок формирования запроса к службе OCSP и проверки ее ответа

5.1 Порядок формирования запроса к службе OCSP

Идентификатор сертификата (или сертификатов, если их несколько), для которого требуется получить актуальный статус, помещается в запрос к службе 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 может быть задан в настройках запрашивающей стороны.

5.2 Порядок формирования ответа службой OCSP

5.2.1 Общие сведения о формировании ответа службы OCSP

5.2.2 Статусы сертификата в ответе службы OCSP

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

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

Примечания

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

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

5.2.3 Значения времени в ответе службы 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.

5.3 Порядок проверки ответа службы OCSP

При получении ответа запрашивающая сторона должна проверить ответ на ошибки о состоянии и, если их нет, проверить различные поля в полученном ответе в соответствии с 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 ответа. Данные проверки могут выполняться в произвольном порядке.

6 Сертификат службы OCSP

6.1 Определение полномочий службы 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 могут быть определены дополнительные проверки, применяемые непосредственно к ответу данной службы или к сертификату, используемому для проверки подписи в ответе.

6.2 Проверка статуса сертификата службы 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, в этом случае решение о необходимости проверки статуса сертификата и о способе выполнения проверки принимается на основе регламента (политики безопасности) запрашивающей стороны.

7 Форматы запроса и ответа

7.1 Общие сведения о формате запроса к службе OCSP и ее ответа

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

7.2 Формат запроса

7.2.1 Общая структура запроса

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

OCSPRequest ::= SEQUENCE {

    tbsRequest               TBSRequest,
    optionalSignature [0]    EXPLICIT Signature OPTIONAL }

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

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

7.2.2 Структура TBSRequest

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

TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1,

    requestorName         [1] EXPLICIT GeneralName OPTIONAL,

    requestList               SEQUENCE OF Request,

requestExtensions     [2] EXPLICIT Extensions OPTIONAL }

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

7.2.2.1 Структура Request

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

Request ::= SEQUENCE {

    reqCert                        CertID,
    singleRequestExtensions    [0] EXPLICIT Extensions OPTIONAL }

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

7.2.2.2 Структура CertID

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

CertID ::= SEQUENCE {

    hashAlgorithm        AlgorithmIdentifier,
    issuerNameHash       OCTET STRING, -- Хэш-код

                                   -- отличительного
                                   -- имени издателя
issuerKeyHash        OCTET STRING, -- Хэш-код открытого
                                   -- ключа издателя
serialNumber         CertificateSerialNumber }

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

7.2.3 Структура Signature

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

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

Signature ::= SEQUENCE {

    signatureAlgorithm       AlgorithmIdentifier,
    signature                BIT STRING,
    certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

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

7.3 Формат ответа

7.3.1 Общая структура ответа

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

OCSPResponse ::= SEQUENCE {

    responseStatus       OCSPResponseStatus,
    responseBytes    [0] EXPLICIT ResponseBytes OPTIONAL }

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

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

7.3.2 Тип OCSPResponseStatus

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

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

OCSPResponseStatus ::= ENUMERATED { successful (0), -- Ответ содержит информацию о -- статусе (статусах) сертификата -- (сертификатов). malformedRequest (1), -- Некорректный запрос. Данный -- ответ означает, что полученный -- запрос не соответствует -- синтаксису протокола OCSP. internalError (2), -- Внутренняя ошибка. Данный -- ответ означает, что при -- обработке запроса службой OCSP -- произошла ошибка. Запрос -- необходимо повторить и, при -- возможности, отправить запрос -- в другую службу OCSP. tryLater (3), -- Попробуйте позже. Данный ответ -- означает, что служба OCSP -- работает корректно, но не -- может ответить в данный момент -- времени.

                         (4)  -- Не используется.
    sigRequired          (5), -- Требуется подпись. Данный

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

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

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

7.3.3 Структура ResponseBytes

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

ResponseBytes ::= SEQUENCE {

    responseType           OBJECT IDENTIFIER,
    response               OCTET STRING }

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

7.3.3.1 Структура BasicOCSPResponse

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

BasicOCSPResponse ::= SEQUENCE {

    tbsResponseData           ResponseData,
    signatureAlgorithm        AlgorithmIdentifier,
    signature                 BIT STRING,
    certs                 [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

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

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

7.3.3.2 Структура ResponseData

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

ResponseData ::= SEQUENCE {

    version               [0] EXPLICIT Version DEFAULT v1,
    responderID               ResponderID,

    producedAt                GeneralizedTime,

    responses                 SEQUENCE OF SingleResponse,

responseExtensions    [1] EXPLICIT Extensions OPTIONAL }

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

7.3.3.3 Структура ResponderID

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

ResponderID ::= CHOICE {

    *byName      [1] Name,*
    *byKey       [2] KeyHash }*

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

7.3.3.4 Структура SingleResponse

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

SingleResponse ::= SEQUENCE {

    *certID                  CertID,*
    *certStatus              CertStatus,*
    *thisUpdate              GeneralizedTime,*
    *nextUpdate          [0] EXPLICIT GeneralizedTime OPTIONAL,*
    *singleExtensions    [1] EXPLICIT Extensions OPTIONAL }*

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

7.3.3.5 Тип CertStatus

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

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

CertStatus ::= CHOICE {

    *good               [0] IMPLICIT NULL,*
    *revoked            [1] IMPLICIT RevokedInfo,*
    *unknown            [2] IMPLICIT UnknownInfo }*

7.4 Расширения запроса и ответа

7.4.1 Порядок использования расширений запроса и ответа

В данном разделе настоящих рекомендаций определен ряд расширений на основе модели расширения, определенной в [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 и ее ответа с указанием поля, куда может включаться каждое из расширений. В случае когда расширение может быть включено в некоторое поле запроса и/или ответа, на пересечении строки с именем расширения и графы с именем поля находится знак "+", в остальных случаях - знак "-".

Таблица 1

Возможность включения расширений в поля запроса и ответа

7.4.2 Одноразовый код

Расширение, содержащее одноразовый код, связывает запрос к службе 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

7.4.3 Ссылки на CRL

Служба 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 ::= SEQUENCE {

    *crlUrl          [0] EXPLICIT IA5String OPTIONAL,*
    *crlNum          [1] EXPLICIT INTEGER OPTIONAL,*
    *crlTime         [2] EXPLICIT GeneralizedTime OPTIONAL }*

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

7.4.4 Принимаемые типы ответов

Настоящие рекомендации устанавливают формат базового типа ответа службы 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

7.4.5 Архивный срез

Служба 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

7.4.6 Расширения записей в CRL

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

7.4.7 Адрес службы

Служба 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 ::= SEQUENCE {

    *issuer                  Name,*
    *locator                 AuthorityInfoAccessSyntax }*

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

7.4.8 Предпочтительные алгоритмы подписи

Запрашивающая сторона может указать набор предпочтительных алгоритмов подписи. Для этого в запрос к службе 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, и должно выглядеть следующим образом.

PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm

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

PreferredSignatureAlgorithm ::= SEQUENCE { sigIdentifier AlgorithmIdentifier, pubKeyAlgIdentifier SMIMECapability OPTIONAL }

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

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

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

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

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

7.4.9 Дополнительная информация об отзыве

В случае если службе 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.

8 Использование российских криптографических алгоритмов

8.1 Использование российских алгоритмов хэширования

При использовании российских криптографических алгоритмов хэширования идентификатор используемого алгоритма хэширования должен быть включен в поле 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».

8.2 Использование российских алгоритмов подписи

При использовании российских криптографических алгоритмов подписи идентификатор используемого алгоритма подписи должен быть включен в поле 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».

9 Способы передачи

9.1 Общие сведения о способах передачи

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

9.2 Протокол OCSP по HTTP

9.2.1 Запрос к службе OCSP по HTTP

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

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

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

GET {Адрес службы OCSP}/{Запрос к службе OCSP OCSPRequest (см. 7.2), последовательно закодированный в DER, затем в base64 [5], после чего представленный в кодировке URL (Percent-Encoding, см. [3])}

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

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

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

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

9.2.2 Ответ службы OCSP по HTTP

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

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

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

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

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

9.3 Протокол OCSP через электронную почту

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

Content-Type: application/ocsp-request Content-Transfer-Encoding: base64

Content-Type: application/ocsp-response Content-Transfer-Encoding: base64

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

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

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

       *MIME-тип                  Расширение файла*
*application/ocsp-request               .ORQ*
*application/ocsp-response              .ORS*

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

9.4 Протокол OCSP на основе файлового протокола

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

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

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

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

Приложение А (рекомендуемое)

OCSP В АСН.1

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

OCSP-2013-88 {iso(1) identified-organization (3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-2013-88(81)} DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS -- PKIX Certificate Extensions AuthorityInfoAccessSyntax, CRLReason, GeneralName FROM PKIXlImplicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(1) id-pkixl-implicit(19) }

    *Name, CertificateSerialNumber, Extensions,*
    *id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier*
    *FROM PKIXlExplicit88 { iso(1) identified-organization(3)*
        *dod(6) internet(1) security(5) mechanisms(5) pkix(7)*
       *id-mod(0) id-pkixl-explicit (18) };*

OCSPReguest ::= SEQUENCE {

    *tbsRequest               TBSRequest,*
    *optionalSignature    [0] EXPLICIT Signature OPTIONAL }*

TBSRequest ::= SEQUENCE {

    *version              [0] EXPLICIT Version DEFAULT v1,*
    *requestorName        [1] EXPLICIT GeneralName OPTIONAL,*
    *requestList              SEQUENCE OF Request,*
    *requestExtensions    [2] EXPLICIT Extensions OPTIONAL }*

Signature ::= SEQUENCE {

    *signatureAlgorithm       AlgorithmIdentifier,*
    *signature                BIT STRING,*
    *certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }*

Version ::= INTEGER { v1(0) }

Request ::= SEQUENCE {

    *reqCert                       CertID,*
    *singleRequestExtensions   [0] EXPLICIT Extensions OPTIONAL }*

CertID ::= SEQUENCE {

    *hashAlgorithm          AlgorithmIdentifier,*
    *issuerNameHash         OCTET STRING, -- Хэш-код отличительного имени*

                                     *-- издателя*
*issuerKeyHash          OCTET STRING, -- Хэш-код открытого ключа*
                                     *-- издателя*
*serialNumber           CertificateSerialNumber }*

OCSPResponse ::= SEQUENCE {

    *responseStatus           OCSPResponseStatus,*
    *responseBytes        [0] EXPLICIT ResponseBytes OPTIONAL }*

OCSPResponseStatus ::= ENUMERATED { successful (0), -- Ответ содержит информацию о -- статусе (статусах) сертификата -- (сертификатов). malformedRequest (1), -- Некорректный запрос. Данный ответ -- означает, что полученный запрос -- не соответствует синтаксису -- протокола OCSP. internalError (2), -- Внутренняя ошибка. Данный ответ -- означает, что при обработке -- запроса службой OCSP произошла -- ошибка. Запрос необходимо -- повторить и, при возможности, -- отправить запрос в другую службу -- OCSP. tryLater (3), -- Попробуйте позже. Данный ответ -- означает, что служба OCSP -- работает корректно, но не может -- ответить в данный момент времени. (4), -- Не используется. sigRequired (5), -- Требуется подпись. Данный ответ -- означает, что запрашивающей -- стороне необходимо подписать свой -- запрос к службе OCSP. unauthorized (6) -- Неуполномоченный. Данный ответ -- может быть возвращен в двух -- случаях. В первом случае служба -- OCSP не уполномочена сформировать -- ответ, который будет принят -- запрашивающей стороной (см. 6.1). -- Во втором случае запрашивающая -- сторона не уполномочена -- направлять запрос к данной службе -- OCSP. Определение полномочий -- запрашивающей стороны не -- относится к протоколу OCSP и -- выходит за рамки действия -- настоящих рекомендаций. }

ResponseBytes ::= SEQUENCE {

    responseType            OBJECT IDENTIFIER,
    *response                OCTET STRING }*

BasicOCSPResponse ::= SEQUENCE {

    *tbsResponseData          ResponseData,*
    *signatureAlgorithm       AlgorithmIdentifier,*
    *signature                BIT STRING,*
    *certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }*

ResponseData ::= SEQUENCE {

    *version              [0] EXPLICIT Version DEFAULT v1,*
    *responderID              ResponderID,*
    *producedAt               GeneralizedTime,*
    *responses                SEQUENCE OF SingleResponse,*
    *responseExtensions   [1] EXPLICIT Extensions OPTIONAL }*

ResponderID ::= CHOICE {

    *byName               [1] Name,*
    *byKey                [2] KeyHash }*

KeyHash ::= OCTET STRING -- хэш-код SHA-1 открытого ключа отвечающей -- стороны (за исключением полей тега и длины).

SingleResponse ::= SEQUENCE {

    *certID                   CertID,*
    *certStatus               CertStatus,*
    *thisUpdate               GeneralizedTime,*
    *nextUpdate           [0] EXPLICIT GeneralizedTime OPTIONAL,*
    *singleExtensions     [1] EXPLICIT Extensions OPTIONAL }*

CertStatus ::= CHOICE {

    *good                 [0] IMPLICIT NULL,*
    *revoked              [1] IMPLICIT RevokedInfo,*
    *unknown              [2] IMPLICIT UnknownInfo }*

RevokedInfo ::= SEQUENCE {

    *revocationTime           GeneralizedTime,*
    *revocationReason     [0] EXPLICIT CRLReason OPTIONAL }*

UnknownInfo ::= NULL

Nonce ::= OCTET STRING

ArchiveCutoff ::= GeneralizedTime

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

ServiceLocator ::= SEQUENCE {

    *issuer                   Name,*
    *locator                  AuthorityInfoAccessSyntax }*

CrlID ::= SEQUENCE {

    *crlUrl               [0] EXPLICIT IA5String OPTIONAL,*
    *crlNum               [1] EXPLICIT INTEGER OPTIONAL,*
    *crlTime              [2] EXPLICIT GeneralizedTime OPTIONAL }*

PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm

PreferredSignatureAlgorithm ::= SEQUENCE {

    *sigIdentifier            AlgorithmIdentifier,*
    *pubKeyAlgIdentifier      SMIMECapability OPTIONAL }*

-- Object Identifiers

*id-kp-OCSPSigning                  OBJECT IDENTIFIER ::= { id-kp 9 }*
*id-pkix-ocsp                       OBJECT IDENTIFIER ::= { id-ad-ocsp }*
*id-pkix-ocsp-basic                 OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }*
*id-pkix-ocsp-nonce                 OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }*
*id-pkix-ocsp-crl                   OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }*
*id-pkix-ocsp-response              OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }*
*id-pkix-ocsp-nocheck               OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }*
*id-pkix-ocsp-archive-cutoff        OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }*
*id-pkix-ocsp-service-locator       OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }*
*id-pkix-ocsp-pref-sig-algs         OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }*
*id-pkix-ocsp-extended-revoke       OBJECT IDENTIFIER ::= { id-pkix-ocsp 9 }*

END

Приложение Б (справочное)

ВЫБОР СЛУЖБОЙ OCSP АЛГОРИТМА ПОДПИСИ ОТВЕТА

Б.1 Общие правила

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

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

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

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

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

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

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

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

Б.2 Порядок выбора службой OCSP алгоритма подписи ответа

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

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

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

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

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

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

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

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

Приложение В (справочное)

ПРИМЕРЫ

В.1 Ключи и сертификаты

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

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

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

MIIBsDCCAV2gAwIBAgIBAjAKBggqhQMHAQEDAjAUMRIwEAYDVQQDEwlFeGFtcGxlQ0EwHhcNMjExMTI4MTQ0NDM2W hcNNDIxMDI4MTQ0NDM2WjAUMRIwEAYDVQQDEwlTZXJ2ZXJUTFMwXjAXBggqhQMHAQEBATALBgkqhQMHAQIBAQIDQw AEQCbq3kYBdV4pNi3Xt2MX7uQ0g4wA7XU8M3JZoIWfpPDUmBzULffy1gjM67tbFEPWq1ihb7wSwRktmPm/5tyINuW jgZowgZcwHQYDVR0OBBYEFICwaDpHKbAsRWB812hG6blB/VPWMA4GA1UdDwEB/wQEAwIB/jATBgNVHSUEDDAKBggr BgEFBQcDATAMBgNVHRMBAf8EAjAAMEMGA1UdIwQ8MDqAFMn2c6pxSOgMz9zqZeYbt/1ou_f4moRikFjAUMRIwEAYDV QQDEwlFeGFtcGxlQ0GCCFIBBf3MjS+7MAoGCCqFAwcBAQMCA0EAL9OWI7BTH4csA0gZg+dKmBsZWrMrTgSgPv7GJ7 1826YOm3PmBUtC2+DQT8ghZQGcdLk14j3LQ7vpK/q5eLimvw==

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

d = 62DD7FCD96B4028493A7F78CFC65E59ED959AFA77B83E0055E8B89E27CE9E60316

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

xq = 26EADE4601755E29362DD7B76317EEE434838C00ED753C337259A0859FA4F0D416 Yq = 981CD42DF7F2D608CCEBBB5B1443D6AB58A16FBC12C1192D98F9BFE6DC8836E516

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

MIIBsjCCAV+gAwIBAgIBATAKBggqhQMHAQEDAjAUMRIwEAYDVQQDEwlFeGFtcGxlQ0EwHhcNMjExMTI4MTQ0NDU4 WhcNNDIxMDI4MTQ0NDU4WjAWMRQwEgYDVQQDEwtPQ1NQU2VydmljZTBeMBcGCCqFAwcBAQEBMAsGCSqFAwcBAgEB AgNDAARA+xPUdwMP8NtarpmT89Puzav9rQ40Cq8I1ypZhnskujBHTjh7yAmElARwrkwikQ/jGMTLjAR0KHFnn3VV OQCQHqOBmjCBlzAdBgNVHQ4EFgQUJoSrectbwJGGOPk3ry/VrNz1C+gwDgYDVR0PAQH/BAQDAgH+MBMGA1UdJQQM MAoGCCsGAQUFBwMJMAwGAlUdEwEB/wQCMAAwQwYDVR0jBDwwOoAUyfZzqnFI6AzP3Opl5hu3/Wi5/iahGKQWMBQx EjAQBgNVBAMTCUV4YWlwbGVDQYIIUgEF/cyNL7swCgYIKoUDBwEBAwIDQQAxYabb+sAabCgl5bCrdPUhsDpRZ3/ lHazIFiBpVPB+5iN5vD/sX0JFYAsizF0TjxWEXb1PDSdH/qJx9Zmd2cCo

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

d = 84D9AE62ECC2A97960068A9EE61724593FCE2B6A5FE54506064528D22B6E844C16

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

xq = FB13D477030FF0DB5AAE9993F3D3EECDABFDAD0E340AAF08D72A59867B24BA3016 Yq = 474E387BC80984940470AE4C22910FE318C4CB8C044E2871679F7555D100901E₁₆

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

MIIBsjCCAV+gAwIBAgIIUgEF/cyNL7swCgYIKoUDBwEBAwIwFDESMBAGA1UEAxMJRXhhbXBsZUNBMB4XDTIxMTEw MjlwNDk1OVoXDTQyMTAyODIwNDk1OVowFDESMBAGA1UEAxMJRXhhbXBsZUNBMGgwIQYIKoUDBwEBAQEwFQYJKoUD BwECAQEBBggqhQMHAQECAgNDAARABZaQRjw5FoKjKJeq+PRoojqvbSLT60RKeaiHIhqGc_7qre7O92ridPqFMMHGu GCAiIk4K550YBCWWg+tNhIFh5aOBizCBIDAdBgNVHQ4EFgQUyfZzqnFI6AzP3Opl5hu3/Wi5/iYwDgYDVR0PAQH/ BAQDAgH+MBIGA1UdEwEB/wQIMAYBAf8CAQEwQwYDVR0jBDwwOoAUyfZzqnFI6AzP3Opl5hu3/Wi5/iahGKQWMBQxE jAQBgNVBAMTCUV4YW1wbGVDQYIIUgEF/cyNL7swCgYIKoUDBwEBAwIDQQAtaycJR+WUCul17CKh4ah1AMI9AIGE6y EAXDZt/DqaPA1ILgAi6Zhu1dTcwrKdh2+b4I8Es4ORITIsizpTVUgL

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

d = 9C85418F6353B11D7A8F7DC831CA6A82A45C2D9EAC2273DBAF3351A448C3642716

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

xq = 059690463C391682A32897AAF8F468A23AAF6D22D3EB444A79A887221A8673BA16 Yq = AB7BB3BDDAB89D3EA14C3071AE182022224E0AE79D1804259683EB4D848161E516

В.2 Запрос

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

SEQUENCE { SEQUENCE {

0. { INTEGER 0 }

1. {

4. { SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) PrintableString 'ServerTLS' } } } } } SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER '1 2 643 7 1 1 2 2' } OCTET STRING E6 4D 6A FI 11 DA 72 6B 3B D6 7B 66 91 52 A5 5F D9 9F 8F 31 DB 2E F3 61 BF C0 5A 62 FB 11 C7 EE OCTET STRING 0D 23 82 46 B9 65 45 23 35 2B D3 73 AD 97 DB B3 F4 34 58 C5 87 1C 0F 4A 69 EE 13 75 F3 9D 53 BB INTEGER 2 } } } }

0. { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER '1 2 643 7 1 1 3 2' } BIT STRING C7 FC 0D DC 8D 3D El 2B 0D 4F 8E F6 64 56 46 7A ED DI 66 17 36 17 9E 21 31 C6 83 A2 AB A5 23 A2 68 5F E8 4D 03 E7 C2 CD 08 07 B8 F3 46 66 6D 05 76 C0 D5 E7 60 ID 59 49 09 45 52 C4 95 A7 5A D3 } } }

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

MIHNMHigAwIBAKEYpBYwFDESMBAGA1UEAxMJU2VydmVyVExTMFcwVTBTMAoGCCqFAwcBAQICBCDmTWrxEdpyazvWe 2aRUqVf2Z+PMdsu82G/wFpi+xHH7gQgDSOCRrllRSM1K9NzrZfbs/Q0WMWHHA9Kae4TdfOdU7sCAQKgUTBPMAoGCC qFAwcBAQMCA0EAx/wN3I094SsNT472ZFZGeu3RZhc2F54hMcaDoqulI6JoX+hNA+fCzQgHuPNGZm0FdsDV52AdWUk JRVLElada0w==

В.3 Ответ

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

SEQUENCE { ENUMERATED 0

0. { SEQUENCE { OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1) OCTET STRING, encapsulates { SEQUENCE { SEQUENCE {

0. { INTEGER 0 }

1. { SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER commonName (2 5 4 3) PrintableString 'OCSPService' } } } } GeneralizedTime '20220421120000Z' SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { OBJECT IDENTIFIER '1 2 643 7 1 1 2 2' } OCTET STRING E6 4D 6A FI 11 DA 72 6B 3B D6 7B 66 91 52 A5 5F D9 9F 8F 31 DB 2E F3 61 BF C0 5A 62 FB 11 C7 EE OCTET STRING 0D 23 82 46 B9 65 45 23 35 2B D3 73 AD 97 DB B3 F4 34 58 C5 87 1C 0F 4A 69 EE 13 75 F3 9D 53 BB INTEGER 2 } [0] GeneralizedTime '20220421120000Z' } } } SEQUENCE { OBJECT IDENTIFIER '1 2 643 7 1 1 3 2' } BIT STRING F9 AD 07 FA B0 B9 85 F3 47 3D 73 01 80 6C CF 16 F8 09 C7 D0 4D 2F 44 82 B2 F2 E4 E0 D3 22 4B 8C 68 5F E8 4D 03 E7 C2 CD 08 07 B8 F3 46 66 6D 05 76 C0 D5 E7 60 1D 59 49 09 45 52 C4 95 A7 5A D3 } } } } }

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

MIIBCQoBAKCCAQIwgf8GCSsGAQUFBzABAQSB8TCB7jCBnKADAgEAoRgwFjEUMBIGA1UEAxMLT0NTUFNlcnZpY2UYD zIwMjIwNDIxMTIwMDAwWjBqMGgwUzAKBggqhQMHAQECAgQg5k1q8RHacms71ntmkVKlX9mfjzHbLvNhv8BaYvsRx+ 4EIA0jgka5ZUUjNSvTc62X27P0NFjFhxwPSmnuE3XznVO7AgECgAAYDzIwMjIwNDIxMTIwMDAwWjAKBggqhQMHAQE DAgNBAPmtB/qwuYXzRz1zAYBszxb4CcfQTS9EgrLy5ODTIkuMaF/oTQPnws0IB7jzRmZtBXbA1edgHVlJCUVSxJWn WtM===

БИБЛИОГРАФИЯ