Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
executable file 957 lines (727 sloc) 62.2 KB

СТБ 34.101.26-2012

Информационные технологии и безопасность

ОНЛАЙНОВЫЙ ПРОТОКОЛ ПРОВЕРКИ СТАТУСА СЕРТИФИКАТА (OCSP)

Інфармацыйныя тэхналогіі і бяспека

АНЛАЙНАВЫ ПРАТАКОЛ ПРАВЕРКI СТАТУСА СЕРТЫФІКАТА (OCSP)

Information technology and security

Online certificate status protocol (OCSP)


Содержание

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

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

3 Термины и определения, обозначения

4 Сокращения

5 Общие положения

6 Онлайновый протокол проверки статуса сертификата

Приложение А (справочное) Ключевые слова

Приложение Б (обязательное) Модуль AСН.1

Приложение В (обязательное) Отличительные правила кодирования

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

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

Настоящий стандарт предназначен для применения при разработке, испытаниях и эксплуатации систем управления открытыми ключами.

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

В настоящем стандарте использованы ссылки на следующие технические нормативные правовые акты в области технического нормирования и стандартизации (далее – ТНПА):

СТБ 1176.1-99 Информационная технология. Защита информации. Функция хэширования

СТБ 1176.2-99 Информационная технология. Защита информации. Процедуры выработки и проверки электронной цифровой подписи

СТБ 34.101.19-2012 Информационные технологии. Форматы сертификатов и списков отозванных сертификатов инфраструктуры открытых ключей

СТБ 34.101.31-2011 Информационные технологии. Защита информации. Криптографические алгоритмы шифрования и контроля целостности

ГОСТ 34.973-91 (ИСО 8824-87) Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)

ГОСТ 34.974-91 (ИСО 8825-87) Информационная технология. Взаимосвязь открытых систем. Описание базовых правил кодирования для абстрактно-синтаксической нотации версии 1 (АСН.1)

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

3 Термины и определения

В настоящем стандарте применяют термины, установленные в СТБ 34.101.19, а также следующие термины с соответствующими определениями:

3.1 OCSP сервер, сервер OCSP: Сторона, предоставляющая онлайновую услугу проверки статуса сертификата.

3.2 OCSP клиент, клиент OCSP: Сторона, запрашивающая проверку сертификата.

Ключевые слова «ДОЛЖЕН», «НЕЛЬЗЯ», «БУДЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «МОЖЕТ» и «НЕОБЯЗАТЕЛЬНО» в настоящем стандарте (выделенные прописными буквами) должны интерпретироваться, как это описано в приложении A.

4 Сокращения

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

АСН.1 – абстрактно-синтаксическая нотация версии 1;

СОС – список отозванных сертификатов;

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

ЭЦП – электронная цифровая подпись;

OCSP –online certificate status protocol – онлайновый протокол проверки статуса сертификата.

5 Общие положения

5.1 Назначение

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

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

5.2 Запрос

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

Запрос OCSP содержит следующие данные:

  • версию протокола;
  • имя OCSP клиента (НЕОБЯЗАТЕЛЬНО);
  • список идентификаторов проверяемых сертификатов;
  • необязательные расширения, которые МОГУТ обрабатываться сервером OCSP.

После получения запроса OCSP сервер должен проверить, что:

  • запрос сформирован правильно;
  • OCSP сервер настроен для предоставления запрашиваемых услуг;
  • запрос содержит всю необходимую информацию.

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

5.3 Ответ

OCSP сервер может возвращать ответы различных типов. Ответ OCSP сервера состоит из типа ответа и собственно ответа. Существует один основной тип ответа, который ДОЛЖЕН поддерживаться всеми серверами и клиентами OCSP. В настоящем разделе рассматривается только данный тип ответа.

Все ответы ДОЛЖНЫ содержать ЭЦП. Ключ, на котором подписывается ответ, ДОЛЖЕН принадлежать одной из следующих сторон:

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

Ответ OCSP состоит из:

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

Ответ по каждому проверяемому сертификату состоит из:

  • идентификатора сертификата;
  • статуса сертификата;
  • срока действия ответа;
  • необязательных расширений.

В настоящем стандарте определяются следующие значения компонента «статус сертификата»:

  • good (действующий);
  • revoked (отозванный);
  • unknown (неизвестный).

Значение «good» означает положительный ответ на запрос о статусе сертификата. Данный ответ означает, что сертификат не отозван, но не означает, что сертификат когда-либо выдавался или что время, в которое был дан ответ, находится в пределах срока действия сертификата.

Значение «revoked» означает, что сертификат был отозван навсегда или что его действие было временно приостановлено.

Значение «unknown» означает, что серверу ничего не известно про запрашиваемый сертификат.

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

5.4 Ошибки

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

  • malformedRequest;
  • internalError;
  • tryLater;
  • sigRequired;
  • unauthorized.

Сервер выдает ответ malformedRequest, если синтаксис полученного запроса не соответствует синтаксису OCSP.

Ответ internalError означает, что возникло недопустимое внутреннее состояние сервера OCSP. Запрос следует повторить, возможно, через другой сервер.

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

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

Ответ unauthorized означает, что клиент не имеет полномочий делать запрос на данный сервер OCSP.

5.5 Время

Ответ может содержать три метки времени:

  • thisUpdate – время, когда точно известно, что текущий статус сертификата верен;
  • nextUpdate – время, когда будет доступна новая информация о статусе сертификата;
  • producedAt – время, когда сервер OCSP подписал данный ответ.

Если значение компонента nextUpdate не задано, это означает, что информация о статусе сертификата постоянно обновляется.

5.6 Предварительное создание ответа

OCSP серверы МОГУТ заранее выдавать подписанные ответы, содержащие информацию о статусе сертификатов в определенное время. Время, когда был точно известен статус сертификата, БУДЕТ отражаться в компоненте ответа thisUpdate. Время, когда будет доступна новая информация о статусе сертификата, отражается в компоненте nextUpdate. Время, когда был создан ответ, указывается в компоненте ответа producedAt.

5.7 Делегирование полномочий подписи онлайнового

протокола проверки статуса сертификата

Ключ, с помощью которого подписывается ответ, необязательно должен быть тем же ключом, которым подписан сертификат. Эмитент сертификата явно делегирует OCSP серверу право подписи, выдавая ему сертификат, содержащий уникальное значение компонента extendedKeyUsage. Данный сертификат ДОЛЖЕН напрямую выдаваться серверу OCSP компетентным УЦ.

5.8 Компрометация ключа удостоверяющего центра

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

5.9 Синтаксис

Сообщения протокола задаются типами АСН.1. Модуль АСН.1, определяющий эти типы, – в соответствии с приложением Б.

Для формирования электронной формы сообщения или некоторых его компонентов значения типов АСН.1 кодируются. В результате кодирования формируется последовательность октетов, которую можно передавать, подписывать и т. д. В ГОСТ 34.974 определены базовые правила кодирования. В приложении B установлены отличительные правила кодирования, которые уточняют базовые правила и обеспечивают однозначность кодового представления.

5.10 Функциональные требования

5.10.1 Содержание сертификата

Чтобы предоставить клиентам доступ к серверу OCSP, УЦ ДОЛЖНЫ поддерживать возможность включения расширения AuthorityInfoAccess (определено в СТБ 34.101.19) в сертификаты, которые могут быть проверены с помощью OCSP. В качестве альтернативы, для доступа к OCSP серверу клиент может локально настроить компонент accessLocation данного расширения.

УЦ, который поддерживает OCSP (непосредственно или через авторизованный сервер), должен обеспечить включение значений uniformResourceIndicator (URI) для компонента accessLocation. Данный УЦ должен также обеспечить включение идентификатора id-ad-ocsp для компонента accessMethod в AccessDescription расширения AuthorityInfoAccess.

Значение компонента accessLocation определяет средство (например, протокол HTTP) получения доступа к серверу OCSP и может содержать дополнительную информацию о нем (например, адреса ресурсов в сети Интернет – URL).

5.10.2 Требования по приему ответа

Прежде чем принять подписанный ответ, OCSP клиенты ДОЛЖНЫ убедиться в том, что:

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

5.11 Аспекты безопасности

При настройке и использовании OCSP следует учитывать указанные ниже аспекты безопасности.

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

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

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

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

6 Онлайновый протокол проверки статуса сертификата

6.1 Запрос

6.1.1 Синтаксис запроса

Запрос OCSP должен быть значением типа OCSPRequest АСН.1:

OCSPRequest ::= 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}

Компоненты типа OCSPRequest имеют следующее значение:

  • tbsRequest – информационная часть запроса;
  • optionalSignature – необязательная ЭЦП информационной части запроса. ЭЦП вырабатывается от кодового представления tbsRequest. При кодировании должны использоваться отличительные правила (см. приложение В).

Компоненты типа TBSRequest имеют следующее значение:

  • version – номер версии для совместимости с будущими версиями настоящего стандарта. Для данной версии стандарта он должен быть равен 0;
  • requestorName – необязательное имя OCSP клиента. Тип GeneralName данного компонента определен в СТБ 34.101.19;
  • requestList – список проверяемых сертификатов;
  • requestExtensions – необязательные расширения, которые могут обрабатываться сервером OCSP. Тип Extensions данного компонента определен в СТБ 34.101.19.

Компоненты типа Signature имеют следующее значение:

  • signatureAlgorithm – идентификатор алгоритма и связанные с данным алгоритмом параметры. Тип AlgorithmIdentifier данного компонента определен в СТБ 34.101.19. МОЖЕТ использоваться алгоритм, определенный в СТБ 1176.2;
  • signature – электронная цифровая подпись;
  • certs – цепочка сертификатов, демонстрирующая действительность открытого ключа ЭЦП.

Компоненты типа CertID имеют следующее значение:

  • hashAlgorithm – идентификато алгоритма хэширования, который используется для определения значений компонентов issuerNameHash и issuerKeyHash, и связанные с данным алгоритмом параметры. МОЖЕТ использоваться алгоритм, определенный в СТБ 34.101.31. Алгоритм хэширования, определенный в СТБ 1176.1, использовать НЕЛЬЗЯ;
  • issuerNameHash – хэш-значение уникального имени эмитента. В СТБ 34.101.19 имя эмитента представляется значением типа Name. Хэшируется кодовое представление данного значения. Для кодирования должны использоваться отличительные правила (см. приложение В);
  • issuerKeyHash – хэш-значение открытого ключа эмитента В СТБ 34.101.19 открытый ключ представляется значением типа SubjectPublicKeyInfo. Хэшируется кодовое представление значения компонента subjectPublicKey данного типа, за исключением тега и длины;
  • serialNumber – серийный номер сертификата, информация о статусе которого запрашивается.

6.1.2 Примечания по запросу

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

Поддержка любого расширения НЕОБЯЗАТЕЛЬНА. НЕ СЛЕДУЕТ маркировать расширения как критические. В 6.3 определяется несколько расширений. Другие расширения МОГУТ определяться в дополнительных стандартах. Нераспознанные расширения ДОЛЖНЫ игнорироваться (если только они не являются критическими).

Клиент OCSP МОЖЕТ подписать запрос. В этом случае ЭЦП рассчитывается от структуры tbsRequest и помещается в компонент Signature. Если запрос подписан, то OCSP клиент ДОЛЖЕН указать свое имя в компоненте requestorName. Клиент также может включать в запрос сертификаты, которые помогут OCSP серверу проверить ЭЦП, расположенную в компоненте Signature.

6.2 Ответ

6.2.1 Синтаксис ответа

Ответ OCSP должен быть значением типа OCSPResponse АСН.1:

OCSPResponse ::= SEQUENCE {
  responseStatus      OCSPResponseStatus,
  responseBytes       [0]  EXPLICIT ResponseBytes OPTIONAL}

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

ResponseBytes ::= SEQUENCE {
  responseType        OBJECT IDENTIFIER,
  response            OCTET STRING}

Компонент responseStatus типа OCSPResponceStatus отражает статус обработки запроса. Если статус указывает на ошибку, то компонент responseBytes не задается. Компонент responseBytes определяет тип ответа (responseType) и собственно ответ (response).

Для основного типа ответа OCSP компонент responseType принимает значение id-pkix-ocsp-basic.

OCSP серверы ДОЛЖНЫ иметь возможность создавать ответы типа id-pkix-ocsp-basic. Соответственно, OCSP клиенты ДОЛЖНЫ иметь возможность получать ответы типа id-pkix-ocsp-basic.

Компонент response ДОЛЖЕН содержать кодовое представление значения типа BasicOCSPResponse:

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

При кодировании ДОЛЖНЫ использоваться отличительные правила (см. приложение В).

Компоненты типа BasicOCSPResponse имеют следующее значение:

  • tbsResponseData – содержит ответы по всем запрашиваемым сертификатам;

  • signatureAlgorithm – идентификатор алгоритма и связанные с данным алгоритмом параметры. Тип AlgorithmIdentifier данного компонента определен в СТБ 34.101.19;

  • signature – ЭЦП, вычисленная от хэш-значения компонента tbsResponseData. Компонент tbsResponseData ДОЛЖЕН быть предварительно закодирован с использованием отличительных правил кодирования (см. приложение В). МОЖЕТ использоваться алгоритм ЭЦП, определенный в СТБ 1176.2. При этом для предварительного хэширования tbsResponseData ДОЛЖЕН использоваться алгоритм, определенный в СТБ 34.101.31;

  • certs – цепочка сертификатов, демонстрирующая действительность открытого ключа ЭЦП.

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

Компоненты типа ResponseData имеют следующее значение:

  • version – номер версии для совместимости с будущими версиями настоящего стандарта. Для данной версии стандарта он должен быть равен 0;

  • responderID – определяет OCSP сервер; принимает значения типа ResponderID:

    ResponderID ::= CHOICE { byname [1] Name, byKey [2] KeyHash}

    KeyHash ::= OCTET STRING

Компонент byName непосредственно задает имя OCSP сервера, используя тип Name.

Компонент byKey содержит хэш-значение открытого ключа OCSP сервера. Хэшируется кодовое представление значения компонента subjectPublicKey типа SubjectPublicKeyInfo, за исключением тега и длины. Для кодирования ДОЛЖНЫ использоваться отличительные правила (см. приложение В). В качестве алгоритма хэширования ДОЛЖЕН использоваться алгоритм, определенный в запросе.

producedAt – время создания ответа (см. 5.5), представлено типом GeneralizedTime, определенным в СТБ 34.101.19. responses – список ответов по всем проверяемым сертификатам. responseExtensions – необязательные расширения, которые могут обрабатываться клиентом OCSP. Тип Extensions данного компонента определен в СТБ 34.101.19.

Ответ по каждому проверяемому сертификату определяется типом SingleResponse:

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 - здесь может быть перечисление

Компоненты типа SingleResponse имеют следующее значение:

  • certID – определен в 6.1.1;
  • certStatus – статус сертификата, определенный типом CertStatus. Значения компонентов типа CertStatus описаны в 5.3;
  • thisUpdate, nextUpdate – временные метки, определяющие интервал действия ответа. Данный интервал соответствует интервалу {thisUpdate, nextUpdate} в СОС. Ответы, в которых компонент nextUpdate содержит более раннее значение, чем время локальной системы, ДОЛЖНЫ считаться ненадежными. Ответы, в которых значение компонента nextUpdate не задано, эквивалентны СОС, в которых компонент nextUpdate также не задан (см. 5.5);
  • singleExtensions – необязательные расширения, которые могут обрабатываться клиентом OCSP и содержат дополнительную информацию о проверяемом сертификате.

Компоненты типа RevokedInfo имеют следующее значение:

  • revocationTime – время, когда проверяемый сертификат был отозван или его действие было временно приостановлено;
  • revocationReason – указывает причину отзыва сертификата. Тип CRLReason определен в СТБ 34.101.19.

6.2.2 Примечания по ответу

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

Клиенты OCSP ДОЛЖНЫ определять и использовать значение поля id-ad-ocspSigning, как описано выше. Они МОГУТ иметь средства локального конфигурирования серверов OCSP и определения набора УЦ, для которых данные серверы являются авторизованными. Клиенты OCSP ДОЛЖНЫ отклонять ответ, если сертификат, необходимый для проверки подписи ответа, не удовлетворяет ни одному из следующих критериев:

  • соответствует локальной конфигурации авторизованных серверов OCSP для проверяемого сертификата;
  • является сертификатом УЦ, который выпустил проверяемый сертификат;
  • содержит значение id-ad-ocspSigning в расширении ExtendedKeyUsage и выпущен УЦ, который выдал проверяемый сертификат.

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

  • УЦ может указать, что OCSP клиент может доверять OCSP серверу в течение срока действия сертификата OCSP сервера. Данный способ реализуется путем включения расширения id-pkix-ocsp-nocheck. Это расширение СЛЕДУЕТ маркировать как некритическое. Содержимое указанного расширения должно быть определено как NULL. УЦ, выдающие сертификаты с таким расширением, должны понимать, что компрометация ключа OCSP сервера будет столь же серьезна, как и компрометация ключа УЦ, используемого для подписи СОС, по крайней мере на время срока действия выданного сертификата. УЦ следует выдавать сертификаты с указанным расширением на очень короткий срок и часто их обновлять;
  • УЦ может указать способ проверки статуса сертификата сервера OCSP. Это можно сделать с помощью расширения CRLDistributionPoints, если проверка должна проводиться с использованием СОС, или с помощью расширения AuthorityInformationAccess, если проверка проводится каким-либо другим способом. Детально способ указания любого из двух данных механизмов описан в СТБ 34.101.19;
  • УЦ может не указывать способа проверки статуса сертификата OCSP сервера. В этом случае вопрос о том, проводить ли проверку, будет находиться в ведении локальной политики безопасности клиента OCSP.

6.3 Расширения

В настоящем разделе определены некоторые стандартные расширения, основанные на типе Extension, определенном в СТБ 34.101.19. Поддержка любых расширений является необязательной как для клиентов, так и для серверов. Далее для каждого расширения определяется его синтаксис, способ обработки расширения сервером OCSP, а также список расширений, которые включаются в соответствующий ответ сервера.

Тип Extension включает компоненты extnID и extnValue. Компонент extnID имеет тип OBJECT IDENTIFIER и содержит идентификатор расширения. Компонент extnValue имеет тип OCTET STRING и содержит информационную часть расширения.

6.3.1 Привязка запроса к ответу

Расширение с идентификатором id-pkix-ocsp-nonce позволяет сделать криптографическую привязку запроса к ответу для предотвращения атак, основанных на повторе ответов (см. 5.11). Расширение включается в запросы как элемент списка requestExtensions и в ответы как элемент списка responseExtensions. Информационной частью расширения должна быть уникальная строка, общая для запроса и ответа.

6.3.2 Ссылки на список отозванных сертификатов

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

Ссылка на СОС может быть указана с помощью URL (URL, по которому можно найти СОС), номера (номера СОС) или времени (времени, когда был создан соответствующий СОС). Для ссылки на СОС может использоваться расширение с идентификатором id-pkix-ocsp-crl. Информационной частью расширения является кодовое представление значения типа

CrlID ::= SEQUENCE {
  crlUrl        [0]  EXPLICIT IA5String OPTIONAL,
  crlNum        [1]  EXPLICIT INTEGER OPTIONAL,
  crlTime       [2]  EXPLICIT GeneralizedTime OPTIONAL}

В случае первого способа ссылки на СОС в компоненте crlUrl будет указан URL, по которому можно найти СОС. Во втором случае компонент crlNum должен содержать значение расширения «Номер СОС», определенного в СТБ 34.101.19. При выборе третьего способа в компоненте crlTime указывается время, когда был выпущен соответствующий СОС.

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

Клиент OCSP МОЖЕТ принимать только определенные типы ответов. Для указания на принимаемые типы ответов клиенту СЛЕДУЕТ использовать расширение с идентификатором id-pkix-ocsp-response. Данное расширение включается в запрос как элемент списка requestExtensions.

Информационной частью расширения является кодовое представление значения типа AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

Идентификаторы, содержащиеся в AcceptableResponses, являются идентификаторами различных типов ответа, которые может принимать клиент OCSP (например, id-pkix-ocsp-basic).

Как отмечено в 6.2.1, OCSP серверы ДОЛЖНЫ быть способны выдавать ответы типа id-pkix-ocsp-basic. Соответственно, клиенты OCSP ДОЛЖНЫ быть способны получать и обрабатывать ответы типа id-pkix-ocsp-basic.

6.3.4 Архивное хранение

OCSP сервер МОЖЕТ сохранять информацию о статусе и после окончания срока действия сертификата. Дата, полученная путем вычитания интервала хранения из значения поля producedAt, называется «архивной меткой».

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

Серверам OCSP, поддерживающим механизм архивирования, СЛЕДУЕТ включать архивную метку в ответы. Архивную метку СЛЕДУЕТ предоставлять в виде расширения singleExtensions с идентификатором id-pkix-ocsp-archive-cutoff.

Например, пусть сервер работает с семилетним интервалом хранения сертификата в архиве. Пусть статус сертификата был определен в момент времени t. Тогда значение архивной метки в ответе будет составлять (t − 7) лет.

Информационной частью расширения является кодовое представление значения типа

ArchiveCutoff ::= GeneralizedTime

6.3.5 Расширения записей списка отозванных сертификатов

Все расширения, указанные в СТБ 34.101.19 как расширения записей СОС, также поддерживаются OCSP как элементы списка singleExtensions.

6.3.6 Переадресация

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

Для переадресации допускается использовать расширение с идентификатором id-pkix-ocsp-service-locator. Данное расширение включается в запросы как элемент списка singleRequestExtensions. Информационной частью расширения является кодовое представление значения типа

ServiceLocator ::= SEQUENCE {
  issuer        Name,
  locator       AuthorityInfoAccessSyntax OPTIONAL}

Компоненты типа ServiceLocator имеют следующее значение:

  • issuer – имя УЦ, который выпустил проверяемый сертификат;
  • locator – способ доступа к информации УЦ.

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

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

Ключевые слова

В настоящем приложении приведено разъяснение значений ключевых слов «ДОЛЖЕН», «НЕЛЬЗЯ», «БУДЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «МОЖЕТ» и «НЕОБЯЗАТЕЛЬНО», используемых в настоящем стандарте.

Ключевые слова «ДОЛЖЕН» и «БУДЕТ» означают, что действия, к которым применены данные ключевые слова, необходимо в точности выполнять. Ключевое слово «НЕЛЬЗЯ» выражает абсолютный запрет на выполнение соответствующих действий.

Ключевое слово «СЛЕДУЕТ» необходимо понимать так, что в некоторых случаях существует реальная причина их игнорировать, но последствия таких действий должны быть очевидными и хорошо взвешенными.

Ключевое слово «НЕ СЛЕДУЕТ» употребляется в тех случаях, когда действие, к которому применено данное ключевое слово, будет в некоторых случаях правильным и даже полезным, однако при этом его последствия должны быть очевидными и хорошо взвешенными.

Ключевые слова «МОЖЕТ» и «НЕОБЯЗАТЕЛЬНО» применяются к действиям (предметам), выполнение или не выполнение (наличие или отсутствие) которых не влияет на ситуацию в целом. Это означает, что программы, работающие с чем-то, помеченным данными ключевыми словами, должны учитывать обе ситуации и корректно их обрабатывать.

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

Приложение Б (обязательное)

Модуль AСН.1

OCSP {iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)}

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS

AuthorityInfoAccessSyntax, CRLReason, GeneralName

FROM PKIX1Implicit88 {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 
  id-pkix1-implicit(19)}

Name, CertificateSerialNumber, Extensions, id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier

FROM PKIX1Explicit88 {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 
  id-pkix1-explicit(18)}; 

OCSPRequest ::= 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,
  erialNumber                    CertificateSerialNumber
}

OCSPResponse ::= SEQUENCE {
  responseStatus                OCSPResponseStatus,
  responseBytes            [0]  EXPLICIT ResponseBytes OPTIONAL
}

OCSPResponseStatus ::= ENUMERATED {
  successful          (0),
  malformedRequest    (1),
  internalError       (2),
  tryLater            (3),
  sigRequired         (5),
  unauthorized        (6)
}

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

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

ArchiveCutoff ::= GeneralizedTime

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

ServiceLocator ::= SEQUENCE {
  issuer                        Name,
  locator                       AuthorityInfoAccessSyntax
}
  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}
END

Приложение В (обязательное)

Отличительные правила кодирования

Кодирование значений типов АСН.1 по отличительным правилам является базовым, определенным в ГОСТ 34.974, с ограничениями, установленными в настоящем приложении. Формат длины. При кодировании длины должен использоваться явный формат, представленный минимальным числом октетов [ср. с ГОСТ 34.974, пункт 6.3.2, перечисление б)].

Формат кодирования строк. Для типов «строка битов» (BIT STRING), «строка октетов» (OCTET STRING) и «строка знаков» (NumericString, PrintableString и др.) не должны использоваться составные формы [ср. с ГОСТ 34.974, пункт 21.5.4].

Компоненты типа «множество». При кодировании значения типа «множество» (SET) значения его компонентов должны располагаться в каноническом порядке. Канонический порядок определяется самым внешним тегом типа компонента и задается следующими правилами:

  • сначала идут теги универсального класса, затем – теги прикладного класса, затем – теги контекстно-зависимого класса и, наконец, теги пользовательского класса (см. ГОСТ 34.973, подраздел 5.8);
  • внутри класса элементы упорядочиваются по возрастанию номеров их тегов.

Примечание – Когда компонент типа «множество» является нетегированным выборочным типом, порядок расположения компонента зависит от тега кодируемого выборочного компонента.

You can’t perform that action at this time.