Методические рекомендации по использованию сервисов электронного нотариата службы «Доверенная третья сторона» (стр. 3 )

3) Revoked – Сертификат отозван. Возвращается информация о времени отзыва сертификата.

3.5.2 Запросы к сервису

Пользователями сервиса помимо утилиты командной строки pki_tool могут выступать любые субъекты, поддерживающие выработку OCSP-запросов и прием OCSP-ответов в рамках RFC 2560.

Пример с использованием утилиты командной строки pki_tool

Формирование и отправка OCSP-запросов может осуществляться с помощью соответствующей команды pki_tool.

Допустимые опции:

-cert file: файл, содержащий сертификат в формате DER, статус которого проверяется. Обязательная опция.

-issuer file: файл, содержащий сертификат издателя в формате DER. Обязательная опция.

-reqout file: файл, в который сохраняется OCSP-запрос.

-respout file: файл, в который сохраняется OCSP-ответ.

-url URL: URL для обращения к сервису OCSP. Обязательная опция.

-host hostname: DNS-имя для обращения к сервису OCSP. Обязательная опция.

-port port: номер порта для обращения к сервису OCSP. По умолчанию происходит соединение по порту 80.

Пример использования:

cmd_line# pki_tool –cert cert. der –issuer issuer. der –host host. domain –url /cgi-bin/ocsp. cgi –port 82 –reqout request. asn –respout response. asn

[ OK ] [ ocsp ] [ Response successful: certificate status good ]

Полное описание протокола OCSP раскрыто в международном стандарте RFC 2560 [3].

3.6 Протокол TSP

В состав Службы «Электронного нотариата» входит программное обеспечение для получения «штампа времени» с использованием протокола TSP (Time Stamping Protocol).

3.6.1 Информационные потоки

Пользователь сервиса формирует TSP-запрос и осуществляет его доставку по протоколу HTTP как MIME объект с Content-Type application/timestamp-query. На стороне сервера производится проверка синтаксиса запроса и формируется TSP-ответ, который доставляется пользователю по протоколу HTTP как MIME объект с Content-Type application/timestamp-reply.

Возможны следующие типы ответов TSP-сервера:

1. Granted – ответ содержит штамп времени.

2. Rejection – запрос не обработан, в ответе содержится информация об ошибке.

3. Waiting – запрос ожидает обработки.

4. RevocationWaiting – предупреждение о том, что приближается отзыв сертифифката.

5. RevocationNotification – уведомление о том, что отзыв сертификата уже произошел.

В случае успешной обработки TSP-запроса (тип Granted) TSP-ответ содержит штамп времени, в противном случае штамп времени не проставляется.

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

1. badAlg – неизвестный или неподдерживаемый идентификатор алгоритма.

2. badRequest – транзакция запрещена или не поддерживается.

3. badDataFormat – неверный формат представленных данных.

4. timeNotAvailable – источник времени не доступен.

5. unacceptedPolicy – запрашиваемая политика не поддерживается сервисом TSP.

6. unacceptedExtension – дополнения не поддерживаются сервисом TSP.

7. addInfoNotAvailable – запрашиваемая дополнительная информация не поддерживается или не доступна.

8. systemFailure – запрос не может быть обработан в связи с системной ошибкой.

3.6.2 Запросы к сервису

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

Пример с использованием pki_tool

Формирование и отправка TSP-запросов может осуществляться с помощью соответствующей команды утилиты командной строки pki_tool.

Допустимые опции:

-in: файл с данными, которые требуют проставления «штампа времени».

-req: файл, в который сохраняется TSP-запрос (по умолчанию /dev/null)

-tsp: файл, в который сохраняется TSP-ответ (stdout default)

-url: URL : URL для обращения к сервису TSP. Обязательная опция.

-port: номер порта (80 по умолчанию).

-host: DNS-имя для обращения к сервису TSP. Обязательная опция.

-tls: флаг, если присутствует, производится TLS-соединение.

Пример использования:

cmd_line# pki_tool –cmd tsp –in some. file –req request. tsq –tsp response. tsr - host host. domain –url /cgi-bin/tsp. cgi

[ OK ] [ tsp ] [ Time Stamp Response received ]

Полное описание протокола TSP раскрыто в международном стандарте RFC 3161 [4].

3.7 Протокол DVCS

Целью протокола DVCS (Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols, RFC 3029) являются всевозможные проверки, подтверждения и выработки «штампа времени».

Реализуемые функции:

1. Удостоверение обладания информацией с или без ее представления сервису.

2. Проверка валидности ЭЦП на текущий момент времени.

3. Проверка валидности сертификата открытого ключа.

4. Выработка квитанции, содержащей «штамп» времени.

Результатом выполнения той или иной функции служит DVC квитанция, образованная службой DVCS Службы «Электронного Нотариата».

3.7.1 Информационные потоки.

1. Пользователь сервиса формирует DVC заявку, которая автоматически обрамляется в CMS [20] сообщение.

2. CMS сообщение, заверенное на ключе зарегистрированного в DVCS пользователе отправляется по протоколу HTTP по методу POST с enctype multipart/form-data на сервер транспортировки запросов. Соединение осуществляется по защищенному транспорту TLS с предоставлением серверу персонального сертификата зарегистрированного в системе пользователя.

3. На стороне сервера происходит проверка соответствия лигитимности соединения, контроль ЭЦП на CMS сообщении и определяются из профиля пользователя специфические настройки.

4. Модуль функциональной поддержки извлекает из CMS сообщения непосредственно DVC заявку, выполняет требуемые в заявке процедуры (при этом для выполнения криптографических преобразований взаимодействует со средством криптографической защиты информации, результатом которых является DVC квитанция.

5. В режиме трансграничного взаимодействия принятая от пользователя заявка переоформляется и направляется в ранее зарегистрированную функционально аналогичную Службу «Электронного нотариата» другого домена для выполнения непосредственных процедур проверок и ожидается квитанция о результатах указанных проверок.

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

7. Полученная квитанция переоформляется и перезаверяется на ключах Службы «Электронного нотариата» и передается пользователю.

8. Созданная таким образом DVC квитанция обрамляется в CMS сообщение, заверенное на ключе DVCS. Регистрационная информация о заявке, и квитанция (в режиме трансграничного взаимодействия квитанции, включая полученные от внешних Служб отправляются на хранение в репозиторий Службы сгруппированные в единую «историю» запроса) размещаются в репозитории сервиса либо на хранение.

9. Квитанция как CMS сообщение в режиме ON-LINE транспортируется пользователю в кодировке DER и инкапсулируется в MIME объект с Content-Type application/dvcs с соответствующим Content-Transfer-Encoding.

Возможны ситуации, при которых обеспечить режим ON-LINE становится невозможно, например, высокая нагрузка на сервис при ограниченной производительности аппаратной платформы. В этом случае пользователь в ON-LINE получит DVC квитанцию специального статуса – WAITING, в этом случае процедуру получения квитанции следует повторить спустя некоторое время.

3.7.2 Пролонгация квитанций.

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

1. Просматривает всю базу репозитория, выявляя цепочки (информация о заявки – квитанции) для данного типа СКЗИ, с взведенным флагом автоматической пролонгации.

2. Для каждой цепочки из последней по дате создания квитанции (CMS сообщения с предварительно проверенной ЭЦП, созданной на «старом», но действительном на данный момент, ключе службы DVCS) выделяется непосредственно тело DVC квитанции.

3. На основе этой DVC квитанции формируется новое CMS сообщение на ключах «нового» DVCS сертификата.

4. Вновь созданное сообщение добавляется в репозиторий как продолжение «истории запроса».

3.7.3 Использование сервиса DVCS.

Пользователями сервиса может выступать любое внешнее программное обеспечение позволяющее осуществлять создание DVC запросов инкапсулированного в CMS с ЭЦП автора запроса, извлечение из CMS ответа подписанного на ключе Уполномоченного лица сервиса DVCS DVC квитанций (и их разбор) и транспортировку CMS запросов – ответов по защищенному протоколу TLS с предоставлением сервису пользовательского персонального сертификата.

В рамках Службы «Электронного нотариата» функции пользователей могут выполнять: Абонентский Пункт (см. раздел 3.9) и программные роботы – утилиты командной строки (см. раздел 3.4).

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

Полное описание протокола DVCS раскрыто в международном стандарте RFC 3029 [2].

3.8 Веб-приложения

Веб-приложение — клиент-серверное приложение, в котором клиентом выступает браузер, а сервером — веб-сервер.

Веб-приложение получает запрос от клиента и выполняет вычисления, после этого формирует веб-страницу и отправляет её клиенту по сети с использованием протокола HTTP. Само веб-приложение может выступать в качестве клиента других служб, например, базы данных или другого веб-приложения, расположенного на другом сервере.

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

3.9 Абонентский пункт пользователя сервиса

Абонентский пункт представляет собой программное обеспечение «Digital Secretary Lite», функционирующее под управлением ОС Windows XP и являющееся клиентской частью защищенной автоматизированной системы технологии инфраструктуры открытых ключей, может выступать в качестве прикладного программного обеспечения по формированию запроса и разбора полученной DVC квитанции. Также с помощью «Digital Secretary Lite» может обеспечиваться административное управление Службой «Электронного нотариата».