СТБ 34.101.81-2019
Информационные технологии и безопасность
ПРОТОКОЛЫ СЛУЖБЫ ЗАВЕРЕНИЯ ДАННЫХ
Інфармацыйныя тэхналогіі і бяспека
ПРАТАКОЛЫ СЛУЖБЫ ЗАВЯРЭННЯ ДАНЫХ
Information technology and security
Data validation and certification server protocols
Настоящий стандарт устанавливает протоколы службы заверения данных, с помощью которых удостоверяются факты владения данными, существования данных, действительности электронных документов и сертификатов открытых ключей. Стандарт определяет форматы запроса к службе и соответствующего ответа, правила создания и обработки запроса и ответа.
Настоящий стандарт применяется при разработке, испытаниях и эксплуатации средств и систем криптографической защиты информации, используемых в инфраструктурах открытых ключей.
В настоящем стандарте использованы ссылки на следующие технические нормативные правовые акты в области технического нормирования и стандартизации (далее – ТНПА):
СТБ 34.101.17-2012 Информационные технологии и безопасность. Синтаксис запроса на получение сертификата
СТБ 34.101.19-2012 Информационные технологии и безопасность. Форматы сертификатов и списков отозванных сертификатов инфраструктуры открытых ключей
СТБ 34.101.23-2012 Информационные технологии и безопасность. Синтаксис криптографических сообщений
СТБ 34.101.26-2012 Информационные технологии и безопасность. Онлайновый протокол проверки статуса сертификата (OCSP)
СТБ 34.101.27-2011 Информационные технологии и безопасность. Требования безопасности к программным средствам криптографической защиты информации
СТБ 34.101.45-2013 Информационные технологии и безопасность. Алгоритмы электронной цифровой подписи и транспорта ключа на основе эллиптических кривых
СТБ 34.101.65-2014 Информационные технологии и безопасность. Протокол защиты транспортного уровня (TLS)
СТБ 34.101.80-2019 Информационные технологии и безопасность. Расширенные электронные цифровые подписи
СТБ 34.101.82-2019 Информационные технологии и безопасность. Протокол постановки штампа времени
ГОСТ 34.973-91 (ИСО 8824-87) Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)
ГОСТ 34.974-91 (ИСО 8825-87) Информационная технология. Взаимосвязь открытых систем. Описание базовых правил кодирования для абстрактно-синтаксической нотации версии 1 (АСН.1)
Примечание – При пользовании настоящим стандартом целесообразно проверить действие ТНПА по каталогу, составленному по состоянию на 1 января текущего года, и по соответствующим информационным указателям, опубликованным в текущем году. Если ссылочные ТНПА заменены (изменены), то при пользовании настоящим стандартом следует руководствоваться действующими взамен ТНПА. Если ссылочные ТНПА отменены без замены, то положение, в котором дана ссылка на них, применяется в части, не затрагивающей эту ссылку.
В настоящем стандарте применяют термины, установленные в СТБ 34.101.19, СТБ 34.101.23, СТБ 34.101.26, СТБ 34.101.45, СТБ 34.101.80, СТБ 34.101.82, ГОСТ 34.973, а также следующие термины с соответствующими определениями:
3.1 аттестат заверения (data validation certificate): Данные, которые удостоверяют факты относительно других данных, например, их существование к определенному моменту времени или действительность.
3.2 действительность (данных): Целостность, подлинность, актуальность и корректность.
3.3 служба заверения данных (data validation and certification server): Поставщик услуг доверия, который подтверждает факты владения данными, существования данных, действительности электронных документов и сертификатов открытых ключей, выпуская аттестаты заверения.
В настоящем стандарте применяют следующие сокращения:
АСН.1 – абстрактно-синтаксическая нотация версии 1 (см. ГОСТ 34.973);
СЗД – служба заверения данных;
СОК – сертификат открытого ключа (см. СТБ 34.101.19);
ЭД – электронный документ;
ЭЦП – электронная цифровая подпись;
OCSP – онлайновый протокол проверки статуса сертификата (см. СТБ 34.101.26).
Для определения типов АСН.1 применяют обозначения, заданные в ГОСТ 34.973.
Ключевое слово «ДОЛЖЕН» означает, что действия, к которым применены данные ключевые слова, необходимо в точности выполнять. Ключевое слово «НЕ ДОЛЖЕН» выражает абсолютный запрет на выполнение соответствующих действий. Ключевые слова «СЛЕДУЕТ» и «РЕКОМЕНДУЕТСЯ» необходимо понимать так, что в некоторых случаях существует реальная причина их игнорировать, но последствия таких действий должны быть очевидными и хорошо взвешенными. Ключевое слово «НЕ СЛЕДУЕТ» применяется в тех случаях, когда действие, к которому применено данное ключевое слово, будет в некоторых случаях правильным и даже полезным, однако при этом его последствия должны быть очевидными и хорошо взвешенными. Ключевые слова «МОЖЕТ» и «НЕОБЯЗАТЕЛЬНО» применяются к действиям (предметам), выполнение или невыполнение (наличие или отсутствие) которых не влияет на ситуацию в целом. Это означает, что программы, работающие с чем-то, помеченным данными ключевыми словами, должны учитывать обе ситуации и корректно их обрабатывать.
Настоящий стандарт определяет протоколы СЗД, с помощью которых можно удостоверить факты владения данными, существования данных, действительности электронных документов и СОК. Стандарт основан на документе [1]. Форматы сообщений протоколов определяются на языке АСН.1, установленном в ГОСТ 34.973. Модуль АСН.1 сообщений протокола приводится в приложении А.
СЗД является поставщиком услуг доверия. Служба получает запрос на проверку определенного факта относительно определенных данных, проводит проверку и, в случае успеха, выпускает аттестат заверения. Аттестат представляет собой ЭД, подписанный службой. Проверив аттестат, можно удостовериться в справедливости запрошенного факта при условии доверия службе. Важно, что проверка аттестатов заверения конкретной службы обычно проще, чем самостоятельная проверка заверяемых фактов.
Могут заверяться факты владения данными и существования данных. В этом случае проверка данных не проводится, они или их хэш-значения просто фиксируются в аттестате. Выпуск аттестата можно использовать как юридически значимый механизм опубликования данных. Аттестат содержит отметку времени, поэтому речь идет о владении или существовании к определенному моменту. После выпуска аттестата от заверенного факта отказаться будет нельзя.
Может заверяться факт действительности ЭД или СОК. Факт фиксируется на момент времени, указанный в аттестате. При сохранении действительности аттестата этот факт будет сохранять актуальность даже после того, как сертификат подписанта документа или заверенный сертификат будут отозваны или закончатся сроки их действия. Важно, что СЗД может проверить свой или чужой аттестат заверения точно так же, как другие ЭД.
Инфраструктура открытых ключей характеризуется списком точек доверия, перечнем допустимых криптографических алгоритмов, набором расширений сертификатов и прочими ограничениями. СЗД может проверять действительность ЭД и СОК в одной инфраструктуре и выпускать аттестат заверения в другой. Для проверки аттестата не нужно иметь доступ к первой инфраструктуре и, таким образом, СЗД позволяет организовать взаимодействие между сторонами (центрами, службами, пользователями) инфраструктур, выступая в роли посредника между ними.
Служба заверения данных частично дублирует функции OCSP-сервера, который заверяет действительность СОК (см. СТБ 34.101.26), и службы штампов времени, которая заверяет существование данных (см. СТБ 34.101.82). OCSP-сервер и служба штампов времени лучше масштабируются, поэтому при проектировании инфраструктуры открытых ключей им следует отдавать предпочтение перед СЗД.
СЗД реализует, по крайней мере, один из следующих сервисов:
- заверение факта владения данными (от англ. Certificate of Possession of Data; cpd);
- заверение факта существования данных (Ceritification of Claim of Possession of Data; ccpd);
- проверка действительности ЭД (Validation of Signed Document; vsd);
- проверка действительности СОК (Validation of Public Key Certificate; vpkc).
Каждый из сервисов возвращает либо аттестат заверения, либо сообщение об ошибке. Возврат аттестата заверения не обязательно означает подтверждение запрошенного факта. Аттестат содержит вердикт проверки, и этот вердикт может быть отрицательным.
Сервис заверения факта владения данными удостоверяет, что сторона, которая обратилась с запросом, располагала указанными в аттестате данными к указанному в аттестате моменту времени. Доказательством владения является предъявление данных в самом запросе.
Сервис заверения факта существования данных удостоверяет, что данные, хэш-значение которых указано в аттестате, существовали к моменту времени, также указанному в аттестате. Сами данные в аттестате не фиксируются. Они предъявляются вне рамок взаимодействия со службой вместе с аттестатом, выпущенным службой. Хэш-значение предъявленных данных сравнивается с хэш-значением в аттестате. Аттестат заверения факта существования является альтернативной формой штампов времени, определенных в СТБ 34.101.82.
Сервис проверки действительности ЭД проверяет все ЭЦП, которыми подписан документ. При проверке используются долговременные параметры и открытые ключи, которые извлекаются из сертификатов подписантов. Действительность сертификатов также проверяется. Недействительность одной из подписей не обязательно означает недействительность всего документа. И, наоборот, документ может быть признан недействительным, если в нем недостает определенных подписей. Точная логика проверки определяется политикой СЗД. Может поддерживаться проверка документов только определенного вида (формата).
Сервис проверки действительности СОК применяется для подтверждения действительности одного или нескольких СОК в указанный момент времени. Проверка выполняется в соответствии с требованиями СТБ 34.101.19.
Протоколы СЗД описывают обращения клиентов к сервисам службы. В каждом из протоколов клиент готовит запрос на заверение, пересылает его СЗД и в ответ получает либо аттестат заверения, либо сообщение об ошибке. СЗД может вернуть несколько аттестатов в ответ на один запрос. После получения аттестата клиент проверяет его и, если все проверки прошли успешно, принимает аттестат в качестве удостоверения запрошенного факта.
Для обеспечения конфиденциальности, контроля целостности и подлинности запрос и ответ могут защищаться, например, инкапсулироваться в контейнеры CMS (см. СТБ 34.101.23) или передаваться по TLS-соединению (см. СТБ 34.101.65).
Транспорт данных между клиентом и СЗД может осуществляться различными способами. Более того, запрос может передаваться одним способом (например, через браузер), а ответ – другим (например, по электронной почте).
При транспорте с помощью протоколов HTTP/HTTPS запросы и ответы СЛЕДУЕТ
кодировать по правилам, установленным в ГОСТ 34.974, с уточнениями, заданными в
СТБ 34.101.19 (приложение Б.1). Кодовые представления запроса и ответа СЛЕДУЕТ
инкапсулировать в простые объекты MIME [2], заголовки Content-Type
и Content-Transfer-Encoding которых принимают соответственно значения
application/dvcs и binary. При транспорте по электронной почте правила
сохраняются, снимаются только ограничения на заголовок
Content-Transfer-Encoding.
Требования к сторонам протоколов определяются в разделе 6, форматы запроса и ответа – в разделе 7.
6.1 СЗД ДОЛЖНА обрабатывать запросы на заверение, выпуская аттестаты заверения или выдавая сообщение об ошибке. Служба ДОЛЖНА указывать в аттестате заверенные факты или, если факты не подтвердились, сообщить о причине отказа от заверения.
6.2 СЗД ДОЛЖНА определить и применять политику заверения данных. Политика устанавливает перечень данных, которые включаются в аттестат (например, сертификаты, списки отозванных сертификатов, ответы OCSP-серверов или других СЗД). Политика ДОЛЖНА дополнительно определять, следует ли СЗД проверять отметки времени в запросах на заверение. Службе СЛЕДУЕТ включать в выпускаемый аттестат идентификатор применяемой политики.
6.3 СЗД ДОЛЖНА нумеровать аттестаты заверения, используя монотонно возрастающий серийный номер. Выпускаемый аттестат ДОЛЖЕН включать текущее значение серийного номера.
6.4 СЗД ДОЛЖНА включать в выпускаемый аттестат отметку или штамп времени. Перед использованием штампа времени СЗД ДОЛЖНА его проверить по правилам СТБ 34.101.80.
6.5 СЗД ДОЛЖНА подписывать аттестаты с помощью средства ЭЦП, удовлетворяющего требованиям СТБ 34.101.27.
6.6 Для личного ключа СЗД, который используется для подписи аттестатов, ДОЛЖЕН быть выпущен соответствующий СОК.
6.7 Аттестат заверения ДОЛЖЕН содержать ссылку на СОК СЗД. Ссылка ДОЛЖНА
представляться значением типа ESSCertIDv2 в подписанном атрибуте
SigningCertificateV2 (атрибут определен в СТБ 34.101.80). При формировании
ссылки ДОЛЖЕН использоваться алгоритм хэширования, определенный в действующем
ТНПА. Если атрибут SigningCertificateV2 содержит несколько ссылок на
сертификаты, то ссылка на СОК СЗД ДОЛЖНА быть первой из них.
6.8 В расширении KeyUsage СОК СЗД (см. СТБ 34.101.19 (пункт 6.2.1.3)) ДОЛЖНЫ
быть установлены флаги digitalSignature и nonRepudiation.
6.9 СОК СЗД ДОЛЖЕН включать расширение ExtKeyUsageSyntax (см. СТБ 34.101.19
(пункт 6.2.1.12)), это расширение ДОЛЖНО быть критическим и в нем ДОЛЖЕН быть
указан идентификатор
id-kp-dvcs OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) 10}
6.10 СОК СЗД МОЖЕТ включать расширение AuthorityInfoAccessSyntax (см. СТБ
34.101.19 (пункт 6.2.11.2)), с помощью которого можно получить информацию о
доступе к службе. Компонент accessMethod этого расширения ДОЛЖЕН принимать
значение
id-mod-dvcs OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 15}
6.11 Перед выпуском аттестата СЗД ДОЛЖНА проверять действительность собственного СОК. В случае ошибки выпуск аттестата ДОЛЖЕН быть отменен.
6.12 СЗД ДОЛЖНА проверять действительность своего и заверяемых СОК по правилам СТБ 34.101.19.
6.13 Служба ДОЛЖНА проверять действительность ЭД, сопровождаемых расширенной электронной цифровой подписью, по правилам СТБ 34.101.80.
6.14 Клиенту, обратившемуся к СЗД с запросом на заверение, СЛЕДУЕТ проверить корректность полученного аттестата: приемлемо ли указанное время выпуска, верно ли задано имя СЗД, соответствует ли аттестат запросу, все ли требуемые компоненты включены в аттестат.
6.15 Клиенту, обратившемуся к СЗД с запросом на заверение, СЛЕДУЕТ проверить подпись полученного аттестата, в том числе действительность СОК СЗД. Проверка ДОЛЖНА выполняться по правилам СТБ 34.101.80.
Тип DigestInfo описывает хэш-значение. Тип определяется следующим образом:
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest }
Digest ::= OCTET STRING
Компонент digestAlgorithm идентифицирует используемый алгоритм хэширования и
его параметры. Компонент digest задает непосредственно хэш-значение.
Тип DVCSTime описывает отметку времени. Тип определяется следующим образом:
DVCSTime ::= CHOICE {
genTime GeneralizedTime,
timeStampToken ContentInfo }
При выборе компонента genTime отметка времени задается стандартным типом
GeneralizedTime, определенным в ГОСТ 34.973. В отметке ДОЛЖНЫ допускаться доли
секунд.
При выборе компонента timeStampToken отметка задается штампом времени ‒
обычным, определенным в СТБ 34.101.82, или в форме аттестата заверения.
Тип ContentInfo определен в СТБ 34.101.23. Идентификатор contentType,
вложенный в ContentInfo, должен принимать значение id-signedData,
определенное в СТБ 34.101.23, а компонент content – непосредственно штамп
или аттестат.
Примечание – Отметки времени в последовательных аттестатах, выдаваемых СЗД, не могут убывать, но могут повторяться. Для точной идентификации аттестатов следует использовать не отметки времени, а серийные номера.
Тип PKIStatusInfo описывает результат проверки, выполненной СЗД. Тип
определен в СТБ 34.101.82. Тип содержит компоненты status (вердикт),
statusString (вердикт в удобной для восприятия форме), failInfo
(информация о причинах ошибки).
Вердикты granted и grantedWithMods в компоненте status означают, что
проверка прошла успешно, вердикт rejection – c ошибкой, вердикт
waiting – проверка не завершена.
Тип PathProcInput описывает политики и отображения политик, которые
используются при проверке заверяемых фактов. Тип определяется следующим
образом:
PathProcInput ::= SEQUENCE {
acceptablePolicySet SEQUENCE SIZE (1..MAX) OF PolicyInformation,
inhibitPolicyMapping BOOLEAN DEFAULT FALSE,
explicitPolicyReqd BOOLEAN DEFAULT FALSE }
Компонент acceptablePolicySet задает перечень допустимых политик и
отображений политик, которые клиент предлагает использовать СЗД или
которые были использованы службой. Тип PolicyInformation определен в СТБ
34.101.19.
Компоненты inhibitPolicyMapping и explicitPolicyReqd задают
соответственно входные параметры initial-policy-mapping-inhibit и
initial-explicit-policy процедуры проверки маршрута сертификации,
определенной в СТБ 34.101.19.
Тип CertEtcToken описывает аттестат, который требуется проверить или
который уже проверен, и результат проверки. Тип определяется следующим
образом:
CertEtcToken ::= CHOICE {
certificate [0] IMPLICIT Certificate,
esscertid [1] ESSCertIDv2,
pkistatus [2] IMPLICIT PKIStatusInfo,
assertion [3] ContentInfo,
crl [4] IMPLICIT CertificateList,
ocspcertstatus [5] IMPLICIT CertStatus,
ocspcertid [6] IMPLICIT CertId,
ocspresponse [7] IMPLICIT OCSPResponse,
capabilities [8] SMIMECapabilities,
extension Extension }
Компонент certificate задает сертификат, а компоненты esscertid,
ocspcertid – ссылки на него. Типы Certificate, ESSCertIDv2 и CertId
определены в СТБ 34.101.19, СТБ 34.101.80 и СТБ 34.101.26 соответственно.
Компонент assertion задает аттестат заверения, штамп времени или любой другой
аттестат, который представляется типом ContentInfo.
Компонент ocspresponse задает OCSP-ответ. Тип OCSPResponse определен в СТБ
34.101.26.
Компонент crl задает список отозванных сертификатов. Тип CertificateList
определен в СТБ 34.101.19.
Компоненты pkistatus и ocspcertstatus задают результат проверки. Тип
CertStatus определен в СТБ 34.101.26.
Компоненты capabilities и extension НЕ ДОЛЖНЫ использоваться. Они приведены
в определении типа только для сохранения совместимости с [1].
Тип TargetEtcChain описывает сертификат, который требуется проверить или
который уже проверен, сопутствующие аттестаты, результаты проверки, политики
проверки. Тип определяется следующим образом:
TargetEtcChain ::= SEQUENCE {
target CertEtcToken,
chain SEQUENCE SIZE (1..MAX) OF CertEtcToken OPTIONAL,
pathProcInput [0] PathProcInput OPTIONAL }
Компонент target задает целевой сертификат, компонент chain – аттестаты и
результаты проверки, компонент pathProcInput – политики.
В запросе на заверение компонент chain содержит список сертификатов, которые
нужны для проверки действительности target. Соответственно в элементах chain
могут быть выбраны компоненты только трех типов: Certificate, ESSCertIDv2
или CertId.
При обработке запроса СЗД выбирает из списка сертификатов те, которые позволяют построить подходящий маршрут сертификации. СЗД обращается к другим службам и получает аттестаты, которые определяют статус сертификатов маршрута: штампы времени, аттестаты заверения, OCSP-ответы, списки отозванных сертификатов.
В ответе СЗД список chain содержит отобранные сертификаты и другие аттестаты,
которые подтверждают результат проверки запрошенного факта. Список chain МОЖЕТ
дополнительно содержать результаты проверки аттестатов списка. Результат
задается выбором одного из вариантов pkistatus или certstatus в элементе
списка. Если результат задан в первом элементе списка, то он касается
сертификата target. Если результат задан во втором и следующем элементе, то он
касается предыдущего элемента (который обязан быть аттестатом). Если аттестат
списка chain не сопровождается результатом его проверки – значит СЗД признает
аттестат действительным. При этом действительный аттестат может означать
недействительность целевого сертификата.
Тип DVCSRequestInformation описывает общие (не относящиеся к заверяемых
фактам) данные запроса. Эти данные (возможно, с корректировками)
повторяются в аттестате заверения. Тип определяется следующим образом:
DVCSRequestInformation ::= SEQUENCE {
version INTEGER DEFAULT 1,
service ServiceType,
nonce INTEGER OPTIONAL,
requestTime DVCSTime OPTIONAL,
requester [0] GeneralNames OPTIONAL,
requestPolicy [1] PolicyInformation OPTIONAL,
dvcs [2] GeneralNames OPTIONAL,
dataLocations [3] GeneralNames OPTIONAL,
extensions [4] IMPLICIT Extensions OPTIONAL }
ServiceType ::= ENUMERATED {cpd(1), vsd(2), vpkc(3), ccpd(4)}
Компонент version задает версию протоколов заверения. Для версии, определяемой
настоящим стандартом, компонент либо отсутствует, либо содержит значение 1.
Компонент service задает запрашиваемый клиентом сервис. Названия сервисов в
определении типа ServiceType объясняются в 5.2.
Компонент nonce МОЖЕТ быть использован для дополнительной защиты от атак,
связанных с повтором запросов.
Компонент requestTime МОЖЕТ быть использован для указания клиентом момента
времени, в который следует проверить действительность ЭД и СОК. Если компонент
отсутствует, то действительность проверяется на текущий момент времени.
Компонент игнорируется сервисами заверения фактов владения и существования
данных.
Компонент requester задает имя клиента. Используется тип GeneralNames,
определенный в СТБ 34.101.19. Интерпретация и использование компонента
requester ДОЛЖНЫ определяться политикой СЗД. Например, клиент подписывает
запрос и указывает в requester идентификационные данные из своего сертификата, а
СЗД проверяет подпись и затем сравнивает значение requester с этими данными. Или
СЗД переадресует запрос другой службе, подписывая его и задавая в requester
свои идентификационные данные.
Компонент requestPolicy СЛЕДУЕТ использовать для описания политики проверки
запрошенных фактов. Если компонент задан, то СЗД ДОЛЖНА проверить, что указанная
политика согласована с собственной политикой службы. Отсутствие компонента
означает, что любая политика является приемлемой.
В компоненте dvcs МОЖНО перечислить вспомогательные СЗД, к которым служба,
отвечающая на запрос, может обратиться за дополнительной информацией или для
выполнения дополнительных операций. Правила использования компонента, в том
числе правила задания имен вспомогательных служб, определяются политикой целевой
службы.
В компоненте dataLocations МОЖНО указать ссылку на расположение дополнительных
данных, связанных с запросом. СЗД не использует компонент для ответа, компонент
может использоваться прикладными программами.
В компоненте extensions МОЖНО задать список расширений с дополнительной
информацией. Тип Extensions списка определен в СТБ 34.101.19. Расширения могут
быть критическими или некритическими, и в зависимости от этого, СЗД обязана их
разбирать или нет. В настоящем стандарте расширения не определяются.
Тип Data описывает заверяемые факты. Тип определяется следующим образом:
Data ::= CHOICE {
message OCTET STRING,
messageImprint DigestInfo,
certs [0] SEQUENCE SIZE (1..MAX) OF TargetEtcChain }
Данные, владение которыми требуется заверить, задаются в компоненте message.
ЭД, действительность которого требуется проверить, также задается в компоненте
message. Документ описывается типом SignedData и кодируется строкой октетов
по правилам ГОСТ 34.974. Клиент определяет сертификаты и другие аттестаты,
которые могут потребоваться для проверки ЭД и включает их в проверяемый документ
в качестве атрибутов. ЭД может содержать несколько подписей. Клиент отвечает за
предоставление аттестатов по каждой из них. Хэш-значение данных, существование
которых требуется заверить, задается в компоненте messageImprint. Сертификаты,
действительность которых требуется проверить, задаются в компоненте certs.
Проверяемые сертификаты сопровождаются аттестатами, за предоставление которых
отвечает клиент.
Тип DVCSCertInfo описывает содержание аттестата заверения. Тип определяется
следующим образом:
DVCSCertInfo ::= SEQUENCE {
version INTEGER DEFAULT 1,
dvReqInfo DVCSRequestInformation,
messageImprint DigestInfo,
serialNumber INTEGER,
responseTime DVCSTime,
dvStatus [0] PKIStatusInfo OPTIONAL,
policy [1] PolicyInformation OPTIONAL,
reqSignature [2] SignerInfos OPTIONAL,
certs [3] SEQUENCE SIZE (1..MAX) OF TargetEtcChain OPTIONAL,
extensions Extensions OPTIONAL }
Компонент version задает версию протоколов заверения. Для версии, определяемой
настоящим стандартом, компонент либо отсутствует, либо содержит значение 1.
Компонент dvReqInfo является копией компонента requestInformation
обработанного запроса. При копировании СЗД МОЖЕТ изменить компоненты dvcs,
requester, dataLocations и nonce, вложенные в dvReqInfo. Изменения могут
потребоваться в случае, когда запрос обрабатывается цепочкой служб или требуется
зафиксировать имя СЗД или требуется указать расположение данных, владение
которыми заверяется. Компонент nonce НЕЛЬЗЯ исключать или сокращать. Его можно
либо добавить (если он отсутствовал), либо расширить. При расширении следует
сдвигать разряды nonce влево и добавлять данные в освободившиеся позиции.
Компонент messageImprint задает хэш-значение компонента data обработанного
запроса. ДОЛЖНЫ применяться следующие правила хэширования:
- при выборе в
dataкомпонентаmessageхэшируются все октеты компонента, кроме октетов тега и длины; - при выборе в
dataкомпонентаmessageImprintиспользуется хэш-значение, заданное в этом компоненте; - при выборе в
dataкомпонентаcertsхэшируется его кодовое представление. Кодовое представление строится в соответствии с СТБ 34.101.19 (приложение Б.1).
Компонент serialNumber содержит уникальный номер запроса.
Компонент responseTime задает время ответа.
Компонент dvStatus задает общий вердикт проверки запрошенного факта.
Отсутствие компонента означает, что вынесен успешный вердикт.
Компонент policy задает политику СЗД.
Компонент reqSignature является копией компонента signerInfos из
обработанного запроса. Решение о включении компонента в DVCSCertInfo
определяется политикой СЗД.
Компонент certs определяет результат проверки. При проверке действительности
СОК список certs является копией такого же списка, вложенного в dvReqInfo.
Элементы списков имеют тип TargetEtcChain. При копировании элемента из одного
списка в другой в его компоненте chain фиксируются выбранное подмножество
аттестатов, дополнительные аттестаты, результаты их проверки. При проверке
действительности ЭД каждый элемент списка certs содержит результат проверки
одной подписи документа. Если в dvStatus возвращается вердикт waiting, то
этот же вердикт может указываться в некоторых элементах certs, или компонент
certs может вообще не возвращаться.
В компоненте extensions МОЖНО задать список расширений с дополнительной
информацией. Расширения могут быть критическими или некритическими, и в
зависимости от это клиенты обязаны их разбирать или нет. В настоящем стандарте
расширения не определяются.
Тип DVCSErrorNotice представляет информацию об ошибках в ответах СЗД. Тип
определяется следующим образом:
DVCSErrorNotice ::= SEQUENCE {
transactionStatus PKIStatusInfo,
transactionIdentifier GeneralName OPTIONAL }
Компонент transactionStatus определяет результат обработки запроса. В случае
ошибки вложенный в transactionStatus компонент status ДОЛЖЕН принимать
значение rejection, а необязательный компонент failureInfo – одно из
следующих значений: badRequest (запрос не разрешен или не поддерживается),
badTime (время в запросе недостаточно близко к текущему), badDataFormat
(неверный формат), wrongAuthority (служба, указанная в запросе, отличается от
службы, давшей ответ), incorrectData (данные клиента некорректны).
Компонент transactionStatus определяет результат обработки запроса. В случае
ошибки вложенный в transactionStatus компонент status ДОЛЖЕН принимать
значение rejection, а необязательный компонент failureInfo – быть
комбинацией следующих значений: badRequest (запрос не разрешен или не
поддерживается), badTime (время в запросе недостаточно близко к текущему),
badDataFormat (неверный формат), wrongAuthority (служба, указанная в
запросе, отличается от службы, давшей ответ), incorrectData (данные клиента
некорректны). Комбинация задается строкой битов (BIT STRING), в которой
единичные биты могут устанавливаться в позициях с номерами 2 (badRequest),
3 (badTime), 5 (badDataFormat) 6 (wrongAuthority) и 7 (incorrectData).
Компонент transactionIdentifier может быть использован для связывания
сообщения об ошибке с запросом. Тип GeneralName определен в СТБ 34.101.19.
Запрос на заверение описывается типом
DVCSRequest ::= SEQUENCE {
requestInformation DVCSRequestInformation,
data Data,
transactionIdentifier GeneralName OPTIONAL }
Компонент requestInformation определяет общие данные запроса, компонент
data – данные, относящиеся к заверяемым фактам.
Компонент transactionIdentifier может быть использован для связывания запросов
с сообщениями об ошибках. Для организации связывания этот компонент ДОЛЖЕН
копироваться в одноименный компонент типа DVCSErrorNotice. Необходимость
связывания определяется политикой СЗД.
Запрос может дополнительно подписываться. Формат подписанного запроса задается
типом SignedData, определенным в СТБ 34.101.23. Данные, которые
непосредственно подписываются, указываются в компоненте encapContentInfo.
Этот компонент, в свою очередь, ДОЛЖЕН содержать вложенный компонент типа
DVCSRequest и идентификатор
id-ct-DVCSRequestData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 7}
Запрос может быть подписан несколько раз. Например, запрос обрабатывается несколькими службами по цепочке и каждая из них добавляет в запрос свою подпись.
Ответ СЗД представляет собой подписанные данные типа SignedData. Данные
инкапсулируются в контейнер ContentInfo. При инкапсуляции им назначается
идентификатор id-signedData, описанный в СТБ 34.101.23.
Если СЗД НЕ МОЖЕТ выработать подпись (например, при компрометации личного ключа
службы), то сообщение об ошибке НЕ ДОЛЖНО содержать подпись, т. е. компонент
signerInfos, вложенный в SignedData, ДОЛЖЕН быть пуст. Клиент ДОЛЖЕН считать
неподписанный ответ критической ошибкой. Клиенту НЕ СЛЕДУЕТ доверять такому
ответу безоговорочно. Однако клиент МОЖЕТ доверять ответу, если он получен по
защищенному каналу, например, TLS-соединению (см. СТБ 34.101.65) с
предварительной аутентификацией СЗД.
В SignedData непосредственно подписываемые данные задаются компонентом
encapContentInfo. В ответе СЗД компонент ДОЛЖЕН содержать вложенный компонент
типа DVCSResponse и идентификатор.
id-ct-DVCSResponseData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 8}
Тип DVCSResponse определяется следующим образом:
DVCSResponse ::= CHOICE {
dvCertInfo DVCSCertInfo,
dvErrorNote [0] DVCSErrorNotice }
Компонент dvCertInfo выбирается при успешной проверке запрошенного факта,
компонент dvErrorNote – при ошибке. При выборе компонента dvCertInfo ответ
целиком представляет собой аттестат заверения, при выборе компонента
dvErrorNote – сообщение об ошибке.
Вложенный в dvCertInfo компонент dvStatus содержит общий вердикт проверки.
Если вердикт в dvStatus отличен от успешного (т. е. от granted и
grantedWithMods), то его поле failInfo МОЖЕТ описывать причину ошибки. Эта
причина МОЖЕТ также описываться в списке certs, вложенном в dvCertInfo.
При проверке действительности ЭД отрицательный результат проверки одной из
подписей не обязательно влечет общий отрицательный вердикт проверки. Например,
МОЖЕТ быть вынесен вердикт grantedWithMods, если действительными признаны
подписи определенных подписантов или определенное количество подписей. Аттестат
ДОЛЖЕН содержать вердикт granted, только если действительными признаны все
подписи документа.
Если окончательный результат проверки не может быть определен сразу, то в
аттестате ДОЛЖЕН быть установлен вердикт waiting. Этот вердикт означает, что
СЗД примет окончательное решение позже, например, после получения дополнительных
аттестатов. Детали откладывания вынесения вердикта являются частью политики СЗД.
СЗД может вернуть несколько аттестатов в ответ на один запрос. В этом случае все
аттестаты кроме одного будут содержать вердикт waiting.
Данные типа SignedData включают атрибуты: подписанные и неподписанные. Сам
аттестат заверения – объект типа SignedData – может быть атрибутом
(подписанным или неподписанным) в другом объекте типа SignedData. Такому
атрибуту назначается следующий идентификатор:
id-aa-dvcs-dvc OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 29}
PKIXDVCS {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dvcs(15)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
Extension, Extensions, AlgorithmIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
GeneralName, PolicyInformation
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)}
PKIStatusInfo, PKIStatusField
FROM PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)}
ContentInfo
FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
ESSCertIDv2
FROM ExtendedSecurityServices-2006 {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-ess-2006(30)}
CertId, OCSPResponse, CertStatus
FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)}
SMIMECapabilities
FROM SecureMimeMessageV3 {iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4)};
id-ad-dvcs OBJECT IDENTIFIER ::= {id-pkix id-ad(48) 4}
id-kp-dvcs OBJECT IDENTIFIER ::= {id-pkix id-kp(3) 10}
id-ct-DVCSRequestData OBJECT IDENTIFIER ::= {id-smime ct(1) 7}
id-ct-DVCSResponseData OBJECT IDENTIFIER ::= {id-smime ct(1) 8}
id-aa-dvcs-dvc OBJECT IDENTIFIER ::= { id-smime aa(2) 29 }
id-pkix OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)}
id-smime OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 16}
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest
}
Digest ::= OCTET STRING
DVCSTime ::= CHOICE {
genTime GeneralizedTime,
timeStampToken ContentInfo
}
TargetEtcChain ::= SEQUENCE {
target CertEtcToken,
chain SEQUENCE SIZE (1..MAX) OF CertEtcToken OPTIONAL,
pathProcInput [0] PathProcInput OPTIONAL
}
PathProcInput ::= SEQUENCE {
acceptablePolicySet SEQUENCE SIZE (1..MAX) OF PolicyInformation,
inhibitPolicyMapping BOOLEAN DEFAULT FALSE,
explicitPolicyReqd BOOLEAN DEFAULT FALSE
}
CertEtcToken ::= CHOICE {
certificate [0] IMPLICIT Certificate,
esscertid [1] ESSCertIDv2,
pkistatus [2] IMPLICIT PKIStatusInfo,
assertion [3] ContentInfo,
crl [4] IMPLICIT CertificateList,
ocspcertstatus [5] IMPLICIT CertStatus,
ocspcertid [6] IMPLICIT CertId,
ocspresponse [7] IMPLICIT OCSPResponse,
capabilities [8] SMIMECapabilities,
extension Extension
}
DVCSRequestInformation ::= SEQUENCE {
version INTEGER DEFAULT 1,
service ServiceType,
nonce INTEGER OPTIONAL,
requestTime DVCSTime OPTIONAL,
requester [0] GeneralNames OPTIONAL,
requestPolicy [1] PolicyInformation OPTIONAL,
dvcs [2] GeneralNames OPTIONAL,
dataLocations [3] GeneralNames OPTIONAL,
extensions [4] IMPLICIT Extensions OPTIONAL
}
ServiceType ::= ENUMERATED {cpd(1), vsd(2), vpkc(3), ccpd(4)}
DVCSRequest ::= SEQUENCE {
requestInformation DVCSRequestInformation,
data Data,
transactionIdentifier GeneralName OPTIONAL
}
Data ::= CHOICE {
message OCTET STRING,
messageImprint DigestInfo,
certs SEQUENCE SIZE (1..MAX) OF TargetEtcChain
}
DVCSResponse ::= CHOICE {
dvCertInfo DVCSCertInfo,
dvErrorNote [0] DVCSErrorNotice
}
DVCSCertInfo ::= SEQUENCE {
version INTEGER DEFAULT 1,
dvReqInfo DVCSRequestInformation,
messageImprint DigestInfo,
serialNumber INTEGER,
responseTime DVCSTime,
dvStatus [0] PKIStatusInfo OPTIONAL,
policy [1] PolicyInformation OPTIONAL,
reqSignature [2] SignerInfos OPTIONAL,
certs [3] SEQUENCE SIZE (1..MAX) OF TargetEtcChain OPTIONAL,
extensions Extensions OPTIONAL
}
DVCSErrorNotice ::= SEQUENCE {
transactionStatus PKIStatusInfo,
transactionIdentifier GeneralName OPTIONAL
}
END
[1] Adams C., Sylvester P., Zolotarev M., Zuccherato R. Internet X.509 Public Key Infrastructure. Data Validation and Certification Server Protocols. Request for Comments: 3029, 2001 (Интернет-инфраструктура открытых ключей X.509. Протоколы проверки и заверения данных)
[2] Freed N., Borenstein N. Multipurpose Internet Mail Extensions (MIME). Part One: Format of Internet Message Bodies. Request for Comments: 2045, 1996 (Универсальные расширения почты интернет (MIME). Часть 1: Формат частей интернет-сообщения)