Защищенные документы.

Данная форма позволяет указать режимы, влияющие на методику проверки ЭЦП и сертификата. Полная процедура проверки ЭЦП под документом включает в себя следующие два этапа:

  1. математическая проверка соответствия ЭЦП подписанным данным и сертификату ключа ЭЦП;
  2. проверка сертификата ключа ЭЦП.
Ошибка или отсутствие необходимых данных на любом из этих этапов приводит к невозможности проверить ЭЦП.

Проверка сертификата также производится в несколько шагов:

  1. построение пути сертификации (может состоять из нескольких сертификатов, включая и специальные кросс-сертификаты);
  2. проверка действительности пути сертификации;
  3. проверка действительности сертификата по СОС. Для систем работающих в режиме приближенном к Real-Time УЦ формирует, так называемые, обновления к СОС (дельта-CRL). Эти списки являются текущим отражением изменения статуса выпущенных из-под конкретного издателя УЦ сертификатов в период между переизданиями регулярного списка отозванных сертификатов.
Ошибка или отсутствие необходимых данных на любом из этих этапов приводит к невозможности проверить сертификат. Поиск необходимых данных (сертификатов промежуточных УЦ, СОС) производится в первую очередь в хранилище АП. Если информации в хранилище недостаточно и доступен сетевой справочник, то ПО АП автоматически запросит необходимые данные в сетевом справочнике. Если сертификат содержит в своем составе специальные расширения (CRLDistributionPoin и FreshestCRL), то поиск СОС и обновлений (дельта CRL) осуществляется сначала по URI, указанным в соответствующих расширениях. Для сложно организованных, мостовых систем информация о промежуточных сертификатах берется из специальных расширений – AuthorityInfoAccess, а решение о действительности связей принимается с учитом расширения: NameConstraints, PolicyConstraints, InhibitAnyPolicy и PolicyMappings.

Замечание: даже при отсутствии ON-LINE, но при наличии иных транспортов для доставки СОС в хранилище не следует включать флаг "Проверка по СОС необязательна", поскольку алгоритм проверок и построения цепочек в первую очередь использует всю имеющуюся информацию из локального хранилища, и только если эта информация не полная или не актуальная происходит организация ON-LINE соединения со службой реестра УЦ.

Замечание: Если по каким то причинам в режиме ON-LINE не будет возможности получить CRL, то будет создан соответствующий Алерт.

Указанная группа настроек определяет:

  1. «Проверка по СОС необязательна», в данном режиме при всех процедурах проверок сертификатов СОС не участвует. В ситуации, когда пользователь АП не имеет возможности своевременно получать актуальные СОС, и регламент конкретной ИОК системы допускает режим такой работы (доминирующим предполагается OFF-LINE режим, списки отозванных сертификатов статичны и субъекты информационного обмена доверены) - пользователь может отключить этап проверки действительности выбранного сертификата по СОС. В этом случае все проверки (подписанных документов и сертификатов) и печать квитанций о проверке ЭЦП будут сопровождаться соответствующим уведомлением.

  2. «Обязательна проверка по СОС» - режим получения (и их участия в процедурах проверок) регулярных СОС в режиме ON-LINE из CDP и/или сетевого справочника системы (Реестра УЦ). Данные автоматически сохраняются в хранилище (база «Отозванные»). Если существует возможность (не обязательное условие) получить также обновления к СОС, то они также будут участвовать в проверке сертификатов.

  3. «Обязательна проверка по СОС и обновлениям к ним» - Аналогичен второму режиму и в дополнение при проверках используются обновления к СОС, так называемые дельта CRL. Замечание: в этом режиме каждый раз, если превышен период действительности обновления (определенная в ПО константа, равная двум минутам), при проверке будет в ON-LINE запрошен список обновлений по точке распространения из состава сертификата (FreshestCRL) и/или сетевого справочника.

Процедуру проверки сертификата возможно поручить специальному сервису из состава Службы «Электронного нотариата» - OCSP. Для этого требуется взвести флаг «Использовать OCSP для проверки сертификатов» и указать URL сервиса в поле «OCSP». В этом случае принятие решения о действительности сертификата опирается на полученную с сервера OCSP заверенную квитанцию. По завершению процедур проверки квитанция на рабочем месте не сохраняется. Если возникнет необходимость в получении заверенной квитанции о статусе сертификата в виде файла следует использовать сервис VPKC из состава DVCS.

Данная форма также содержит флаг «Доверять всем самоподписанным сертификатам» находящимся в хранилище, даже если они были установлены в токен не в режиме «Администратор» и для этих сертификатов не взведен (или сам токен, например NSS, не имеет поддержки) флаг CKA_TRUSTED.

Пользователь также может указать URL к исполняемым модулям Службы «Электронного нотариата» для проведения различных проверок по протоколам DVCS, OCSP и TSP. Замечание: текущая версия ПО АП в ограниченном объеме может взаимодействовать со Службой «Электронного нотариата».


© 2005 LLC Top Cross
All Rights Reserved
info@top-cross.ru