СТБ 34.101.26-2012
Информационные технологии и безопасность
ОНЛАЙНОВЫЙ ПРОТОКОЛ ПРОВЕРКИ СТАТУСА СЕРТИФИКАТА (OCSP)
Інфармацыйныя тэхналогіі і бяспека
АНЛАЙНАВЫ ПРАТАКОЛ ПРАВЕРКI СТАТУСА СЕРТЫФІКАТА (OCSP)
Information technology and security
Online certificate status protocol (OCSP)
3 Термины и определения, обозначения
6 Онлайновый протокол проверки статуса сертификата
Приложение А (справочное) Ключевые слова
Приложение Б (обязательное) Модуль AСН.1
Приложение В (обязательное) Отличительные правила кодирования
Настоящий стандарт устанавливает требования к онлайновому протоколу проверки статуса сертификата инфраструктуры открытых ключей. Стандарт определяет форматы сообщений, которыми обмениваются взаимодействующие стороны, и их действия в рамках протокола.
Настоящий стандарт предназначен для применения при разработке, испытаниях и эксплуатации систем управления открытыми ключами.
В настоящем стандарте использованы ссылки на следующие технические нормативные правовые акты в области технического нормирования и стандартизации (далее – ТНПА):
СТБ 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 января текущего года, и по соответствующим информационным указателям, опубликованным в текущем году. Если ссылочные ТНПА заменены (изменены), то при пользовании настоящим стандартом следует руководствоваться замененными (измененными) ТНПА. Если ссылочные ТНПА отменены без замены, то положение, в котором дана ссылка на них, применяется в части, не затрагивающей эту ссылку.
В настоящем стандарте применяют термины, установленные в СТБ 34.101.19, а также следующие термины с соответствующими определениями:
3.1 OCSP сервер, сервер OCSP: Сторона, предоставляющая онлайновую услугу проверки статуса сертификата.
3.2 OCSP клиент, клиент OCSP: Сторона, запрашивающая проверку сертификата.
Ключевые слова «ДОЛЖЕН», «НЕЛЬЗЯ», «БУДЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «МОЖЕТ» и «НЕОБЯЗАТЕЛЬНО» в настоящем стандарте (выделенные прописными буквами) должны интерпретироваться, как это описано в приложении A.
В настоящем стандарте применяют следующие сокращения:
АСН.1 – абстрактно-синтаксическая нотация версии 1;
СОС – список отозванных сертификатов;
УЦ – удостоверяющий центр;
ЭЦП – электронная цифровая подпись;
OCSP – online certificate status protocol – онлайновый протокол проверки статуса сертификата.
В СТБ 34.101.19 для проверки статуса сертификата используются периодически обновляемые СОС. Вместе с проверкой СОС или в дополнение к ней может использоваться OCSP.
OCSP позволяет приложениям определять состояние заданного сертификата. С помощью OCSP можно получить своевременную и более полную информацию о статусе сертификата, чем с помощью СОС. Поэтому OCSP может использоваться для выполнения ряда функциональных требований к приложениям.
OCSP клиент посылает запрос о статусе OCSP серверу и приостанвливает обработку проверяемого сертификата, пока не будет получен ответ.
Запрос OCSP содержит следующие данные:
- версию протокола;
- имя OCSP клиента (НЕОБЯЗАТЕЛЬНО);
- список идентификаторов проверяемых сертификатов;
- необязательные расширения, которые МОГУТ обрабатываться сервером OCSP.
После получения запроса OCSP сервер должен проверить, что:
- запрос сформирован правильно;
- OCSP сервер настроен для предоставления запрашиваемых услуг;
- запрос содержит всю необходимую информацию.
Если любое из перечисленных выше условий не соблюдается, OCSP сервер выдает сообщение об ошибке; в противном случае он возвращает ответ.
OCSP сервер может возвращать ответы различных типов. Ответ OCSP сервера состоит из типа ответа и собственно ответа. Существует один основной тип ответа, который ДОЛЖЕН поддерживаться всеми серверами и клиентами OCSP. В настоящем разделе рассматривается только данный тип ответа.
Все ответы ДОЛЖНЫ содержать ЭЦП. Ключ, на котором подписывается ответ, ДОЛЖЕН принадлежать одной из следующих сторон:
- УЦ, выдавшему проверяемый сертификат;
- доверенному OCSP серверу, открытый ключ которого OCSP клиент признает действительным;
- назначенному УЦ OCSP серверу (авторизованному серверу), который владеет специально отмеченным сертификатом, напрямую выданным УЦ и указывающим на то, что данный сервер может выдавать ответы OCSP для всех сертификатов, выпускаемых данным УЦ.
Ответ OCSP состоит из:
- версии синтаксиса ответа;
- названия OCSP сервера;
- ответов по каждому проверяемому сертификату;
- необязательных расширений;
- идентификатора используемого алгоритма ЭЦП;
- ЭЦП хэш-значения ответа.
Ответ по каждому проверяемому сертификату состоит из:
- идентификатора сертификата;
- статуса сертификата;
- срока действия ответа;
- необязательных расширений.
В настоящем стандарте определяются следующие значения компонента «статус сертификата»:
good
(действующий);revoked
(отозванный);unknown
(неизвестный).
Значение good
означает положительный ответ на запрос о статусе сертификата.
Данный ответ означает, что сертификат не отозван, но не означает, что сертификат
когда-либо выдавался или что время, в которое был дан ответ, находится в
пределах срока действия сертификата.
Значение revoked
означает, что сертификат был отозван навсегда или что его
действие было временно приостановлено.
Значение unknown
означает, что серверу ничего не известно про запрашиваемый
сертификат.
Расширения могут использоваться OCSP сервером для указания дополнительной информации о сертификате, например подтверждения выпуска сертификата, его действительности и т. д.
В случае возникновения ошибок сервер OCSP может возвратить сообщение об ошибке. Такие сообщения не подписываются. Ошибки могут быть следующих типов:
malformedRequest
;internalError
;tryLater
;sigRequired
;unauthorized
.
Сервер выдает ответ malformedRequest
, если синтаксис полученного запроса не
соответствует синтаксису OCSP.
Ответ internalError
означает, что возникло недопустимое внутреннее состояние
сервера OCSP. Запрос следует повторить, возможно, через другой сервер.
В случае, если сервер OCSP находится в рабочем состоянии, но временно не может
предоставить информацию о статусе запрошенного сертификата, используется ответ
tryLater
.
Ответ sigRequired
используется тогда, когда для получения информации о статусе
сертификата требуется, чтобы запрос был подписан клиентом.
Ответ unauthorized
означает, что клиент не имеет полномочий делать запрос на
данный сервер OCSP.
Ответ может содержать три метки времени:
thisUpdate
– время, когда точно известно, что текущий статус сертификата верен;nextUpdate
– время, когда будет доступна новая информация о статусе сертификата;producedAt
– время, когда сервер OCSP подписал данный ответ.
Если значение компонента nextUpdate
не задано, это означает, что информация о
статусе сертификата постоянно обновляется.
OCSP серверы МОГУТ заранее выдавать подписанные ответы, содержащие информацию о
статусе сертификатов в определенное время. Время, когда был точно известен
статус сертификата, БУДЕТ отражаться в компоненте ответа thisUpdate
. Время,
когда будет доступна новая информация о статусе сертификата, отражается в
компоненте nextUpdate
. Время, когда был создан ответ, указывается в компоненте
ответа producedAt
.
Ключ, с помощью которого подписывается ответ, необязательно должен быть
тем же ключом, которым подписан сертификат. Эмитент сертификата явно
делегирует OCSP серверу право подписи, выдавая ему сертификат, содержащий
уникальное значение компонента extendedKeyUsage
. Данный сертификат
ДОЛЖЕН напрямую выдаваться серверу OCSP компетентным УЦ.
Если серверу OCSP становится известно о том, что личный ключ некоторого УЦ был скомпрометирован, он МОЖЕТ сообщать об отозванном состоянии всех сертификатов, выданных данным УЦ.
Сообщения протокола задаются типами АСН.1. Модуль АСН.1, определяющий эти типы, – в соответствии с приложением Б.
Для формирования электронной формы сообщения или некоторых его компонентов значения типов АСН.1 кодируются. В результате кодирования формируется последовательность октетов, которую можно передавать, подписывать и т. д. В ГОСТ 34.974 определены базовые правила кодирования. В приложении B установлены отличительные правила кодирования, которые уточняют базовые правила и обеспечивают однозначность кодового представления.
Чтобы предоставить клиентам доступ к серверу OCSP, УЦ ДОЛЖНЫ поддерживать
возможность включения расширения AuthorityInfoAccess
(определено в СТБ
34.101.19) в сертификаты, которые могут быть проверены с помощью OCSP. В
качестве альтернативы, для доступа к OCSP серверу клиент может локально
настроить компонент accessLocation
данного расширения.
УЦ, который поддерживает OCSP (непосредственно или через авторизованный сервер),
должен обеспечить включение значений uniformResourceIndicator
(URI) для
компонента accessLocation
. Данный УЦ должен также обеспечить включение
идентификатора id-ad-ocsp
для компонента accessMethod
в AccessDescription
расширения AuthorityInfoAccess
.
Значение компонента accessLocation
определяет средство (например, протокол
HTTP) получения доступа к серверу OCSP и может содержать дополнительную
информацию о нем (например, адреса ресурсов в сети Интернет – URL).
Прежде чем принять подписанный ответ, OCSP клиенты ДОЛЖНЫ убедиться в том, что:
- сертификат, указанный в полученном ответе, соответствует сертификату, указанному в запросе;
- ЭЦП в ответе действительна;
- подписывающая сторона является предполагаемым получателем запроса;
- подписывающая сторона в настоящее время уполномочена подписывать ответ;
- с момента, когда был точно известен статус сертификата (компонент
thisUpdate
), прошло относительно немного времени; - если известно время, когда информация о статусе сертификата обновится
(компонент
nextUpdate
), следует убедиться, что оно еще не наступило.
При настройке и использовании OCSP следует учитывать указанные ниже аспекты безопасности.
Протокол OCSP может использоваться только при наличии соединения с OCSP сервером. В системах управления открытыми ключами при угрозе отсутствия соединения следует предусмотреть резервный переход к СОС.
OCSP уязвим к атакам типа «отказ в обслуживании». Во-первых, большой поток запросов может привести к неработоспособности сервера, поскольку ответы требуется подписывать, а выработка ЭЦП является достаточно трудоемкой вычислительной операцией. Во-вторых, сообщения об ошибках не подписываются, и злоумышленник может загрузить клиентов фальшивыми сообщениями.
Использование предварительно рассчитанных ответов позволяет проводить атаки по
повтору ответов. В ходе таких атак старые ответы со статусом good
повторяются
вплоть до окончания их срока действия, но уже после истечения срока действия
целевых сертификатов. При вводе в действие серверов OCSP необходимо тщательно
оценить преимущества использования предварительно рассчитанных ответов
относительно возможности осуществления повторных атак и потерь при их успешном
проведении.
Запросы не содержат информации об OCSP сервере, на который они направляются. Это позволяет злоумышленнику направить запрос на любое количество серверов OCSP.
Запрос 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.3 определяется несколько расширений. Другие расширения МОГУТ определяться в дополнительных стандартах. Нераспознанные расширения ДОЛЖНЫ игнорироваться (если только они не являются критическими).
Клиент OCSP МОЖЕТ подписать запрос. В этом случае ЭЦП рассчитывается от
структуры tbsRequest
и помещается в компонент Signature
. Если запрос
подписан, то OCSP клиент ДОЛЖЕН указать свое имя в компоненте requestorName
.
Клиент также может включать в запрос сертификаты, которые помогут OCSP серверу
проверить ЭЦП, расположенную в компоненте Signature
.
Ответ 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.
Ключ, на котором подписывается ответ, не обязательно должен совпадать с ключом,
на котором подписан сертификат. Однако необходимо убедиться в том, что сторона,
подписывающая ответы, уполномочена это делать. Следовательно, эмитент
сертификатов ДОЛЖЕН или подписывать ответы OCSP самостоятельно, или ДОЛЖЕН явно
делегировать данные полномочия другой стороне. Делегирование права подписи
ответов OCSP ДОЛЖНО реализовываться путем включения значения идентификатора
id-kp-OCSPSigning
в расширение сертификата extendedKeyUsage
, которое, в
свою очередь, должно содержаться в сертификате OCSP сервера. Данный сертификат
ДОЛЖЕН выдаваться напрямую УЦ, который выпустил проверяемый сертификат.
Клиенты OCSP ДОЛЖНЫ определять и использовать значение поля id-kp-ocspSigning
,
как описано выше. Они МОГУТ иметь средства локального конфигурирования серверов
OCSP и определения набора УЦ, для которых данные серверы являются
авторизованными. Клиенты OCSP ДОЛЖНЫ отклонять ответ, если сертификат,
необходимый для проверки подписи ответа, не удовлетворяет ни одному из следующих
критериев:
- соответствует локальной конфигурации авторизованных серверов OCSP для проверяемого сертификата;
- является сертификатом УЦ, который выпустил проверяемый сертификат;
- содержит значение
id-kp-ocspSigning
в расширенииExtendedKeyUsage
и выпущен УЦ, который выдал проверяемый сертификат.
Так как авторизованный OCSP сервер предоставляет информацию о статусе одного или более УЦ, клиентам OCSP необходимо знать, как проверить, не отозван ли сертификат этого сервера. УЦ может обеспечить эту проверку тремя способами:
- УЦ может указать, что OCSP клиент может доверять OCSP серверу в течение срока
действия сертификата OCSP сервера. Данный способ реализуется путем включения
расширения
id-pkix-ocsp-nocheck
. Это расширение СЛЕДУЕТ маркировать как некритическое. Содержимое указанного расширения должно быть определено как NULL. УЦ, выдающие сертификаты с таким расширением, должны понимать, что компрометация ключа OCSP сервера будет столь же серьезна, как и компрометация ключа УЦ, используемого для подписи СОС, по крайней мере на время срока действия выданного сертификата. УЦ следует выдавать сертификаты с указанным расширением на очень короткий срок и часто их обновлять; - УЦ может указать способ проверки статуса сертификата сервера OCSP. Это можно
сделать с помощью расширения
CRLDistributionPoints
, если проверка должна проводиться с использованием СОС, или с помощью расширенияAuthorityInformationAccess
, если проверка проводится каким-либо другим способом. Детально способ указания любого из двух данных механизмов описан в СТБ 34.101.19; - УЦ может не указывать способа проверки статуса сертификата OCSP сервера. В этом случае вопрос о том, проводить ли проверку, будет находиться в ведении локальной политики безопасности клиента OCSP.
В настоящем разделе определены некоторые стандартные расширения, основанные на
типе Extension
, определенном в СТБ 34.101.19. Поддержка любых расширений
является необязательной как для клиентов, так и для серверов. Далее для каждого
расширения определяется его синтаксис, способ обработки расширения сервером
OCSP, а также список расширений, которые включаются в соответствующий ответ
сервера.
Тип Extension
включает компоненты extnID
и extnValue
. Компонент extnID
имеет тип OBJECT IDENTIFIER
и содержит идентификатор расширения. Компонент
extnValue
имеет тип OCTET STRING
и содержит информационную часть расширения.
Расширение с идентификатором id-pkix-ocsp-nonce
позволяет сделать
криптографическую привязку запроса к ответу для предотвращения атак, основанных
на повторе ответов (см. 5.11). Расширение включается в запросы как
элемент списка requestExtensions
и в ответы как элемент списка
responseExtensions
. Информационной частью расширения должна быть уникальная
строка, общая для запроса и ответа.
Может потребоваться, чтобы 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
указывается время, когда был
выпущен соответствующий СОС.
Клиент 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
.
OCSP сервер МОЖЕТ сохранять информацию о статусе и после окончания срока
действия сертификата. Дата, полученная путем вычитания интервала хранения
из значения поля producedAt
, называется «архивной меткой».
Приложения, взаимодействующие с сервером OCSP, используют архивную метку для проверки того, была (или не была) верной ЭЦП в момент ее создания, даже если срок действия сертификата, необходимого для подтверждения подписи, истек.
Серверам OCSP, поддерживающим механизм архивирования, СЛЕДУЕТ включать
архивную метку в ответы. Архивную метку СЛЕДУЕТ предоставлять в виде
расширения singleExtensions
с идентификатором
id-pkix-ocsp-archive-cutoff
.
Например, пусть сервер работает с семилетним интервалом хранения сертификата в архиве. Пусть статус сертификата был определен в момент времени t. Тогда значение архивной метки в ответе будет составлять (t − 7) лет.
Информационной частью расширения является кодовое представление значения типа
ArchiveCutoff ::= GeneralizedTime
Все расширения, указанные в СТБ 34.101.19 как расширения записей СОС,
также поддерживаются OCSP как элементы списка singleExtensions
.
Сервер OCSP может работать в режиме переадресации. В этом режиме сервер получает запрос и перенаправляет его на другой сервер OCSP, наделенный полномочиями по отношению к проверяемому сертификату.
Для переадресации допускается использовать расширение с идентификатором
id-pkix-ocsp-service-locator
. Данное расширение включается в запросы как
элемент списка singleRequestExtensions
. Информационной частью расширения
является кодовое представление значения типа
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax OPTIONAL}
Компоненты типа ServiceLocator
имеют следующее значение:
issuer
– имя УЦ, который выпустил проверяемый сертификат;locator
– способ доступа к информации УЦ.
Значения компонентов должны устанавливаться по значениям соответствующих компонентов из проверяемого сертификата.
В настоящем приложении приведено разъяснение значений ключевых слов «ДОЛЖЕН», «НЕЛЬЗЯ», «БУДЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «МОЖЕТ» и «НЕОБЯЗАТЕЛЬНО», используемых в настоящем стандарте.
Ключевые слова «ДОЛЖЕН» и «БУДЕТ» означают, что действия, к которым применены данные ключевые слова, необходимо в точности выполнять. Ключевое слово «НЕЛЬЗЯ» выражает абсолютный запрет на выполнение соответствующих действий.
Ключевое слово «СЛЕДУЕТ» необходимо понимать так, что в некоторых случаях существует реальная причина их игнорировать, но последствия таких действий должны быть очевидными и хорошо взвешенными.
Ключевое слово «НЕ СЛЕДУЕТ» употребляется в тех случаях, когда действие, к которому применено данное ключевое слово, будет в некоторых случаях правильным и даже полезным, однако при этом его последствия должны быть очевидными и хорошо взвешенными.
Ключевые слова «МОЖЕТ» и «НЕОБЯЗАТЕЛЬНО» применяются к действиям (предметам), выполнение или не выполнение (наличие или отсутствие) которых не влияет на ситуацию в целом. Это означает, что программы, работающие с чем-то, помеченным данными ключевыми словами, должны учитывать обе ситуации и корректно их обрабатывать.
Данные ключевые слова введены в первую очередь для определения требований к действиям, которые влияют на безопасность и надежность рассматриваемых объектов, а также в интересах их унификации.
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);
- внутри класса элементы упорядочиваются по возрастанию номеров их тегов.
Примечание – Когда компонент типа «множество» является нетегированным выборочным типом, порядок расположения компонента зависит от тега кодируемого выборочного компонента.