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

Лекция 17. Единое пространство доверия к электронным документам, обладающим юридической силой. Сервисы безопасности Сабанов Алексей Геннадьевич, к.т.н., доцент кафедры т ИУ-10 План лекции • Доверенные сервисы для обеспечения юридической силы ЭД • Принципы исследования сервисов Доверенные сервисы Под доверенными сервисами будем понимать электронные сервисы, участвующие в создании, валидации, обработке, хранении электронных подписей, электронных печатей, меток доверенного времени, электронных документов, средств доставки и заверения электронных сообщений, разграничения и управления доступом, аутентификации, в том числе на на Web-сайтах, электронных сертификатов (в том числе атрибутных), актуальных реестров (ролей участников электронного взаимодействия, уполномоченных лиц и др.), сервисы регистрации, документирования и т.д. 3 Регулирование сервисов Рекомендации МСЭ • ITU-T Recommendation X.509 Information technology Open Systems Interconnection - The Directory: Publickey and attribute certificate frameworks. V.7. 2012. • ITU-T Recommendation X.842 «Information technology – Security techniques – Guidelines for the use and management of trusted third party services», 2002. • ITU-T Recommendation X.843 «Information technology – Security techniques – Specification of TTP services to support the application of digital signatures», 2001. • ITU-T Recommendation X.200, X.800-811 и др. 5 Рекомендации X.842(ISO/IEC TR 14516) Сервис штампов времени Сервис штампов времени криптографически приписывает к документу доверенное время (обычно к хэшу документа, называемому также слепком сообщения), предоставляя таким образом средство к обнаружению таких модификаций, как датировка задним числом, запись и повторная передача и других видов подлога. В основе сервиса лежит использование источника времени, обеспечивающего высокую надежность, доступность и точность часов. Назначение сервиса: подтверждать существование данных в определенный момент времени. Сервис неотказуемости Для обеспечения неотказуемости (невозможности отказа от авторства) сервис предоставляет доказательство записи, согласования, отправки, происхождения, передачи, получения, владения или доставки данных на определенный момент времени. Доказательство соответствия между ползователем (или процессом, действующим от имени пользователя) и данными, которые пользователь собирает, модифицирует или пересылает формируется на основе криптографической проверки значений, сгенерированных с использованием криптографических алгоритмов. Важным компонентом предоставления доказательства является проставление штампа времени. Сервис управления ключами Охватывает процессы генерации, регистрации, сертификации, распространения, установки, хранения, генерации производных ключей, архивирования, отзыв, отмену регистрации и уничтожение ключей. В зависимости от способа генерации ключевого материала, такой сервис может быть службой распространения ключей (когда ключ генерируется ДТС) или службой переноса ключей (когда ключ генерируется одним из пользователей и передаётся другому 6 посредством ДТС). Рекомендации X.842 Сервис управления сертификатами Включает в себя сервис управления PKI-сертификатами (ДТС выступает в роли УЦ (CA), реализующего управление процессами жизненного цикла PKIсертификатов); сервис управления сертификатами атрибутов, безопасно связывающих идентификационные данные пользователя с набором атрибутов. Для аутентификации пользователя атрибутный сертификат может ссылаться на PKI-сертификат пользователя; сервис аутентификации пользователей с использованием сертификатов; сервис отзыва сертификатов. Сервис электронного нотариата Сервис электронного нотариата использует ряд базовых сервисов (сервис доверенного времени, управления сертификатами, архив, сервис неотказуемости и другие) для разрешения споров между пользователями, удостоверения существования, подлинности документа посредством их подписания ЭП и проставления штампа времени или другим образом и для других целей. Сервис генерации свидетельств Сервис осуществляет сбор информации, относящейся к документу, сообщению или событию (идентификаторы участвующих субъектов, их местонахождение, передаваемые данные, метод их передачи, метку времени) для создания контрольной записи в журнале ДТС в целях анализа, аудита или других целей. Также сервис может осуществлять хранение свидетельств; хранения и регистрации документов. 7 Рекомендации X.842. Прочие сервисы • • • • • • Служба каталога – предоставляет доступ к и осуществляет безопасное хранение PKI-сертификатов, списков отозванных сертификатов, атрибутных сертификатов и другой актуальной доверенной информации. Служба идентификации и аутентификации – может быть предоставлена в on-line или off-line режиме. Может выполнять задачи по удостоверению подлинности пользователей и данных, осуществлять проверку идентификационной и аутентификационной информации субъектов доступа, объектов доступа и данных, в том числе с помощью механизма проверки ЭП. Служба восстановления – могут осуществлять восстановление ключей и данных. Служба персонализации – сохраняют криптографический материал (секретные ключи, открытые ключи, сертификаты, случайные числа) в устройствах аутентификации, т.е. смарт-картах. Служба должна обеспечивать регистрацию персонализированных токенов конкретных пользователей. Служба контроля доступа – может выступать службой удостоверения полномочий пользователей, предоставляя информацию, связанную с контролем доступа. Служба сообщения об инцидентах и управления оповещениями – генерирует и доставляет оповещения при возникновении инцидента ИБ, например, мошенничества. Оповещение может быть направлено пользователем ДТС или получено ДТС в автоматическом режиме. 8 Европейский институт ETSI Европейский институт по стандартизации в области телекоммуникаций (European Telecommunications Standards Institute, ETSI) – независимая некоммерческая организация и признанный региональный орган по стандартизации, который официально ответственен за стандартизацию информационных и телекоммуникационных технологий в пределах Европейского союза. ETSI обеспечивает поддержку европейского законодательства путем создания гармонизированных европейских стандартов. Стандарты, разработанные ETSI совместно с Европейским комитетом по стандартизации (CEN) и Европейским комитетом электротехнической стандартизации (CENELEC), признаны европейскими стандартами (EN). Рекомендации ETSI Поставщик доверенных сервисов (Trusted Service Provider - TSP) – сущность, предоставляющая один или более доверенный сервис. Доверенный сервис – сервис, предоставляющий услуги в электронном виде для: • cоздания, проверки (верификации) и подтверждения действительности (валидации) ЭП и связанных цифровых сертификатов. • создания, проверки (верификации) и подтверждения действительности (валидации) меток времени и связанных цифровых сертификатов. • зарегистрированной доставки документов, сообщений. • создания, верификации и валидации сертификатов веб-ресурса. • хранения ЭП или сертификатов, относящихся к данному сервису. TSP предоставляет следующие сервисы для цифровых сертификатов: Сервис регистрации: проверяет подлинность субъектов, связанные с субъектом специфические атрибуты. Результаты сервиса передаются на сервис Издания сертификатов. Проверяется также доказательство владения (proof of posession) субъекта закрытым ключом, если он не сгенерирован CA. Сервис издания сертификатов: создает и подписывает сертификаты, основываясь на идентичности и атрибутах, проверенных сервисом регистрации. Сервис распространения: передает сертификаты субъектам, и по согласию субъекта делает их доступными Доверяющей стороне. Также сервис предоставляет (делает доступными) политики и другую публикуемую информацию подписантам и Доверяющим сторонам. Сервис управления отзывом: процессы запроса и уведомления, относящиеся к отзыву, которые определяют какие действия должны быть предприняты. Результаты сервиса передаются в сервис статуса отзыва Сервис статуса отзыва: предоставляет статус отзыва сертификата Доверяющим сторонам Сервис обеспечения устройств субъекта: изготовляет, предоставляет, делает доступными для субъектов защищенные криптографические устройства или другие защищенные устройства (например, генерация ключевой пары и доставка закрытого ключа субъекту; создание и передача модуля для генерации ЭП и код его активации) Некоторые документы НИСТ NIST Special Publication 800-33 Технические модели, лежащие в основе безопасности информационных технологий NIST Special Publication 800-35 Руководство по сервисам безопасности информационных технологий. 2003. NIST Special Publication 800-37 Руководство по применению общих правил управления рисками к государтсвенным информационным системам. 2010. NIST Special Publication 800-57 Рекомендации по управлению ключами– Part 1: General. NIST Special Publication 800-53A Руководство по безопасному управлению доступом к государтсвенным информационным системам. 2003. NIST Special Publication 800-63 Рекомендации по электронной аутентификации. 2006. NIST Special Publication 800-103 Онтология электронных удостоверений. 2006. NIST Special Publication 800-114 руководство пользователя по безопасности внешних устройств при доступе к сети и удаленном доступе. Пример структуры документа НИСТ 1. Цель Статус 3. Введение 1 4. Определения и сокращения 4 5. Модель электронной аутентификации 9 5.1. Пользователи, ЦР и CSP 10 5.2. Аутентификаторы 11 5.3. Электронные удостоверения 12 5.4. Проверяющие стороны 13 5.5. Подтверждения 13 5.6. Доверяющие стороны 14 6. Аутентификаторы 15 6.1. Угрозы аутентификаторам 16 6.2. Уровни аутентификаторов 16 7. Регистрация и подтверждение подлинности 19 7.1. Угрозы регистрации 19 7.1.1. Модель угроз 19. 7.1.2. Противодействие угрозам регистрации 20 7.2. Уровни регистрации 20 7.2.1. Требования к регистрации и подтверждению подлинности 21 7.2.2. Требования к сохранению записей 25 7.3. Сопоставление политик сертификатов FPKI уровням регистрации 25 8. Протоколы аутентификации 26 8.1. Угрозы аутентификации 26 8.1.1. Угрозы протоколам аутентификации 26 8.1.2. Противодействие угрозам протоколу аутентификации 27 8.2. Требования к механизму аутентификации 30 8.2.1. Уровень 1 31 8.2.2. Уровень 2 32 8.2.3. Уровень 3 34 8.2.4. Уровень 4 37 9. Краткое изложение технических требований к уровням 38 9.1.1. Связь политик PKI с уровнем строгости электронной аутентификации 10. Ссылки 43 10.1. Общие ссылки 43 10.2. Бюллетени лаборатории информационных технологий НИСТ 43 10.3. Специальные публикации НИСТ 44 10.4. Федеральные стандарты обработки информации 45 10.5. Политики сертификации 45 Приложение А: Оценка качества паролей 46 А.1 Случайно сгенерированные пароли 47 А.2 Пароли, заданные пользователями 47 А.2 Другие типы паролей 51 А.3 Примеры 51 Сервис аутентификации • обеспечение доказательства подлинности предъявленного идентификатора (ISO/IEC 29115); • доказательство принадлежности аутентификатора, с помощью которого производится доказательство подлинности, конкретному объекту (ISO/IEC 10181-2); • аутентификация сторон – подтверждение того, что взаимодействующая сторона является той, за которую себя выдает (ISO 9798-3). Нормативно-правовые документы РФ • • • • • • • • • Федеральный закон от 06.04.2011 № 63-ФЗ «Об электронной подписи». ГОСТ Р 34.11-2012 «Информационная технология. Криптографическая защита информации. Функция хэширования». ГОСТ Р 34.10-2012. «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи». Приказ Минкомсвязи России № 242 от 29.09.2011 г. «Об утверждении порядка передачи реестров квалифицированных сертификатов ключей проверки электронной подписи и иной информации в федеральный орган исполнительной власти, уполномоченный в сфере использования электронной подписи, в случае прекращения деятельности аккредитованного удостоверяющего центра». Приказ Минкомсвязи России № 250 от 05.10.2011 г. «Об утверждении порядка формирования и ведения реестров квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров». Приказ Минкомсвязи России № 320 от 23.11.2011 г. «Об аккредитации удостоверяющих центров». Приказ Минкомсвязи России № 41 от 23.03.2009 г. «Об утверждении Требований к технологиям, форматам, протоколам информационного взаимодействия, унифицированным программнотехническим средствам подсистемы удостоверяющих центров общероссийского государственного информационного центра». Приказ ФСБ России № 795 от 27.12.2011 г. «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи». Приказ ФСБ России г. № 796 от 27.12.2011 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра» Сервис доверенного времени • Сервис меток доверенного времени совместно с сервисом штампов времени (RFC 3161 "Time-Stamp Protocol (TSP)") образуют Службу доверенного времени. • Суть сервиса состоит в синхронизации серверного времени для всех удостоверяющих центров, участвующих в формировании и проверки статуса сертификата Штамп времени Штамп времени — это подписанный электронной подписью документ, которым Служба штампов времени удостоверяет, что в указанный момент времени ей было предоставлено значение хэшфункции от другого документа. Само значение хэш-функции также указывается в штампе. Использование штампа времени 1. Удостоверено время создания документа. Штамп времени на документе удостоверяет точное время создания этого документа для того, чтобы в последующем разрешать конфликты, связанные с его использованием. Таким образом, с помощью штампа времени вы обеспечиваете неотказуемость автора документа от своей подписи. 2. Сохранена актуальность электронной подписи. Наличие штампа времени в подписанном документе позволяет продлевать срок действия электронной подписи. Такой штамп удостоверяет, например, что подпись была создана до того, как сертификат ключа подписи был аннулирован (отозван). Таким образом, для проверки подписи, созданной до момента отзыва сертификата, вы можете использовать уже отозванный сертификат. 3. Цепочка штампов времени позволяет создавать системы архивного хранения электронных документов, сохраняющие актуальность ЭП в документах. В ином случае, актуальность подписанного документа ограничена сроком действия сертификата ключа подписи и сроком действия сертификата на СКЗИ, использованное для создания оригинальной подписи документа. 4. Удостоверено время поступления и получения документа Штамп времени может использоваться для удостоверения точного времени, когда документ поступил или получен, в тех случаях, когда это необходимо. 5. Удостоверено время проведения операции по записи в журнале событий Служба штампов времени Служба штампов времени (Time Stamping Authority — TSA) — это доверенный субъект Инфраструктуры открытых ключей (PKI), который обладает точным и надёжным источником времени и оказывает услуги по созданию штампов времени. Основной функцией Службы Штампов Времени является создание «штампов времени», которые подтверждают факт существования данных (значения хэш-функции) в определенный момент времени, заверяют то, что данные существовали к конкретному моменту времени. Значение хэш-функции от документа, на который получен штамп времени, служит для связи штампа с документом. При включении в штамп времени не самого документа, а значения хэшфункции, сохраняется конфиденциальность документа перед Службой штампов времени. Что требуется для работы с модулем TSP? Работа с TSP службой потребует ПО КриптоАРМ Стандарт и Модуль TSP / КриптоАРМ СтандартPRO Для работы с данным ПО необходимо преобрести лицензии на - КриптоАРМ Стандарт с модулем TSP / КриптоАРМ Стандарт+ - КриптоПро TSP Client (поставляется вместе с лицензией на модуль TSP) В случае работы со сторонним сервисом штампов времени дополнительно устанавливать ничего не требуется. Если же клиент хочет использовать собственный сервис штампов времени, то необходима покупка сервера службы Штампов Времени, например, от компании «КриптоПро» - КриптоПро TSP Server. Если планируется использовать ГОСТ алгоритмы, то необходима покупка ГОСТ-ового криптопровайдера КриптоПро CSP или Signal Com CSP. Доверенное время Квалифицированная доверенная электронная метка времени признается доказательством времени события, которое она фиксирует, и целостности данных, к которым привязана. Метка доверенного времени должна удовлетворять следующим требованиям: • быть привязана к эталонному времени ГУЦ РФ, а для трансграничных операций - среднему времени по Гринвичу (также - всемирное координированное время); • использовать точный датчик времени; • выпускаться доверенным поставщиком доверенных служб; • подписываться усиленной квалифицированной ЭП поставщика доверенных сервисов. • Уровни доверия к метке времени определяются бизнес-процессами, для которых она предназначена. Зависят от степени рассинхронизации часов поставщика доверенных сервисов с эталонным временем. Сервис валидации • проверка действительности данных, связанных с подписанным сообщением или документом, а также сертификатов ключей подписи (RFC 2459). • Может проводиться по стандартизованному протоколу Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (DVCS) с квитанцией за подписью сервера (RFC 3029). Для проверки статуса сертификата также используется Online Certificate Status Protocol - OCSP (RFC 2560). Отдельно может проводиться проверка действительности сертификата открытого ключа – Validation of Public Key Certificates (VPKC) Назначение сервиса действительности (валидации) сертификата Сервис валидации предназначен для централизованной проверки действительности электронных удостоверений и сертификатов (полномочий и ЭП) субъекта ИС, а также для комплексной проверки ЭП и меток времени. В комплексную проверку действительности ЭП в качестве процедур входят проверки действительности сертификатов субъекта, создавшего подпись (полномочий и ЭП) и метки времени (при ее наличии). Назначение сервиса валидации – проверка действительности (или валидация): • электронных удостоверений доступа, требуемых для идентификации и аутентификации и авторизации субъекта доступа в ИС; • атрибутных сертификатов полномочий, требуемых для подтверждения полномочий доступа к ЭД или для его подписания; • сертификатов ключа проверки ЭП; • проверки штампов времени различного назначения; • комплексной проверки электронной подписи. Валидация цифрового сертификата Европейским институтом по стандартизации ETSI были выпущены рекомендации по реализации сервисов создания и валидации видов электронных подписей, форматы которых приняты в пределах Европейского союза: ETSI TS 119 102-1 V1.0.1 «Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation», 2015 [1]. ETSI TR 119 100 V1.1.1 «Electronic Signatures and Infrastructures (ESI); Guidance on the use of standards for signature creation and validation», 2016 [2]. ETSI TS 119 101 V1.1.1 «Electronic Signatures and Infrastructures (ESI); Policy and security requirements for applications for signature creation and signature validation», 2016 [3]. В соответствии с этими документами, сервис валидации представляет из себя сервис, который на основании предъявленного подписанного ЭД либо его хэш-кода и ЭП производит проверку действительности подписи и выпускает отчет по результатам проверки. Так как валидация сертификата ЭП входит в валидацию ЭП в качестве процедуры, правомерно использовать рекомендации ETSI в части, касающейся требований к содержанию проверок действительности сертификатов ЭП. Проверка действительности ЭП осуществляется в соответствии с политикой валидации. Политика валидации - совокупность правил, применимых к единичной ЭП или к набору взаимосвязанных ЭП, которые определяют технические и процедурные требования к валидации ЭП (набора взаимосвязанных ЭП), в соответствии с которыми ЭП (набор взаимосвязанных ЭП) может быть определена как действительная в целях удовлетворения потребностей бизнеса. Включает в себя (согласно рекомендация ETSI): Требования к криптографическим алгоритмам – включают требования к длине открытого ключа, содержащегося в сертификате; требования к используемым криптографическим алгоритмам и проч. Требования к параметрам цифрового сертификата – включают требования к корневым сертификатам; требования к цепочке сертификации; к формату и содержанию сертификата ЭП; требования к актуальности информации об отзыве сертификата ЭП и пр. Требования к валидации ЭП – включают требования к атрибутам субъекта, создавшего подпись; требования к меткам времени; требования к месту создания подписи; требования к формату ЭД и другим элементам, включаемым в ЭП. Перечень проверок Проверка формата сертификата ЭП: проверяется по формальным признакам (формат и структура файла -нотация); проверяется наличие обязательных полей и дополнений; проверяется содержание обязательных полей и дополнений. Имеется политика валидации для проверки сертификата ЭП, определяющая требования к проверке сертификата КС, сертификатов ЦС и криптографическим алгоритмам. Срок действия сертификата не истек. Сертификат не отозван, и информация об отзыве удовлетворяет требованиям к актуальности. Проверена цепочка сертификации. Срок действия сертификатов ЦС не истек. Ни один из сертификатов ЦС не отозван. Сертификаты ЦС соответствуют требованиям (ограничения по длине и проч.). Криптографическая проверка сертификата КС Криптографическая проверка целостности полей сертификата КС. Проверка требований к используемым криптографическим алгоритмам. Проверка требований к длине ключа проверки ЭП. Способы проверки статуса сертификата Критически важным является управление информацией о статусе отзыва сертификатов. Подтверждение статуса обеспечивают единственный способ проверки валидности сертификата при условии успешной верификации содержимого полей сертификата, его срока действия и криптографической целостности. В настоящее время службы подтверждения статуса отзыва цифрового сертификата подразделяются на службы, работающие в режиме on-line и offline. К off-line службам относятся списки отозванных сертификатов CRL и его сокращенные версии (Delta CRL). К on-line службам относят протоколы подтверждения статуса отзыва сертификата в режиме реального времени, в частности, протокол OCSP. Способы проверки статуса сертификата Список отозванных сертификатов (Certificate revocation list - CRL) стандартизован; содержит перечень серийных номеров действительных сертификатов, которые были отозваны по каким-либо причинам в пределах покрываемой данным CRL области (домене). CRL поддерживается Издателем PKI-сертификатов, регулярность обновлений определяется политикой Издателя (Удостоверяющего центра) и требованиями законодательства. Для получения информации о статусе отзыва сертификата клиент обращается к ресурсу, предоставляющему CRL, скачивает его и проверяет наличие серийного номера искомого сертификата. Delta CRL – список отозванных сертификатов меньшего размера, который содержит информацию о действительных сертификатах, статус отзыва которых был изменен с момента выпуска последнего актуального CRL. Delta CRL содержит ссылку на полный CRL. Для проверки статуса отзыва сертификата клиент обращается к ресурсу, который предоставляет Delta CRL, скачивает его и проверяет наличие серийного номера искомого сертификата. Распространение CRL может осуществляться по различным протоколам – LDAP (поверх транспортного протокола TCP), HTTP либо HTTPS, FTP другими. Один из недостатков использования CRL состоит в том, что процедура скачивания CRL и Delta CRL и поиска в нем искомого серийного номера крайне ресурсоемка, сильно зависит от емкости каналов связи и доступности ресурса, предоставляющего CRL либо Delta CRL OCSP-клиент 1. Генерация запроса 2. Подписание запроса (опционально) 3. Обмен сообщениями OCSP Сообщение >>> OCSP-запрос >>> <<< OCSP-ответ (ошибка) <<< 4. Проверка валидности OCSP-ответа <<< OCSP-ответ (статус) <<< OCSP-сервер 3. Проверка валидности запроса: 3.1. Запрос не валиден Генерация сообщения об ошибке (не подписывается сервером) 3.2. Запрос валиден Генерация ответа Подписание ответа Протокол подтверждения статуса сертификата в режиме реального времени (Online Certificate Status Protocol - OCSP) стандартизован. Он позволяет приложениям определять текущий статус (отзыва) сертификата в режиме on-line более быстрым способом, чем обращение к CRL. В протоколе участвует OCSP-сервер и OCSP-клиент, который обмениваются сообщениями (OCSP-запрос, OCSP-ответ) с информацией, требуемой для проверки статуса. Схема обмена сообщениями между OCSP-клиентом и OCSP-сервером представлена в таблице. При обращении к одной и той же базе отозванных сертификатов, поддерживаемой УЦ, приложение, использующее службу OCSP, получает информацию об актуальном статусе отзыва сертификата в режиме реального времени без необходимости синхронизации, загрузки и хранения информации из базы данных. Статус сертификата в OCSP-ответе Действителен (good) – положительный статус сертификата. Означает, что сертификат с заданным серийным номером не отозван в пределах интервала валидности ответа. В расширении может присутствовать информация, утверждающая другие статусы сертификата – был выпущен, действителен и др. Отозван (revoked) – сертификат с указанным серийным номером либо отозван, либо приостановлен. Может возвраться в случае, если CA не выпускал сертификата с таким серийным номером. Ответ OCSP-сервера должен включать расширение с определением причины отзыва сертификата (Extended Revoked Definition) Не известен (unknown) – издатель сертификата не распознан OCSP-сервером (не обслуживается данным OCSP-сервером) Значения времени в OCSP-ответе могут быть следующими: thisUpdate – ближайшая к моменту проверки статуса сертификата дата и время, когда OCSP-серверу поступила информация о корректности определенного статуса сертификата (good/revoked/unknown) nextUpdate – ближайшая дата и время, до или во время которой будет доступна обновленная информация о статусе сертификата producedAt – дата и время подписания OCSP-ответа OCSP-сервером revocationTime – дата и время отзыва или приостановления действия сертификата. Интервал валидности ответа (response validity interval) составляет промежуток времени {thisUpdate, nextUpdate}. Должен признаваться ненадежным статус сертификата, если в полученном OCSP-ответе время nextUpdate более раннее, чем текущее время в системе. Некоторые проверки в OCSP Валидация запроса OCSP-сервером включает следующие проверки: Запрос сформирован корректно; OCSP-сервер предоставляет запрашиваемый сервис; Запрос содержит необходимую информацию для OCSP-сервера. Если запрос OCSP-клиента не валиден, то ему возвращается сообщение об ошибке. Проверка валидности OCSP-ответа при получении OCSP-клиентом включает проверки: сертификат в ответе соответствует запрашиваемому сертификату; ЭП в ответе валидна; субъект (OCSP-сервер) идентифицирован и соответствует тому субъекту, которому был отправлен запрос; субъект, подписавший OCSP-ответ, авторизован для предоставления OCSP-ответа по запрашиваемому сертификату; дата и время thisUpdate соответствует предъявляемым требованиям к дате поступления такой информации; дата и время nextUpdate является более поздними, чем текущие дата и время. Типы ошибок в OCSP • malformedRequest – некорректно сформированный OCSP-запрос (синтаксис запроса); • internalError – ошибка на стороне OCSP-сервера (нештатное состояние); • tryLater – ошибка на стороне OCSP-сервера, без возможности возвратить сообщение об ошибке; • sigRequired – требуется подпись OCSP-запроса клиентским приложением; • unauthorized – OCSP-клиент не авторизован для выполнения запроса к данному OCSP-серверу, либо OCSP-сервер не в состоянии ответить. Протокол. В качестве транспортного протокола для передачи OCSP-сообщений между клиентом и сервером в настоящее время используются протоколы HTTP, может считаться надежным только при использовании шифрования (как, например, функционируют программно-аппаратные комплексы компании «КриптоПро», предоставляющие службу OCSP); HTTPS (HTTP поверх TLS) – используется в сети Интернет для подтверждения статуса сертификатов веб-сайтов. Алгоритм проверки Спасибо за внимание! 31