ETSI TS 101 733 V1.8.3 (2011-01) Техническая спецификация Электронные подписи и инфраструктуры (ESI); усовершенствованные электронные подписи CMS (CAdES) ETSI TS 101 733, версия 1.8.3 (201101) Ссылка на документ RTS/ESI-000111 Ключевые слова: электронная коммерция, электронная подпись, безопасность. ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Тел.: +33 4 92 94 42 00 Факс: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Примечание Отдельные копии настоящего документа доступны по адресу в Интернете: http://www.etsi.org. Настоящий документ может быть предоставлен в нескольких электронных версиях либо в печатном варианте. В любом случае фактического или кажущегося расхождения между такими версиями справочной версией является документ в формате PDF. В случае разногласий справочным документом является копия, распечатанная на принтерах ETSI, либо версия в формате PDF, которая хранится на определенном сетевом диске в Секретариате ETSI. Пользователи настоящего документа должны принять к сведению, что документ может быть пересмотрен или его статус может быть изменен. Информацию о текущем статусе настоящего и других документов ETSI можно получить по адресу http://portal.etsi.org/tb/status/status.asp. При обнаружении каких-либо ошибок в настоящем документе просим направлять свои замечания в одну из следующих служб: http://portal.etsi.org/chaircor/ETSI_support.asp. Уведомление об авторских правах Запрещается воспроизводить какие-либо части настоящего документа без письменного разрешения. Действие авторского права и вышеуказанного ограничения распространяется на воспроизведение документа на любом носителе. © Европейский институт телекоммуникационных стандартов, 2011. Все права защищены. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, логотипы TIPHON и ETSI являются торговыми марками ETSI, зарегистрированные в пользу его членов. ETSI ETSI TS 101 733, версия 1.8.3 (201101) 3GPPTM является торговой маркой ETSI, зарегистрированной в пользу его членов и организационных партнеров 3GPP. LTE™ является торговой маркой ETSI, которая в данный момент зарегистрирована в пользу его членов и организационных партнеров 3GPP. GSM® и логотип GSM являются торговыми марками, зарегистрированными и принадлежащими Ассоциации GSM. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Оглавление Права на интеллектуальную собственность................................................................................................................... 7 Предисловие ...................................................................................................................................................................... 7 Введение ............................................................................................................................................................................ 7 1 Область действия .................................................................................................................................................. 8 2 2.1 2.2 Ссылки ................................................................................................................................................................... 9 Нормативные ссылки ...................................................................................................................................... 9 Информационные ссылки ............................................................................................................................. 10 3 3.1 3.2 Определения и аббревиатуры ............................................................................................................................12 Определения ................................................................................................................................................... 12 Аббревиатуры ................................................................................................................................................ 13 4 Обзор ....................................................................................................................................................................14 4.1 Основные участники ..................................................................................................................................... 15 4.2 Регламенты подписей .................................................................................................................................... 16 4.3 Форматы электронных подписей ................................................................................................................. 16 4.3.1 Простая электронная подпись CAdES (CAdES-BES) ........................................................................... 16 4.3.2 Электронные подписи CAdES с явно указанным регламентом (CAdES-EPES) ................................ 18 4.4 Форматы электронных подписей с проверочными данными .................................................................... 18 4.4.1 Электронная подпись со временем (CAdES-T) ..................................................................................... 19 4.4.2 Электронная подпись с полным набором проверочных данных (CAdES-C) ..................................... 20 4.4.3 Расширенные форматы электронных подписей .................................................................................... 21 4.4.3.1 Расширенная долгосрочная электронная подпись (CAdES-X Long) ............................................. 21 4.4.3.2 Расширенная электронная подпись с типом времени (Time Type) 1 (CAdES-X Type 1) ............. 22 4.4.3.3 Расширенная электронная подпись с типом времени (Time Type) 2 (CAdES-X Type 2) ............. 22 4.4.3.4 Расширенная долгосрочная электронная подпись с типами времени 1 или 2 (CAdES-X Long) . 23 4.4.4 Архивная электронная подпись (CAdES-A) .......................................................................................... 23 4.5 Арбитраж ........................................................................................................................................................ 24 4.6 Процесс проверки .......................................................................................................................................... 24 5 Атрибуты электронных подписей .....................................................................................................................25 5.1 Общий синтаксис ........................................................................................................................................... 25 5.2 Тип содержимого данных ............................................................................................................................. 25 5.3 Тип содержимого подписанных данных ..................................................................................................... 25 5.4 Тип SignedData ............................................................................................................................................... 25 5.5 Тип EncapsulatedContentlnfo ......................................................................................................................... 25 5.6 Тип Signerlnfo ................................................................................................................................................. 26 5.6.1 Процесс вычисления хэш-значения сообщения .................................................................................... 26 5.6.2 Процесс формирования подписи ............................................................................................................ 26 5.6.3 Процесс проверки подписи ..................................................................................................................... 26 5.7 Обязательные атрибуты простой электронной подписи ............................................................................ 26 5.7.1 Атрибут content-type ................................................................................................................................ 26 5.7.2 Хэш-значение сообщения ........................................................................................................................ 27 5.7.3 Атрибуты ссылки на сертификат подписи ............................................................................................ 27 5.7.3.1 Определение атрибута signing-certificate ESS .................................................................................. 27 5.7.3.2 Определение атрибута ESS signing-certificate-v2 ............................................................................ 27 5.7.3.3 Другое определение атрибута signing-certificate ............................................................................. 28 5.8 Дополнительные обязательные атрибуты для электронных подписей с явно указанным регламентом 29 5.8.1 Атрибут signature-policy-identifier .......................................................................................................... 29 5.9 Необязательные атрибуты, импортированные из CMS.............................................................................. 30 5.9.1 Атрибут signing-time ................................................................................................................................ 30 5.9.2 Атрибут countersignature ......................................................................................................................... 30 5.10 Необязательные атрибуты, импортированные из ESS ............................................................................... 30 5.10.1 Атрибут content-reference ........................................................................................................................ 31 5.10.2 Атрибут content-identifier ........................................................................................................................ 31 ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 5.10.3 Атрибут content-hints ............................................................................................................................... 31 ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 5.11 5.11.1 5.11.2 5.11.3 5.11.4 5.12 5.12.1 5.12.2 Дополнительные необязательные атрибуты, определенные в настоящем документе 32 Атрибут commitment-type-indication....................................................................................................... 32 Атрибут signer-location ............................................................................................................................ 33 Атрибут signer-attributes .......................................................................................................................... 33 Атрибут content-time-stamp ..................................................................................................................... 34 Поддержка множества подписей.................................................................................................................. 34 Независимые подписи ............................................................................................................................. 34 Встроенные подписи ................................................................................................................................ 34 6 Дополнительные атрибуты проверки электронной подписи .......................................................................... 35 6.1 Атрибут штампа времени подписи (CAdES-T) ........................................................................................... 36 6.1.1 Определение атрибута signature-time-stamp .......................................................................................... 36 6.2 Полный набор проверочных данных (CAdES-C)........................................................................................ 36 6.2.1 Определение атрибута complete-certificate-references ........................................................................... 37 6.2.2 Определение атрибута complete-revocation-references .......................................................................... 37 6.2.3 Определение атрибута attribute-certificate-references ............................................................................ 38 6.2.4 Определение атрибута attribute-revocation-references ........................................................................... 39 6.3 Расширенные проверочные данные (CAdES-X) ......................................................................................... 39 6.3.1 Проверочные данные со штампом времени (CAdES-X Type l или Type 2) ........................................ 39 6.3.2 Долгосрочные проверочные данные (CAdES-X Long, CAdES-X Long Type 1 или 2) ....................... 39 6.3.3 Определение атрибута certificate-values ................................................................................................. 40 6.3.4 Определение атрибута revocation-values ................................................................................................ 40 6.3.5 Определение атрибута CAdES-C-time-stamp ......................................................................................... 41 6.3.6 Определение атрибута time-stamped-certs-crls-references ..................................................................... 42 6.4 Архивные проверочные данные ................................................................................................................... 42 6.4.1 Определение атрибута archive-time-stamp .............................................................................................. 42 7 7.1 7.2 7.3 7.4 7.5 7.6 Другие стандартные структуры данных............................................................................................................ 43 Формат сертификата открытого ключа ....................................................................................................... 43 Формат списка отзыва сертификатов .......................................................................................................... 44 Формат ответа OCSP ..................................................................................................................................... 44 Формат штампа времени ............................................................................................................................... 44 Формат имени и атрибута ............................................................................................................................. 44 Атрибутный сертификат ............................................................................................................................... 44 8 8.1 8.2 8.3 8.4 Требования по соответствию ............................................................................................................................. 45 Простая электронная подпись CAdES (CAdES-BES)................................................................................. 45 Электронная подпись CAdES с явно указанным регламентом ................................................................. 46 Проверка с помощью штампов времени ..................................................................................................... 46 Проверка с помощью безопасных записей .................................................................................................. 46 Приложение A (нормативное): Определения ASN.l.................................................................................................. 47 А.l Определения формата подписи с использованием синтаксиса X.208 ASN.l .................................................. 47 А.2 Определения формата подписи с использованием синтаксиса X.680 ASN.l ................................................. 52 Приложение Б (справочное): Расширенные формы электронных подписей ................................................... 58 Б.l Расширенные формы проверочных данных ........................................................................................................ 58 Б.l.l CAdES-X Long .................................................................................................................................................. 58 Б.1.2 CAdES-X Type 1 ............................................................................................................................................. 59 Б.1.3 CAdES-X Type 2 ............................................................................................................................................. 60 Б.1.4 CAdES-X Long Type 1 и CAdES-X Long Type 2 .......................................................................................... 61 Б.2 Расширения штампа времени .............................................................................................................................. 62 Б.3 Архивные проверочные данные (CAdES-A)...................................................................................................... 62 Б.4 Пример проверочной последовательности ........................................................................................................ 64 Б.5 Дополнительные необязательные компоненты ................................................................................................. 67 Приложение В (справочное): Общее описание....................................................................................................... 68 В.1 Регламент подписи .............................................................................................................................................. 68 ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) В.2 Подписанная информация .................................................................................................................................. 69 В.3 Компоненты электронной подписи ................................................................................................................... 69 В.3.1 Ссылка на регламент подписи ....................................................................................................................... 69 В.3.2 Указание вида обязательств .......................................................................................................................... 69 В.3.3 Идентификатор сертификата от подписывающей стороны ........................................................................ 70 В.3.4 Атрибуты роли ................................................................................................................................................ 70 В.3.4.1 Заявленная роль ....................................................................................................................................... 70 В.3.4.2 Сертифицированная роль ........................................................................................................................ 70 В.3.5 Местоположение подписывающей стороны ................................................................................................ 71 В.3.6 Время подписания .......................................................................................................................................... 71 В.3.7 Формат содержимого ..................................................................................................................................... 71 В.3.8 Атрибут content-hints ...................................................................................................................................... 71 В.3.9 Перекрестные ссылки на содержимое .......................................................................................................... 71 В.4 Компоненты проверочных данных .................................................................................................................... 72 В.4.1 Информация о статусе отзыва ....................................................................................................................... 72 В.4.1.1 Сведения CRL .......................................................................................................................................... 72 В.4.1.2 Сведения OCSP ........................................................................................................................................ 72 В.4.2 Путь сертификации ........................................................................................................................................ 73 В.4.3 Штампы времени для долгосрочного использования подписей ................................................................ 73 В.4.4 Штампы времени для долгосрочного использования подписей до компрометации ключа центра сертификации ................................................................................................................................................................. 74 В.4.4.1 Добавление штампов времени в электронную подпись с полными проверочными данными (CAdES-X Type 1) 74 В.4.4.2 Добавление штампов времени в сертификаты и ссылки на сведения об отзыве (CAdES-X Type 2) 75 В.4.5 Штампы времени для архива подписи ......................................................................................................... 75 В.4.6 Ссылки на дополнительные данные ............................................................................................................. 76 В.4.7 Штампы времени для взаимного распознавания ......................................................................................... 76 В.4.8 Компрометация ключа службы штампов времени ...................................................................................... 76 В.5 Множество подписей .......................................................................................................................................... 77 Приложение Г (справочное). Протоколы данных для взаимодействия с поставщиками доверенных услуг 78 Г.l Оперативные протоколы .................................................................................................................................... 78 Г.l.l Извлечение сертификата ............................................................................................................................... 78 Г.1.2 Извлечение списка отзыва сертификатов .................................................................................................... 78 Г.l.3 Оперативный статус сертификата ................................................................................................................ 78 Г.1.4 Штампы времени ........................................................................................................................................... 78 Г.2 Протоколы управления ....................................................................................................................................... 78 Г.2.1 Запрос на отзыв сертификата ....................................................................................................................... 78 Приложение Д (справочное). Вопросы безопасности ............................................................................................ 79 Д.l Защита закрытого ключа .................................................................................................................................... 79 Д.2 Выбор алгоритмов ............................................................................................................................................... 79 Приложение Е (справочное). Пример структурированного содержимого и использования формата MIME 80 Е.l Использование MIME для кодирования данных ............................................................................................... 80 Е.l.l Данные заголовка .......................................................................................................................................... 80 Е.1.2 Кодирование содержимого ........................................................................................................................... 81 Е.l.3 Составное содержимое .................................................................................................................................. 81 Е.2 S/MIME ................................................................................................................................................................ 82 Е.2.1 Использование application/pkcs7-mime ........................................................................................................ 82 Е.2.2 Использование application/pkcs7-signature .................................................................................................. 83 Приложение Ж (справочное). Ж.l Связь с Европейской директивой и инициативой EESSI ........................ 84 Введение .............................................................................................................................................................. 84 ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Ж.2 Электронные подписи и директива ................................................................................................................... 84 Ж.3 Форматы электронной подписи ETSI и директива .......................................................................................... 85 ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Ж.4 Стандарты EESSI и классы электронных подписей 85 Ж.4.1 Структура стандартов EESSI ........................................................................................................................ 85 Ж.4.2 Классы электронных подписей .................................................................................................................... 85 Ж.4.3 Классы электронных подписей и формат электронной подписи ETSI ..................................................... 86 Приложение З (справочное). электронных Программные интерфейсы (API) для формирования и проверки маркеров подписей.................................................................................................................... 87 З.1 Кадры данных ...................................................................................................................................................... 87 З.2 Интерфейсы IDUP-GSS-API, определенные IETF ........................................................................................... 88 З.3 Интерфейсы безопасности CORBA, определенные OMG............................................................................... 89 Приложение И (справочное). Криптографические алгоритмы .......................................................................... 90 1.1 Алгоритмы хэширования ................................................................................................................................... 90 1.1.1 SHA-1.............................................................................................................................................................. 90 1.1.2 Общие сведения ............................................................................................................................................. 90 1.2 Алгоритмы цифровой подписи .......................................................................................................................... 91 1.2.1 DSA ................................................................................................................................................................. 91 1.2.2 RSA ................................................................................................................................................................. 91 1.2.3 Общие сведения ............................................................................................................................................. 91 Приложение Й (справочное). Рекомендации по именованию ............................................................................. 93 Й.l Выделение имен .................................................................................................................................................. 93 Й.2 Предоставление доступа к сведениям о регистрации ...................................................................................... 93 Й.3 Схемы именования .............................................................................................................................................. 94 Й.3.1 Схемы именования для отдельных граждан ............................................................................................... 94 Й.3.2 Схемы именования для сотрудников организации..................................................................................... 94 Приложение К (справочное). Вычисление хэш-значения штампа времени..................................................... 95 Приложение Л (справочное). Изменения по сравнению с предыдущей версией ............................................. 97 Л.l Изменения до версии 1.7.4 ................................................................................................................................. 97 Л.2 Изменение между версиями 1.7.4 и 1.8.1 .......................................................................................................... 97 Л.3 Изменения между версиями 1.8.1 и 1.8.3 .......................................................................................................... 97 Приложение М (справочное). Список литературы ......................................................................................... 98 История документа ......................................................................................................................................................... 99 ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Права на интеллектуальную собственность Права на интеллектуальную собственность, которые являются существенными или потенциально существенными в отношении настоящего документа, могут быть заявлены в адрес ETSI. Информация о данных существенных правах на интеллектуальную собственность (при их наличии) общедоступна для членов ETSI и лиц, не являющихся членами ETSI, и содержится в документе ETSI SR 000 314: «Права на интеллектуальную собственность; существенные или потенциально существенные, права на интеллектуальную собственность, заявленные в адрес ETSI в отношении стандартов ETSI», который можно получить в Секретариате ETSI. Последние обновления можно загрузить с сайта ETSI (http://webapp.etsi.org/IPR/home.asp). Согласно Политике ETSI в области прав на интеллектуальную собственность ETSI не проводит расследований, в том числе в отношении прав на интеллектуальную собственность. В отношении существования других прав на интеллектуальную собственность, не упоминаемых в документе ETSI SR 000 314 (или его обновленных версиях, содержащихся на сайте ETSI), которые являются, могут являться или могут стать существенными для настоящего документа, никаких гарантий не предоставляется. Предисловие Настоящая Техническая спецификация (ТС) составлена Техническим комитетом ETSI по электронным подписям и инфраструктурам (ESI). Введение Электронная коммерция развивается как будущее ведения бизнеса между компаниями по локальным, региональным и глобальным сетям. Доверие при таком способе ведения дел необходимо для успеха и дальнейшего развития электронной коммерции. Поэтому важно, чтобы у компаний, использующих такой метод работы, были подходящие средства и механизмы обеспечения безопасности для защиты их операций и гарантии доверия среди партнеров. В этой связи электронная подпись является важным компонентом безопасности, который может быть использован для защиты информации и обеспечения надежности электронного бизнеса. Настоящий документ предназначен для описания электронных подписей для различных типов операций, в том числе и деловых (таких как запросы на приобретение, контракты, счета), в которых длительный срок действия очень важен. В документе также обсуждается вопрос подтверждения электронной подписи, даже если подписывающая или проверяющая сторона попытается отрицать действительность подписи (т. е. отказаться от подписи; см. ISO/IEC 10181-5 [i.1]). Таким образом, данный документ можно использовать для любой операции между физическим лицом и компанией, между двумя компаниями, между физическим лицом и правительственным учреждением и т.д. Настоящий документ не зависит от сферы его использования, он подходит, например, для пластиковых карт, SIM-карт GSM, специальных программ для электронных подписей и т.д. Европейская директива, посвященная электронным подписям [i.5], определяет электронную подпись следующим образом: «Данные в электронном формате, которые прилагаются к другим электронным данным или логически связаны с ними, и служат методом проверки подлинности». В данном документе под электронной подписью понимается форма усовершенствованной электронной подписи, как описано в директиве [i.5]. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Область действия 1 В область действия настоящего документа входят только форматы электронной подписи. В предыдущих версиях настоящего документа описывались форматы электронной подписи и регламенты электронной подписи. Эти аспекты регламентов электронной подписи теперь описываются в документе TR 102 272 [i.2]. Настоящий документ определяет ряд форматов электронной подписи, в том числе электронные подписи с длительным сроком действия. Здесь также описываются доказательства действительности, даже если подписывающая или проверяющая сторона пытается это отрицать (отказаться от подписи). В настоящем документе регламентируется использование поставщиков доверенных услуг (например, служб штампов времени) и данных, которые необходимо архивировать (например, перекрестные сертификаты и списки отзыва) для выполнения требований к долгосрочным электронным подписям. Электронные подписи, описываемые в данном документе, можно использовать для арбитража при возникновении разногласий между подписывающей и проверяющей стороной через определенное время (даже через несколько лет). В данном документе описывается концепция регламентов подписи, которую можно использовать для обеспечения технической согласованности при проверке электронных подписей, но их применение не является обязательным. Данный документ основан на использовании криптографических алгоритмов с применением открытого ключа для создания цифровых подписей, поддерживаемых сертификатами открытых ключей. В данном документе также описывается использование служб штампов времени и временных меток для подтверждения действительности подписи после истечения срока действия важных элементов электронной подписи. Дополнительно в настоящем документе также определены способы обеспечения долгосрочной защиты от компрометации ключей и потерявших стойкость алгоритмов. Данный документ основан на существующих общепринятых стандартах. К ним относятся следующие стандарты: • RFC 3852 [4] «Криптографический синтаксис сообщений (CMS)» (Cryptographic Message Syntax (CMS)); • Рекомендация ISO/IEC 9594-8/ITU-T X.509 [1] «Информационные технологии. Взаимодействие открытых систем. Справочник: Основы открытых ключей и атрибутных сертификатов» (Information technology - Open Systems Interconnection - The Directory:Public-key and attribute certificate frameworks); • RFC 3280 [2]: «Профиль сертификатов инфраструктуры открытых ключей Интернет X.509 и списков отзыва сертификатов (CRL)» (Internet X.509 Public Key Infrastructure (PKIX) Certificate and Certificate Revocation List (CRL) Profile); • RFC 3161 [7] «Протокол штампов времени (TSP) инфраструктуры открытых ключей Интернет X.509» (Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)). ПРИМЕЧАНИЕ. Полный список ссылок см. в пункте 2. В настоящем документе описаны форматы усовершенствованных электронных подписей с использованием языка ASN.1 (Abstract Syntax Notation 1). Эти форматы основаны на CMS (синтаксисе криптографических сообщений), определенном в документе RFC 3852 [4]. Эти электронные подписи называются CAdES (усовершенствованные электронные подписи CMS). В другом документе, TS 101 903 [i.3], описываются форматы усовершенствованных электронных подписей XML (XAdES), основанных на XMLDSIG. Кроме того, в настоящем документе указаны другие документы, определяющие форматы сертификатов открытого ключа, атрибутных сертификатов, списков отзыва сертификатов и поддерживающие их протоколы, в том числе протоколы, используемые доверенными сторонними организациями для создания и проверки электронных подписей. Справочные приложения содержат следующие данные: • иллюстрации расширенных форм форматов электронной подписи, предоставляющих защиту от различных уязвимостей, и примеры процессов проверки (приложение Б); • описание некоторых концепций, используемых в данном документе, с обоснованием для нормативных составляющих этого документа (приложение В); ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) • сведения о протоколах для взаимодействия с поставщиками доверенных услуг (приложение Г); • рекомендации по именованию (приложение Д); ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) • содержимого и MIME (приложение Е); пример структурированного • связь настоящего документа и директивы, посвященной электронным подписям [i.5], и связанных с ней инициатив по стандартизации (приложение Ж); • программные интерфейсы (API) для поддержки процессов создания и проверки электронных подписей (приложение З); • криптографические алгоритмы, которые могут быть использованы (приложение И); • схемы именования (приложение Й); • вычисление хэш-значения штампа времени (приложение К); • изменения по сравнению с предыдущими версиями (приложение Л). Ссылки 2 Ссылки являются либо определенными (с указанием даты публикации и (или) номера издания или версии), либо неопределенными. Для определенных ссылок учитывается только указанное издание. Для неопределенных ссылок учитывается последняя версия документа (в том числе любые дополнения). Документы, на которые ссылаются другие документы и которые невозможно найти в общем доступе в ожидаемом месте, можно найти по адресу http://docbox.etsi.org/Reference. ПРИМЕЧАНИЕ. Все гиперссылки, приведенные в данном пункте, являются действующими на момент публикации настоящего документа, однако ETSI не может гарантировать их действительность в долгосрочной перспективе. 2.1 Нормативные ссылки Следующие нормативные документы являются обязательными к применению в настоящем стандарте. [I] Рекомендация ITU-T X.509 (2000) / ISO/IEC 9594-8 (2001) «Информационные технологии. Взаимодействие открытых систем. Справочник. Основы открытых ключей и атрибутных сертификатов» (Information technology – Open Systems Interconnection - The Directory: Public-key and Attribute Certificate frameworks). [2] IETF RFC 3280 (2002) «Профиль сертификатов инфраструктуры открытых ключей Интернет X.509 и списков отзыва сертификатов (CRL)» (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile). [3] IETF RFC 2560 (1999) «Протокол проверки состояния сертификата в режиме реального времени (OCSP) инфраструктуры открытых ключей Интернет X.509» (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP). [4] IETF RFC 3852 (2004) «Синтаксис криптографических сообщений (CMS)» (Cryptographic Message Syntax (CMS)). [5] IETF RFC 2634 (1999) «Расширенные службы безопасности для S/MIME» (Enhanced Security Services for S/MIME). [6] IETF RFC 2045 (1996): «Многоцелевые расширения почты Интернет (MIME) Часть 1. Формат тела сообщения Интернет» (Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies). ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) [7] IETF RFC 3161 (2001): «Протокол штампов времени (TSP) инфраструктуры открытых ключей Интернет X.509» (Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)). [8] ITU-T Recommendation X.680 (1997) «Информационные технологии – язык Abstract Syntax Notation One (ASN.1). Стандарт базовой нотации» (Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation). [9] ITU-T Recommendation X.501 (2000) / ISO/IEC 9594-1 (2001) «Информационные технологии. Взаимодействие открытых систем. Справочник. Модели» (Information technology – Open Systems Interconnection - The Directory: Models). [10] IETF RFC 3370 (2002) «Алгоритмы криптографического синтаксиса сообщений (CMS)» (Cryptographic Message Syntax (CMS) Algorithms). [II] Рекомендация ITU-T F.1 «Рабочие положения для международной общественной телеграфной службы» (Operational provisions for the international public telegram service). [12] Рекомендация ITU-T X.500 «Информационные технологии. Взаимодействие открытых систем. Справочник. Обзор концепций, моделей и служб» (Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services). ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) [13] IETF RFC 3281 (2002) «Профиль сертификата для авторизации с атрибутом Internet» (An Internet Attribute Certificate Profile for Authorization). [14] Рекомендация ITU-T X.208 (1988) «Спецификация языка Abstract Syntax Notation One (ASN.1)» (Specification of Abstract Syntax Notation One (ASN.1)). ПРИМЕЧАНИЕ. Действие рекомендации ITU-T X.208 было прекращено 30 октября 2002 г. в результате ее замены рекомендацией ITU-T X.680-683. Все известные недостатки X.208 были исправлены в рекомендациях ITU-T X.680-683 (1993), измененных в 1997 и 2002 гг. Однако ссылка на данный документ сохранена для совместимости с документом RFC 3852 [4]. [15] IETF RFC 5035 (2007) «Обновление стандарта Enhanced Security Services (ESS). Добавление адаптивности алгоритма CertID» (Enhanced Security Services (ESS) Update:Adding CertID Algorithm Agility). [16] Утратил силу. 2.2 Информационные ссылки Нижеуказанные документы не являются существенными для использования настоящего документа, однако они могут помочь при обращении к определенным темам. [i.1] ISO/IEC 10181-5 (сентябрь 1996 г.) «Информационные технологии – взаимодействие открытых систем – основы безопасности для открытых систем – основы конфиденциальности» (Information technology - Open Systems Interconnection - Security frameworks for open systems: Confidentiality framework). [i.2] ETSI TR 102 272 «Электронные подписи и инфраструктуры (ESI); формат ASN.1 для регламентов электронных подписей» (Electronic Signatures and Infrastructures (ESI); ASN.1 format for signature policies). [i.3] ETSI TS 101 903 «Усовершенствованная электронная подпись XML (XAdES)» (XML Advanced Electronic Signatures (XAdES)). [i.4] ISO 7498-2 (1989) «Системы обработки информации – взаимодействие открытых частей – базовая модель – часть 2. Безопасная архитектура» (Information processing systems - Open Systems Interconnection – Basic Reference Model - Part 2: Security Architecture). [i.5] Директива Европейского парламента и Европейского совета 1999/93/EC от 13 декабря 1999 г. по использованию общей инфраструктуры электронных подписей. [i.6] ISO/IEC 13888-1 (2004 г.) «Методы безопасности ИТ – невозможность отказа – часть 1. Общая информация» (IT security techniques - Non-repudiation - Part 1: General). [i.7] ETSI TR 102 038 «Безопасность ТС. Электронные подписи и инфраструктуры (ESI); формат XML для регламентов подписей» (TC Security - Electronic Signatures and Infrastructures (ESI); XML format for signature policies). [i.8] IETF RFC 3125 (2000) «Регламенты электронных подписей» (۫Electronic Signature Policies). [i.9] ETSI TS 101 861: «Профиль штампов времени» (Time stamping profile). [i.10] IETF RFC 3494 (2003) «Протоколы инфраструктуры открытых ключей Интернет X.509 – LDAP версии 2» (Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2). [i.11] IETF RFC 4523 (2006) «Облегченный протокол доступа к каталогам (LDAP). Определение схем для сертификатов X.509» (Lightweight Directory Access Protocol (LDAP). Schema Definitions for X.509 Certificates). [i.12] IETF RFC 4210 (2005) «Управляющие протоколы для сертификатов инфраструктуры открытых ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) ключей Интернет X.509» (Internet X.509 Public Key Infrastructure Certificate Management Protocols). [i.13] IETF RFC 3851 «Спецификация версии 3.1 для безопасных/многоцелевых расширений почты Интернет (S/MIME)» (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification). [i.14] IETF RFC 2743 (2000) «Общий программный интерфейс сервисов безопасности версии 2, обновление 1» (Generic Security Service Application Program Interface Version 2, Update 1). [i.15] IETF RFC 2479 (1998) «Общий программный интерфейс сервисов безопасности для защиты независимых модулей данных» (Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)). [i.16] ISO/IEC 10118-1 (2000 г.) «Информационные технологии – безопасные методы – функции хэширования – часть 1. Общая информация» (Information technology - Security techniques - Hashfunctions - Part 1: General). [i.17] ISO/IEC 10118-2 (2000 г.) «Информационные технологии – безопасные методы – функции хэширования – часть 2. Функции хэширования, использующие шифрование n-битными блоками» (Information technology - Security techniques - Hash-functions - Part 2: Hash-functions using an n-bit block cipher). ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) [i.18] ISO/IEC 10118-3 (2004 г.) «Информационные технологии – безопасные методы – функции хэширования – часть 3. Выделенные функции хэширования» (Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions). [i.19] ISO/IEC 10118-4 (1998 г.) «Информационные технологии – безопасные методы – функции хэширования – часть 4. Функции хэширования, использующие арифметику в остаточных классах» (Information technology - Security techniques - Hash-functions - Part 4: Hash-functions using modular arithmetic). [i.20] ANSI X9.30-2 (1997 г.) «Шифрование с открытым ключом с использованием необратимых алгоритмов – часть 2. Безопасный алгоритм хэширования (SHA-1)» (Public Key Cryptography Using Irreversible Algorithms - Part 2: The Secure Hash Algorithm (SHA-1)). [i.21] ANSI X9.31-2 (1996 г.) «Шифрование с открытым ключом с использованием обратимых алгоритмов для финансовой отрасли – часть 2. Алгоритмы хэширования» (Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry - Part 2: Hash Algorithms). [i.22] IETF RFC 3447 (2003 г.): «Криптографические стандарты для открытых ключей (PKCS) №1. Криптографическая спецификация RSA версии 2.1» (Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1). [i.23] IEEE 1363 (2000 г.) «Спецификации стандартов для шифрования с открытым ключом» (Standard Specifications For Public Key Cryptography). [i.24] ISO/IEC 9796 (все части) «Информационные технологии – безопасные методы – схемы цифровых подписей, обеспечивающие восстановления сообщения» (Information technology - Security techniques - Digital signature schemes giving message recovery). [i.25] ISO/IEC 9796-2:2002/Amd 1:2008 «Информационные технологии – безопасные методы – схемы цифровых подписей, обеспечивающие восстановление сообщения – часть 2. Механизмы, основанные на целочисленной факторизации» (Information technology - Security techniques – Digital signature schemes giving message recovery - Part 2: Integer factorization based mechanisms). [i.26] ISO/IEC 9796-3 «Информационные технологии – безопасные методы – схемы цифровых подписей, обеспечивающие восстановления сообщения – часть 3. Механизмы, основанные на дискретном логарифме» (Information technology - Security techniques - Digital signature schemes giving message recovery - Part 3: Discrete logarithm based mechanisms). [i.27] ISO/IEC 14888-1 (2008 г.) «Информационные технологии – безопасные методы – цифровые подписи с приложением – часть 1. Общая информация» (Information technology - Security techniques - Digital signatures with appendix - Part 1: General). [i.28] ISO/IEC 14888-2 (2008 г.) «Информационные технологии – безопасные методы – цифровые подписи с приложением – часть 2. Механизмы, основанные на целочисленной факторизации» (Information technology - Security techniques - Digital signatures with appendix - Part 2: Integer factorization based mechanisms). [i.29] ISO/IEC 14888-3 (2006 г.) «Информационные технологии – безопасные методы – цифровые подписи с приложением – часть 3. Механизмы, основанные на дискретном логарифме» (Information technology - Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms). [i.30] ISO/IEC 11770-3 (2008 г.) «Информационные технологии – безопасные методы – управление ключами – часть 3. Механизмы, использующие асимметричные методы» (Information technology Security techniques - Key management - Part 3: Mechanisms using asymmetric techniques). [i.31] ANSI X9.30.1 (1997 г.) «Шифрование с открытым ключом с использованием необратимых алгоритмов – часть 1. Алгоритм цифровой подписи (DSA)» (Public Key Cryptography Using Irreversible Algorithms - Part 1: The Digital Signature Algorithm (DSA)). [i.32] ANSI X9.62 (2005 г.) «Шифрование с открытым ключом для финансовой отрасли. Алгоритм эллиптической кривой для цифровой подписи (ECDSA)» (Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA)). ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) [i.33] IETF RFC 2616 (1999) «Гипертекстовый протокол передачи – HTTP/1.1» (Hypertext Transfer Protocol - HTTP/1.1). [i.34] IETF RFC 4346 (2006) «Протокол TLS версии 1.1» (The TLS Protocol Version 1.0). [i.35] IETF RFC 5280 «Профиль сертификатов инфраструктуры открытых ключей Интернет X.509 и списков отзыва сертификатов (CRL)» (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile). [i.36] IETF RFC 3369 (2002) «Синтаксис криптографических сообщений (CMS)» (Cryptographic Message Syntax (CMS)). [i.37] ISO/IEC 15946-2 (2002 г.) «Информационные технологии – методы безопасности – криптографические методы, основанные на эллиптических кривых – часть 2. Цифровые подписи» (Information technology - Security techniques – Cryptographic techniques based on elliptic curves - Part 2: Digital signatures). [i.38] CWA 14171:2004 «Общее руководство по проверке цифровых подписей» (General guidelines for electronic signature verification). [i.39] FIPS Pub 180-2 «Стандарт безопасного хэширования (SHS)» (Secure Hash Standard (SHS)). [i.40] ANSI X9.TR 31 (2005 г.) «Спецификация обмена закрытыми ключами для симметричных алгоритмов, включая дополнение (2009 г.)» (Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms, Includes Supplement (2009 г.)). [i.41] ANSI X9.31-1 (1993 г.) «Американский национальный стандарт. Шифрование с открытым ключом с использованием обратимых алгоритмов для финансовой отрасли» (American National Standard, Public-Key Cryptography Using Reversible Algorithms for the Financial Services Industry). ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 3 Определения и аббревиатуры 3.1 Определения В данном документе применяются следующие термины и определения. Арбитр - проводит арбитраж спорных вопросов между подписывающей и проверяющей стороной, связанных с несогласием о действительности цифровой подписи. Атрибутный центр (AA) - центр, назначающий полномочия, путем выпуска атрибутных сертификатов. Список отзыва атрибутной службы (AARL) - список отзыва, содержащий ссылки на сертификаты, выданные атрибутным центрам, которые более не признаются действительными выдавшей их стороной. Список отзыва атрибутных сертификатов (ACRL) - список отзыва, содержащий список атрибутных сертификатов, которые более не признаются действительными выдавшей их службой. Сертификат центра - сертификат, выданный центру (например, центру сертификации или атрибутному центру). Центр сертификации (CA) - центр, которому доверяет один или несколько пользователей, предназначенный для создания и назначения сертификатов открытых ключей; при необходимости центр сертификации может создавать ключи пользователей. ПРИМЕЧАНИЕ. См. рекомендацию ITU-T X.509 [1]. Список отзыва центра сертификации (CARL) - список отзыва, содержащий сертификаты открытых ключей, выданные центрам сертификации, которые более не признаются действительными выдавшей их стороной. Список отзыва сертификатов (CRL) - подписанный список, содержащий набор сертификатов открытых ключей, которые более не признаются действительными выдавшей их стороной. Цифровая подпись - данные, добавленные к объекту данных, или криптографическое преобразование объекта данных, позволяющие получателю информации проверить источник и целостность объекта данных и защититься от подделки, например, отправителем. ПРИМЕЧАНИЕ. См. стандарт ISO 7498-2 [i.4]. Электронная подпись - данные в электронном виде, которые присоединены или логически связаны с другими электронными данными и которые используются для проверки подлинности. ПРИМЕЧАНИЕ. См. директиву 1999/93/EC [i.5] Европейского парламента и Совета от 13 декабря 1999 г., посвященную электронным подписям. Электронная подпись с явно указанным регламентом (EPES) - электронная подпись, в которой регламент подписи, используемый для ее проверки, указан явно. Расширенные электронные подписи - электронные подписи, дополненные согласно базовым требованиям дополнительными данными, такими как штампы времени и данные об отзыве сертификата, используемыми для устранения распространенных угроз. Период отсрочки - период времени, в течение которого сведения об отзыве сертификата могут передаваться участвующим сторонам в процессе отзыва. Исходная проверка - процесс, выполняемый проверяющей стороной после создания электронной подписи для получения дополнительной информации, которая позволяет сделать подпись долгосрочной. Сертификат открытого ключа (PKC) - открытый ключ пользователя, который в сочетании с дополнительной информацией, защищен от подделок с помощью цифровой подписи с закрытым ключом центра сертификации, выдавшего данный сертификат. ПРИМЕЧАНИЕ. См. рекомендацию ITU-T X.509 [1]. Алгоритм Ривеста-Шамира-Эдльмана (RSA) - асимметричный криптографический алгоритм, основанный на ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) сложности факторизации очень больших чисел с использованием пары ключей: закрытого и открытого. Издатель регламента подписи - лицо, определяющее и издающее регламент подписи. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Регламент подписи - набор правил для создания и проверки электронной подписи, который определяет технические и процедурные требования для создания и проверки электронных подписей с целью удовлетворения определенных деловых потребностей и с помощью которого можно проверить действительность подписи. Регламент проверки подписи - часть регламента подписи, которая определяет технические требования к подписывающей стороне для создания подписи и к проверяющей стороне для проверки подписи. Подписывающая сторона – лицо, создающее электронную подпись. Последующая проверка - процесс, выполняемый проверяющей стороной для оценки действительности подписи. ПРИМЕЧАНИЕ. Последующая проверка может быть выполнена даже через несколько лет после создания подписи и завершения исходной проверки. Для нее не требуются дополнительные данные, кроме тех, что были получены во время исходной проверки. Метка времени - информация в журнале аудита от поставщика доверенных услуг, которая привязывает представление данных к определенному времени, тем самым предоставляя доказательства, что данные существовали до этого времени. Служба меток времени - доверенная третья сторона, создающая записи в журнале аудита, чтобы указать, что данные существовали до определенного момента времени. Штамп времени - объект данных, который привязывает представление данных к определенному времени, тем самым предоставляя доказательства, что данные существовали до этого времени. Служба штампов времени (TSA) - доверенная третья сторона, создающая штампы времени, чтобы указать, что данные существовали до определенного момента времени. Модуль штампов времени (TSU) - набор программного и аппаратного обеспечения, управляемого как отдельный модуль, с единым действующим ключом подписания штампа времени. Поставщик доверенных услуг (TSP) - лицо, помогающее установить доверенные отношения, предоставляя определенную информацию по запросу. Действительная электронная подпись - электронная подпись, прошедшая проверку. Проверочные данные – дополнительные данные, которые могут использоваться проверяющей стороной для проверки действительности электронной подписи. Проверяющая сторона - лицо, проверяющее информацию. ПРИМЕЧАНИЕ 1. См. стандарт ISO/IEC 13888-1 [i.6]. ПРИМЕЧАНИЕ 2. В контексте данного документа - это лицо, проверяющее электронную подпись. 3.2 Аббревиатуры Для целей настоящего документа используются следующие аббревиатуры: AA AARL ACRL API ARL ASCII ASN.1 CA CAD CAdES CAdES-A CAdES-BES CAdES-C CAdES-EPES CAdES-T CadES-X Long атрибутный центр; список отзыва атрибутного центра; список отзыва атрибутных сертификатов; интерфейс прикладных программ; список отзыва служб; американская кодовая таблица - American Standard Code for Information Interchange; язык Abstract Syntax Notation 1; Центр сертификации; модуль приема карт; усовершенствованная электронная подпись CMS; подпись CAdES с архивными проверочными данными; простая электронная подпись CAdES; подпись CAdES с полными проверочными данными; электронная подпись CAdES с явно указанным регламентом; подпись CAdES со значением времени; подпись CAdES с расширенными долгосрочными проверочными данными; ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) подпись CAdES с расширенными проверочными данными; список отзыва центра сертификации; Европейский комитет по стандартизации; синтаксис криптографических сообщений; обобщенная архитектура посредника объектных запросов; список отзыва сертификатов; соглашение семинара CEN; отличительные правила кодирования (для ASN.1); дискретный логарифм; алгоритм цифровой подписи; CAdES-X CARL CEN CMS CORBA CRL CWA DER DL DSA ПРИМЕЧАНИЕ. сведения о криптографических алгоритмах см. в приложении Д; эллиптическая кривая; эллиптическая кривая-Эгнью, Мюллер, Вэнстоун; эллиптическая кривая-алгоритм цифровой подписи; эллиптическая кривая-Нюберг, Рюппель; стандарт электронного обмена данными в управлении, торговле и на транспорте; европейская инициатива по стандартизации электронных подписей; электронная подпись, основанная на явно указанном регламенте; электронная подпись; улучшенные службы безопасности (улучшенный CMS); язык определения интерфейса; целочисленная факторизация; многоцелевые расширения электронной почты; Национальный институт стандартов и технологий; протокол OCSP; идентификатор объекта; группа управления объектами; сертификат открытого ключа; инфраструктура открытых ключей с использованием X.509 (рабочая группа IETF); Центр регистрации; алгоритм Ривеста-Шамира-Эдльмана; безопасный алгоритм хэширования 1; EC EC-AMV ECDSA EC-NR EDIFACT EESSI EPES ES ESS IDL IF MIME NIST OCSP OID OMG PKC PKIX RA RSA SHA-1 ПРИМЕЧАНИЕ. TSA TSP TST TSU URI URL XAdES XML XMLDSIG сведения о криптографических алгоритмах см. в приложении Д; служба штампов времени; поставщик доверенных услуг; штамп времени; модуль штампов времени; универсальный код ресурса; универсальный указатель ресурса; усовершенствованные электронные подписи XML; расширяемый язык разметки; цифровая подпись XML. Обзор 4 В данном документе определен ряд форматов электронной подписи (ES), основанных на CMS (RFC 3852 [4]) с добавлением подписанных и неподписанных атрибутов. В этом пункте представлены следующие сведения: • описание основных участвующих сторон (4.1); • концепция регламентов подписей (4.2); • обзор различных форматов электронной подписи (4.3); • концепция проверочных данных и обзор форматов, использующих проверочные данные (4.4); ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) • вопросы арбитража (4.5) и процесса проверки (4.6). Формальные спецификации атрибутов представлены в пунктах 5 и 6, в приложениях В и Г представлено описание определений различных форм электронных подписей. Основные участники 4.1 Согласно данному документу, основными участниками деловых операций, обеспечиваемых электронными подписями, являются: • подписывающая сторона; • проверяющая сторона; • поставщики доверенных услуг (TSP); • арбитр. Подписывающая сторона создает электронную подпись. Когда подписывающая сторона добавляет цифровую подпись к данным с использованием заданного формата, тем самым она берет на себя обязательства по отношению к подписываемым данным. Проверяющая сторона проверяет электронную подпись. Проверяющей стороной может быть одно лицо или несколько лиц. Поставщики доверенных услуг (TSP) – это одно или несколько лиц, которые позволяют создать доверенные отношения между подписывающей и проверяющей стороной. Они осуществляют поддержку подписывающей и проверяющей стороны с помощью соответствующих служб, в том числе: • сертификатов пользователей; • перекрестных сертификатов, штампов времени; • списков отзыва сертификатов, списков отзыва служб и ответов OCSP. Следующие поставщики доверенных услуг используются для обеспечения функций, определенных в данном документе: • центры сертификации; • центры регистрации; • издатели CRL; • службы OCSP; • центры хранения (например, каталог); • службы штампов времени; • службы меток времени; • издатели регламентов подписи. Центры сертификации предоставляют пользователям сертификаты открытых ключей и услуги по их отзыву. Центры регистрации позволяют идентифицировать и регистрировать лица до того, как центр сертификации создаст сертификаты. Центры хранения публикуют списки отзыва сертификатов, выданные центрами сертификации, регламенты подписей, выданные издателями регламентов подписей и, дополнительно, сертификаты открытых ключей. Службы штампов времени подтверждают, что определенные данные были сформированы до указанного времени. Службы меток времени регистрируют то, что определенные данные были сформированы до указанного времени. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Издатели регламентов подписей определяют регламенты подписей, используемые подписывающими и проверяющими сторонами. В некоторых случаях требуется использование следующих поставщиков доверенных услуг: • атрибутные центры. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Атрибутные центры предоставляют пользователям атрибуты, связанные с сертификатами открытых ключей. Арбитр – это лицо, проводящее арбитраж спорных ситуаций между подписывающей и проверяющей сторонами. 4.2 Регламенты подписей В данном документе описывается концепция регламентов подписи, которую можно использовать для обеспечения технической согласованности при проверке электронных подписей. Если подробный регламент подписи, используемый проверяющей стороной, явно указан подписывающей стороной или его использование подразумевается подписываемыми данными, то при проверке электронной подписи можно получить согласованные результаты. Если регламент подписи, используемый проверяющей стороной, не указан явно подписывающей стороной или его нельзя определить по другим данным, или если регламент подписи неполный, то проверяющие стороны, в том числе арбитры, могут получить разные результаты при проверке электронной подписи. Поэтому рекомендуется использовать подробные регламенты подписей, обеспечивающие согласованность проверки подписи с точки зрения как подписывающей, так и проверяющей сторон. Дополнительные сведения о регламентах подписей представлены в следующих источниках: • TR 102 038 [i.7]; • пунктах 5.8.1, В.1 и В.3.1 настоящего документа; • RFC 3125 [i.8]; • TR 102 272 [i.2]. 4.3 Форматы электронных подписей В данном пункте представлен обзор двух форм усовершенствованной электронной подписи CMS, описанной в настоящем документе, а именно простой электронной подписи CAdES (CAdES-BES) и электронной подписи CAdES на основе явно указанного регламента (CAdES-EPES). В соответствии с данным документом подписывающая сторона должна создать подпись в одном из этих форматов. 4.3.1 Простая электронная подпись CAdES (CAdES-BES) Простая электронная подпись CAdES (CAdES-BES) согласно настоящему документу содержит: • подписанные пользовательские данные (например, документ подписывающей стороны), как определено в CMS (RFC 3852 [4]); • набор обязательных подписанных атрибутов, как определено в CMS (RFC 3852 [4]) и ESS (RFC 2634 [5]); • дополнительные обязательные подписанные атрибуты, определенные в данном документе; • значение цифровой подписи, вычисленное для пользовательских данных и для подписанных атрибутов при их наличии, как указано в CMS (RFC 3852 [4]). Простая электронная подпись CAdES (CAdES-BES), согласно данному документу, может содержать: • набор дополнительных подписанных атрибутов; • набор дополнительных неподписанных атрибутов. Обязательные подписанные атрибуты: • Content-type. Этот атрибут определен в документе RFC 3852 [4] и определяет тип подписываемого значения EncapsulatedContentInfo. Подробные сведения см. в пункте 5.7.1 настоящего документа. Обоснование его включения указано в пункте В.3.7. • Message-digest. Этот атрибут определен в документе RFC 3852 [4] и определяет хэш-значение сообщения строки октетов (OCTET STRING) eContent в подписываемом элементе encapContentInfo. Подробные сведения см. в пункте 5.7.2. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) • ESS signing-certificate ИЛИ ESS signing-certificate-v2. Атрибут ESS signingcertificate определен в стандарте Enhanced Security Services (ESS), RFC 2634 [5] и позволяет использовать только SHA-1 как алгоритм хэширования. Атрибут ESS signing-certificate-v2 определен в документе ESS Update: Adding CertID Algorithm Agility, опубликованном в документе RFC 5035 [15], и разрешает использовать любой алгоритм хэширования. Электронная подпись CAdES-BES, соответствующая требованиям данного документа, должна содержать один из этих атрибутов. Подробное описание этих атрибутов см. в пункте 5.7.3. Обоснование его включения указано в пункте В.3.3. Необязательные подписанные атрибуты могут быть добавлены в электронную подпись CAdES-BES, в том числе необязательные подписанные атрибуты, определенные в CMS (RFC 3852 [4]), ESS (RFC 2634 [5]) и настоящем документе. Далее перечислены необязательные атрибуты, определенные в пункте 5, обоснование использования которых приведено в приложении В: • Signing-time: согласно CMS (RFC 3852 [4]), указывает время подписи, как заявлено подписывающей стороной. Подробные сведения и краткое обоснование указаны в пункте 5.9.1. В пункте В.3.6 приводится полное обоснование. • content-hints: согласно ESS (RFC 2634 [5]), предоставляет сведения, описывающие наиболее глубоко вложенное подписанное содержимое многоуровневого сообщения, если одно содержимое встроено в другое. В пункте 5.10.1 представлена подробная спецификация. В пункте В.30.8 представлено обоснование. • content-reference: согласно ESS (RFC 2634 [5]), может быть использован как способ привязки сообщений запроса и ответа при обмене данными между двумя сторонами. В пункте 5.10.1 представлена подробная спецификация. В пункте В.3.9 представлено обоснование. • content-identifier: согласно ESS (RFC 2634 [5]), содержит идентификатор, который можно использовать в дальнейшем в предыдущем описанном атрибуте content-reference. В пункте 5.10.2 представлена подробная спецификация. • commitment-type-indication: этот атрибут определен в данном документе как способ указания обязательства, которое берет на себя подписывающая сторона при создании подписи. В пункте 5.11.1 представлена подробная спецификация. В пункте В.3.2 представлено обоснование. • signer-location: этот атрибут определен в данном документе. Он позволяет подписывающей стороне указать место, где подписывающая сторона предположительно создала подпись. В пункте 5.11.2 представлена подробная спецификация. В пункте В.3.5 представлено обоснование. • Signer-attributes: этот атрибут определен в данном документе. Он позволяет встроить заявленную или сертифицированную роль в подписанные данные. В пункте 5.11.3 представлена подробная спецификация. В пункте В.3.4 представлено обоснование. • content-time-stamp: этот атрибут определен в данном документе. Он позволяет встроить подписываемый штамп времени данных в подписываемую информацию. Атрибут предоставляет доказательство существования данных до создания подписи. В пункте 5.11.4 представлена подробная спецификация. В пункте В.3.6 представлено обоснование. Форма CAdES-BES также может содержать экземпляры неподписанных атрибутов согласно CMS (RFC 3852 [4]) и ESS (RFC 2634 [5]). • Атрибут CounterSignature согласно CMS (RFC 3852 [4]); его можно использовать, если требуются встроенные подписи (т. е. подпись предыдущей подписи). В пункте 5.9.2 представлена подробная спецификация. В пункте В.5 представлено обоснование. Структура электронной подписи CAdES-BES представлена на рис. 1. Электр. подпись (CAdES -BES) Документ подписывающ ей стороны Подписанные атрибуты ETSI Цифровая подпись ETSI TS 101 733, версия 1.8.3 (2011-01) Рисунок 1. Схема формата CAdES-BES Требования соответствия для подписывающей стороны CAdES-BES определены в пункте 8.1. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) ПРИМЕЧАНИЕ. CAdES-BES – это минимально возможный формат электронной подписи, которую должна создать подписывающая сторона. Он не предоставляет достаточно информации для долгосрочной проверки. Например, информация об отзыве, выданная соответствующим издателем, должна быть доступна для долгосрочной проверки (см. пункт 4.4.2). Формат CAdES-BES удовлетворяет юридические требования для электронных подписей, определенных в Европейской директиве по электронным подписям [i.5], (дальнейшее обсуждение связи данного документа с директивой см. в приложении В). Он обеспечивает базовую проверку подлинности и защиту целостности. Семантика подписанных данных формата CAdES-BES и его контекст могут неявно указывать проверяющей стороне на регламент подписи. Спецификация содержимого регламентов подписей выходит за рамки данного документа. Однако дополнительные сведения о регламентах подписей приведены в TR 102 038 [i.7], RFC 3125 [i.8] и пунктах 5.8.1, В.1 и В.3.1 настоящего документа. 4.3.2 Электронные подписи CAdES с явно указанным регламентом (CAdES-EPES) Согласно настоящему документу, электронная подпись CAdES с явно указанным регламентом (CAdES-EPES) расширяет определение электронной подписи для соответствия определенному регламенту подписи. Электронная подпись CAdES с явно указанным регламентом (CAdES-EPES) содержит подписанный атрибут (sigPolicyID), указывающий регламент подписи, который должен будет использоваться для проверки электронной подписи. Данный подписанный атрибут защищен подписью. В подписи также могут быть другие подписанные атрибуты, необходимые для соответствия требуемому регламенту подписи. В пункте 5.7.3 представлено описание атрибута signature-policy-identifier. В пункте В.1 представлено краткое обоснование его использования. Спецификация содержимого регламентов подписей выходит за рамки данного документа. Дополнительные сведения о регламентах подписей приведены в TR 102 038 [i.7] и пунктах 5.8.1, В.1 и В.3.1 данного документа. Структура электронной подписи CAdES-EPES представлена на рис. 2. Электр. подпись (CAdES -EPES ) Документ подписывающе й стороны Идентификатор регламента подписи Подписанные атрибуты Цифровая подпись Рисунок 2. Схема формата CAdES-EPES Требования соответствия для подписывающей стороны CAdES-EPES определены в пункте 8.2. 4.4 Форматы электронных подписей с проверочными данными Согласно настоящему документу, для проверки электронной подписи требуются дополнительные данные. Эти дополнительные данные называются проверочными данными и содержат: • сертификаты открытых ключей (PKC); • информацию о статусе отзыва для каждого PKC; • доверенные штампы времени, примененные к цифровой подписи; в противном случае метка времени должна ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) быть доступна в журнале аудита; • сведения о регламенте подписи, используемом для проверки электронной подписи, если это необходимо. Проверочные данные могут собираться подписывающей стороной, проверяющей стороной или ими обеими. При наличии подписанного атрибута signature-policy-identifier он должен соответствовать требованиям регламента подписи. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Проверочные данные содержат сертификаты центра сертификации, а также сведения о статусе отзыва в форме списков отзыва сертификатов (CRL) или информации о статусе сертификата (OCSP), предоставленного службой OCSP. Проверочные данные также содержат доказательства того, что подпись была создана до определенного момента времени. Ими могут быть штамп времени или метка времени. В данном документе определены неподписанные атрибуты с возможностью включения проверочных данных, которые можно добавлять в подписи CAdES-BES и CAdES-EPES, что позволяет получить форматы электронной подписи, содержащие проверочные данные. В пунктах 4.4.1-4.4.4 приводится описание этих форматов и их основных характеристик. 4.4.1 Электронная подпись со значением времени (CAdES-T) Согласно настоящему документу, электронная подпись со значением времени (CAdES-T) – это электронная подпись, для которой существует связанное с ней доверенное время. Доверенное время может быть указано следующими способами: • как неподписанный атрибут time-stamp, добавляемый к электронной подписи; • как метка времени электронной подписи, предоставленная поставщиком доверенных услуг. Атрибут time-stamp содержит штамп времени значения электронной подписи. В пункте 6.1.1 представлена подробная спецификация. В пункте В.4.3 представлено обоснование. Метка времени, предоставленная поставщиком доверенных услуг, должна иметь такой же смысл для атрибута signature-time-stamp, но в этом случае в электронную подпись атрибут не добавляется, а доказательства метки времени должны быть предоставлена поставщиком доверенных услуг. Управление метками времени выходят за рамки данного документа. Наличие доверенного времени предоставляет начальные возможности для обеспечения долгосрочного действия электронной подписи. Электронные подписи с атрибутом time-stamp или простые электронные подписи или электронные подписи с явно указанным регламентом с меткой времени, формирующие CAdES-T, показаны на рис. 3. CAdES-T CAdES-BES или CAdES-EPES Документ подписывающ ей стороны Подписанные атрибуты Цифровая подпись атрибут signature- timestamp, необходимый при использовании штампов времени. Иначе, подпись BES/EPES должна иметь соответствующую метку времени. Управление меткой времени и ее предоставление является обязанностью TSP. ПРИМЕЧАНИЕ 1. Штамп времени добавляется в CAdES-BES или CAdES-EPES как неподписанный атрибут. ПРИМЕЧАНИЕ 2. Штампы времени сами могут содержать неподписанные атрибуты, необходимые для проверки штампа времени, например атрибуты complete-certificate-references и complete-revocation-references, как указано в настоящем документе. Рисунок 3. Схема форматов CAdES-T ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 4.4.2 Электронная подпись с полным набором проверочных данных (CAdES-C) Согласно настоящему документу, электронная подпись с полным набором проверочных данных (CAdES-C) добавляет в подпись CAdES-T атрибуты complete-certificate-references и complete-revocationreferences. Атрибут complete-certificate-references содержит ссылки на все этапы сертификации, присутствующие в пути сертификации, используемом для проверки подписи. Атрибут complete-revocationreferences содержит ссылки на списки отзыва сертификатов и/или на ответы OCSP, используемые для проверки подписи. В пункте 6.2 представлена подробная спецификация. Хранение ссылок позволяет хранить значения пути сертификации, а также списки отзыва сертификатов или ответы OCSP в другом месте, что сокращает размер хранимой электронной подписи. В пунктах В.4.1-В.4.2 приводится обоснование использования проверочных данных и ситуаций, в которых нужно создавать подписи в формате CAdES-C. Электронные подписи с дополнительными проверочными данными, формирующими подпись CAdES-C, показаны на рис. 4. CAdES-T CAdES-BES или CAdES-EPES Документ подписываю щей стороны Подписанные атрибуты Цифровая подпись При отсутствии метки времени атрибут штампа времени является обязательным для цифровой подписи CAdES-C Полные ссылки на сертифик аты и списки отзыва Рисунок 4. Схема формата CAdES-C ПРИМЕЧАНИЕ 1. Полные ссылки на сертификаты и списки отзыва добавляются в CAdES-T как неподписанный атрибут. ПРИМЕЧАНИЕ 2. Как минимум, подписывающая сторона предоставляет CAdES-BES или, при указании того, что подпись соответствует конкретному регламенту подписи, CAdES-EPES. ПРИМЕЧАНИЕ 3. Чтобы сократить риски отказа от создания подписи, указанное доверенное время должно быть максимально близко ко времени создания подписи. Подписывающая сторона или поставщик доверенных услуг могут предоставить подпись CAdES-T. В противном случае проверяющая сторона должна создать подпись CAdES-T при первом получении электронной подписи, так как CAdES-T предоставляет независимое доказательство существования подписи до указанного доверенного времени. ПРИМЕЧАНИЕ 4. Указание доверенного времени CAdES-T должно быть создано до отзыва или истечения срока действия сертификата. ПРИМЕЧАНИЕ 5. Подписывающая сторона и поставщик доверенных услуг могут предоставить подпись CAdES C для минимизации подобного риска, а если подписывающая сторона не предоставляет CAdESC, проверяющая сторона должна создать CAdES-C, когда необходимый компонент отзыва и проверочных данных станут доступными. Для этого может понадобиться период отсрочки. ПРИМЕЧАНИЕ 6. Период отсрочки позволяет распространить информацию об отзыве сертификата в процессе отзыва. Этот период может продлиться от времени запроса отзыва сертификата уполномоченным лицом до времени, когда информация станет доступна для использования. Чтобы убедиться, что сертификат не был отозван на момент времени добавления метки или штампа времени в подпись, проверяющим сторонам следует дождаться окончания периода отсрочки. Регламент подписи может определять конкретные значения для периодов отсрочки. Схема периода отсрочки приведена на рис. 5. ‘ ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Период отсрочки Время создания подписи Первая проверка статуса отзыва Формирорван ие CAdES-C Формирование и проверка пути сертификации Вторая проверка статуса отзыва Штамп времени или метка времени для подписи Рисунок 5. Схема периода отсрочки ПРИМЕЧАНИЕ 7. В CWA 14171 [i.38] определен процесс проверки подписи с помощью CAdES-T, CAdES-C и периода отсрочки. В приложении Б приведены примеры процессов проверки. В пункте В.4 представлены дополнительные сведения об использовании периодов отсрочки во время проверки. Требования соответствия для проверяющей стороны определены в пункте 8.3 для подписей CAdES-C со штампом времени и пункте 8.4 для подписей CAdES-C с метками времени. В настоящем документе определяются требования по соответствию только для проверяющей стороны с электронной подписью с полным набором проверочных данных (CAdES-C). Это значит, что не требуется реализовывать расширенные и архивные формы электронной подписи, определенные в пунктах 4.4.3-4.4.4, для совместимости с данным документом. 4.4.3 Расширенные форматы электронных подписей Формат CAdES-C можно расширить, добавив неподписанные атрибуты в электронную подпись. В настоящем документе определяются различные неподписанные атрибуты, применимые для долгосрочной проверки и для предотвращения некоторых аварийных ситуаций, описанных в приложении В. В приложении Б представлено описание различных расширенных форматов, всех обязательных неподписанных атрибутов для каждого типа и способов их использования в процессе проверки электронной подписи. В пунктах 4.4.3.1-4.4.3.4 приведен обзор различных форм расширенных форматов подписей. 4.4.3.1 Расширенная долгосрочная электронная подпись (CAdES-X Long) Согласно настоящему документу, долгосрочная расширенная подпись (CAdES-X Long) добавляет атрибуты certificate-values и revocation-values в формат CadES-C. Первый из них содержит весь путь сертификации, необходимый для проверки подписи. Второй атрибут содержит списки отзыва сертификатов и ответы OCSP, необходимые для проверки подписи. Они обеспечивают хранение информации о сертификатах и отзывах, необходимой для проверки CAdES-C, и предотвращают утерю информации. В пунктах 6.3.3 и 6.3.4 представлена подробная спецификация. В пункте Б.1.1 приводится описание создания формата подписи. В пунктах В.4.1-В.4.2 представлено обоснование использования. Структура формата CAdES-X Long представлена на рис. 6. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) CAdES-X Long CAd ES-C CAd ES Идентификатор регламента подписи (необязательно) Подписанные атрибуты Цифровая подпись Штамп времени необязателен при наличии метки времени Полные ссылки на сертификат ы и списки отзыва Полные данные сертификато в и списков отзыва Рисунок 6. Схема формата CAdES-X-Long 4.4.3.2 Type 1) Расширенная электронная подпись с типом времени (Time Type) 1 (CAdES-X Согласно данному документу, расширенный формат подписи с типом времени 1 (CAdES-X Type 1) добавляет атрибут CAdES-C-time-stamp, содержимое которого является штампом времени на самой подписи CAdES-C, в формат подписи CAdES-C. Это обеспечивает защиту целостности и доверенного времени во всех элементах и ссылках. Это позволяет защищать сертификаты, списки отзыва сертификатов и ответы OCSP при компрометации ключа центра сертификации, ключа списка отзыва сертификатов или ключа издателя OCSP. В пункте 6.3.5 представлена подробная спецификация. В пункте Б.1.2 приводится описание процесса добавления штампов времени. В пункте В.4.4.1 представлено обоснование. Структура формата CAdES-X Type 1 представлена на рис. 7. CAdES-X type 1 CAdES-C CAdES Идентификатор регламента подписи (необязательно) Подписанные атрибуты Цифровая подпись Штамп времени необязателен при наличии метки времени Полные ссылки на сертификат ы и списки отзыва Штамп времени для CAdES-C Рисунок 7. Схема формата CAdES-X Type 1 4.4.3.3 Type 2) Расширенная электронная подпись с типом времени (Time Type) 2 (CAdES-X Согласно данному документу, расширенный формат подписи с типом времени 2 (CAdES-X Type 2) добавляет к формату CAdES-C атрибут CAdES-C-time-stamped-certs-crls-references, содержимым которого является штамп времени на ссылках на путь сертификации и сведения об отзыве. Это обеспечивает защиту целостности и доверенного времени во всех ссылках. Это позволяет защищать сертификаты, списки отзыва сертификатов и ответы OCSP при компрометации ключа службы сертификации, ключа списка отзыва сертификатов или ключа издателя OCSP. Форматы CAdES-X Type 1 и CAdES-X Type 2 защищают от одних и тех же угроз. Выбор одного из этих двух форматов зависит от среды. В пункте 6.3.5 представлена подробная спецификация. В пункте Б.1.3 приводится описание процесса создания штампов времени. В пункте В.4.4.2 представлено обоснование. Структура формата CAdES-X Type 2 представлена на рис. 8. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) CAdES-X Type 2 CAdES-C CAdES Идентификато р регламента подписи (необязательн о) Цифровая подпись Подписанные атрибуты Штамп времени необязателен при наличии метки времени Полные ссылки на сертификаты и списки отзыва Штамп времени только для полных ссылок на сертификаты и списки отзыва Рисунок 8. Схема формата CAdES-X Type 2 4.4.3.4 Расширенная долгосрочная электронная подпись с типом времени 1 или 2 (CAdES-X Long) Согласно данному документу, формат расширенной долгосрочной электронной подписи со значением времени (CAdES-X Long Type 1 или 2) – это сочетание подписи CAdES-X Long и одного из ранее описанных типов (CAdESX Type 1 и CAdES-X Type 2). В пункте Б.1.4 приводится описание процесса создания штампов времени. В пункте В.4.8 представлено обоснование. Структура форматов CAdES-X Long Type 1 и CAdES-X Long Type 2 представлена на рис. 9. CAdES-X Long Type 1 или 2 CAdES-C CAdES Идентификатор регламента подписи (необязательно ) Подписанные и неподписанные атрибуты Цифровая подпись Штамп времени для CAdES-C Штамп времени необязателен при наличии метки времени Полные ссылки на сертификат ы и списки отзыва Штамп времени для полных ссылок на сертификаты и списки отзыва Полные значения сертификато в и списков отзыва Рисунок 9. Схема форматов CAdES-X Long Type 1 и CAdES-X Long Type 2 4.4.4 Архивная электронная подпись (CAdES-A) Согласно настоящему документу, архивная форма электронной подписи (CAdES-A) формируется на основе CAdES-X Long, CAdES-X Long Type 1 или 2 за счет добавления одного или нескольких атрибутов archive-time-stamp. Эта форма используется для архивации долгосрочных подписей. Последовательные штампы времени защищают весь материал от уязвимостей алгоритмов хэширования или взлома криптографического материала или криптографических алгоритмов. В пункте 6.4 представлена подробная спецификация. В пунктах В.4.5 и В.4.8 представлено обоснование использования. Структура формы электронной подписи CAdES-A представлена на рис. 10. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) CAdES-A CAdES-C CAdES-BES Все Идентификато р регламента подписанные и неподписанные подписи атрибуты (необязательн о) Цифровая подпись Штамп времени для цифровой подписи Штамп времени для CAdES Полные ссылки на сертификаты и списки отзыва Штамп времени для полных ссылок на сертификаты и списки отзыва Полные значения сертификатов и списков отзыва Архивный штамп времени Рисунок 10. Схема формата CAdES-A 4.5 Арбитраж Электронная подпись в формате CAdES-C может использоваться для арбитража при возникновении разногласий между подписывающей и проверяющей стороной и при выполнении следующих условий: • арбитр знает, где получить сертификат подписывающей стороны (если его еще нет), все перекрестные сертификаты и необходимые списки отзыва сертификатов, списки отзыва атрибутных сертификатов и ответы OCSP, ссылки на которые указаны в подписи CAdES-C; • при использовании штампов времени в подписи CAdES-T сертификат от модуля штампов времени, выдавшего штамп времени в формате CAdES-T, должен быть еще действителен; • при использовании штампов времени в подписи CAdES-T сертификат от модуля штампов времени, выдавшего штамп времени в формате CAdES-T, не отозван на момент арбитража; • при использовании меток времени в подписи CAdES-T служба меток времени предоставляет доступ к надежному журналу аудита для просмотра значений времени; • ни один из закрытых ключей, соответствующих сертификатам, используемым для проверки цепочки подписей, не был скомпрометирован; • криптографический алгоритм, использованный во время создания подписи CAdES-C, не был взломан на момент арбитража; • если регламент подписи может быть определен явно или неявно, то арбитр может определить правила, необходимые для проверки электронной подписи. 4.6 Процесс проверки В процессе проверки выполняется проверка электронной подписи. В результате может быть получен один из следующих статусов: • недействительный; • незавершенная проверка; • действительный. Недействительный статус означает, что формат подписи неправильный или цифровая подпись не смогла пройти проверку (например, произошла ошибка проверки целостности цифровой подписи или один из сертификатов, от которого зависит проверка цифровой подписи, является недействительным или отозванным). Незавершенная проверка означает, что статус проверки подписи на данный момент неизвестен. В случае ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) незавершенной проверки приложению или пользователю могут быть предоставлены дополнительные сведения. Это позволит определить дальнейший ход действий при работе с электронной подписью. При незавершенной проверке электронную подпись можно проверить позже, когда станет доступна дополнительная информация. ПРИМЕЧАНИЕ. Статус незавершенной проверки, например, может быть вызван недоступностью всех необходимых сертификатов или незаконченным периодом отсрочки. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Действительный статус означает, что подпись прошла проверку и соответствует регламенту проверки подписи. Примеры последовательностей проверки приведены в приложении Б. Атрибуты электронных подписей 5 Этот пункт основан на существующем синтаксисе CMS, определенном в документе RFC 3852 [4], и улучшенных службах безопасности (ESS), определенных в документе RFC 2634 [5]. Общая структура электронной подписи соответствует структуре, определенной в CMS. Электронная подпись использует атрибуты, определенные в CMS, ESS и настоящем документе. В настоящем документе определены атрибуты подписи, используемые, но не определенные в других материалах. В настоящем документе определен минимально необходимый набор атрибутов и значения цифровой подписи для электронной подписи. Регламент подписи может требовать наличия других подписанных атрибутов. 5.1 Общий синтаксис Общий синтаксис электронной подписи соответствует синтаксису, определенному в CMS (RFC 3852 [4]). ПРИМЕЧАНИЕ. Синтаксис CMS определяет типы содержимого для атрибутов id-data, id-signedData, id-envelopedData, id-digestedData, id-encryptedData и id-authenticatedData. Хотя CMS разрешает определение других типов содержимого в других документах, тип ASN.1 не должен быть типом CHOICE (выбор). В данном документе не определяются другие типы содержимого. 5.2 Тип содержимого данных Тип содержимого данных электронной подписи соответствует типу, определенному в CMS (RFC 3852 [4]). ПРИМЕЧАНИЕ. Если типом содержимого является id-data, рекомендуется кодировать содержимое с помощью формата MIME и использовать тип MIME для определения формата представления данных. Пример использования MIME для определения типа кодирования см. в пункте Е.1. 5.3 Тип содержимого подписанных данных Тип содержимого Signed-data электронной подписи соответствует типу, определенному в CMS (RFC 3852 [4]). 5.4 Тип SignedData Синтаксис типа SignedData соответствует синтаксису, определенному в CMS (RFC 3852 [4]). Поля типа SignedData соответствуют полям, определенным в CMS (RFC 3852 [4]). Идентификатор сертификата подписывающей стороны, использованного для создания подписи, всегда подписан (см. пункт 5.7.3). Регламент проверки может задавать требования наличия определенных сертификатов. Случай вырождения, в котором подписывающих сторон нет, не является действительным согласно данному документу. 5.5 Тип EncapsulatedContentInfo Синтаксис типа EncapsulatedContentInfo электронной подписи соответствует синтаксису, определенному в CMS (RFC 3852 [4]). В целях долгосрочной проверки, как определено в данном документе, рекомендуется использовать атрибут eContent или архивировать подписываемые данные так, чтобы сохранить кодирование данных. Важно, чтобы строка октетов (OCTET STRING), используемая для создания подписи, оставалась одинаковой при каждой проверке подписи арбитром или проверяющей стороной. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) ПРИМЕЧАНИЕ. необязательным: В CMS атрибут eContent является ■ если он присутствует, подписанные данные необходимо встроить в структуру SignedData, которая будет содержать как подписанные данные, так и подпись; однако доступ к подписанным данным может получить только проверяющая сторона, которая может декодировать структуру SignedData, закодированную в формате ASN.1; ■ если этот атрибут отсутствует, подписанные данные можно отправлять и хранить отдельно от подписи, а структура SignedData содержит только подпись; в этом случае только подписываемые данные необходимо сохранять и распространять таким образом для сохранения кодировки данных. Случай вырождения, когда подписывающих сторон нет, не является действительным согласно данному документу. 5.6 Тип SignerInfo Синтаксис типа SignerInfo электронной подписи соответствует синтаксису, определенному в CMS (RFC 3852 [4]). В типе SignerInfo представлена информация о подписывающей стороне. При наличии нескольких независимых подписей (см. пункт Б.5) для каждой подписывающей стороны присутствует экземпляр этого поля. Значение полей типа SignerInfo соответствует синтаксису CMS (RFC 3852 [4]), но поле signedAttrs должно содержать следующие атрибуты: • content-type, как определено в пункте 5.7.1; • message-digest, как определено в пункте 5.7.2; • signing-certificate, как определено в пункте 5.7.3. 5.6.1 Процесс вычисления хэш-значения сообщения Процесс вычисления хэш-значения соответствует процессу, определенному в CMS (RFC 3852 [4]). 5.6.2 Процесс формирования подписи Входные данные для процесса формирования подписи соответствуют данным, определенным в CMS (RFC 3852 [4]). 5.6.3 Процесс проверки подписи Процедуры проверки подписи определены в CMS (RFC 3852 [4]) и усовершенствованы в данном документе: входными данными для процесса проверки подписи должен быть открытый ключ подписывающей стороны, который должен проверяться с помощью атрибута ссылки сертификата подписи, который содержит ссылку на сертификат подписи. Т. е. если используется сертификат SigningCertificateV2 из документа RFC 5035 [15] или SigningCertificate из документа ESS RFC 2634 [5], открытый ключ из первого сертификата, который определен в последовательности идентификаторов сертификатов, полученный от SigningCertificate должен использоваться для проверки цифровой подписи. 5.7 Обязательные атрибуты простой электронной подписи Следующие атрибуты должны присутствовать в подписанных данных, определенных в данном документе. Атрибуты определены в CMS (RFC 3852 [4]). 5.7.1 Атрибут content-type Атрибут content-type показывает тип подписываемого содержимого. Синтаксис атрибутного типа content-type соответствует синтаксису, определенному в CMS (RFC 3852 [4]), пункт 11.1. ПРИМЕЧАНИЕ 1. Как указано в документе RFC 3852 [4], значение атрибута content-type (т. е. ContentType) ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) равно значению eContentType подписываемого атрибута EncapsulatedContentInfo. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) ПРИМЕЧАНИЕ 2. Для реализаций, поддерживающих создание подписей, если значением атрибута contenttype является id-data, рекомендуется кодировать eContent с использованием формата MIME. Для реализаций, поддерживающих проверку подписей, если подписанные данные (т. е. eContent) закодированы с использованием формата MIME, то идентификатором объекта атрибута content-type является id-data. В обоих случаях атрибуты content-type MIME используются для определения формата представления данных. Дополнительные сведения об использовании MIME см. в приложении Е. 5.7.2 Хэш-значение сообщения Синтаксис атрибута message-digest (хэш-значение сообщения) электронной подписи соответствует синтаксису, определенному в CMS (RFC 3852 [4]). 5.7.3 Атрибуты ссылки на сертификат подписи Атрибуты ссылки на сертификат подписи поддерживаются с помощью атрибута ESS signing-certificate или атрибута ESS-signing-certificate-v2. Эти атрибуты должны содержать ссылку на сертификат подписывающей стороны. Они предназначены для предотвращения простых атак с заменой и повторной выдачей, а также позволяют использовать ограниченный набор сертификатов для проверки подписи. У них компактная форма (намного короче, чем у полных сертификатов), что позволяет однозначно идентифицировать сертификат. Один и только один из следующих атрибутов должен присутствовать в поле signedData, определенном в данном документе: • атрибут signing-certificate ESS, определенный в документе ESS RFC 2634 [5], должен использоваться, если применяется алгоритм хэширования SHA-1; • атрибут signing-certificate-v2 ESS, определенный в документе ESS Update: Adding CertID Algorithm Agility, RFC 5035 [15], который должен использовать при применении других алгоритмов хэширования. Сертификат, используемый для проверки подписи (т. е. сертификат подписывающей стороны), должен быть определен в проверочной последовательности, и эта последовательность не должна быть пустой. Регламент проверки подписи может требовать наличия других сертификатов, которые могут содержать все сертификаты, вплоть до точки доверия. 5.7.3.1 Определение атрибута signing-certificate ESS Синтаксис атрибута типа signing-certificate электронной подписи соответствует синтаксису, определенному в улучшенных службах безопасности (ESS), RFC 2634 [5], и описывается далее в данном документе. Последовательность поля с информацией о регламенте не используется в настоящем документе. Атрибут signing-certificate ESS должен быть подписанным атрибутом. Кодированное значение ESSCertID для данного сертификата должно включать поле issuerSerial. При наличии данного атрибута значение issuerAndSerialNumber в поле SignerIdentifier структуры SignerInfo должно совпадать со значением поля issuerSerial в ESSCertID. Кроме того, значение certHash из ESSCertID должно совпадать с хэш-значением сертификата, вычисленным по алгоритму SHA-1. Опознанный сертификат должен использоваться в процессе проверки подписи. Если хэш-значение сертификата не совпадает с хэш-значением сертификата, используемого для проверки подписи, подпись должна считаться недействительной. ПРИМЕЧАНИЕ. Если атрибутный сертификат используется подписывающей стороной для связи роли или других атрибутов подписывающей стороны с электронной подписью, то данные сведения указываются в атрибуте signer-attributes, как определено в пункте 5.8.3. 5.7.3.2 Определение атрибута ESS signing-certificate-v2 Атрибут signing-certificate-v2 ESS аналогичен атрибуту signing-certificate ESS, определенному выше, за исключением того, что этот атрибут можно использовать с алгоритмами хэширования, отличными от SHA-1. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Синтаксис атрибутного типа signing-certificate-v2 электронной подписи соответствует синтаксису, определенному в документе ESS Update: Adding CertID Algorithm Agility, RFC 5035 [15] и описывается далее в данном документе. Последовательность поля с информацией о регламенте не используется в настоящем документе. Этот атрибут должен использоваться так же, как и атрибут signing-certificate ESS, описанный выше. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Идентификатор объекта данного атрибута: id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 47 } При наличии данного атрибута значение issuerAndSerialNumber в поле SignerIdentifier структуры SignerInfo должно совпадать со значением поля issuerSerial в ESSCertIDv2. Кроме того, значение certHash из ESSCertIDv2 должно совпадать с хэш-значением, вычисленным с помощью функции хэширования, указанной в поле hashAlgorithm. Опознанный сертификат должен использоваться в процессе проверки подписи. Если хэшзначение сертификата не совпадает с хэш-значением сертификата, используемого для проверки подписи, подпись должна считаться недействительной. Реализации данного документа должны поддерживать использование как атрибута signing-certificate, так и атрибута signing-certificate-v2 в штампах времени в соответствии с документом RFC 5035 [15]. ПРИМЕЧАНИЕ 1. Если атрибутный сертификат используется подписывающей стороной для связи роли или других атрибутов подписывающей стороны с электронной подписью, то данные сведения указываются в атрибуте signer-attributes, как определено в пункте 5.8.3. ПРИМЕЧАНИЕ 2. В предыдущих версиях данного документа для той же цели использовался другой атрибут сертификата подписи (см. пункт 5.7.3.3). Теперь данный атрибут не используется за счет упрощения структуры. 5.7.3.3 Другое определение атрибута signing-certificate В более ранних версиях данного документа другой атрибут signing-certificate использовался в качестве альтернативы атрибуту signing-certificate ESS при применении алгоритмов хэширования, отличных от SHA-1. Теперь данный атрибут не используется, так как структура атрибута signing-certificate-v2 была упрощена. Но его описание все равно включено в настоящий документ для обеспечения обратной совместимости. id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 19 } Атрибут other-signing-certificate заполняется так же, как атрибут OtherSigningCertificate согласно синтаксису ASN.1: OtherSigningCertificate ::= certs SEQUENCE OF policies SEQUENCE OF -- NOT USED SEQUENCE { OtherCertID, PolicyInformation OPTIONAL IN THE PRESENT DOCUMENT } OtherCertID ::= SEQUENCE { otherCertHash issuerSerial OtherHash, IssuerSerial OPTIONAL } OtherHash ::= CHOICE { sha1Hash OtherHashValue, -- This contains a SHA-1 hash otherHash OtherHashAlgAndValue} OtherHashValue ::= OCTET STRING OtherHashAlgAndValue ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue } ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 5.8 Дополнительные обязательные атрибуты для электронных подписей с явно указанным регламентом 5.8.1 Атрибут signature-policy-identifier Данный документ требует, чтобы ссылка на регламент подписи была включена в структуру signedData в подписи CAdES-EPES. Эта ссылка определяется явно. Регламент подписи определяет правила создания и проверки электронной подписи и включается как подписанный атрибут в каждую электронную подпись с явно указанным регламентом. Атрибут signature-policy-identifier должен быть подписанным атрибутом. Следующий идентификатор объекта определяет атрибут signature-policy-identifier: id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 15 } Типом значений signature-policy-identifier является тип ASN.1 SignaturePolicyIdentifier: SignaturePolicyIdentifier ::=CHOICE{ signaturePolicyId SignaturePolicyId, signaturePolicyImplied SignaturePolicyImplied -- not used in this version} SignaturePolicyId ::= SEQUENCE { sigPolicyId SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL} SignaturePolicyImplied ::= NULL Поле sigPolicyId содержит идентификатор объекта, который однозначно определяет версию регламента подписи. У этого поля следующий синтаксис: SigPolicyId ::= OBJECT IDENTIFIER Поле sigPolicyHash может содержать идентификатор алгоритма хэширования и хэш-значение регламента подписи. Значение hashValue в поле sigPolicyHash может быть равно нулю, что означает, что хэш-значение регламента неизвестно. ПРИМЕЧАНИЕ. Использование значения zero-sigPolicyHash предназначено для обеспечения обратной совместимости с предыдущими версиями данного документа. Если значение sigPolicyHash равно нулю, хэш-значение не следует сравнивать с вычисленным хэш-значением регламента подписи. Если регламент подписи определен с помощью синтаксиса ASN.1, то хэш-значение вычисляется без полей внешнего типа и длины, при этом должен использоваться алгоритм хэширования, указанный в поле sigPolicyHash. Если регламент подписи определен с помощью другой структуры, ее тип и алгоритм хэширования должны быть указаны в регламенте подписи или с помощью квалификатора регламента подписи. SigPolicyHash ::= OtherHashAlgAndValue OtherHashAlgAndValue ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue } OtherHashValue ::= OCTET STRING Идентификатор регламента подписи может быть определен с использованием другой информации о квалификаторе. Семантика и синтаксис квалификатора соответствуют семантике и синтаксису идентификатору объекта в поле the sigPolicyQualifierId. Такой квалификатор использует следующий синтаксис: SigPolicyQualifierInfo ::= SEQUENCE { sigPolicyQualifierId SigPolicyQualifierId, sigQualifier ANY DEFINED BY sigPolicyQualifierId } ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) В данном документе определены следующие квалификаторы: • spuri: содержит URI или URL – адрес ссылки на регламент подписи в Интернете; • sp-user-notice: содержит примечание пользователя, которое должно отображаться при каждой проверке подписи. -- идентефикаторы квалификаторов sigpolicyQualifierIds, описанные в настоящем документе SigPolicyQualifierId ::= OBJECT IDENTIFIER id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 1 } SPuri ::= IA5String id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2 } SPUserNotice ::= SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL} NoticeReference ::= SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } DisplayText ::= CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) } 5.9 Необязательные атрибуты, импортированные из CMS Следующие атрибуты могут присутствовать в структуре signed-data. Они определены в CMS (RFC 3852 [4]) и импортированы в данный документ. Данные атрибуты описываются в данном документе, где это необходимо. 5.9.1 Атрибут signing-time Атрибут signing-time определяет время, когда по заявлению подписывающей стороны был выполнен процесс подписания. Значением атрибута Signing-time для электронной подписи является тип ASN.1 SigningTime, как определено в CMS (RFC 3852 [4]). ПРИМЕЧАНИЕ. В документе RFC 3852 [4] указано, что «даты между 1 января 1950 г. и 31 декабря 2049 г. включительно должны кодироваться как время в формате UTC (UTCTime). Все даты до 1950 г. и после 2049 г. должны кодироваться в формате GeneralizedTime». 5.9.2 Атрибут countersignature Типом значений атрибута countersignature для электронной подписи является тип ASN.1 CounterSignature, как определено в CMS (RFC 3852 [4]). Атрибут countersignature является неподписанным атрибутом. 5.10 Необязательные атрибуты, импортированные из ESS Следующие атрибуты могут присутствовать в подписанных данных, определенных в настоящем документе. Эти атрибуты определены в ESS и импортированы в данный документ и соответствующим образом описаны здесь. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 5.10.1 Атрибут content-reference Атрибут content-reference – это ссылка одной структуры SignedData на другую. Он может использоваться для связи ответа на исходное сообщение с самим сообщением или встраивания одной структуры SignedData в другую с помощью ссылок. Атрибут content-reference является подписанным атрибутом. Типом значений атрибута content-reference для электронной подписи является тип ASN.1 ContentReference, как определено в ESS (RFC 2634 [5]). Атрибут content-reference используется, как определено в ESS (RFC 2634 [5]). 5.10.2 Атрибут content-identifier Атрибут content-identifier предоставляет идентификатор для подписанного содержимого, используемый, если ссылка на это содержимое потребуется в будущем, например, в атрибуте content-reference в других подписанных данных, присланных позже. Атрибут content-identifier является подписанным атрибутом. Типом значений атрибута content-identifier для электронной подписи является тип ASN.1 ContentIdentifier, как определено в ESS (RFC 2634 [5]). Как минимум, атрибут content-identifier должен содержать объединение идентификационной информации пользователя (такой как имя пользователя или идентификационная информация открытого ключевого материала), строку GeneralizedTime и случайное число. 5.10.3 Атрибут content-hints Атрибут content-hints предоставляет сведения о наиболее глубоко вложенном подписанном содержимом многоуровневого сообщения, в котором одно содержимое встроено в другое. Синтаксис типа атрибута content-hints электронной подписи соответствует синтаксису, определенному в ESS (RFC 2634 [5]). Если этот атрибут используется для указания точного формата данных, представляемых пользователю, применяются следующие правила: • contentType показывает тип связанного содержимого; это идентификатор объекта (т. е. уникальная строка целых чисел), назначенная службой, определяющей тип содержимого; • если значением contentType является id-data, поле contentDescription должно определять формат представления данных, который может быть задан типами MIME. Если формат содержимого задан с помощью типов MIME, применяются следующие правила: • значением contentType должен быть id-data, как определено в CMS (RFC 3852 [4]); • поле contentDescription должно использоваться для указания кодировки данных в соответствии с правилами, определенными в документе RFC 2045 [6]. Пример структурированного содержимого и типов MIME см. в приложении Е. ПРИМЕЧАНИЕ 1. pkcs7(7) 1 } id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) ПРИМЕЧАНИЕ 2. Поле contentDescription является необязательным в ESS (RFC 2634 [5]). Оно может использоваться для дополнения поля contentTypes, определенного в другом месте. Такие определения выходят за рамки данного документа. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Дополнительные необязательные атрибуты, определенные в настоящем документе 5.11 В данном пункте определяется ряд атрибутов, которые могут использоваться для предоставления дополнительной информации проверяющей стороне: а) тип обязательства подписывающей стороны; б) заявленное месторасположение создания подписи; в) заявленные атрибуты или сертифицированные атрибуты подписывающей стороны; г) штамп времени содержимого, примененный до подписания содержимого. 5.11.1 Атрибут commitment-type-indication Могут возникать ситуации, в которых подписывающая сторона хочет явно указать проверяющей стороне, что при подписывании данных она задает тип обязательства от лица подписывающей стороны. Атрибут commitment-typeindication передает такую информацию. Атрибут commitment-type-indication является подписанным атрибутом. Тип обязательства может быть: • определен как часть регламента подписи, при этом тип обязательства обладает точной семантикой, определенной как часть регламента подписи; • зарегистрированным типом, при этом тип обязательства обладает точной семантикой, определенной при регистрации и соответствующей правилам центра регистрации. Таким центром регистрации может быть торговая ассоциация или законодательный орган. Регламент подписи определяет набор атрибутов, которые он «распознает». Такой «распознанный» набор атрибутов включает все типы обязательств, определенных в регламенте подписи, а также все внешне заданные типы обязательств, которые регламент может распознавать. Это поле может содержать только распознаваемые типы обязательств. Следующий идентификатор объекта определяет атрибут commitment-type-indication: id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} Типом значений атрибута commitment-type-indication является тип ASN.1 CommitmentTypeIndication. CommitmentTypeIndication ::= SEQUENCE { commitmentTypeId CommitmentTypeIdentifier, commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF CommitmentTypeQualifier OPTIONAL} CommitmentTypeIdentifier ::= OBJECT IDENTIFIER CommitmentTypeQualifier ::= SEQUENCE { commitmentTypeIdentifier CommitmentTypeIdentifier, qualifier ANY DEFINED BY commitmentTypeIdentifier } Использование квалификаторов для типа обязательства выходит за рамки данного документа. В настоящем документе определены следующие общие типы обязательства. id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 3} id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member-body(2) ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 5} ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 6} Данные общие типы обязательства имеют следующий смысл: • Proof of origin (доказательство происхождения) указывает, что подписывающая сторона признает создание, утверждение и отправку сообщения. • Proof of receipt (доказательство получения) указывает, что подписывающая сторона признает получение содержимого сообщения. • Proof of delivery (доказательство доставки) указывает, что поставщик доверенных услуг, предоставляющий эту информацию, доставил сообщение в локальное хранилище, доступное получателю сообщения. • Proof of sender (доказательство отправителя) указывает, что лицо, предоставляющее эту информацию, отправило сообщение (но необязательно создало его). • Proof of approval (доказательство утверждения) указывает, что подписывающая сторона утвердила содержимое сообщения. • Proof of creation (доказательство создания) указывает, что подписывающая сторона создала сообщения (но необязательно утвердила или отправила его). 5.11.2 Атрибут signer-location Атрибут signer-location определяет мнемонический код адреса, определяющего географическое положение подписывающей стороны (например, город). Мнемонический код регистрируется в стране, в которой расположена подписывающая сторона, и используется для предоставления услуг общедоступной телеграфной связи (в соответствии с рекомендацией МСЭ-Т F.1 [11]). Атрибут signer-location является подписанным атрибутом. Следующий идентификатор объекта определяет атрибут signer-location: id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} Типом значений атрибута signer-location является тип ASN.1 SignerLocation: SignerLocation ::= SEQUENCE { -- at least one of the following shall be present: countryName [0] DirectoryString OPTIONAL, -- As used to name a Country in X.500 localityName [1] DirectoryString OPTIONAL, -- As used to name a locality in X.500 postalAdddress [2] PostalAddress OPTIONAL } PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 5.11.3 Атрибут signer-attributes Атрибут signer-attributes определяет дополнительные атрибуты подписывающей стороны (например, роль). Это могут быть следующие атрибуты: • заявленные атрибуты подписывающей стороны; • сертифицированные атрибуты подписывающей стороны. Атрибут signer-attributes должен быть подписанным атрибутом. Следующий идентификатор объекта определяет атрибут signer-attribute: id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} Типом значений атрибута signer-attributes является тип ASN.1 SignerAttribute: SignerAttribute ::= SEQUENCE OF CHOICE { claimedAttributes [0] ClaimedAttributes, certifiedAttributes [1] CertifiedAttributes } ClaimedAttributes ::= SEQUENCE OF Attribute ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) CertifiedAttributes ::= AttributeCertificate -- согласно определению в документе RFC 3281: см. пункт 4.1. ПРИМЕЧАНИЕ 1. Можно использовать только один атрибут signer-attributes. ПРИМЕЧАНИЕ 2. Поля Attribute и AttributCertificate определяются в соответствии с рекомендациями МСЭ-Т X.501 [9] и X.509 [1]. 5.11.4 Атрибут content-time-stamp content-time-stamp – это атрибут, являющийся штампом времени содержимого подписанных данных до их подписания. Атрибут content-time-stamp является подписанным атрибутом. Следующий идентификатор объекта определяет атрибут content-time-stamp: id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} Типом значений атрибута content-time-stamp является тип ASN.1 ContentTimestamp: ContentTimestamp::= TimeStampToken Значением messageImprint типа TimeStampToken (как описано в документе RFC 3161 [7]) должно быть хэш-значение сообщения, как указано в пункте 5.6.1 данного документа. Дополнительные сведения о типе TimeStampToken и его определение см. в пункте 7.4. ПРИМЕЧАНИЕ. Атрибут content-time-stamp указывает, что подписанная информация была сформирована до даты, заданной атрибутом content-time-stamp. 5.12 Поддержка множества подписей 5.12.1 Независимые подписи Множество независимых подписей (см. пункт Б.5) поддерживаются независимой структурой SignerInfo от каждой подписывающей стороны. Каждая структура SignerInfo должна содержать все атрибуты, требуемые настоящим документом, и должна независимо обрабатываться проверяющей стороной. ПРИМЕЧАНИЕ. Независимые подписи могут использоваться для предоставления независимых подписей от различных сторон с разными подписанными атрибутами или для предоставления множества подписей от одной стороны с использованием разных алгоритмов подписи. В последнем случае другие атрибуты (кроме значений времени и сведений о регламенте подписи) в общем случае будут одинаковыми. 5.12.2 Встроенные подписи Множество встроенных подписей (см. пункт В.5) поддерживаются с помощью неподписанного атрибута countersignature (см. пункт 5.9.2). Каждая удостоверяющая подпись в атрибуте countersignature хранится как неподписанный атрибут структуры SignerInfo, к которой применяется удостоверяющая подпись. ПРИМЕЧАНИЕ. Удостоверяющие подписи могут использоваться для предоставления подписей от различных сторон с разными подписанными атрибутами или для предоставления множества подписей от одной стороны с использованием разных алгоритмов подписи. В последнем случае другие атрибуты (кроме значений времени и сведений о регламенте подписи) в общем случае будут одинаковыми. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 6 Дополнительные атрибуты проверки электронной подписи В данном пункте определяются атрибуты, которые содержат разные типы проверочных данных. Эти атрибуты основаны на электронной подписи, описанной в пункте 5. К ним относятся следующие атрибуты: • атрибут Signature-time-stamp, применяемый к значению электронной подписи или метке времени в журнале аудита. Согласно определению, это электронная подпись со временем (CAdES-T). • Полный набор проверочных данных, которые состоят из штампа времени значения подписи и ссылок на все сертификаты (complete-certificate-references) и списки отзыва (complete-revocationreferences), используемые для полной проверки электронной подписи. Согласно определению, это электронная подпись с полным набором проверочных данных (CAdES-C). ПРИМЕЧАНИЕ 1. Форматы электронной подписи CAdES-T описаны в пункте 4.4, а соответствующие атрибуты определены в пункте 6.1.1. ПРИМЕЧАНИЕ 2. Форматы электронной подписи CAdES-C описаны в пункте 4.4. Обязательные атрибуты формата подписи CAdES-C определены в пунктах 6.2.1-6.2.2. Необязательные атрибуты определены в пунктах 6.2.3 и 6.2.4. Кроме того, определены следующие дополнительные расширенные формы проверочных данных. Обзор расширенных форм проверочных данных см. в приложении Б. • CAdES-X со штампом времени: в данном документе определены два типа штампов времени, используемых в расширенных проверочных данных. - Тип 1(CAdES-X Type 1): состоит из штампа времени для электронной подписи и полных проверочных данных (CAdES-C). - Тип 2 (CAdES-X Type2): состоит из штампа времени для ссылок на путь сертификации и ссылок на списки отзыва, используемых для поддержки CAdES-C. ПРИМЕЧАНИЕ 3. Форматы CAdES-X Type 1 и CAdES-X Type 2 описаны в пунктах Б.1.2 и Б.1.3 соответственно. • CAdES-X Long: состоит из полного набора проверочных данных (CAdES-C) и фактических значений всех данных о сертификатах и списках отзыва, используемых в CAdES-C. ПРИМЕЧАНИЕ 4. Форматы электронной подписи CAdES-X Long описаны в пункте Б.1.1. • CAdES-X Long Type 1 или CAdES-X Long Type 2: состоят из X-Time-Stamp (Type 1 или Type 2) и актуальных значений всех данных о сертификатах и списках отзыва, используемых в CAdES-C в соответствии с форматом CAdES-X Long. В данном пункте также определены структуры данных, используемые в формате архивных проверочных данных (CAdES-A) расширенных форм. • Архивная форма электронной подписи (CAdES-A) состоит из следующих элементов: - полный набор проверочных данных (CAdESC); - значения сертификатов и списков отзыва (как в формате CAdES-X Long); - любые существующие штампы времени расширенной электронной подписи (CAdES-X Type 1 или CAdES-X Type 2), если они используются; подписанные данные пользователя и дополнительный архивный штамп времени, примененный ко всем данным. Архивный штамп времени может применяться повторно через длительные промежутки времени для обеспечения действительности электронной подписи при ослаблении алгоритмов электронной подписи и штампов времени. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Дополнительные данные, необходимые для создания описанных выше форм электронной подписи, передаются как неподписанные атрибуты, связанные с отдельной подписью за счет размещения в поле unsignedAttrs структуры SignerInfo. Таким образом, все атрибуты, определенные в пункте 6, являются неподписанными атрибутами. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) ПРИМЕЧАНИЕ 5. Если требуется поддержка множества подписей, как описано в пункте 5.12, у каждой подписи должна быть отдельная структура SignerInfo. Таким образом, для создания CAdES-T, CAdES-C и т. д. каждой подписи требуются собственные значения неподписанных атрибутов. ПРИМЕЧАНИЕ 6. 6.4. 6.1 Необязательные атрибуты расширенных проверочных данных определены в пунктах 6.3 и Атрибут штампа времени подписи (CAdES-T) Электронная подпись со штампом времени – это электронная подпись, для которой доступна часть (но не все) проверочных данных, необходимых для проверки (например, доступна часть данных о сертификатах и списках отзывов, но не все эти данные). Минимальная структура проверочных данных штампа времени: • атрибут подписи time-stamp, определенный в пункте 6.1.1, примененный к значению электронной подписи. 6.1.1 Определение атрибута signature-time-stamp Атрибут signature-time-stamp – это значение TimeStampToken, вычисленное для значения подписи определенной подписывающей стороны. Это неподписанный атрибут. В электронной подписи может быть несколько экземпляров этого атрибута от разных служб штампов времени. Следующий идентификатор объекта определяет атрибут signature-time-stamp: id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} Типом значений атрибута signature-time-stamp является тип ASN.1 SignatureTimeStampToken: SignatureTimeStampToken ::= TimeStampToken Значением поля messageImprint в TimeStampToken должно быть хэш-значение поля signature в атрибуте SignerInfo для структуры signedData, к которой применяется штамп времени. Дополнительные сведения о типе TimeStampToken и его определение см. в пункте 7.4. ПРИМЕЧАНИЕ 1. При использовании множества подписей, возможны следующие варианты: TimeStampToken вычисляется для всех подписывающих сторон; TimeStampToken вычисляется для всех подписей подписывающей стороны; TimeStampToken не присутствует в подписи другой подписывающей стороны. ПРИМЕЧАНИЕ 2. При использовании нескольких подписей несколько штампов времени, выданных разными службами штампов времени, могут присутствовать в одной структуре signerInfo (см. документ RFC 3852 [4]). 6.2 Полный набор проверочных данных (CAdES-C) Электронная подпись с полным набором проверочных данных (CAdES-C) – это электронная подпись, для которой доступны все дополнительные проверочные данные, необходимые для проверки (т. е. все данные о сертификатах и списках отзывов). Эта форма основана на формате CAdES-T, описанном выше. Как минимум, полные проверочные данные должны содержать следующие элементы: • время, представленное атрибутом signature-timestamp, как определено в пункте 6.1.1, или меткой времени, которой управляет служба меток времени; ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) • атрибут complete-certificate-references, как определено в пункте 6.2.1; • атрибут complete-revocation-references, как определено в пункте 6.2.2. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 6.2.1 Определение атрибута complete-certificate-references complete-certificate-references – это неподписанный атрибут. Он ссылается на полный набор сертификатов центра сертификации, используемые для проверки электронной подписи с полными проверочными данными вплоть до сертификата подписывающей стороны (но не включая его). Только один экземпляр этого атрибута должен быть включен в электронную подпись. ПРИМЕЧАНИЕ 1. Сертификат подписывающей стороны указывается в атрибуте сертификата подписывающей стороны (см. пункт 5.7.3). id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} Для значения атрибута complete-certificate-references используется синтаксис типа ASN.1 OtherSigningCertificate: CompleteCertificateRefs ::= SEQUENCE OF OtherCertID Тип OtherCertID определен в пункте 5.7.3.3. IssuerSerial должен присутствовать в OtherCertID. Значение certHash должно совпадать с хэш-значением указанного сертификата. ПРИМЕЧАНИЕ 2. Копии значений сертификатов могут храниться в атрибуте certificate-values, определенном в пункте 6.3.3. Этот атрибут может содержать ссылки на цепочку сертификации для любого модуля штампов времени, который предоставляет штампы времени. В этом случае неподписанный атрибут добавляется к структуре signedData соответствующего штампа времени как атрибут unsignedAttrs в поле signerInfos. 6.2.2 Определение атрибута complete-revocation-references complete-revocation-references – это неподписанный атрибут. Только один экземпляр этого атрибута должен быть включен в электронную подпись. Он ссылается на полный набор списков отзыва сертификатов, списков отзыва атрибутных сертификатов и ответов OCSP, которые использовались для проверки подписывающей стороной, и сертификатов центра сертификации, используемых в подписи с полными проверочными данными. Этот атрибут показывает, что проверяющая сторона со всей ответственностью собрала доступные сведения об отозванных сертификатах. Ссылки, хранимые в этом атрибуте, можно использовать для получения информации, на которую он ссылается, если она хранится не в структуре CMS, а в другом месте. Следующий идентификатор объекта определяет атрибут complete-revocation-references: id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} Для значения атрибута complete-revocation-references используется синтаксис типа ASN.1 CompleteRevocationRefs: CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef CrlOcspRef ::= SEQUENCE { crlids [0] CRLListID OPTIONAL, ocspids [1] OcspListID OPTIONAL, otherRev [2] OtherRevRefs OPTIONAL } Атрибут CompleteRevocationRefs должен содержать одно поле CrlOcspRef для signing-certificate и одно такое же поле для каждого OtherCertID в этом атрибуте. Второе и последующие поля CrlOcspRef должны быть указаны в том же порядке, как и для OtherCertID, к которому они относятся. По крайней мере одно поле CRLListID, OcspListID или OtherRevRefs должно присутствовать для всех доверенных центров сертификации пути сертификации. CRLListID ::= crls SEQUENCE { SEQUENCE OF CrlValidatedID } CrlValidatedID ::= crlHash SEQUENCE { OtherHash, ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) crlIdentifier CrlIdentifier ::= SEQUENCE { crlissuer crlIssuedTime CrlIdentifier OPTIONAL } Name, UTCTime, ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) crlNumber INTEGER OPTIONAL } OcspListID ::= SEQUENCE { ocspResponses SEQUENCE OF OcspResponsesID } OcspResponsesID ::= ocspIdentifier ocspRepHash } SEQUENCE { OcspIdentifier, OtherHash OPTIONAL OcspIdentifier ::= SEQUENCE { ocspResponderID ResponderID, -- As in OCSP response data producedAt GeneralizedTime -- As in OCSP response data } OtherRevRefs ::= SEQUENCE { otherRevRefType OtherRevRefType, otherRevRefs ANY DEFINED BY otherRevRefType } OtherRevRefType ::= OBJECT IDENTIFIER При создании crlValidatedID значение crlHash вычисляется по всему списку отзыва сертификатов, закодированному в формате DER, включая и подпись. crlIdentifier обычно присутствует, если список отзыва сертификатов нельзя получить из других данных. crlIdentifier используется для идентификации списка отзыва сертификатов с использованием имени издателя и времени выпуска списка, которое должно соответствовать времени в поле thisUpdate, содержащемся в выпущенном списке отзыва сертификатов, и поле crlNumber, если оно задано. crlListID – это неподписанный атрибут. Если идентифицированный список отзыва сертификатов является списком изменений, то этот атрибут ссылается на набор списков отзыва сертификатов для предоставления полного списка отзыва, включаемого в проверочные данные. Поле OcspIdentifier используется для идентификации ответа OCSP с помощью имени издателя и времени выдачи ответа OCSP, которое должно соответствовать времени в выданном ответе OCSP. В предыдущих версиях данного стандарта элемент ocspRefHash был необязательным. Для обеспечения обратной совместимости структура ASN.1 не была изменена, при этом настоятельно рекомендуется включать данный элемент в свои реализации стандарта. Реализации, проверяющие подпись, могут принимать подписи без этого элемента. Но следует помнить, что его отсутствие позволяет применять атаки с заменой ответов OCSP, например, при компрометации ключей службы OCSP. Реализации, принимающие подписи без этого элемента, могут использовать сторонние механизмы для гарантии того, что ни один из ключей службы OCSP не был скомпрометирован на время проверки. ПРИМЕЧАНИЕ 1. Копии списка отзыва сертификатов и ответов OCSP могут храниться в атрибуте revocation-values, определенном в пункте 6.3.4. ПРИМЕЧАНИЕ 2. Рекомендуется использовать данный атрибут вместо атрибута OtherRevocationInfoFormat, определенного в документе RFC 3852 [4], для обеспечения обратной совместимости с предыдущими версиями этого стандарта. Синтаксис и семантика других ссылок на списки отзыва выходят за рамки данного документа. Определение синтаксиса другой формы информации об отозванных сертификатах соответствует синтаксису OtherRevRefType. Данный атрибут может содержать ссылки на полный набор списков отзыва сертификатов, списков отзыва атрибутных сертификатов и ответов OCSP, которые использовались для проверки пути сертификации любого модуля штампов времени, предоставляющего штампы времени. В этом случае неподписанный атрибут добавляется к структуре signedData соответствующего штампа времени как атрибут unsignedAttrs в поле signerInfos. 6.2.3 Определение атрибута attribute-certificate-references Этот атрибут используется только при наличии атрибутного сертификата пользователя в электронной подписи. attribute-certificate-references – это неподписанный атрибут. Он ссылается на полный набор сертификатов атрибутного центра, используемых для проверки атрибутного сертификата. Только один экземпляр этого атрибута должен быть включен в электронную подпись. id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 44} ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Для значения атрибута attribute-certificate-references используется синтаксис типа ASN.1 AttributeCertificateRefs: AttributeCertificateRefs ::= SEQUENCE OF OtherCertID Тип OtherCertID определен в пункте 5.7.3.3. ПРИМЕЧАНИЕ. Копии значений сертификатов могут храниться в атрибуте certificate-values, определенном в пункте 6.3.3. 6.2.4 Определение атрибута attribute-revocation-references Этот атрибут используется только при наличии атрибутного сертификата пользователя в электронной подписи и только при возможности отзыва атрибутного сертификата. attribute-revocation-references – это неподписанный атрибут. Только один экземпляр этого атрибута должен быть включен в электронную подпись. Он ссылается на полный набор списков отзыва атрибутных сертификатов и ответов OCSP, используемых для проверки атрибутного сертификата. Этот атрибут можно использовать для того, чтобы показать, что проверяющая сторона со всей ответственностью собрала доступные сведения об отозванных сертификатах. Следующий идентификатор объекта определяет атрибут attribute-revocation-references: id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 45} Для значения атрибута attribute-revocation-references используется синтаксис типа ASN.1 AttributeRevocationRefs: AttributeRevocationRefs ::= 6.3 SEQUENCE OF CrlOcspRef Расширенные проверочные данные (CAdES-X) В данном разделе определен ряд необязательных атрибутов, используемых расширенными формами электронных подписей (обзор этих форм проверочных данных см. в приложении Б). 6.3.1 Проверочные данные со штампом времени (CAdES-X Type 1 или Type 2) Расширенные проверочные данные могут включать один из следующих дополнительных атрибутов, формируя проверочные данные штампа времени CAdES-X Time-Stamp (CAdES-X Type 1 или CAdES-X Type 2), для обеспечения дополнительной защиты от компрометации центра сертификации в дальнейшем и обеспечения целостности используемых проверочных данных: • штамп времени CAdES-C, как определено в пункте 6.3.5 (CAdES-X Type 1); • сертификаты со штампами времени и ссылки на списки отзыва сертификатов, как определено в пункте 6.3.6 (CAdES-X Type 2). 6.3.2 Долгосрочные проверочные данные (CAdES-X Long, CAdES-X Long Type 1 или 2) Расширенные проверочные данные также могут содержать следующие дополнительные сведения, формируя подпись CAdES-X Long, если у последующих процессов не будет доступа к этой информации: • certificate-values, как определено в пункте 6.3.3; • revocation-values, как определено в пункте 6.3.4. Помимо атрибутов certificate-values и revocation-values, определенных в пунктах 6.3.3 и 6.3.4, расширенные проверочные данные могут содержать один из следующих дополнительных атрибутов, формируя CAdES-X Long Type 1 или CAdES-X Long Type 2. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) • штамп времени CAdES-C, как определено в пункте 6.3.3 (CAdES-X Long Type 1); • сертификаты со штампами времени и ссылки на списки отзыва сертификатов, как определено в пункте 6.3.4 (CAdES-X Long Type 2). ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Форматы CAdES-X Long Type 1 и CAdES-X Long Type 2 обеспечивают дополнительную защиту от компрометации центра сертификации в дальнейшем и обеспечивают целостность используемых проверочных данных. ПРИМЕЧАНИЕ 1. Подпись CAdES-X Long предоставляет долгосрочное доказательство действительности подписи, до тех пор пока ключи центра сертификации, ключи издатели списка отзыва сертификатов и ключи службы OCSP не скомпрометированы и являются стойкими к криптографическим атакам. ПРИМЕЧАНИЕ 2. Пока данные штампов времени действительны, подписи типа CAdES-X Long Type 1 и CAdES-X Long Type 2 обеспечивают следующую характеристику для долгосрочных подписей: если подпись была признана действительной, она будет оставаться действительной через несколько месяцев и даже лет после истечения срока действия сертификатов или компрометации пользовательского ключа. 6.3.3 Определение атрибута certificate-values Этот атрибут может использоваться для хранения информации о сертификате, необходимой для следующих форм расширенных электронных подписей: CAdES-X Long, CAdES X-Long Type 1 и CAdES-X Long Type 2 (пример такой формы электронной подписи см. в пункте Б.1.1). certificate-values – это неподписанный атрибут. Только один экземпляр этого атрибута должен быть включен в электронную подпись. Он содержит значения сертификатов, указанных в атрибуте complete-certificatereferences. ПРИМЕЧАНИЕ. Если используется атрибутный сертификат, он не предоставляется в этой структуре, а предоставляется подписывающей стороной как атрибут signer-attributes (см. пункт 5.11.3). Следующий идентификатор объекта определяет атрибут certificate-values: id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} Для значения атрибута certificate-values используется синтаксис типа ASN.1 CertificateValues: CertificateValues ::= SEQUENCE OF Certificate Тип Certificate определен в пункте 7.1 (и соответствует рекомендации МСЭ-Т X.509 [1]). Этот атрибут может содержать информацию о сертификатах для любых модулей штампов времени, предоставляющих штампы времени, если эти сертификаты еще не включены в них как часть подписей модулей штампов времени. В этом случае неподписанный атрибут добавляется к структуре signedData соответствующего штампа времени. 6.3.4 Определение атрибута revocation-values Этот атрибут используется для хранения информации об отозванных сертификатах, необходимой для следующих форм расширенных электронных подписей: CAdES-X Long, CAdES X-Long Type 1 и CAdES-X Long Type 2 (пример такой формы электронной подписи см. в пункте Б.1.1). revocation-values – это неподписанный атрибут. Только один экземпляр этого атрибута должен быть включен в электронную подпись. Он содержит значения списков отзыва сертификатов и ответов OCSP, указанных в атрибуте complete-revocation-references. ПРИМЕЧАНИЕ. Рекомендуется использовать данный атрибут вместо атрибута OtherRevocationInfoFormat, определенного в документе RFC 3852 [4], для обеспечения обратной совместимости с предыдущими версиями данного документа. Следующий идентификатор объекта определяет атрибут revocation-values: id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24} Для значения атрибута revocation-values используется синтаксис типа ASN.1 RevocationValues: RevocationValues ::= SEQUENCE { crlVals [0] SEQUENCE OF CertificateList OPTIONAL, ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) otherRevVals [2] OtherRevVals OPTIONAL} ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) OtherRevVals ::= SEQUENCE { otherRevValType OtherRevValType, otherRevVals ANY DEFINED BY OtherRevValType } OtherRevValType ::= OBJECT IDENTIFIER Синтаксис и семантика других значений отозванных сертификатов (OtherRevVals) выходят за рамки данного документа. Определение синтаксиса другой формы информации об отозванных сертификатах соответствует синтаксису OtherRevRefType. Поле CertificateList определено в пункте 7.2 (и соответствует рекомендации МСЭ-Т X.509 [1]). Поле BasicOCSPResponse определено в пункте 7.3 (и соответствует документу RFC 2560 [3]). Этот атрибут может содержать значения данных отозванных сертификатов, включая списки отзыва сертификатов и ответы OCSP, для любых модулей штампов времени, предоставляющих штампы времени, если эти сертификаты еще не включены в них как часть подписей модулей штампов времени. В этом случае неподписанный атрибут добавляется к структуре signedData соответствующего штампа времени. 6.3.5 Определение атрибута CAdES-C-time-stamp Этот атрибут используется для защиты от компрометации ключа центра сертификации. Он используется для добавления штампов времени полной электронной подписи (CAdES-C). Данный атрибут используется в следующих формах расширенных электронных подписей: CAdES-X Type 1 и CAdES-X Long Type 1 (пример такой формы электронной подписи см. в пункте Б.1.2). CAdES-C-time-stamp – это неподписанный атрибут. Это штамп времени хэш-значения электронной подписи и полных проверочных данных (CAdES-C). Он является специализированным атрибутом TimeStampToken, который применяет штамп времени к CAdES-C. В электронной подписи может быть несколько экземпляров этого атрибута от разных служб штампов времени. ПРИМЕЧАНИЕ 1. Рекомендуется кодировать атрибуты, к которым применяется штамп времени в формате DER. Если DER не используется, двоичное кодирование структур ASN.1, к которым применяется штамп времени, должно быть сохранено с целью обеспечения согласованного повторного вычисления хэш-значения данных. ПРИМЕЧАНИЕ 2. Каждый атрибут включается в хэш-значение с полями attrType и attrValues (с типом и длиной), но без типа и длины внешней последовательности (SEQUENCE). Следующий идентификатор объекта определяет атрибут CAdES-C-Timestamp: id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} Для значения атрибута CAdES-C-Timestamp используется синтаксис ASN.1 ESCTimeStampToken: ESCTimeStampToken ::= TimeStampToken Значение поля messageImprint в TimeStampToken должно быть хэш-значением объединенных значений (без кодирования типа или длины этого значения) следующих объектов данных: • представление поля SignatureValue в структуре SignerInfo в виде строки октетов (OCTET STRING); • signature-time-stamp или метка времени, управляемая службой меток времени; • атрибут complete-certificate-references; • атрибут complete-revocation-references. Дополнительные сведения о типе TimeStampToken и его определение см. в пункте 7.4. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 6.3.6 Определение атрибута time-stamped-certs-crls-references Этот атрибут используется для защиты от компрометации ключа центра сертификации. Он применяется для добавления штампа времени к ссылкам на сертификаты и списки отзыва сертификатов. Атрибут используется в следующих формах расширенной электронной подписи: CAdES-X Type 2 и CAdES X-Long Type 2 (пример такой формы электронной подписи см. в пункте Б.1.3). Атрибут time-stamped-certs-crls-references является неподписанным атрибутом. Это штамп времени, выданный для списка указанных сертификатов и ответов OCSP, а также списков отзыва сертификатов для защиты от определенных видов компрометации центра сертификации. Он использует следующий синтаксис: ПРИМЕЧАНИЕ 1. Рекомендуется кодировать атрибуты, к которым применяется штамп времени в формате DER. Если DER не используется, двоичное кодирование структур ASN.1, к которым применяется штамп времени, должно быть сохранено с целью обеспечения согласованного повторного вычисления хэшзначения данных. ПРИМЕЧАНИЕ 2. Каждый атрибут включается в хэш-значение с полями attrType и attrValues (с типом и длиной), но без типа и длины внешней последовательности (SEQUENCE). Следующий идентификатор объекта определяет атрибут time-stamped-certs-crls-references: id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} Для значения данного атрибута используется синтаксис типа ASN.1 TimestampedCertsCRLs: TimestampedCertsCRLs ::= TimeStampToken Значение поля messageImprint в TimeStampToken является хэш-значением объединенных значений (без кодирования типа или длины этого значения) следующих объектов данных, присутствующих в электронной подписи с полными проверочными данными (CAdES-C): • атрибут complete-certificate-references; • атрибут complete-revocation-references. 6.4 Архивные проверочные данные Если электронная подпись должна оставаться действительной в течение очень долгого времени, а штамп времени электронной подписи может перестать быть действительным из-за слабости алгоритма или ограничений периода действия сертификата службы штампов времени, то может потребоваться неоднократное применение штампа времени к электронной подписи. В этом случае для архивной формы электронной подписи (CAdES-A) может понадобиться атрибут архивного штампа времени. Этот атрибут можно применять повторно. 6.4.1 Определение атрибута archive-time-stamp Атрибут archive-time-stamp – это штамп времени многих элементов структуры signedData в электронной подписи. Если атрибуты certificate-values и revocation-values отсутствуют в CAdES-BES или CAdESEPES, они должны быть добавлены в электронную подпись до вычисления штампа времени архива. archive-timestamp – это неподписанный атрибут. В электронной подписи может быть несколько экземпляров этого атрибута, добавленных в разное время и от разных служб штампов времени. Следующий идентификатор объекта определяет атрибут archive-time-stamp: id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 48} Типом значений атрибута archive-time-stamp является тип ASN.1 ArchiveTimeStampToken: ArchiveTimeStampToken ::= TimeStampToken ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Значение поля messageImprint в TimeStampToken является хэш-значением объединения следующих элементов: • элемент encapContentInfo последовательности SignedData; • любое внешнее содержимое, защищенное подписью, если элемент eContent поля encapContentInfo опущен; • элементы Certificates и crls последовательности SignedData, если они указаны; • все элементы данных в последовательности SignerInfo, включая все подписанные и неподписанные атрибуты. ПРИМЕЧАНИЕ 1. Альтернативный атрибут archiveTimestamp, заданный идентификатором объекта { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27, определен в предыдущих версиях TS 101 733. Атрибут archiveTimestamp, определенный в версиях TS 101 733 до 1.5.1, несовместим с атрибутом, определенном в настоящем документе. Атрибут archiveTimestamp, определенный в версиях 1.5.1-1.6.3 документа TS 101 733, совместим с настоящим документом, если содержимое является внутренним для encapContentInfo. Если версия TS 101 733, используемая подписывающей стороной, известна всем получателям, использование атрибута archiveTimestamp, определенного в предыдущих версиях TS 101 733, не рекомендуется. ПРИМЕЧАНИЕ 2. Для удостоверяющих подписей, хранимых как атрибуты countersignature, не требуются независимые архивные штампы времени, так как они защищены архивным штампом времени для структуры SignedData. ПРИМЕЧАНИЕ 3. Если используется кодирование в формате DER, рекомендуется сохранить двоичное кодирование структур ASN.1, к которым применяется штамп времени, при архивации с целью обеспечения согласованного повторного вычисления хэш-значения данных. ПРИМЕЧАНИЕ 4. Хэш-значение вычисляется для полученных или сохраненных объединенных элементов данных, включая кодирование типа и длины. ПРИМЕЧАНИЕ 5. Хотя рекомендуется кодировать неподписанные атрибуты в формате DER, нельзя гарантировать, что они закодированы в формате DER без предварительной договоренности. Дополнительные сведения о типе TimeStampToken и его определение см. в пункте 7.4. Штамп времени должен создаваться с помощью надежных алгоритмов (или с помощью более длинных ключей), более стойких, чем алгоритмы в исходных электронных подписях и штампах времени со слабыми алгоритмами (с малой длиной ключа). ПРИМЕЧАНИЕ 6. Такая форма электронной подписи также обеспечивает защиту от компрометации ключа поставщика доверенных услуг. ArchiveTimeStamp добавляется как неподписанный атрибут в последовательность SignerInfo. Для проверки одного атрибута ArchiveTimeStamp элементы данных SignerInfo должны быть объединены (кроме всех атрибутов ArchivTimeStampToken, добавленных позднее). Данные о сертификатах и списках отзыва сертификатов, необходимые для проверки ArchiveTimeStamp, должны предоставляться с помощью одного из следующих методов: 7 • модуль штампов времени предоставляет данные в структуре SignedData штампа времени; • добавление атрибутов complete-certificate-references и complete-revocationreferences поставщика доверенных услуг как неподписанных атрибутов в TimeStampToken, если необходимые данные хранятся в другом месте; • добавление атрибутов certificate-values и revocation-values поставщика доверенных услуг как неподписанных атрибутов в TimeStampToken, если необходимые данные хранятся в другом месте. Другие стандартные структуры данных ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 7.1 Формат сертификата открытого ключа Базовый синтаксис сертификата X.509 версии 3 определен в рекомендации МСЭ-Т X.509 [1]. Профиль сертификата X.509 версии 3 определен в документе RFC 3280 [2]. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 7.2 Формат списка отзыва сертификатов Синтаксис списка отзыва сертификатов X.509 версии 2 определен в рекомендации МСЭ-Т X.509 [1]. Профиль списка отзыва сертификатов X.509 версии 2 определен в документе RFC 3280 [2]. 7.3 Формат ответа OCSP Формат ответа OCSP определен в документе RFC 2560 [3]. 7.4 Формат штампа времени Формат типа TimeStampToken определен в документе RFC 3161 [7] и описан в документе TS 101 861 [i.9]. Реализации данного документа должны поддерживать использование как атрибута signing-certificate, так и атрибута signing-certificate-v2 в штампах времени в соответствии с документом RFC 5035 [15]. 7.5 Формат имени и атрибута Синтаксис имен и других атрибутов определен в рекомендации МСЭ-Т X.509 [1]. ПРИМЕЧАНИЕ 1. Имя, используемое подписывающей стороной и хранящееся в виде субъекта в сертификате подписывающей стороны, выделяется и проверяется при регистрации в центре сертификации напрямую или косвенно через центр регистрации до выдачи сертификата. Данный документ не налагает ограничений на формат имени. Именем субъекта может быть отличительное имя, как определено в рекомендации МСЭ-Т X.500 [12], которое хранится в поле субъекта сертификата, или любое другое имя из поля расширения сертификата subjectAltName, как определено в рекомендации МСЭ-Т X.509 [1]. Если у субъекта нет отличительного имени, его именем может быть пустая последовательность, при этом расширение subjectAltName должно быть критичным. Все центры сертификации, атрибутные центры и службы штампов времени должны использовать отличительные имена в поле subject своих сертификатов. Отличительное имя должно включать идентификаторы организации, предоставляющей услуги, и юрисдикцию (например, страну), в пределах которой она работает. Если подписывающая сторона подписывается как физическое лицо, но также желает идентифицировать себя как сторону, действующую от лица организации, ей может потребоваться предоставить две независимые формы идентификации. Первое удостоверение, которое напрямую связано с ключом подписи, определяет подписывающую сторону как физическое лицо. Второе удостоверение, управляемое независимо, указывает, что человек действует от лица организации, возможно, с заданной ролью. В этом случае одно из двух удостоверений передается в поле subject/subjectAltName сертификата подписывающей стороны, как описано выше. В настоящем документе не указывается формат атрибута подписывающей стороны, который может быть включен в сертификаты открытых ключей. ПРИМЕЧАНИЕ 2. Атрибут подписывающей стороны может поддерживаться с помощью заявленной роли в поле подписанных атрибутов CMS или за счет размещения атрибутного сертификата, содержащего сертифицированную роль в поле подписанных атрибутов CMS (см. пункт 7.6). 7.6 Атрибутный сертификат Синтаксис типа AttributeCertificate определен в документе RFC 3281 [13]. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Требования соответствия 8 Для реализаций, поддерживающих создание подписей, настоящий документ определяет требования по соответствию для создания двух форм простой электронной подписи, одна из которых должна быть реализована. Для реализаций, поддерживающих проверку подписей, настоящий документ определяет требования по соответствию для проверки двух форм простой электронной подписи, одна из которых должна быть реализована. В настоящем документе определяются только требования соответствию вплоть до электронной подписи с полными проверочными данными (CAdES-C). Это значит, что не требуется реализовывать расширенные и архивные формы электронной подписи (CAdES-X, CAdES-A) для совместимости с данным документом. При проверке включение необязательных подписанных и неподписанных атрибутов должно поддерживаться только для обеспечения возможности проверки подписи. Семантика необязательных атрибутов может не поддерживаться, если иное не указано регламентом подписи. Простая электронная подпись CAdES (CAdES-BES) 8.1 Согласно данному документу система, поддерживающая подписывающие стороны CAdES-BES, должна, как минимум, поддерживать создание электронной подписи, состоящей из следующих компонентов: • общий синтаксис и тип содержимого CMS, как определено в документе RFC 3852 [4] (см. пункты 5.1 и 5.2); • структура CMS SignedData, как определено в документе RFC 3852 [4], с версией 1 или 3, как описано в разделе 5.1 документа RFC 3852 [4] (см. примечание 3) и, по крайней мере, с одной последовательностью SignerInfo (см. пункты 5.3-5.6); • следующие атрибуты CMS, определенные в документе RFC 3852 [4]: • - content-type; этот атрибут должен присутствовать всегда (см. пункт 5.7.1); - message-digest; этот атрибут должен присутствовать всегда (см. пункт 5.7.2); один следующих атрибутов, определенных в настоящем документе: - signing-certificate: как определено в пункте 5.7.3.1; или - signing-certificate v2, как определено в пункте 5.7.3.2. ПРИМЕЧАНИЕ 1. В предыдущих версиях настоящего документа использовался другой атрибут signingcertificate (см. пункт 5.7.3.3). Теперь этот атрибут не рекомендуется к использованию, так как структура signing-certificate-v2 проще другого атрибута signing-certificate. Реализации формы простой электронной подписи, соответствующей всем указанным выше требованиям кроме последнего (например, без атрибута signing-certificate или signing-certificate v2), могут использовать все атрибуты проверки, определенные в данном документе, для поддержки CMS-вариантов CAdES-T, CAdES-C, CAdES-X и т. д. Такие подписи могут называться CMS-T, CMS-C, CMS-X и т. д. ПРИМЕЧАНИЕ 2. Такие электронные подписи могут быть уязвимы для атак с заменой сертификатов, как описано в пункте В.3.3. ПРИМЕЧАНИЕ 3. В разделе 5.1 документа RFC 3852 [4] указано требование, в соответствии с которым версия CMS SignedData должна быть задана как 3, если присутствуют сертификаты из структуры SignedData и выполняется следующее условие: присутствуют какие-либо атрибутные сертификаты версии 1 ИЛИ версия какой-либо из структур SignerInfo задана как 3 ИЛИ значение eContentType из поля encapContentInfo отличается от id-data. В противном случае версия CMS SignedData должна быть задана как 1. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 8.2 Электронная подпись CAdES с явно указанным регламентом Согласно данному документу, система, поддерживающая подписывающие стороны на основе регламента, должна, как минимум, поддерживать создание электронной подписи, состоящей из предыдущих компонентов, заданных для простой подписывающей стороны, и следующих компонентов: • следующие атрибуты, определенные в пункте 5.9: - signature-policy-identifier; этот атрибут должен присутствовать всегда (см. пункт 5.8.1). Проверка с помощью штампов времени 8.3 Согласно настоящему документу, система, поддерживающая проверяющие стороны, со средствами для применения штампов времени, как минимум, должна поддерживать: • проверку обязательных компонентов электронной подписи, как указано в пункте 8.1; • атрибут signature-time-stamp, как определено в пункте 6.1.1; • атрибут complete-certificate-references, как определено в пункте 6.2.1; • атрибут complete-revocation-references, как определено в пункте 6.2.2; • сертификаты открытого ключа, как определено в рекомендации МСЭ-Т X.509 [1] (см. пункт 8.1); • один из следующих компонентов: - списки отзыва сертификатов, как определено в рекомендации МСЭ-Т X.509 [1] (см. пункт 8,2); - протокол OCSP, как определено в документе RFC 2560 [3] (см. пункт 8.3). Проверка с помощью безопасных записей 8.4 Согласно данному документу, система, поддерживающая проверяющие стороны, как минимум, должна поддерживать: • проверку обязательных компонентов электронной подписи, как указано в пункте 8.1; • атрибут complete-certificate-references, как определено в пункте 6.2.1; • атрибут complete-revocation-references, как определено в пункте 6.2.2; • должна поддерживаться запись самой электронной подписи и времени первой проверки подписи с помощью указанных данных о сертификатах и списках отзыва сертификатов. Запись должна проводиться таким образом, чтобы изменения не могли остаться необнаруженными. • сертификаты открытого ключа, как определено в рекомендации МСЭ-Т X.509 [1] (см. пункт 8.1); • и один из следующих компонентов: - списки отзыва сертификатов, как определено в рекомендации МСЭ-Т X.509 [1] (см. пункт 8,2); - протокол OCSP, как определено в документе RFC 2560 [3] (см. пункт 8.3). ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение A (нормативное). Определения ASN.1 В данном приложении представлена сводка по всем определениям синтаксиса ASN.1 для нового синтаксиса, определенного в данном документе. А.1 Определения формата подписи с использованием синтаксиса X.208 ASN.1 ПРИМЕЧАНИЕ. Модуль ASN.1, определенный в пункте А.1, использующий синтаксис, заданный в рекомендации МСЭ-Т X.208 [14], имеет бóльший приоритет, чем синтаксис, определенный в пункте А.2, в случае конфликта. ETS-ElectronicSignatureFormats-ExplicitSyntax88 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) eSignature-explicit88(28)} DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS All IMPORTS -- Синтаксис криптографических сообщений (CMS): RFC 3852. ContentInfo, ContentType, id-data, id-signedData, SignedData, EncapsulatedContentInfo, SignerInfo, idcontentType, id-messageDigest, MessageDigest, id-signingTime, SigningTime, id-countersignature, Countersignature FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } -- Атрибуты, определенные ESS: обновление ESS. -- RFC 5035 (добавление взаимозаменяемости алгоритмов CertID). id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-contentReference, ContentReference, id-aa-contentIdentifier, ContentIdentifier, id-aa-signingCertificateV2 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) } -- Инфраструктура открытых ключей Интернет X.509 — профиль сертификатов и списков отзыва сертификатов: RFC 3280. Certificate, AlgorithmIdentifier, CertificateList, Name, DirectoryString, Attribute, BMPString, UTF8String FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit (18)} GeneralNames, 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 (19)} -- Профиль атрибутного сертификата Интернет для авторизации: RFC 3281. AttributeCertificate FROM PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-attribute-cert(12)} -- Протокол OCSP, RFC 2560. BasicOCSPResponse, ResponderID FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} -- Штамп времени (TimeStampToken) по протоколу TSP, RFC 3161. FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} ; -- Определения ребер идентификаторов объектов, используемые в настоящем документе -================================================================== -- Используемый идентификатор объекта, ссылающийся на механизмы электронной подписи, основанные на настоящем документе. -- Для использования с программным интерфейсом независимой защиты моделей данных IDUP API (см. приложение Г). id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= { itu-t(0) identified-organization(4) etsi(0) electronic-signature-standard (1733) part1 (1) idupMechanism (4) etsiESv1(1) } -- Атрибуты CMS простой электронной подписи, определенные в данном документе. -- ======================================================= -- OtherSigningCertificate – Не рекомендуется к использованию. id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 19 } OtherSigningCertificate ::= certs SEQUENCE OF policies SEQUENCE OF -- NOT USED OtherCertID ::= SEQUENCE { otherCertHash issuerSerial SEQUENCE { OtherCertID, PolicyInformation OPTIONAL IN THE PRESENT DOCUMENT } OtherHash, IssuerSerial OPTIONAL } OtherHash ::= CHOICE { sha1Hash OtherHashValue, -- This contains a SHA-1 hash otherHash OtherHashAlgAndValue} -- Атрибуты регламента электронной подписи, определенные в настоящем документе. -- ================================================= -- Обязательные атрибуты простой электронной подписи (как указано выше) и дополнение. -- Атрибут Signature-policy-identifier. id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 15 } SignaturePolicyIdentifier ::= CHOICE { signaturePolicyId SignaturePolicyId, signaturePolicyImplied SignaturePolicyImplied -- not used in this version } SignaturePolicyId ::= SEQUENCE { sigPolicyId SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL } SignaturePolicyImplied ::= NULL SigPolicyId ::= OBJECT IDENTIFIER SigPolicyHash ::= OtherHashAlgAndValue OtherHashAlgAndValue ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue } ETSI ETSI TS 101 733, версия 1.8.3 (201101) OtherHashValue ::= OCTET STRING SigPolicyQualifierInfo ::= SEQUENCE { sigPolicyQualifierId SigPolicyQualifierId, sigQualifier ANY DEFINED BY sigPolicyQualifierId } SigPolicyQualifierId ::= OBJECT IDENTIFIER id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 1 } SPuri ::= IA5String id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2 } SPUserNotice ::= SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL} NoticeReference ::= SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } DisplayText ::= CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) } -- Необязательные атрибуты электронной подписи. -- Атрибут Commitment-type. id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} CommitmentTypeIndication ::= SEQUENCE { commitmentTypeId CommitmentTypeIdentifier, commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF CommitmentTypeQualifier OPTIONAL} CommitmentTypeIdentifier ::= OBJECT IDENTIFIER CommitmentTypeQualifier ::= SEQUENCE { commitmentTypeIdentifier CommitmentTypeIdentifier, qualifier ANY DEFINED BY commitmentTypeIdentifier } id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 3} id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 5} id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 6} -- Атрибут Signer-location. id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} SignerLocation ::= SEQUENCE { -- at least one of the following shall be present ETSI ETSI TS 101 733, версия 1.8.3 (201101) countryName [0] DirectoryString OPTIONAL, -- As used to name a Country in X.500 localityName [1] DirectoryString OPTIONAL, -- As used to name a locality in X.500 postalAdddress [2] PostalAddress OPTIONAL } PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString -- Атрибут Signer-attributes. id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} SignerAttribute ::= SEQUENCE OF CHOICE { claimedAttributes [0] ClaimedAttributes, certifiedAttributes [1] CertifiedAttributes } ClaimedAttributes ::= SEQUENCE OF Attribute CertifiedAttributes ::= AttributeCertificate -- as defined in RFC 3281: see clause 4.1 -- Атрибут Content-timestamp. id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} ContentTimestamp::= TimeStampToken -- Атрибут Signature-timestamp. id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} SignatureTimeStampToken ::= TimeStampToken -- Атрибут Complete-certificate-references. id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} CompleteCertificateRefs ::= SEQUENCE OF OtherCertID -- Атрибут Complete-revocation-references. id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef CrlOcspRef ::= SEQUENCE { crlids [0] CRLListID OPTIONAL, ocspids [1] OcspListID OPTIONAL, otherRev [2] OtherRevRefs OPTIONAL } CRLListID ::= crls SEQUENCE { SEQUENCE OF CrlValidatedID} CrlValidatedID ::= crlHash crlIdentifier SEQUENCE { OtherHash, CrlIdentifier OPTIONAL} CrlIdentifier ::= SEQUENCE { crlissuer crlIssuedTime crlNumber } Name, UTCTime, INTEGER OPTIONAL OcspListID ::= SEQUENCE { ocspResponses SEQUENCE OF OcspResponsesID} OcspResponsesID ::= ocspIdentifier ocspRepHash SEQUENCE { OcspIdentifier, OtherHash OPTIONAL ETSI ETSI TS 101 733, версия 1.8.3 (201101) } OcspIdentifier ::= SEQUENCE { ocspResponderID ResponderID, -- As in OCSP response data producedAt GeneralizedTime -- As in OCSP response data } OtherRevRefs ::= SEQUENCE { otherRevRefType OtherRevRefType, otherRevRefs ANY DEFINED BY otherRevRefType } OtherRevRefType ::= OBJECT IDENTIFIER -- Атрибут Certificate-values. id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} CertificateValues ::= SEQUENCE OF Certificate -- Атрибут Certificate-revocation-values. id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24} RevocationValues ::= SEQUENCE { crlVals [0] SEQUENCE OF CertificateList OPTIONAL, ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, otherRevVals [2] OtherRevVals OPTIONAL} OtherRevVals ::= SEQUENCE { otherRevValType OtherRevValType, otherRevVals ANY DEFINED BY otherRevValType } OtherRevValType ::= OBJECT IDENTIFIER -- Атрибут штампа времени подписи CAdES-C. id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} ESCTimeStampToken ::= TimeStampToken -- Сертификаты и списки отзыва сертификатов со штампом времени. id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} TimestampedCertsCRLs ::= TimeStampToken -- Атрибут архивного штампа времени. id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 48} ArchiveTimeStampToken ::= TimeStampToken -- Атрибут Attribute-certificate-references. id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 44} AttributeCertificateRefs ::= SEQUENCE OF OtherCertID -- Атрибут Attribute-revocation-references. id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 45} AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef ETSI ETSI TS 101 733, версия 1.8.3 (201101) END А.2 Определения формата подписи с использованием синтаксиса ASN.1 X.680 ПРИМЕЧАНИЕ. Модуль ASN.1, определенный в пункте А.1, в случае конфликта имеет бóльший приоритет, чем модуль, определенный в пункте А.2 и использующий синтаксис согласно рекомендации МСЭ-Т X.680 (1997) [8]. ETS-ElectronicSignatureFormats-ExplicitSyntax97 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) eSignature-explicit97(29)} DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS All IMPORTS -- Синтаксис криптографических сообщений (CMS): RFC 3852. ContentInfo, ContentType, id-data, id-signedData, SignedData, EncapsulatedContentInfo, SignerInfo, id-contentType, id-messageDigest, MessageDigest, id-signingTime, SigningTime, id-countersignature, Countersignature FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } -- Атрибуты, определенные ESS: обновление ESS -- RFC 5035 (добавление взаимозаменяемости алгоритмов CertID). id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-contentReference, ContentReference, id-aa-contentIdentifier, ContentIdentifier, id-aa-signingCertificateV2 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) } -- Инфраструктура открытых ключей Интернет X.509 — профиль сертификатов и списков отзыва сертификатов: RFC 3280. Certificate, AlgorithmIdentifier, CertificateList, Name, Attribute FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} GeneralNames, 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(19)} -- Профиль атрибутного сертификата Интернет для авторизации: RFC 3281. AttributeCertificate FROM PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-attribute-cert(12)} -- Протокол OCSP, RFC 2560. BasicOCSPResponse, ResponderID FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} -- RFC 3161, инфраструктура открытых ключей X.509 Интернет. -- Протокол TSP. TimeStampToken FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} ETSI ETSI TS 101 733, версия 1.8.3 (201101) -- X.520 DirectoryString {} FROM SelectedAttributeTypes {joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4} ; -- Определения ребер идентификаторов объектов, используемые в настоящем документе. -- ================================================================== -- Используемый идентификатор объекта, ссылающийся на механизмы электронной подписи, основанные на настоящем документе. -- Для использования с программным интерфейсом IDUP API (см. приложение Г). id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= { itu-t(0) identified-organization(4) etsi(0) electronic-signature-standard (1733) part1 (1) idupMechanism (4) etsiESv1(1) } -- Атрибуты простой электронной подписи, определенные в настоящем документе. -- =================================================== -- Атрибуты CMS, определенные в настоящем документе. -- OtherSigningCertificate – не рекомендуется к использованию. id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 19 } OtherSigningCertificate ::= certs SEQUENCE OF policies SEQUENCE OF -- NOT USED OtherCertID ::= SEQUENCE { otherCertHash issuerSerial SEQUENCE { OtherCertID, PolicyInformation OPTIONAL IN THE PRESENT DOCUMENT } OtherHash, IssuerSerial OPTIONAL } OtherHash ::= CHOICE { sha1Hash OtherHashValue, -- This contains a SHA-1 hash otherHash OtherHashAlgAndValue} -- Атрибуты регламента электронной подписи, определенные в настоящем документе. -- ==================================================== -- Обязательные атрибуты простой электронной подписи и дополнение. -- Идентификатор регламента подписи. id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 15 } SignaturePolicyIdentifier ::= CHOICE { signaturePolicyId SignaturePolicyId, signaturePolicyImplied SignaturePolicyImplied -- not used in this version } SignaturePolicyId ::= SEQUENCE { sigPolicyId SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL } SignaturePolicyImplied ::= NULL ETSI ETSI TS 101 733, версия 1.8.3 (201101) SigPolicyId ::= OBJECT IDENTIFIER SigPolicyHash ::= OtherHashAlgAndValue OtherHashAlgAndValue ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, hashValue OtherHashValue } OtherHashValue ::= OCTET STRING SigPolicyQualifierInfo ::= SEQUENCE { sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id ({SupportedSigPolicyQualifiers}), qualifier SIG-POLICY-QUALIFIER.&Qualifier ({SupportedSigPolicyQualifiers} {@sigPolicyQualifierId})OPTIONAL } SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= { noticeToUser | pointerToSigPolSpec } SIG-POLICY-QUALIFIER ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Qualifier OPTIONAL } WITH SYNTAX { SIG-POLICY-QUALIFIER-ID &id [SIG-QUALIFIER-TYPE &Qualifier] } noticeToUser SIG-POLICY-QUALIFIER ::= { SIG-POLICY-QUALIFIER-ID id-spq-ets-unotice SIG-QUALIFIER-TYPE SPUserNotice } pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= { SIG-POLICY-QUALIFIER-ID id-spq-ets-uri SIG-QUALIFIER-TYPE SPuri } id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 1 } SPuri ::= IA5String id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2 } SPUserNotice ::= SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL} NoticeReference ::= SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } DisplayText ::= CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) } -- Необязательные атрибуты электронной подписи. -- Тип обязательства. id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} CommitmentTypeIndication ::= SEQUENCE { commitmentTypeId CommitmentTypeIdentifier, commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF CommitmentTypeQualifier OPTIONAL} CommitmentTypeIdentifier ::= OBJECT IDENTIFIER CommitmentTypeQualifier ::= SEQUENCE { commitmentQualifierId COMMITMENT-QUALIFIER.&id, qualifier COMMITMENT-QUALIFIER.&Qualifier OPTIONAL } COMMITMENT-QUALIFIER ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, ETSI ETSI TS 101 733, версия 1.8.3 (201101) &Qualifier OPTIONAL } WITH SYNTAX { COMMITMENT-QUALIFIER-ID &id [COMMITMENT-TYPE &Qualifier] } id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 3} id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 5} id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 6} -- Месторасположение подписывающей стороны. id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} SignerLocation ::= SEQUENCE { -- Должен присутствовать по крайней мере один из следующих элементов. countryName [0] DirectoryString OPTIONAL, -- Аналогично использованию названия страны в стандарте X.500. localityName [1] DirectoryString OPTIONAL, -- Аналогично использованию местоположения в стандарте X.500. postalAdddress [2] PostalAddress OPTIONAL } PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString{maxSize} -- Параметры maxSize в соответствии со стандартом X.683. -- Атрибуты подписывающей стороны. id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} SignerAttribute ::= SEQUENCE OF CHOICE { claimedAttributes [0] ClaimedAttributes, certifiedAttributes [1] CertifiedAttributes } ClaimedAttributes ::= SEQUENCE OF Attribute CertifiedAttributes ::= AttributeCertificate -- as defined in RFC 3281: see clause 4.1. -- Штамп времени содержимого. id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} ContentTimestamp::= TimeStampToken -- Штамп времени подписи. id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} SignatureTimeStampToken ::= TimeStampToken -- Полные ссылки на сертификаты. id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} ETSI ETSI TS 101 733, версия 1.8.3 (201101) CompleteCertificateRefs ::= SEQUENCE OF OtherCertID -- Полные ссылки на отозванные сертификаты. id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef CrlOcspRef ::= SEQUENCE { crlids [0] CRLListID OPTIONAL, ocspids [1] OcspListID OPTIONAL, otherRev [2] OtherRevRefs OPTIONAL } CRLListID ::= crls SEQUENCE { SEQUENCE OF CrlValidatedID} CrlValidatedID ::= crlHash crlIdentifier SEQUENCE { OtherHash, CrlIdentifier OPTIONAL} CrlIdentifier ::= SEQUENCE { crlissuer crlIssuedTime crlNumber } Name, UTCTime, INTEGER OPTIONAL OcspListID ::= SEQUENCE { ocspResponses SEQUENCE OF OcspResponsesID} OcspResponsesID ::= ocspIdentifier ocspRepHash } SEQUENCE { OcspIdentifier, OtherHash OPTIONAL OcspIdentifier ::= SEQUENCE { ocspResponderID ResponderID, -- As in OCSP response data producedAt GeneralizedTime -- As in OCSP response data } OtherRevRefs ::= SEQUENCE { otherRevRefType OTHER-REVOCATION-REF.&id, otherRevRefs SEQUENCE OF OTHER-REVOCATION-REF.&Type } OTHER-REVOCATION-REF ::= CLASS { &Type, &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { WITH SYNTAX &Type ID &id } -- Значения сертификатов. id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} CertificateValues ::= SEQUENCE OF Certificate -- Значения отозванных сертификатов. id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24} RevocationValues ::= SEQUENCE { crlVals [0] SEQUENCE OF CertificateList OPTIONAL, ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, otherRevVals [2] OtherRevVals OPTIONAL} OtherRevVals ::= SEQUENCE { otherRevValType OTHER-REVOCATION-VAL.&id, otherRevVals SEQUENCE OF OTHER-REVOCATION-REF.&Type } OTHER-REVOCATION-VAL ::= CLASS { &Type, ETSI ETSI TS 101 733, версия 1.8.3 (201101) &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { WITH SYNTAX &Type ID &id } -- Штамп времени CAdES-C. id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} ESCTimeStampToken ::= TimeStampToken -- Сертификаты и списки отзыва сертификатов со штампом времени. id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} TimestampedCertsCRLs ::= TimeStampToken -- Архивный штамп времени. id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 48} ArchiveTimeStampToken ::= TimeStampToken -- Ссылки на атрибутные сертификаты. id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 44} AttributeCertificateRefs ::= SEQUENCE OF OtherCertID -- Ссылки на отозванные атрибутные сертификаты. id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 45} AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef END ETSI ETSI TS 101 733, версия 1.8.3 (201101) Приложение Б (справочное). Расширенные формы электронных подписей В пункте 4 приведен обзор различных форматов электронных подписей, включенных в настоящий документ. В данном приложении перечисляются атрибуты, которые должны присутствовать в различных расширенных форматах электронных подписей, и приводится пример проверяющих последовательностей с использованием расширенных форматов. Б.1 Расширенные формы проверочных данных Полные проверочные данные (CAdES-C), описанные в пункте 4.3 и показанные на рис. 3, могут быть расширены для создания электронных подписей с расширенными проверочными данными. Некоторые формы электронных подписей, включающие расширенные проверочные данные, описаны ниже. Электронная подпись X-Long (CAdES-X Long) – это подпись CAdES-C со значениями сертификатов и данными об отозванных сертификатах. Эта форма электронной подписи может быть полезна, если у проверяющей стороны нет прямого доступа к следующей информации: • сертификат подписывающей стороны; • все сертификаты центра сертификации, составляющие полный путь сертификации; • все данные, связанные со статусом отзыва сертификатов, как указано в CAdES-C. В некоторых ситуациях дополнительные штампы времени могут быть созданы и добавлены в электронные подписи в качестве дополнительных атрибутов, например: • штампы времени для всех проверочных данных, хранимых в электронной подписи (CAdES-C); такой тип расширенных проверочных данных называется CAdES-X Type 1; • штампы времени для отдельных справочных данных, используемых для полной проверки; эта форма расширенных проверочных данных называется CAdES-X Type 2. ПРИМЕЧАНИЕ 1. Преимущества и недостатки форматов CAdES-X Type 1 и CAdES-X Type 2 описаны в пункте В.4.4. Описанные выше формы штампов времени могут быть полезны при необходимости учета риска компрометации ключей центра сертификации, используемых в цепочке сертификатов. Может использоваться сочетание двух указанных выше форматов. Такая форма расширенных проверочных данных называется ES X-Long Type 1 или CAdES-X Long Type 2. Эта форма электронной подписи может быть полезна, если проверяющей стороне требуются значения данных и доказательства времени существования проверочных данных. ПРИМЕЧАНИЕ 2. Преимущества и недостатки форматов CAdES-X long Type 1 и CAdES-X long Type 2 описаны в пункте В.4.6. Б.1.1 CAdES-X Long Электронная подпись с дополнительными проверочными данными, формирующими подпись CAdES-X Long, показана на рис. Б.1 и состоит из следующих компонентов: • подпись CAdES-BES или CAdES-EPES, как определено в пунктах 4.3, 5.7 и 5.8; • атрибут complete-certificate-references, как определено в пункте 6.2.1; ETSI ETSI TS 101 733, версия 1.8.3 (201101) • атрибут complete-revocation-references, как определено в пункте 6.2.2. ETSI ETSI TS 101 733, версия 1.8.3 (201101) Необходимо наличие следующих атрибутов, если поставщик доверенных услуг не предоставляет метку времени для электронной подписи: • атрибут signature-time-stamp, как определено в пункте 6.1.1. Следующие атрибуты необходимы, если полные значения сертификатов и данных об отозванных сертификатах не включены в подпись CAdES-BES или CAdES-EPES: • атрибут certificate-values, как определено в пункте 6.3.3; • атрибут revocation-values, как определено в пункте 6.3.4. Если используются атрибутные сертификаты, то могут присутствовать следующие атрибуты: • атрибут attribute-certificate-references, как определено в пункте 6.2.3; • атрибут attribute-revocation-references, как определено в пункте 6.2.4. Могут использоваться и другие неподписанные атрибуты, но они не являются обязательными. ПРИМЕЧАНИЕ. Ссылки на атрибутные и отозванные сертификаты присутствуют только при наличии в электронной подписи пользовательского атрибутного сертификата (см. пункты 6.2.2 и 6.2.3). CAdES-X Long CAdES-C CAdES-BES или CAdES- EPES Идентификатор регламента подписи (необязательно) Подписанные атрибуты Цифровая подпись Штамп времени на подписи необязателен при наличии метки времени Полные ссылки на сертификаты и списки отзыва Полные данные сертификатов и списков отзыва (т. е. все дополнительные значения) Рисунок Б.1. Схема формата CAdES-X-Long Б.1.2 CAdES-X Type 1 Электронная подпись с дополнительными проверочными данными, формирующими расширенные проверочные данные (Type 1 X), показана на рис. Б.2 и состоит из следующих компонентов: • подпись CAdES-BES или CAdES-EPES, как определено в пунктах 4,2, 5,7 и 5.8; • атрибут complete-certificate-references, как определено в пункте 6.2.1; • атрибут complete-revocation-references, как определено в пункте 6.2.2; • атрибут CAdES-C-Timestamp, как определено в пункте 6.3.5. Необходимо наличие следующих атрибутов, если поставщик доверенных услуг не предоставляет метку времени для электронной подписи: • атрибут signature-time-stamp, как определено в пункте 6.1.1. ETSI ETSI TS 101 733, версия 1.8.3 (201101) Если используются атрибутные сертификаты, то могут присутствовать следующие атрибуты: • атрибут attribute-certificate-references, как определено в пункте 6.2.3; • атрибут attribute-revocation-references, как определено в пункте 6.2.4. Могут использоваться и другие неподписанные атрибуты, но они не являются обязательными. ETSI ETSI TS 101 733, версия 1.8.3 (201101) CAdES-X type 1 CAdES-C CAdES-BES или CAdES-EPES Идентификатор регламента подписи (необязательно) Подписанные атрибуты Цифровая подпись Штамп времени подписи необязателен при наличии метки времени Полные ссылки на сертификаты и списки отзыва Штамп времени для CAdES-C Рисунок Б.2. Схема формата CAdES-X Type 1 Б.1.3 CAdES-X Type 2 Электронная подпись с дополнительными проверочными данными, формирующими расширенные проверочные данные (Type 2 X), показана на рис. Б.3 и состоит из следующих компонентов: • подпись CAdES-BES или CAdES-EPES, как определено в пунктах 4,2, 5.7 и 5.8; • атрибут complete-certificate-references, как определено в пункте 6.2.1; • атрибут complete-revocation-references, как определено в пункте 6.2.2; • атрибут time-stamped-certs-crls-references, как определено в пункте 6.3.6. Необходимо наличие следующих атрибутов, если поставщик доверенных услуг не предоставляет метку времени для электронной подписи: • атрибут signature-time-stamp, как определено в пункте 6.1.1. Если используются атрибутные сертификаты, то могут присутствовать следующие атрибуты: • атрибут attribute-certificate-references, как определено в пункте 6.2.3; • атрибут attribute-revocation-references, как определено в пункте 6.2.4. Могут использоваться и другие неподписанные атрибуты, но они не являются обязательными. CAdES-X Type 2 CAdES-C CAdES-BES или CAdES-EPES Идентификатор регламента подписи (необязательно) Подписанные атрибуты Цифровая подпись Штамп времени подписи необязателен при наличии метки времени Полные ссылки на сертификаты и списки отзыва Рисунок Б.3. Схема формата CAdES-X Type 2 ETSI Штамп времени только для полных ссылок на сертификаты и списки отзыва ETSI TS 101 733, версия 1.8.3 (201101) Б.1.4 CAdES-X Long Type 1 и CAdES-X Long Type 2 Электронная подпись с дополнительными проверочными данными, формирующими CAdES-X Long Type 1 и CAdES-X Long Type, показана на рис. Б.4 и состоит из следующих компонентов: • подпись CAdES-BES или CAdES-EPES, как определено в пунктах 4.3, 5.7 и 5.8; • атрибут complete-certificate-references, как определено в пункте 6.2.1; • атрибут complete-revocation-references, как определено в пункте 6.2.2. Необходимо наличие следующих атрибутов, если поставщик доверенных услуг не предоставляет метку времени для электронной подписи: • атрибут signature-time-stamp, как определено в пункте 6.1.1. Следующие атрибуты необходимы, если полные значения сертификатов и данных об отозванных сертификатах не включены в подпись CAdES-BES или CAdES-EPES: • атрибут certificate-values, как определено в пункте 6.3.3; • атрибут revocation-values, как определено в пункте 6.3.4. Если используются атрибутные сертификаты, то могут присутствовать следующие атрибуты: • атрибут attribute-certificate-references, как определено в пункте 6.2.3; • атрибут attribute-revocation-references, как определено в пункте 6.2.4. Кроме того, требуется один из следующих атрибутов: • атрибут CAdES-C-Timestamp, как определено в пункте 6.3.5; • атрибут time-stamped-certs-crls-references, как определено в пункте 6.3.6. Могут использоваться и другие неподписанные атрибуты, но они не являются обязательными. CAdES-X Long Type 1 или 2 CAdES-C CAdES-BES или CAdES-EPES Идентификтор регламента подписи (необязательн о) Подписанные атрибуты Цифровая подпись Штамп времени подписи необязателен при наличии метки времени Полные ссылки на сертифика ты и списки отзыва Штамп времени для CAdES-C Штамп времени для полных ссылок на сертификаты и списки отзыва Полные значения сертификатов и списков отзыва Рис. Б.4. Схема форматов CAdES-X Long Type 1 и CAdES-X Long Type 2 ETSI ETSI TS 101 733, версия 1.8.3 (201101) Б.2 Расширения штампа времени Каждый экземпляр атрибута time-stamp может включать в качестве неподписанных атрибутов в структуре signedData штампа времени следующие атрибуты, относящиеся к модулю штампов времени: • атрибут complete-certificate-references модуля штампов времени, как определено в пункте 6.2.1; • атрибут complete-revocation-references модуля штампов времени, как определено в пункте 6.2.2; • атрибут certificate-values модуля штампов времени, как определено в пункте 6.3.3; • атрибут revocation-values модуля штампов времени, как определено в пункте 6.3.4. Могут использоваться и другие неподписанные атрибуты, но они не являются обязательными. Б.3 Архивные проверочные данные (CAdES-A) Перед тем, как алгоритмы, ключи и другие криптографические данные, использованные на момент создания подписи CAdES-C, станут нестойкими, а криптографические функции станут уязвимыми или срок действия сертификатов, поддерживающих предыдущие штампы времени, истечет, к подписанным данным, CAdES-C и любым дополнительным сведениям (т. е. для любого варианта CAdES-X) должны быть применены штампы времени. При возможности следует использовать более стойкие алгоритмы, чем в исходном штампе времени (или ключи с большей длиной). Эти дополнительные данные и штамп времени называются архивными проверочными данными, необходимыми для формата архивной электронной подписи (CAdES-A). Процесс применения штампа времени может повторяться, если механизм защиты, использованный для добавления штампа времени к предыдущей подписи CAdES-A, ослабевает. Таким образом, подпись CAdES-A может содержать множество встроенных штампов времени. Пример электронной подписи с дополнительными проверочными данными для CAdES-C и CAdES-X, формирующими CAdES-A, показан на рис. Б.5. CAdES-A состоит из следующих элементов: • CAdES-BES или CAdES-EPES, а также соответствующие подписанные и неподписанные атрибуты; • атрибут complete-certificate-references, как определено в пункте 6.2.1; • атрибут complete-revocation-references, как определено в пункте 6.2.2. Необходимо наличие следующих атрибутов, если поставщик доверенных услуг не предоставляет метку времени для электронной подписи: • атрибут signature-time-stamp, как определено в пункте 6.1.1. Если используются атрибутные сертификаты, то могут присутствовать следующие атрибуты: • атрибут attribute-certificate-references, как определено в пункте 6.2.3; • атрибут attribute-revocation-references, как определено в пункте 6.2.4. Следующие атрибуты необходимы, если полные значения сертификатов и данных об отозванных сертификатах не включены в подпись CAdES-BES или CAdES-EPES: • атрибут certificate-values, как определено в пункте 6.3.3; • атрибут revocation-values, как определено в пункте 6.3.4. Кроме того, может присутствовать один ETSI ETSI TS 101 733, версия 1.8.3 (201101) из следующих атрибутов: • атрибут CAdES-C-Timestamp, как определено в пункте 6.3.5; • атрибут time-stamped-certs-crls-references, как определено в пункте 6.3.6. Следующие атрибуты являются обязательными: • атрибуты archive-time-stamp, как определено в пункте 6.4.1. ETSI ETSI TS 101 733, версия 1.8.3 (201101) В электронной подписи может быть несколько экземпляров атрибута archive-time-stamp, добавленных в разное время и от разных модулей штампов времени. Штамп времени должен создаваться с помощью надежных алгоритмов (или с помощью более длинных ключей), более стойких, чем алгоритмы в исходных электронных подписях и штампах времени. Могут использоваться и другие неподписанные атрибуты электронной подписи, но они не являются обязательными. Атрибут archive-time-stamp будет содержать данные о сертификатах и списках отзыва, необходимые для проверки archive-time-stamp. К ним могут относиться следующие неподписанные атрибуты: • атрибут complete-certificate-references модуля штампов времени, как определено в пункте 6.2.1; • атрибут complete-revocation-references модуля штампов времени, как определено в пункте 6.2.2; • атрибут certificate-values модуля штампов времени, как определено в пункте 6.3.3; • атрибут revocation-values модуля штампов времени, как определено в пункте 6.3.4. Могут использоваться и другие неподписанные атрибуты, но они не являются обязательными. CAdES-A CAdES-X CAdES-C CAdES-BES или CAdES-EPES Идентификтор регламента подписи (необязательн о) Все подписанные и неподписанны е атрибуты Цифровая подпись Штамп времени цифровой подписи Полные ссылки на сертификаты и списки отзыва Штамп времени для CAdES-C Штамп времени для полных ссылок на сертификаты и списки отзыва Рисунок Б.5. Схема формата CAdES-A ETSI Полные значения сертификат ов и списков отзыва Архивный штамп времени ETSI TS 101 733, версия 1.8.3 (201101) Б.4 Пример проверочной последовательности Как было описано ранее, подписывающая сторона или первоначальная проверяющая сторона может собрать все дополнительные данные, формирующие электронную подпись. На рис. Б.6 и далее описывается, как с помощью процесса проверки можно сформировать полную электронную подпись с течением времени. CAdES- C CAdES-T Элект. подпись (CAdES) Идентификатор регламента подписи (необязательно) Другие подписанные атрибуты Цифровая подпись Штамп времени цифровой подписи Полные ссылки на сертификаты и списки отзыва Подписанные данные пользователя Процесс проверки Издатель регламента подписи ■ Действительна ■ Недействительна ■ Проверка не завершена Поставщик доверенных услуг Рисунок Б.6. Схема проверочной последовательности CAdES Вскоре после получения электронной подписи (CAdES) от подписывающей стороны (1) можно проверить значение цифровой подписи. Процесс проверки обычно добавляет по крайней мере один штамп времени (2), если подписывающая сторона не предоставила штамп времени, которому доверяет проверяющая сторона. В процессе проверки можно также проверить электронную подпись с использованием дополнительных данных (например, сертификатов, списка отзыва сертификатов и т.д.), предоставленных поставщиком доверенных услуг. Если это возможно, процесс проверки должен соответствовать требованиям регламента подписи. Если в процессе проверка не завершается, то результатом работы процессы является подпись CAdES-T. Для подтверждения действительного или недействительного статуса и передачи этих сведений пользователю (4), все дополнительные данные, необходимые для проверки CAdES-C, должны быть доступны (например, полные данные о сертификатах и списках отзыва). Когда полный набор проверочных данных (CAdES-C) становится доступен, в процессе проверки следует выполнить следующие действия: • получить все необходимые дополнительные сертификаты и данные о статусе отзыва; • завершить все проверки электронной подписи с помощью полных данных о сертификатах и информации об отзыве (если штампа времени нет, его можно добавить на этом этапе, объединив процессы формирования CAdES-T и CAdES-C); • записать полные ссылки на сертификаты и списки отзыва (3); • уведомить пользователя о статусе подписи (4). В то же время, когда в процессе проверки создается подпись CAdES-C, процесс может предоставить и/или записать значения сертификатов и списков отзыва, используемые в CAdES-C (5). Конечный результат называется CAdES-X Long. ETSI ETSI TS 101 733, версия 1.8.3 (201101) Это показано на рис. Б.7. CAdES-X Long CAdES-T CAdES Идентификатор регламента подписи (необязательно) Другие подписанные атрибуты Подписанные данные пользователя Штамп времени цифровой подписи Цифровая подпись Проверка Издатель регламента подписи Полные ссылки на сертификаты и списки отзыва ■ Действительна ■ Недействительна Полные значения сертификат ов и списков отзыва Поставщик доверенных услуг Рисунок Б.7. Схема проверочной последовательности с CAdES-X Long Когда в процессе проверки создается подпись CAdES-C, также могут создаваться расширенные формы проверочных данных. Первым вариантом является применение штампа времени ко всем данным, формируя CAdES-X Type 1. Это показано на рис. Б.8. CAdES-X type 1 CAdES-C Элек. подпись (CAdES) Идентификтор регламента подписи (необязательно) Подписанные данные пользователя Другие подписанные атрибуты Штамп времени цифровой подписи Цифровая подпись Процесс проверки Издатель регламента подписи Полные ссылки на сертификат ы и списки отзыва ■ Действительна ■ Недействительна Штамп времени для CAdES-C Поставщик доверенных услуг Рисунок Б.8. Схема подписи CAdES с расширенными проверочными данными ETSI ETSI TS 101 733, версия 1.8.3 (201101) (CAdES-X Type 1) ETSI ETSI TS 101 733, версия 1.8.3 (201101) Другим вариантом является применение штампа времени к данным о сертификатах и списках отзыва для проверки электронной подписи (но не к самой подписи) (6). Конечный результат называется CAdES-X Type 2. Это показано на рис. Б.9. CAdES-X Type 2 CAdES-C Элек. подпись (CAdES) Идентификтор регламента подписи (необязательно ) Подписанные данные пользователя Другие подписанные атрибуты Цифровая подпись Полные ссылки на сертификат ы и списки отзыва Штамп времени цифровой подписи Процесс проверки ■ Действительна ■ Недействительна Штамп времени для полных ссылок на сертификаты и списки отзыва \ Издатель регламента подписи Поставщик доверенных услуг Рисунок Б.9. Схема подписи CAdES с расширенными проверочными данными (CAdES-X Type 2) До того, как алгоритмы, используемые в какой-либо из этих электронных подписей, будут скомпрометированы или, возможно, станут уязвимыми в будущем, может понадобиться применить штамп времени ко всей электронной подписи, в том числе ко всем проверочным и пользовательским данным, и сформировать электронную подпись с архивными проверочными данными (CAdES-A) (7). Подпись CAdES-A показана на рис. Б.10. ETSI ETSI TS 101 733, версия 1.8.3 (201101) CAdES-A CAdES-X CAdES-C Элек. подпись (CAdES Идентификатор регламента подписи (необязательно) Другие подписанные атрибуты Цифровая подпись Полные ссылки на сертификат ы и списки отзыва Штамп времени цифровой подписи Штамп времени для CAdES-C Штамп времени для полных ссылок на сертификаты и списки отзыва Полные значения сертификат ов и списков отзыва Архивны й штамп времени Подписанные данные пользователя Процесс проверки Издатель регламента подписи ■ Действител ьна ■ Недействит ельна Поставщик доверенных услуг Рисунок Б.10. Схема подписи CAdES-A Б.5 Дополнительные необязательные компоненты В настоящем документе также определены дополнительные компоненты, используемые для следующих целей: • указание типа обязательств подписывающей стороны; • указание заявленного времени создания подписи; • указание заявленного местоположения подписывающей стороны; • указание заявленной или сертифицированной роли, от имени которой была создана подпись; • поддержка удостоверяющих подписей; • поддержка множества подписей. ETSI ETSI TS 101 733, версия 1.8.3 (201101) Приложение В (справочное). Общее описание В данном приложении описываются концепции нормативных частей данного документа и приводится их обоснование. Спецификация, приведенная ниже, содержит описание того, почему и когда каждый компонент электронной подписи является полезным, с кратким описанием уязвимостей и угроз, а также способов защиты от них. В.1 Регламент подписи Регламент подписи – это набор правил для создания и проверки электронной подписи, с помощью которых можно определить действительность подписи. В данном юридическом и договорном контексте под регламентом подписи может пониматься соответствие требованиям. Регламент подписи может быть выдан, например, стороной, использующей электронные подписи, и выбран подписывающей стороной для взаимодействия с первой стороной. Или же регламент подписи может сформировать торговая ассоциация и его должны будут использовать все ее члены. Подписывающая и проверяющая стороны следуют одному регламенту подписи. Регламент подписи может быть явно идентифицирован или определен неявно семантикой подписываемых данных и других внешних данных, например, договора, на который приводится ссылка и который сам ссылается на регламент подписи. У явного регламента подписи есть глобальная уникальная ссылка, которая привязана к электронной подписи подписывающей стороной при вычислении подписи. Регламент подписи должен быть доступен в читабельном виде, чтобы можно было оценить, как он выполняет требования юридического и договорного контекста, в котором он применяется. Для реализации автоматической обработки электронной подписи те части регламента, которые определяют электронные правила создания и проверки электронной подписи, также должны быть подробно определены в виде, поддерживающем компьютерную обработку. Таким образом, регламент подписи включает в себя следующие компоненты: • правила, применяемые к технической проверке определенной подписи; • правила, которые могут неявно подразумеваться при принятии регламентов сертификатов, применяемых к электронной подписи (например, правила обеспечения секретности закрытого ключа подписи); • правила, относящиеся к среде, используемой подписывающей стороной, например, использование оговоренного устройства приема карт (CAD) вместе с пластиковой картой. Например, к числу основных правил, необходимых для технической проверки, могут относиться следующие правила: • признанные корневые ключи или «центры сертификации верхнего уровня»; • приемлемые регламенты сертификатов (если существуют); • необходимые расширения и значения сертификатов (если существуют); • необходимость статуса отзыва для каждого компонента дерева сертификации; • приемлемые службы штампов времени (если используются штампы времени); • приемлемые организации для хранения журналов аудита с метками времени (если используются метки времени); • приемлемые атрибутные центры (если они используются); • правила, определяющие компоненты электронной подписи, которые должна предоставить подписывающая сторона, и данные, требуемые проверяющей стороной для обеспечения долгосрочной ETSI ETSI TS 101 733, версия 1.8.3 (201101) проверки подписи. ETSI ETSI TS 101 733, версия 1.8.3 (201101) В.2 Подписанная информация Подписываемая информация может быть определена как сообщение в формате MIME, которое можно использовать для указания формата содержимого и выбора правильного способа его отображения или приложения для его обработки. Информация может состоять из форматированных данных, произвольного текста или полей электронной формы (e-form). Например, может использоваться формат PDF компании Adobe™ или язык XML. В приложении Г показано, как может структурироваться содержимое для указания типа подписанных данных с помощью MIME. В.3 Компоненты электронной подписи В.3.1 Ссылка на регламент подписи Если две независимые стороны хотят оценить электронную подпись, они обязательно должны получить одинаковый результат. Это требование можно выполнить с помощью подробных регламентов подписей, обеспечивающих согласованность проверки подписи. Регламенты подписи могут быть определены неявно, с помощью подписываемых данных, или определены явно, с помощью формата CAdES-EPES, который требует использовать один регламент подписи проверяющей и подписывающей сторонами. Подписывая идентификатор регламента подписи в CAdES-EPES, подписывающая сторона явно указывает, что она применила регламент подписи при ее создании. Для однозначного определения сведений о явном регламенте подписи, который должен использоваться для проверки подписи CAdES-EPES, подпись, идентификатор и хэш-значение регламента подписи должны входить в число подписываемых данных. Дополнительные сведения о явном регламенте (например, ссылка на документ в Интернете) могут передаваться как «квалификаторы» для идентификатора регламента подписи. Для однозначного определения уполномоченного лица, отвечающего за определение явного регламента подписи, можно подписать регламент подписи. В.3.2 Указание вида обязательств Тип обязательств можно указать в электронной подписи двумя способами: • явно используя атрибут commitment-type-indication в электронной подписи; • определив, явно или неявно, из семантики подписываемых данных. Если тип обязательства указан явно с помощью соответствующего атрибута в электронной подписи, принятие проверенной подписи подразумевает принятие семантики этого типа обязательства. Семантика явного указания типа обязательства может быть предметом договора между подписывающей и проверяющей стороной, может быть указана как часть регламента подписи или зарегистрирована для общего использования во множестве регламентов. Если используется формат электронной подписи CAdES-EPES и электронная подпись содержит указание типа обязательства, нераспознаваемое регламентом подписи, подпись считается недействительной. Сведения о том, как обязательства указываются с помощью семантики подписываемых данных, выходят за рамки данного документа. ПРИМЕЧАНИЕ. Примеры обязательств, указанных с помощью семантики подписываемых данных: ■ явное обязательство, взятое на себя подписывающей стороной и указанное типом подписываемых данных; таким образом, структура подписываемых данных может содержать явное обязательство в контексте приложения (например, заказ на покупку по стандарту EDIFACT); ■ неявное обязательство, взятое на себя подписывающей стороной, так как подписываемые данные обладали определенной семантикой (значением), которая может быть интерпретирована только человеком (т. е. произвольный текст). ETSI ETSI TS 101 733, версия 1.8.3 (201101) В.3.3 Идентификатор сертификата от подписывающей стороны Во многих реальных средах пользователи могут получить от разных центров сертификации и даже от одного центра сертификации разные сертификаты с одинаковым открытым ключом для различных имен. Основное преимущество состоит в том, что пользователь может применять один закрытый ключ для разных целей. Многократное использование закрытого ключа является преимуществом, если пластиковая карта применяется для защиты закрытого ключа, так как объем хранилища карты всегда ограничен. Если используются несколько центров сертификации, каждый сертификат может содержать отдельное удостоверение, например гражданина страны или сотрудника компании. Таким образом, если закрытый ключ используется для разных целей, сертификат нужен для разъяснения контекста, в котором закрытый ключ использовался при создании подписи. Если есть возможность использования нескольких закрытых ключей, подписывающая сторона должна указать проверяющей стороне конкретный используемый сертификат. Многие текущие схемы просто добавляют сертификат после подписанных данных и, следовательно, уязвимы для атак подмены. Если сертификат от подписывающей стороны просто добавлен к подписи и не защищен подписью, то кто угодно может заменить его на другой сертификат, при этом будет казаться, что сообщение подписано кем-то другим. Для защиты от такого типа атак идентификатор подписывающей стороны должен быть защищен цифровой подписью. Для однозначной идентификации сертификата, используемого для проверки подписи, идентификатор сертификата от подписывающей стороны должен входить в подписываемые данные. В.3.4 Атрибуты роли Несмотря на значимость имени подписывающей стороны, должность этой стороны в компании или организации не менее важна. Определенная информация (например, договор) может быть действительна, только если она подписана стороной с определенной ролью, например, директором по продажам. Во многих случаях не важно, кто является директором по продажам, но важна уверенность в том, что компания предоставила подписывающей стороне полномочия директора по продажам. В настоящем документе определены два способа реализации такой функциональности: • за счет размещения заявленного имени роли в поле подписанных атрибутов CMS; • за счет размещения атрибута с сертифицированным именем роли в поле подписанных атрибутов CMS. ПРИМЕЧАНИЕ. Другой возможный подход заключается в использовании дополнительных атрибутов с именами ролей в сертификате удостоверения подписывающей стороны. Однако было принято решение не использовать этот подход, так как он значительно усложняет управление сертификатами. Например, при использовании отдельных сертификатов для удостоверения и ролей подписывающей стороны нет необходимости выдавать новые ключи удостоверения при изменении роли пользователя. В.3.4.1 Заявленная роль Подписывающей стороне можно доверить указывать собственную роль без какого-либо сертификата, ее подтверждающего. В этом случае заявленную роль можно добавить в подпись как подписанный атрибут. В.3.4.2 Сертифицированная роль В отличие от сертификатов открытых ключей, привязывающих идентификатор к открытыму ключу, атрибутные сертификаты привязывают идентификатор сертификата к определенным атрибутам, таким как роль. Атрибутный сертификат выдается НЕ центром сертификации (CA), а атрибутным центром (AA). В большинстве случаев атрибутный центр может находиться под контролем организации или компании, которая лучше всех осведомлена о том, какие атрибуты относятся к каким лицам. Атрибутный центр может использовать сертификаты открытых ключей, выданные любым центром сертификации, или указывать на них, если соответствующее отношение доверия может быть установлено с этим центром сертификации. У атрибутных сертификатов могут быть различные периоды действия. Эти периоды могут быть довольно короткими, например, длиться один день. Хотя в этом случае необходимо получать новый атрибутный сертификат каждый день, здесь тоже есть свои преимущества, так как отзыв таких сертификатов может не требоваться. При подписании данных подписывающая сторона должна будет указать, какой атрибутный сертификат она выбирает. Для этого атрибутный сертификат ETSI ETSI TS 101 733, версия 1.8.3 (201101) нужно будет включить в подписываемые данные, чтобы обеспечить защиту цифровой подписью подписывающей стороной. Для однозначной идентификации атрибутных сертификатов, используемых для проверки подписи, идентификатор атрибутных сертификатов от подписывающей стороны должен входить в подписываемые данные. ETSI ETSI TS 101 733, версия 1.8.3 (201101) В.3.5 Местоположение подписывающей стороны В некоторых транзакциях может потребоваться указать местоположение подписывающей стороны во время применения подписи. Поэтому в подпись может быть включен дополнительный индикатор местоположения. Для указания местоположения подписывающей стороны во время применения подписи в нее может быть включен соответствующий атрибут (location). В.3.6 Время подписания Данный документ предоставляет возможность включать заявленное время подписания как атрибут электронной подписи. С помощью этого атрибута подписывающая сторона может указать заявленное время подписания. При создании электронной подписи со временем (CAdES-T) доверенный штамп времени извлекается и добавляется в электронную подпись, или же журнал аудита содержит доверенную метку времени. Когда проверяющая сторона принимает подпись, она может проверить, входят ли указанные значения времени в приемлемые границы. Еще один необязательный атрибут определен в данном документе для применения штампа времени к содержимому и предоставления доказательства существования содержимого на момент, указанный штампом времени. С помощью этого атрибута перед подписанием документа можно получить доверенное время и включить его в цифровую подпись. Для этого требуется подключиться к службе штампов времени до создания подписи, при этом значение времени может представлять собой неточное время подписи, так как оно может быть получено заранее. Однако этот необязательный атрибут может использоваться подписывающей стороной, чтобы доказать, что подписанный объект существовал до даты, указанной в штампе времени (см. пункт 5.11.4). В.3.7 Формат содержимого При представлении подписанных данных пользователю (человеку) важно отсутствие неоднозначности, как и при представлении подписанной информации проверяющей стороне. Для выбора адекватного представления данных (в виде текста, звука или видео) проверяющей стороной, когда данные (в отличие от данных, которые в дальнейшем подписываются или шифруются) встраиваются в структуру SignedData (если значение eContentType в поле EncapsulatedContentInfo равно id-data), следует использовать следующую информацию для определения типа подписываемого документа. В большинстве случаев для этого применяется типизация содержимого и механизм кодирования MIME, определенные в документе RFC 2045 [6]). Дополнительные сведения об использовании формата MIME представлены в приложении Е. В.3.8 Атрибут content-hints Атрибут content-hints предоставляет сведения о наиболее глубоко вложенном подписанном содержимом многоуровневого сообщения, в котором одно содержимое встроено в другое. Это может быть полезно, если подписанные данные зашифрованы. В.3.9 Перекрестные ссылки на содержимое При представлении подписанных данных в отношении других подписанных данных может быть необходимо определить связь между ними. Атрибуты content-reference и content-identifier, как определено в ESS (RFC 2634 [5]), предоставляют способ привязки сообщений запроса и ответа при обмене данными между двумя сторонами. ETSI ETSI TS 101 733, версия 1.8.3 (201101) В.4 Компоненты проверочных данных В.4.1 Информация о статусе отзыва Проверяющая сторона должна убедиться, что сертификат подписывающей стороны был действителен во время создания подписи. Этого можно добиться следующими способами: • с помощью списков отзыва сертификатов (CRL); • с помощью ответов от службы проверки статуса сертификатов в реальном времени (например, полученных по протоколу OCSP). ПРИМЕЧАНИЕ 1. Время подписи может быть неизвестно, поэтому штампы или метки времени могут использоваться для указания момента времени, когда подпись существовала. ПРИМЕЧАНИЕ 2. Если при проверке электронной подписи и данных о статусе отзыва необходим период отсрочки, он должен быть достаточно длительным, чтобы соответствующая служба смогла обработать последний запрос на отзыв сертификата, а запрос распространился в системе отзыва. Этот период отсрочки должен добавляться ко времени, указанному в штампе или метке времени, и, следовательно, данные о статусе отзыва должны быть получены после завершения периода отсрочки. В.4.1.1 Сведения CRL При использовании списков отзыва сертификатов для получения сведений об отозванных сертификатах проверяющая сторона должна убедиться, что на момент первой проверки она получает эти сведения от центра сертификации подписывающей стороны. Это должно быть сделано в кратчайшие сроки для минимизации задержки между созданием и проверкой подписи. Однако для того, чтобы центры сертификации обработали запросы на отзыв сертификатов, требуется период отсрочки. Например, запрос на отзыв может поступить в центр сертификации как раз перед выдачей следующего списка отзыва сертификатов, а времени на включение обновленной информации об отозванных сертификатах может быть недостаточно. Этот процесс также включает проверку того, что серийный номер сертификата подписывающей стороны не включен в список отзыва сертификатов. Как подписывающая сторона, так и первоначальная проверяющая сторона или последующая проверяющая сторона могут получить этот список. Если список получает подписывающая сторона, то он передается проверяющей стороне. Для упрощения последующей проверки или арбитража можно заархивировать список отзыва сертификатов. Или же, если список заархивирован в другом месте, что допустимо для арбитража, серийный номер использованного списка может быть заархивирован вместе с проверенной электронной подписью в формате CAdES-C. Даже если серийный номер сертификата есть в списке отзыва со статусом «приостановлен» (suspended), подпись не должна считаться действительной, так как приостановленный сертификат не должен использоваться даже своим полноправным владельцем. В.4.1.2 Сведения OCSP При использовании службы OCSP для получения сведений об отозванных сертификатах проверяющая сторона должна убедиться, что на момент первой проверки она получает ответ OCSP с действительным статусом. Это должно быть сделано в кратчайшие сроки после создания подписи, но при этом должен быть предоставлен период отсрочки, достаточный для того, чтобы соответствующая служба смогла обработать последние запросы на отзыв сертификата. Подписывающая, проверяющая или третья сторона могут получить этот ответ OCSP. Так как ответы OCSP являются временными и не архивируются поставщиками доверенных услуг, в том числе центром сертификации, каждая проверяющая сторона должна убедиться, что они хранятся в надежном месте. Проще всего сохранить их с привязкой к электронной подписи. Альтернативный метод – хранить ответы OCSP так, чтобы их можно было легко извлекать и встраивать ссылки на них в электронную подпись формата CAdES-C. Так же, как и при использовании списка отзыва сертификатов, сертификат может быть объявлен недействительным, но с дополнительным статусом «приостановлен» (suspended). В этом случае применим такой же комментарий, что и для списка отзыва сертификатов. ETSI ETSI TS 101 733, версия 1.8.3 (201101) В.4.2 Путь сертификации Проверяющей стороне может потребоваться убедиться в действительности пути сертификации на момент создания подписи вплоть до точки доверия в соответствии с: • ограничениями именования; • ограничениями регламента сертификата; • регламентом подписи, если он применим. Так как время подписи нельзя знать точно, следует использовать верхний предел времени, указанный штампом или меткой времени. В этом случае необходимо получить все сертификаты в пути сертификации, начиная с сертификатов подписывающей стороны и заканчивая самозаверенным сертификатом доверенного корневого центра сертификации. Если это возможно, эти сведения указываются как часть регламента подписи. Кроме того, необходимо получить списки отзыва центров сертификации (CARL), чтобы доказать, что ни один из центров сертификации из цепочки не был отозван на момент создания подписи. Опять же, весь этот материал может быть встроен в электронную подпись (формы ES X). Альтернативой может быть хранение этих данных так, чтобы их можно было легко извлекать и встраивать ссылки на них в электронную подпись формата CAdES-C. В.4.3 Штампы времени для долгосрочного использования подписей Важным свойством долгосрочных подписей является то, если подпись была признана действительной, она будет оставаться действительной через несколько месяцев и даже лет. У подписывающей стороны, проверяющей стороны или обеих этих сторон могут потребовать доказательство того, что цифровая подпись была создана или проверена в течение периода действия всех сертификатов, составляющих путь сертификации. В этом случае подписывающая сторона, проверяющая сторона или обе эти стороны также должны будут предоставить доказательство того, что сертификат подписывающей стороны и все сертификаты центра сертификации, используемые для формирования действительной цепочки сертификации, не были отозваны на момент времени создания или проверки подписи. Будет крайне трудно признать подпись недействительной, даже если использованные ключи или сертификаты были скомпрометированы в дальнейшем. Таким образом, существует необходимость иметь возможность продемонстрировать, что ключи подписи были действительны на момент ее создания, чтобы предоставить долгосрочное свидетельство действительности подписи. Может возникнуть ситуация, когда сертификат был действителен на момент создания подписи, но был отозван после этого. В таком случае должно быть предоставлено доказательство того, что документ был подписан до отзыва ключа подписи. Такое доказательство можно получить с помощью штампов времени от службы штампов времени (TSA). Штамп времени формируется за счет отправки хэш-значения указанных данных в службу штампов времени. Возвращенный «штамп времени» – это подписанный документ, содержащий это хэш-значение, удостоверение службы штампов времени и время применения штампа. Это доказывает, что указанные данные существовали до применения штампа времени. Применение штампа времени к цифровой подписи (за счет отправки хэш-значения службе штампов времени) перед отзывом закрытого ключа подписывающей стороны позволяет предоставить доказательство того, что подпись была создана до отзыва сертификата. Если получатель хочет принять действительную электронную подпись, он должен убедиться, что получил действительный штамп времени подписи до отзыва этого ключа (и любого другого ключа, используемого для проверки). Чем быстрее будет получен штамп времени после времени создания подписи, тем лучше. Любой штамп времени или любая метка времени, созданная после истечения срока действия любого сертификата в пути сертификации, не имеет ценности для доказательства действительности подписи. Следует отметить, что подписи могут быть созданы в автономном режиме, а штампы времени могут быть применены кем угодно в дальнейшем, например подписывающей стороной или любым получателем, заинтересованным в действительности подписи. Таким образом, можно предоставить штамп времени ETSI ETSI TS 101 733, версия 1.8.3 (201101) подписывающей стороне вместе с подписанным документом, или же он будет принят получателем после получения подписанного документа. Штамп времени НЕ ЯВЛЯЕТСЯ компонентом простой электронной подписи, но при этом он является важным компонентом электронной подписи со значением времени. В соответствии с данным документом при применении штампа времени к цифровой подписи подписывающей стороны штамп времени выдается доверенным источником, который называют службой штампов времени. Согласно данному документу, для того, чтобы электронная подпись стала считаться подписью с полными проверочными данными, к цифровой подписи должен быть применен штамп времени от доверенного источника. Допустимые службы штампов времени могут быть указаны в регламенте проверки подписи. В настоящем документе такой метод называется форматом CAdES-C. ETSI ETSI TS 101 733, версия 1.8.3 (201101) Если и подписывающая, и проверяющая сторона должны применить штамп времени к подписи для выполнения требований регламента подписи, то в регламенте может быть указана допустимая задержка между двумя штампами времени. В.4.4 Штампы времени для долгосрочного использования подписей до компрометации ключа центра сертификации Расширенные электронные подписи со штампами времени необходимы при наличии требования защиты от возможности компрометации ключа центра сертификации в цепочке сертификатов. У проверяющей стороны могут потребовать предоставить по запросу доказательство того, что путь сертификации и данные об отозванных сертификатах были действительны на момент создания подписи, даже если один из выданных ключей или ключей службы OCSP был скомпрометирован в дальнейшем. В настоящем документе определены два способа использования штампов времени для защиты от компрометации ключей: • применение штампа времени к электронной подписи с полными проверочными данными при использовании ответа OCSP для получения статуса сертификата от подписывающей стороны (CAdES-X Type 1). Этот формат приемлем для использования с ответами OCSP и обеспечивает дополнительные преимущества – защиту целостности всех данных. • применение штампа времени только к пути сертификации и ссылкам на сведения об отозванных сертификатах при использовании списков отзыва сертификатов для получения статуса сертификата от подписывающей стороны (CAdES-X Type 2). Такой формат подходит при использовании списков отзыва сертификатов, так как информацию со штампом времени можно использовать для нескольких подписей (если у подписывающих сторон есть свои сертификаты, выданные одним центром сертификации и если подписи можно проверить с помощью одинаковых списков отзыва сертификатов). ПРИМЕЧАНИЕ. штамп времени. Подписывающая сторона, проверяющая сторона или обе этих стороны могут получить В.4.4.1 Добавление штампов времени в электронную подпись с полными проверочными данными (CAdES-X Type 1) При использовании ответа OCSP необходимо применить штамп времени к этому ответу в случае, если ключ от службы OCSP скомпрометирован. Так как информация в ответе OCSP относится к определенному пользователю и моменту времени, для каждой полученной подписи требуется отдельный штамп времени. Вместо применения штампа времени только к ссылкам на путь сертификации и данным об отозванных сертификатах, которые включают ответ OCSP, штамп времени применяется к подписи CAdES-C. Так как путь сертификации и ссылки на данные об отозванных сертификатах включены в подпись с полными проверочными данными, они также защищены. Это обеспечивает механизм обеспечения целостности электронной подписи с полными проверочными данными с теми же криптографическими затратами. Любое изменение может быть обнаружено незамедлительно. Следует отметить, что существуют и другие средства защиты целостности и обнаружения нарушения целостности электронной подписи с полными проверочными данными, которые также можно использовать. Хотя для этого метода требуется штамп времени для каждой подписи, он хорошо подходит для отдельных пользователей, желающих получить копию всех полученных проверенных подписей с защищенной целостностью данных. За счет применения штампа времени к полной электронной подписи, в том числе цифровой подписи и всем ссылкам на сертификаты и данные об отозванных сертификатах, используемые для проверки подписи, можно гарантировать, что результат проверки будет однозначным. В данном документе такой метод называется форматом CAdES-X Type 1. ПРИМЕЧАНИЕ. Отношение доверия достигается за счет включения хэш-значения данных, на которые указывается ссылка. Если по какой-либо причине требуется сохранить копию дополнительных данных, на которые указана ссылка, можно прикрепить к электронной подписи дополнительные данные. В этом случае подпись становится подписью CAdES-X Type 1, как определено в настоящем документе. CAdES-X Long Type 1 – это просто объединение подписи CAdES-X Type 1 и копии дополнительных данных, на которые указывают ссылки. ETSI ETSI TS 101 733, версия 1.8.3 (201101) В.4.4.2 Добавление штампов времени в сертификаты и ссылки на сведения об отзыве (CAdES-X Type 2) Применение штампа времени к каждой электронной подписи с полными проверочными данными, как описано выше, может быть неэффективно, особенно когда один набор сертификатов центров сертификации и сведения о списке отзыва сертификатов используются для проверки множества подписей. Применение штампов времени к сертификатам центра сертификации не позволит злоумышленникам выдать фальшивые сертификаты центра сертификации, которые по заявленной информации существовали до компрометации ключа центра сертификации. Любые поддельные сертификаты центра сертификации со штампом времени покажут, что сертификат был создан после компрометации действительного ключа центра сертификации. Таким же образом, применение штампов времени к спискам отзыва сертификатов центра сертификации не позволит злоумышленникам выдать фальшивые списки отзыва сертификатов, которые якобы существовали до компрометации ключа центра сертификации. Применить штампы времени к часто используемым сертификатам и спискам отзыва сертификатов можно централизованно, т.е. в компании или с помощью поставщика услуг. Этот метод сокращает объем данных, к которым проверяющая сторона должна применить штампы времени. Например, число штампов можно сократить до одного в день (если все подписывающие стороны используют один центр сертификации, а список отзыва сертификата действителен в течение всего дня). Информация, к которой нужно применить штамп времени – это не сами сертификаты и списки отзыва, а однозначные ссылки на них. В данном документе такой метод называется форматом CAdES-X Type 2 и для его применения необходимо соблюдать следующее условие: • все ссылки на сертификаты центра сертификации и данные об отозванных сертификатах (т.е. списки отзыва сертификатов), используемые при проверке CAdES-C, покрываются одним или несколькими штампами времени. Таким образом, подпись CAdES-C со штампом времени на значении подписи на момент времени T1 может считаться действительной, если штамп времени был применен ко всем ссылкам на сертификаты и списки отзыва сертификатов после T1. В.4.5 Штампы времени для архива подписи Развитие компьютерной отрасли повысило вероятность взлома алгоритмов и компрометации ключей. Поэтому существует требование защиты электронных подписей от такой возможности. С течением времени криптографические алгоритмы, использованные для создания электронной подписи, могут потерять стойкость (например, из-за времени, доступного для криптоанализа, или улучшения методов криптоанализа). Перед тем, как вероятность потери стойкости алгоритмов станет высокой, проверяющая сторона должна принять дополнительные меры для обеспечения действительности электронной подписи. Для достижения этой цели можно использовать разные методы в зависимости от природы ослабления криптографического алгоритма. Для простоты в настоящем документе используется один метод – архивные проверочные данные. Архивные проверочные данные состоят из проверочных данных и полных данных о сертификатах и отозванных сертификатах, которые включены в электронную подпись и которым применен штамп времени. Архивные проверочные данные необходимы, если хэш-функция и криптографические алгоритмы, использованные для создания подписи, более не являются безопасными. Кроме того, если хэш-функция, используемая службой штампов времени, не может считаться безопасной, требуются вложенные штампы времени архивной электронной подписи. Вероятность компрометации поставщика доверенных услуг должна быть значительно меньше, чем вероятность компрометации ключей пользователя, так как поставщики доверенных услуг, как ожидается, используют более стойкие криптографические алгоритмы и ключи. Можно ожидать, что будут использоваться новые алгоритмы (или старые алгоритмы с более длинными ключами). В этом случае последовательность штампов времени обеспечит защиту от подделки подписи. Каждый штамп времени должен быть применен до компрометации ключа подписи или взлома алгоритмов, используемых службой штампов времени. Службы штампов времени должны использовать длинные ключи (так, на момент создания проекта данного документа длина ключа для алгоритма подписи RSA составляла, как минимум, 2048 бит) и более стойкий или другой криптографический алгоритм. ETSI ETSI TS 101 733, версия 1.8.3 (201101) Вложенные штампы времени также защищают проверяющую сторону от компрометации ключа или взлома алгоритма старых электронных подписей. Данный процесс защиты следует реализовать и повторить до того, как криптографические алгоритмы, использованные для создания предыдущего штампа времени, перестанут быть безопасными. Таким образом, архивные проверочные данные могут содержать множество встроенных штампов времени. В данном документе такой подход называется форматом CAdES-A. ETSI ETSI TS 101 733, версия 1.8.3 (201101) В.4.6 Ссылки на дополнительные данные Даже при использовании расширенных проверочных данных CAdES-X Type 1 или CAdES-X Type 2 проверяющие стороны все равно должны отслеживать все компоненты, использованные для проверки подписи, чтобы в дальнейшем иметь возможность их извлечения. Эти компоненты могут быть заархивированы внешним источником, например, поставщиком доверенных услуг. В этом случае информация, предоставленная как часть электронной подписи с полными проверочными данными (CAdES-C), является адекватной. Фактические ссылки на сертификаты и сведения о списке отзыва сертификатов в подписи CAdES-C можно получить, когда они необходимы для арбитража. Если ссылки на дополнительные данные не являются адекватными, может потребоваться включить фактические значения всех данных о сертификатах и списках отзыва в электронную подпись. В данном документе такой подход называется форматом CAdES-X Long Type 1 и CAdES-X Long Type 2. В.4.7 Штампы времени для взаимного распознавания В некоторых бизнес-сценариях и подписывающая, и проверяющая стороны должны применить штамп времени к собственной копии значения подписи. В идеальной ситуации два штампа времени должны быть максимально близки друг к другу по времени. ПРИМЕР. Контракт подписывается двумя сторонами, А и Б, представляющими соответствующие организации. Доступны два метода применения штампа времени к данным подписывающей и проверяющей сторон: ■ по условиям данного контракта можно использовать одного заранее известного «надежного» поставщика доверенных услуг; ■ если обе организации используют собственные службы штампов времени, А и Б могут применить штамп времени к транзакции с помощью этих служб штампов времени. Во втором случае электронная подпись будет считаться действительной, только если оба штампа времени были получены в приемлемое время (т. е. между получением штампов времени не должно быть длительной задержки). Таким образом, ни А, ни Б не смогут отказаться от времени подписи, указанного собственной службой штампов времени. Поэтому А и Б не нужно договариваться о «надежном» поставщике доверенных услуг для осуществления действительной транзакции. Следует отметить, что подписи могут быть созданы в автономном режиме, а штампы времени могут быть применены кем угодно в дальнейшем, например подписывающей стороной или получателем, заинтересованным в действительности подписи. Таким образом, можно предоставить штамп времени подписывающей стороне вместе с подписанным документом, или же он будет принят получателем после приема подписанного документа. Бизнес-сценарии могут потребовать использования одного или нескольких , описанных выше методов применения штампа времени к долгосрочной подписи. Эта информация может быть включена в согласованный регламент проверки подписи, входящий в общий регламент подписи, согласно которому цифровые подписи можно использовать для поддержки деловых отношений между двумя сторонами. В.4.8 Компрометация ключа службы штампов времени Серверы службы штампов времени должны быть реализованы так, чтобы после установки закрытого ключа подписи вероятность его компрометации была минимальной в течение максимально долгого периода времени. Таким образом, период действия ключей службы штампов времени должен быть как можно более длительным. И CAdES-T, и CAdES-C содержат по крайней мере один штамп времени для подписи подписывающей стороны. Для обеспечения защиты от компрометации закрытого ключа подписи, использованного для создания штампа времени, можно применять архивные проверочные данные, если другая служба штампов времени вовлечена в процесс создания дополнительного штампа времени. Если считается, что ключ службы штампов времени, использованный для формирования предыдущего штампа времени, может быть скомпрометирован (например, после истечения срока действия), то следует использовать подпись CAdES-A. Для очень долгих периодов времени этот процесс можно повторять с использованием новых ключей служб штампов времени. В данном документе такой подход называется вложенным форматом CAdES-A. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) В.5 Множество подписей Некоторые электронные подписи могут быть действительны, только если они содержат несколько подписей. Обычно это происходит при подписании контракта между двумя сторонами. Порядок применения подписей может быть как важен, так и не важен. Может потребоваться поддержка нескольких форм множественных и удостоверяющих подписей, которые делятся на две основные категории: • независимые подписи; • встроенные подписи. Независимые подписи – это параллельные подписи, для которых порядок не имеет значения. Существует возможность использования нескольких независимых подписей для одних и тех же данных. Встроенные подписи применяются одна за другой и используются, если порядок применения подписей важен. При этом существует возможность подписи уже подписанных данных. Эти формы описаны в пункте 5.13. Все другие схемы множественных подписей, таких как подписанный документ с удостоверяющей подписью, двойная удостоверяющая подпись или множество подписей, можно свести к одному или нескольким описанным выше случаям. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение Г (справочное). Протоколы данных для взаимодействия с поставщиками доверенных услуг Г.1 Оперативные протоколы Подписывающие и проверяющие стороны могут использовать следующие протоколы для взаимодействия с поставщиками доверенных услуг во время создания и проверки электронных подписей. Г.1.1 Извлечение сертификата Сертификаты пользователей, центра сертификации и перекрестные сертификаты можно извлечь из репозитория с помощью протокола LDAP, как определено в документе RFC 3494 [i.10], с использованием схемы, описанной в документе RFC 4523 [i.11]. Г.1.2 Извлечение списка отзыва сертификатов Списки отзыва сертификатов, в том числе списки отзыва центров сертификации и частичные списки отзыва сертификатов, можно извлечь из репозитория с помощью протокола LDAP, как определено в документе RFC 3494 [i.10], с использованием схемы, описанной в документе RFC 4523 [i.11]. Г.1.3 Оперативный статус сертификата В качестве альтернативы использованию списков отзыва сертификатов статус сертификата можно проверить с помощью протокола проверки состояния сертификата в режиме реального времени (OCSP), как указано в документе RFC 2560 [3]. Г.1.4 Штампы времени Доступ к службе штампов времени можно получить с помощью протокола TSP, определенного в документе RFC 3161 [7]. Г.2 Протоколы управления Подписывающие и проверяющие стороны могут использовать следующие протоколы управления для контроля использования сертификатов. Г.2.1 Запрос на отзыв сертификата Запросить отзыв сертификата можно, используя сообщения запроса и ответа отзыва, определенные в документе RFC 4210 [i.12]. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение Д (справочное). Вопросы безопасности Д.1 Защита закрытого ключа Безопасность механизма электронной подписи, определенного в данном документе, зависит от безопасности закрытого ключа подписывающей стороны. Реализации данного механизма должны принимать меры для защиты закрытых ключей от компрометации. Д.2 Выбор алгоритмов При реализации механизма электронной подписи следует помнить, что стойкость криптографических алгоритмов с течением времени ослабевает. По мере разработки новых методов криптоанализа и наращивания вычислительной мощности компьютеров трудозатраты для взлома определенного криптографического алгоритма снижаются. Поэтому реализации криптографических алгоритмов должны быть модульными и обеспечивать оперативное включение новых алгоритмов. Т. е. следует быть готовым к тому, что набор обязательных к реализации алгоритмов со временем изменится. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение Е (справочное). Пример структурированного содержимого и использования формата MIME Е.3 Использование MIME для кодирования данных Подписанное содержимое может быть структурировано с помощью формата MIME (многоцелевые расширения электронной почты, документ RFC 2045 [6]). Хотя структура MIME изначально была разработана для электронной почты, она обладает рядом характеристик, которые делают ее полезной при кодировании различных электронных документов и других мультимедийных данных (например, фотографий и видео). К ним относятся следующие характеристики: • предоставление средств для указания типа передаваемого «объекта» (например, текст, изображение, ZIP- файл, данные приложения); • предоставление средств для связи имени файла с объектом; • связь нескольких независимых объектов (например, документа и изображения) для формирования составного объекта; • обработка данных, закодированных в текстовом или двоичном формате, и, если необходимо, перекодирование двоичных данных в текст. При кодировании одного объекта данные MIME состоят из следующих компонентов: • сведения заголовка; • кодированное содержимое. Эту структуру можно расширить для поддержки составного содержимого. Е.1.1 Данные заголовка Заголовок MIME содержит следующие данные. Сведения о версии MIME: например, MIME-Version: 1.0 Сведения о типе информации, включающие информацию, описывающую содержимое в степени, достаточной для ее представления пользователю или приложению. К ним относятся сведения о типе мультимедийных данных (например, текст, изображение, звук) или указание того, что данные передаются для определенного типа приложения. В случае с текстовыми данными тип содержимого содержит информацию об использованном наборе символов. Например, Content-Type: text/plain; charset="us-ascii" Информация о формате кодирования содержимого, которая определяет способ кодирования данных (сведения о форматах кодирования, поддерживаемых MIME, см. далее). Другая информация о содержимом, например описание или связанное с ним имя файла. Пример заголовка MIME для текстового объекта: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Пример заголовка MIME для двоичного файла, содержащего документ PDF: ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Content-Type: application/pdf Content-Transfer-Encoding: base64 Content-Description: JCFV201.pdf Content-Disposition: filename="JCFV201.pdf" ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Е.1.2 Кодирование содержимого MIME поддерживает ряд механизмов для кодирования текстовых и двоичных данных. Текстовые данные можно передавать открыто как строки текстовых данных в виде 7- или 8-битных символов ASCII. MIME также поддерживает кодировку вида «Допущено к печати», которая преобразует символы, отличные от базовых символов ASCII, в ASCII-последовательность. Двоичные данные могут передаваться следующими способами: • открыто, в виде 8-битных октетов; • с преобразованием в базовый набор символов с помощью системы Base64. ПРИМЕЧАНИЕ. Так как существуют ретрансляторы электронной почты, которые могут обрабатывать только 7-битные символы ASCII, кодирование Base64 обычно используется в Интернете. Е.1.3 Составное содержимое Несколько объектов (например, текст и вложенный файл) можно связать друг с другом с помощью специального типа «составного» (multi-part) содержимого. Для этого используется тип содержимого multipart с указанием строки, которая будет использоваться для разделения каждой части содержимого. Помимо заголовка для всего составного содержимого каждая его часть содержит собственный заголовок, определяющий внутренний тип содержимого и формат кодирования. Пример составного содержимого: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BC4599.98004A80" Content-Transfer-Encoding: 7bit ----- =_NextPart_000_01BC4599.98004A80 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Per your request, I've attached our proposal for the Java Card Version 2.0 API and the Java Card FAQ. ----- =_NextPart_000_01BC4599.98004A80 Content-Type: application/pdf; name="JCFV201.pdf" Content-Transfer-Encoding: base64 Content-Description: JCFV201.pdf Content-Disposition: attachment; filename="JCFV201.pdf" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAA EAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA//////////////////////////////////////// AANhAAQAYg== ----- =_NextPart_000_01BC4599.98004A80-- Составное содержимое может быть вложенным. Таким образом, набор связанных объектов (например, текст HTML и изображения) можно обработать как одно вложение в другом объекте (например, текстовом). Поле Content-Type каждой части сообщения MIME указывает тип содержимого. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Е.2 S/MIME Специальное использование формата MIME для передачи защищенных данных CMS (с расширением, указанным в настоящем документе) называется S/MIME (см. документ RFC 3851 [i.13]). Эл. почта От: Иванова Кому: Сидорову Тема: подписанный документ. S/MIME Content Type= application/pkcs7 CMS + подпись ETSI MIME Content Type = application/ octetstream SignedData Econtent Файл Word Уважаемый господин Иванов, получили 100 банок. Сидоров. Рисунок Е.1. Схема связи с использованием S/MIME S/MIME передает электронные подписи следующими способами: • как объект application/pkcs7-mime с данными CMS в виде двоичного вложения (PKCS7 – имя предыдущей версии CMS); - подписанные данные могут быть включены в структуру SignedData, которая может быть включена в один объект S/MIME. См. документ RFC 3851 [i.13], пункт 3.4.2: «Подпись с использованием application/pkcs7-mime и структуры SignedData» и рис. Е.2 ниже. или • как объект multipart/signed с подписанными данными и подписью, закодированными как отдельные объекты MIME; - подписанные данные не включаются в структуру SignedData, а структура CMS содержит только подпись. См. документ RFC 3851 [i.13], пункт 3.4.3: «Подпись с использованием формата multipart/signed» и рис. Е.3 ниже. Рисунок Е.2. Подпись с использованием application/pkcs7-mime Е.2.1 Использование application/pkcs7-mime Этот подход аналогичен обработке подписанных данных, как любого другого вложенного двоичного файла. Пример подписанных данных, закодированных с использованием этого подхода: ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Content-Type: application/pkcs7-mime; smime-type=signed-data; Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75 ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Е.2.2 Использование application/pkcs7-signature CMS также поддерживает альтернативную структуру, в которой подпись и защищаемые данные являются отдельными объектами MIME, которые передаются в одном сообщении. В этом случае подписанные данные не включаются в структуру SignedData, а структура CMS содержит только подпись. См. документ RFC 3851 [i.13], пункт 3.4.3: «Подпись с использованием формата multipart/signed» и рис. Е.3 ниже. Пример подписанных данных, закодированных с использованием этого подхода: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 --boundary42 Content-Type: text/plain This is a clear-signed message. --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42-- При использовании второго подхода подписанные данные проходят через процесс CMS и передаются как часть подписанной составной структуры MIME, как показано на рис. Е.3. Структура CMS содержит только электронную подпись. Рисунок Е.3. Подпись с использованием application/pkcs7-signature У второго подхода с использованием multipart/signed есть преимущество, которое состоит в том, что подписанные данные может декодировать любая система, совместимая с MIME, даже если она не распознает электронные подписи, закодированные CMS. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение Ж (справочное). Связь с Европейской директивой и инициативой EESSI Ж.1 Введение В данном приложении описывается связь электронных подписей, созданных в соответствии с настоящим документом, и требований директивы Европейского парламента и Совета, посвященной электронным подписям [i.5]. ПРИМЕЧАНИЕ. Для получения дополнительных сведений о национальных законодательных требованиях, касающихся использования электронных подписей, необходима юридическая консультация. Настоящий документ – это один из наборов стандартов, определенных согласно «Европейской инициативе по стандартизации электронных подписей» (EESSI) и посвященных продуктам и решениям для использования электронных подписей, совместимых с Европейской директивой по электронным подписям [i.5]. Ж.2 Электронные подписи и директива В данной директиве [i.5] электронные подписи определены как: • «данные в электронном виде, которые присоединены или логически связаны с другими электронными данными и которые служат методом проверки подлинности». Директива [i.5] указывает, что электронная подпись не должна лишаться «юридического действия и приемлемости в качестве доказательства в юридических процессах» только на основании того, что она представлена в электронной форме. Директива [i.5] определяет электронную подпись как эквивалентную собственноручной подписи, если она соответствует определенным критериям. • Это «усовершенствованная электронная подпись» со следующими свойствами: а) она уникально связана с подписывающей стороной; б) она позволяет идентифицировать подписывающую сторону; в) она создана с помощью средств, которые контролируются только подписывающей стороной; г) она связана с данными так, что любое последующее изменение данных можно обнаружить. • Она основана на сертификате, который соответствует подробным критериям, указанным в приложении I директивы [i.5], и выдается «поставщиком услуг сертификации», соответствующим требованиям, указанным в приложении II директивы [i.5]. Такой сертификат называется «квалифицированным сертификатом». • Она создается «устройством», подробные критерии для которого указаны в приложении III директивы [i.5]. Такое устройство называется «устройством для безопасного создания подписи». Такая форма электронной подписи называется «квалифицированной электронной подписью» в EESSI (см. далее). ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Ж.3 Форматы электронной подписи ETSI и директива Электронная подпись, созданная в соответствии с данным документом: а) считается «электронной подписью» согласно условиям директивы [i.5]; б) считается «усовершенствованной электронной подписью» согласно условиям директивы [i.5]; в) считается «квалифицированной электронной подписью», если выполнены дополнительные требования, указанные в приложениях I, II и III директивы [i.5]. Требования, указанные в приложениях I, II и III директивы [i.5], выходят за рамки данного документа и регламентируются в других стандартах. Ж.4 Стандарты EESSI и классы электронных подписей Ж.4.1 Структура стандартов EESSI EESSI рассматривает стандарты в нескольких областях. Последний список стандартов и их версий см. на сайтах ETSI и CEN: • использование сертификатов открытых ключей X.509 в качестве квалифицированных сертификатов; • управление безопасностью и регламент сертификатов для поставщиков служб шифрования, выдающих квалифицированные сертификаты; • требования безопасности для надежных систем, используемые поставщиками служб шифрования, выдающими квалифицированные сертификаты; • требования безопасности для устройств безопасного создания подписей; • требования безопасности для систем создания подписей; • процедуры проверки электронной подписи; • синтаксис и форматы кодирования электронных подписей; • протокол для взаимодействия со службой штампов времени; • требования регламента для служб штампов времени; • форматы электронных подписей XML. Каждый из этих стандартов описывает ряд требований, в том числе требования для квалифицированных электронных подписей, как указано в статье 5.1 директивы [i.5]. Однако некоторые из них также посвящены общим требованиям для электронных подписей, используемых для бизнеса и электронной коммерции, которые подпадают под категорию статьи 5.2 директивы [i.5]. Такую вариативность требований можно определить как разные уровни или разные варианты использования. Ж.4.2 Классы электронных подписей Так как некоторые из этих стандартов описывают определенный спектр требований, рекомендуется определить набор стандартов для решения конкретных бизнес-задач. Такой набор стандартов и их применение определяют класс электронных подписей. Уже определенный первый класс – это квалифицированная электронная подпись, соответствующая требованиям 5.1 директивы [i.5]. Можно определить ограниченный набор «классов электронных подписей» и соответствующих профилей в тесном сотрудничестве с действующими лицами на рынке (компании, пользователи, поставщики). Потребность в таких стандартах (помимо квалифицированных электронных подписей) возникает в таких областях, как: ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) • разные классы долгосрочных электронных подписей; • электронные подписи для бизнес-транзакций с ограниченной ценностью. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Ж.4.3 Классы электронных подписей и формат электронной подписи ETSI Формат электронной подписи, определенный в настоящем документе, применим к области EESSI – «форматы электронной подписи и кодирования». Электронная подпись, созданная подписывающей стороной (см. пункты 5 и 10.1), применима к следующему классу электронных подписей: «квалифицированные электронные подписи, соответствующие требованиям статьи 5.1» При добавлении атрибутов проверяющей стороной (см.пункты 6 и 10.2) квалифицированная электронная подпись становится долгосрочной. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение З (справочное). Интерфейсы API для формирования и проверки маркеров электронных подписей Несмотря на то, что в данном документе описывается формат электронной подписи, возникает вопрос о существовании программных интерфейсов (API) для управления такими структурами. Определено, по крайней мере, два таких интерфейса API: один, заданный группой инженерной поддержки Интернета (IETF), и другой, определенный Группой управления объектами (OMG). З.1 Кадры данных Для использования этих интерфейсов требуется разбить ранее определенные структуры данных электронной подписи на кадры с помощью формата маркеров, независимого от механизмов реализации. В пункте 3.1 документа RFC 2743 [i.14] описывается независимый от механизмов уровень инкапсуляции исходного маркера последовательности контекста GSS-API, использующий идентификатор типа механизма, который будет применяться в этом контексте и позволяющий однозначно интерпретировать маркеры. Чтобы эти интерфейсы могли обработать все форматы данных электронной подписи, определенные в настоящем документе, они разбиваются на кадры в соответствии со следующим описанием. Формат кодирования тега маркера получен из ASN.1 и DER, но его конкретное представление определено непосредственно в форме октетов, а не на уровне ASN.1, для обеспечения совместимой реализации без использования общего кода обработки ASN.1. Тег маркера состоит из следующих элементов (в указанном порядке): 1) 0x60 – тег для последовательности (SEQUENCE) из документа RFC 2743 [i.14]; указывает, что далее следует кодированная форма заданной длины; 2) октеты, определяющие длину последующих данных (т. е. суммированную длину элементов 3-5 из этого списка, а также объект маркера, определенного используемым механизмом, следующий за тегом). Этот элемент состоит из переменного числа октетов: - если указанное значение меньше 128, оно представляется одним октетом, восьмой (старший) бит которого задан как 0, а оставшиеся биты представляют само значение; - если указанное значение больше или равно 128, оно представлено двумя или более октетами, где восьмой бит первого октета задан как 1, а оставшиеся биты первого октета указывают число дополнительных октетов; последующие октеты содержат значение, по 8 бит на октет, начиная со старшего бита; для кодирования длины используется минимальное число октетов (т. е. в кодировку длины не включаются октеты, представляющие начальные нули). 3) 0x06 – тег для идентификатора объекта (OBJECT IDENTIFIER); 4) длина идентификатора объекта – длина (число октетов) идентификатора объекта, который содержится в элементе 5, закодированного согласно правилам, описанным в пунктах 2а и 2б выше; ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) 5) Октеты идентификатора объекта – переменное число октетов, закодированных по правилам ASN.1 BER: - первый октет содержит сумму двух значений: (1) компонент идентификатора объекта верхнего уровня, умноженный на 40 (в десятичном формате); (2) компонент идентификатора объекта второго уровня. Это единственный случай, когда при кодировании идентификатора объекта один октет представляет содержимое нескольких компонентов. - Последующие октеты при необходимости последовательно кодируют младшие компоненты в представленном идентификаторе объекта. Кодирование компонента может занимать несколько октетов, по 7 бит на октет (старшие биты идут первыми), а восьмой бит равен 1 для всех октетов кроме последнего. Для кодирования каждого компонента используется минимальное число октетов (т. е. в кодировку компонента не включаются октеты, представляющие начальные нули). ПРИМЕЧАНИЕ. Во многих реализациях элементы 3-5 могут храниться и указываться как смежные строковые константы. Тег маркера идет сразу после объекта маркера, определяемого механизмом. Учтите, что никакой независимый указатель размера не изменяет следующее значение идентификатора объекта для указания размера объекта маркера, определяемого механизмом. Маркеры, соответствующие требованиям настоящего документа, включают следующий идентификатор объекта (OID) для обработки интерфейсами IDUP-API: id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= { itu-t(0) identified-organization(4) etsi(0) electronic-signature-standard (1733) part1 (1) IDUPMechanism (4) etsiESv1(1) } З.2 Интерфейсы IDUP-GSS-API, определенные IETF Рабочая группа IETF CAT в декабре 1998 г. представила документ RFC 2479 [i.15], описывающий интерфейс IDUPGSS-API (Independent Data Unit Protection, независимая защита модулей данных), позволяющий обрабатывать формат данных электронной подписи, определенный в настоящем документе. Интерфейс IDUP-GSS-API поддерживает службы, гарантирующие невозможность отказа от обязательств. Он поддерживает формирование свидетельств (где «свидетельство» – это информация, которая сама по себе или вместе с другой информацией используется для предоставления доказательства выполнения события или действия), а также проверку свидетельств. IDUP поддерживает разные типы доказательств. Все типы, определенные в IDUP, поддерживаются данным документом с помощью параметра commitment-type. В пункте 2.3.3 IDUP описываются вызовы, необходимые для обработки доказательств (вызовы EV). Группа вызовов EV предоставляет простой высокоуровневый интерфейс для взаимодействия с соответствующими механизмами IDUP, когда разработчики приложения сталкиваются с единственным доказательством: без шифрования и служб обеспечения целостности данных. Все операции создания и проверки выполняются в соответствии с содержимым политики NR, указанной в контексте. Get_token_details используется для возврата в приложение атрибутов, соответствующих заданному входному маркеру. Так как маркеры IDUP-GSS-API должны быть непрозрачными для вызывающего приложения, эта функция позволяет приложению получить сведения о маркере без нарушения непрозрачности IDUP. Очень большое значение имеет тип механизма, который приложение может использовать как входные данные для вызова функции IDUP_Establish_Env() для определения правильной среды, в которой необходимо обработать маркер. Функция Generate_token создает маркер невозможности отказа с использованием текущей среды. Функция Verify_evidence проверяет маркер свидетельства с помощью текущей среды. Эта операция возвращает код ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) major_status, который можно использовать для определения того, является ли свидетельство в маркере полным (т. е. его можно проверить позже, даже через несколько лет). Если доказательство маркера неполное, маркер можно передать другому интерфейсу API, form_complete_pidu для его дополнения. Это происходит при возврате статуса «условно действительно» (conditionally valid). Это соответствует статусу «незавершенная проверка» (validation incomplete), определенному в настоящем документе. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Form_complete_PIDU используется в основном, если маркер свидетельства не содержит все данные, необходимые для проверки, и предполагается, что некоторые данные, хранящиеся за пределами маркера, могут стать недоступными в интервале между созданием и проверкой маркера свидетельства, если они не хранятся в самом маркере. Операция Form_Complete_PIDU собирает недостающие сведения и включает их в маркер, что позволяет гарантировать возможность проверки в будущем. З.3 Интерфейсы безопасности CORBA, определенные OMG Интерфейсы невозможности отказа определены в документе CORBA Security, созданном Группой управления объектами (OMG). Эти интерфейсы описаны на языке IDL и являются необязательными. Обработка «маркеров», поддерживающих невозможность отказа, достигается за счет следующих интерфейсов: • set_NR_features определяет функции, применяемые к будущим операциям создания и проверки свидетельства; • get_NR_features возвращает функции, применяемые к будущим операциям создания и проверки свидетельства; • Generate_token создает маркер невозможности отказа с помощью текущих функций обеспечения невозможности отказа; • verify_evidence проверяет маркер свидетельства с помощью текущих функций обеспечения невозможности отказа; • get_tokens_details возвращает сведения о входном маркере невозможности отказа. Возвращаемая информация зависит от типа маркера. • form_complete_evidence используется, если маркер свидетельства не содержит все данные, необходимые для проверки, и предполагается, что некоторые данные, хранящиеся за пределами маркера, могут стать недоступными в интервале между созданием и проверкой маркера свидетельства . Операция form_Complete_evidence собирает недостающие сведения и включает их в маркер, что позволяет гарантировать возможность проверки в будущем. ПРИМЕЧАНИЕ. Сходство двух наборов интерфейсов API очевидно. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение И (справочное). Криптографические алгоритмы Документ RFC 3370 [10] описывает соглашения по использованию нескольких криптографических алгоритмов с синтаксисом CMS. Только алгоритмы хэширования и подписи подходят для использования вместе с данным документом. После публикации документа RFC 3370 [10] алгоритм MD5 был взломан. Он больше не считается соответствующим требованиям и удален из списка алгоритмов. И.1 Алгоритмы хэширования 1.1.1 SHA-1 Алгоритм хэширования SHA-1 определен в документе FIPS Pub 180-2 [i.39]. Идентификатор алгоритма SHA-1: sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } Поле параметров AlgorithmIdentifier является необязательным. Если оно присутствует, то содержит значение ASN.1 NULL. Приложения должны принимать структуру AlgorithmIdentifiers как с отсутствующими параметрами, так и со значением NULL. Приложения должны создавать структуру SHA-1 AlgorithmIdentifiers с параметрами, имеющими значение NULL. 1.1.2 Общие сведения Далее представлены материалы, описывающие работу, проделанную в сфере алгоритмов хэширования или, как их еще называют, функций хэширования: • ИСО/МЭК 10118-1 (1994) [i.16] «Информационные технологии – безопасные методы – функции хэширования – часть 1. Общие понятия» (Information technology - Security techniques - Hash-functions - Part 1: General). Документ ИСО/МЭК 10118-1 [i.16] содержит определения и описывает базовые концепции. • ИСО/МЭК 10118-2 (1994) [i.17] «Информационные технологии – безопасные методы – функции хэширования – часть 2. Функции хэширования с использованием алгоритма с блоком в n бит» (Information technology - Security techniques - Hash-functions Part 2: Hash-functions using an n-bit block cipher algorithm). Документ ИСО/МЭК 10118-2 [i.17] определяет два способа формирования функции хэширования на основе блочного шифра. • ИСО/МЭК 10118-3 (1997) [i.18] «Информационные технологии – безопасные методы – функции хэширования – часть 3. Выделенные функции хэширования» (Information technology - Security techniques - Hashfunctions Part 3: Dedicated hash-functions). Документ ИСО/МЭК 10118-3 [i.18] определяет следующие выделенные функции хэширования: - SHA-1 (FIPS 180-1); - RIPEMD-128; - RIPEMD-160. • ИСО/МЭК 10118-4 (1998) [i.19] «Информационные технологии – безопасные методы – функции хэширования – часть 4. Функции хэширования с использованием арифметики в остаточных классах» (Information technology - Security techniques - Hash-functions - Part 4: Hash-functions using modular arithmetic). • Публикация FIPS 180-2 (2002) [i.39] «Безопасный стандарт хэширования SHS» (Secure Hash Standard SHS). В документе FIPS 180-2 описаны четыре алгоритма хэширования: SHA-1, SHA-256, SHA-384 и SHA-512. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Алгоритм SHA-1 был впервые опубликован в 1993 г., слегка изменен в 1995 г. и переименован в SHA-1 в документе FIPS 180-1. • ANSI X9.30-2 (1997) [i.20] «Шифрование с открытым ключом с использованием необратимых алгоритмов – часть 2. Алгоритм безопасного хэширования (SHA-1)» (Public Key Cryptography Using Irreversible Algorithms - Part 2: The Secure Hash Algorithm (SHA-1)). В документе X9.30-2 описывается ANSI-версия алгоритма SHA-1. • ANSI X9.31-2 (1996) [i.21] «Шифрование с открытым ключом с использованием обратимых алгоритмов для финансовой отрасли – часть 2. Алгоритмы хэширования» (Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry - Part 2: Hash Algorithms). В документе X9.31-2 [i.21] описываются алгоритмы хэширования. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) И.2 Алгоритмы цифровой подписи И.2.1 DSA Алгоритм подписи DSA определен в документе FIPS Pub 186. DSA всегда используется с алгоритмом хэширования сообщений SHA-1. Идентификатор алгоритма DSA: id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } Поле параметров AlgorithmIdentifier отсутствует. И.2.2 RSA Алгоритм подписи RSA определен в документе RFC 3447 [i.22]. Документ RFC 3370 [10] описывает использование алгоритма подписи RSA с алгоритмом хэширования SHA-1. Идентификатор алгоритма RSA с SHA-1: Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } ПРИМЕЧАНИЕ. приложениях. Документ RFC 3370 [10] не рекомендует использовать алгоритм MD5 в новых И.2.3 Общие сведения Далее представлены материалы, описывающие работу, проделанную в сфере механизмов цифровой подписи. • Публикация FIPS 186-2 (2000) Digital Signature Standard (DSS). Алгоритм цифровой подписи (DSA) Национального института стандартов и технологий (NIST) – это вариант механизма цифровой подписи ElGamal, основанного на дискретном логарифме. Для алгоритма DSA требуется 160-битная функция хэширования и обязательное использование алгоритма SHA-1. • IEEE 1363 [i.23] (2000) Standard Specifications For Public Key Cryptography. Документ IEEE 1363 [i.23] описывает механизмы цифровых подписей, ввода ключей в действие и шифрования на основе трех семейств схем открытых ключей: - «традиционные» методы на основе дискретных логарифмов (DL), т. е. алгоритм Диффи-Хеллмана (DH), алгоритм Менезеса-Кью-Вэнстоуна (MQV), алгоритм цифровой подписи (DSA) и цифровые подписи Нюберга-Рюппеля (NR); - варианты DL-механизмов, описанных выше, на основе эллиптической кривой (EC), т. е. EC-DH, ECMQV, ECDSA и EC-NR. К вариантам реализации с эллиптическими кривыми относятся варианты с вычислением модуля простого числа (mod p) и характеристикой 2 с полиномным или нормальным базисным представлением; - методы на основе целочисленной факторизации (IF), в том числе шифрование RSA, цифровые подписи RSA и передача ключей на основе RSA. • ИСО/МЭК 9796 [i.24] Information technology - Security techniques - Digital signature schemes giving message recovery. Документ ИСО/МЭК 9796 [i.24] описывает механизм цифровой подписи, основанный на методе открытых ключей RSA и специально созданной функции избыточности. • ИСО/МЭК 9796-2 [i.25] Information technology - Security techniques - Digital signature schemes giving message recovery - Part 2: Integer factorization based mechanisms. Документ ИСО/МЭК 9796-2 [i.25] описывает механизмы цифровой подписи с частичным восстановлением сообщения, которые также основаны на алгоритме RSA, но используют функцию хэширования. • ИСО/МЭК 9796-3 [i.26] Digital signature schemes giving message recovery - Part 4: Discrete logarithm based mechanisms. Документ ИСО/МЭК 9796-3 [i.26] описывает механизмы цифровой подписи с частичным восстановлением сообщения, которые основаны на использовании дискретных логарифмов. Данный документ содержит схему Нюберга-Рюппеля. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) • ИСО/МЭК 14888-1 [i.27] (1998) Information technology - Security techniques - Digital signatures with appendix Part 1: General. Документ ИСО/МЭК 14888-1 [i.27] содержит определения и описывает базовые концепции цифровых подписей с дополнениями. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) ИСО/МЭК 14888-2 [i.28] (1999) Information technology - Security techniques - Digital signatures with appendix - Part 2: Identity-based mechanisms. Документ ИСО/МЭК 14888-2 [i.28] описывает схемы цифровых подписей с дополнениями, которые используют ключевой материал на основе удостоверений. Данный документ также содержит описание методов с нулевым разглашением Фиата-Шамира и Гиллу-Кискатра. • ИСО/МЭК 14888-3 [i.29] (1998) Information technology - Security techniques - Digital signatures with appendix Part 3: Certificate-based mechanisms. Документ ИСО/МЭК 14888-3 [i.29] описывает схемы цифровых подписей с дополнениями, которые используют ключевой материал на основе сертификатов. Данный документ содержит пять схем: - DSA; - ECDSA, аналог алгоритма DSA NIST на основе эллиптических кривых; - подписи Пойнтчевалу-Воденэ; - подписи RSA; - ESIGN. • ИСО/МЭК 15946-2 [i.37] (2002) Information technology - Security techniques – Cryptographic techniques based on elliptic curves - Part 2: Digital signatures. • Документ ИСО/МЭК 11770-3 [i.30] (2002) описывает схемы цифровых подписей с дополнениями, используя эллиптические кривые. Данный документ содержит две схемы: - ECDSA, аналог алгоритма DSA NIST на основе эллиптических кривых; - EC-AMV, аналог алгоритма Эгнью-Мюллера-Вэнстоуна на основе эллиптических кривых. • ANSI X9.TR 31 [i.40] (2005) Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms, Includes Supplement (2009). Документ ANSI X9.31-1 [i.41] описывает механизм цифровых подписей с дополнениями, используя открытый ключ RSA. • ANSI X9.30.1 [i.31] (1997) Public Key Cryptography Using Irreversible Algorithms - Part 1: The RSA Digital Signature Algorithm. Документ ANSI X9.30.1 [i.31] описывает алгоритм цифровой подписи NIST (DSA). • ANSI X9.62 [i.32] (2005) Public Key Cryptography for the Financial Services Industry for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA). Документ ANSI X9.62 [i.32] описывает алгоритм цифровой подписи в форме эллиптической кривой, аналог алгоритма цифровой подписи NIST (DSA), использующего эллиптические кривые. В приложениях приводится математическое обоснование криптографических механизмов с использованием эллиптических кривых, а также множество примеров. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение Й (справочное). Рекомендации по именованию Й.1 Выделение имен Имя субъекта выделяется с использованием схемы регистрации, которой управляет центр регистрации (RA), для обеспечения уникальности имени. Этот центр регистрации может быть независимым органом или его функции может выполнять центр сертификации. Помимо обеспечения уникальности имени центр регистрации проверяет, правильно ли выделенное имя идентифицирует подателя заявки и проводятся ли проверка подлинности для предотвращения подделки. Имя, выделенное центром регистрации, основано на регистрационных данных, предоставленных заявителем или связанных с ним (таких как имя, дата рождения, адрес проживания), а также информации, предоставленной центром регистрации. Обычно используются три варианта: • имя основано только на регистрационных данных, которые уникально идентифицируют заявителя (например, «Сергей Иванов, дата рождения: 6 июля 1956 г.»); • имя основано на регистрационных данных и квалификаторах, добавленных центром регистрации для обеспечения уникальности («Сергей Иванов 12»); • регистрационные данные хранятся центром регистрации конфиденциально, при этом центр регистрации выделяет «псевдоним». Й.2 Предоставление доступа к сведениям о регистрации В определенных обстоятельствах может потребоваться, чтобы информация, использованная во время регистрация, но не опубликованная в сертификате, была доступна третьим лицам (например, арбитру для разрешения конфликта или правоохранительным органам). Такие регистрационные данные, скорее всего, содержат личные и конфиденциальные данные. Таким образом центр регистрации должен установить политику, определяющую следующие условия: • следует ли предоставлять доступ к регистрационным данным; • кому следует предоставлять доступ к регистрационным данным; • в каких случаях следует предоставлять доступ к регистрационным данным. Эта политика может отличаться в зависимости от того, используется ли центр регистрации только внутри компании или публично. Политика должна учитывать национальное законодательство и любые законы, связанные с защитой данных и конфиденциальности. На данный момент предоставление доступа к регистрационным данным является локальной задачей центра регистрации. Но при необходимости открытого доступа можно использовать стандартные протоколы, такие как HTTP, как определено в документе RFC 2616 [i.33] (протокол доступа через Интернет), с дополнительными механизмами безопасности, необходимыми для выполнения требований по защите данных (например, протокол TLS, описанный в документе RFC 4346 [i.34]), с проверкой подлинности клиента. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Й.3 Схемы именования Й.3.1 Схемы именования для отдельных граждан В некоторых случаях имя субъекта, которое содержится в сертификате открытого ключа, может быть недостаточно однозначным. Это может произойти из-за существования омонимов или использования псевдонимов. Отличить имена можно при наличии дополнительных атрибутов. Однако добавление дополнительных атрибутов в сертификат открытого ключа, размещенного в открытом репозитории, противоречит требованиям по защите конфиденциальности. В любом случае центр регистрации получит информацию в ходе регистрации, но не все данные будут размещены в сертификате. Для достижения баланса этих двух противоречивых требований в сертификате открытого ключа можно разместить хэш-значения некоторых дополнительных атрибутов. Когда владелец сертификата предоставит эти атрибуты, их можно будет проверить. Использование биометрических атрибутов позволяет однозначно идентифицировать человека. Примеры биометрических атрибутов, которые можно использовать: фотография или собственноручная подпись владельца сертификата. ПРИМЕЧАНИЕ. Использование хэш-значений защищает конфиденциальность, только при достаточно большом размере возможных входных данных. Например, применение хэш-значения номера социального страхования человека, как правило, недостаточно, так как из него можно легко восстановить исходное значение. Фотографию можно использовать, если проверяющая сторона встречалась с человеком лично и хочет убедиться, что полученный сертификат связан с этим человеком. В таком случае при первом обмене данными отправляется фотография, а проверяющая сторона может использовать хэш-значение в сертификате, чтобы проверить, тот ли этот человек. При следующем обмене данными фотографию отправлять не требуется. Собственноручную подпись можно использовать, если до этого был получен подписанный документ. В таком случае при первом обмене данными отправляется изображение собственноручной подписи, а проверяющая сторона может использовать хэш-значение в сертификате, чтобы проверить, совпадает ли ручная подпись с присланной. При следующем обмене данными отправлять ручную подпись не требуется. Й.3.2 Схемы именования для сотрудников организации Имя сотрудника организации, скорее всего, представляет собой сочетание названия организации и идентификатора сотрудника в этой организации. Название организации обычно является зарегистрированным именем, т. е. названием компании, используемым в деловых операциях. Это имя регистрируется центром именования, который гарантирует, что зарегистрированное название организации является однозначным и его нельзя спутать с названием другой организации. Для получения дополнительной информации о зарегистрированном имени организации необходимо вернуться в общедоступный каталог, поддерживаемый центром именования. Идентификатор может быть именем или псевдонимом (например, прозвищем или номером сотрудника). Если это имя, то предполагается, что оно достаточно информативное для однозначной идентификации человека. Если это псевдоним, сертификат не разглашает личность человека. Однако он обеспечивает правильную проверку подлинности человека во время регистрации, который может получить определенные права, явно или косвенно получаемые при владении сертификатом. В любом случае этого может быть недостаточно из-за существования омонимов. Одним из решений может быть размещение дополнительных атрибутов в сертификате, например, можно указать для организации название города, в котором она расположена. Однако чем больше информации в сертификате, тем больше проблем возникает при изменении структуры организации или места работы. Это может быть не самым лучшим решением. Альтернативный способ – указать дополнительные атрибуты (подразделение и место работы) с помощью доступа к каталогу, который поддерживается компанией. Вероятно, что во время регистрации центр регистрации получил больше информации, чем размещено в сертификате, если такая дополнительная информация хранится в репозитории, доступном только для организации. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение К (справочное). Вычисление хэш-значения штампа времени В таблицах К.1-К.3 описываются атрибуты, участвующие при вычислении хэш-значения со штампом времени, равные значению поля messageImprint структуры TimeStampToken для штампов времени, определенных в данном документе. Таблица К.1. Идентификация атрибутов, используемых для вычисления хэш-значения Тип штампа времени Идентификация id-aa-ets-contentTimestamp lid-aa-signatureTimeStampToken 1 lid-aa-ets-escTimeStamp 1 |id-aa-ets-certCRLTimestamp |id-aa-ets-archiveTimestamp D S C R A Элементы данных ASN.1, включенные в хэш-значение как значение объекта данных, определяются символом «"». Таблица К.2. Подпись CAdES ASN.1 ContentInfo ::= SEQUENCE { contentType ContentType, -- id-signedData content [0] EXPLICIT ANY DEFINED BY contentType } ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Таблица К.3. SignedData Тег ASN.1 1 2 3 4 5 6 7 SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmldentifiers, encapContentInfo SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL -- отсутствует, если подпись не прикреплена }, 8 –- внешние данные (если подпись не прикреплена) (см. примечание) A " " " Длина A " " " Значение A " " ", D A, D certificates [0] IMPLICIT CertificateSet OPTIONAL, A A A crls [1] IMPLICIT CertificateRevocationLists A A A signerInfos SET OF SEQUENCE { -- SignerInfo version CMSVersion, A A A sid SignerIdentifier, A A A digestAlgorithm DigestAlgorithmldentifier, A A A signedAttrs [0] IMPLICIT SET SIZE (1..MAX) OF A A A SEQUENCE { -- Attribute " " " attrType OBJECT IDENTIFIER, " " " " " " attrValues SET OF AttributeValue } OPTIONAL, signatureAlgorithm A A A 20 SignatureAlgorithmldentifier, signature OCTET STRING, -- SignatureValue A A S, C, A 21 unsignedAttrs [1] IMPLICIT SET SIZE (1..MAX) OF 22 A A SEQUENCE { A 23 -- if attrType is id-aa-signatureTimeStampToken C -- if attrType is id-aa-ets-certificateRefs C, R -- if attrType is id-aa-ets-revocationRefs C, R attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } OPTIONAL } } ПРИМЕЧАНИЕ 1. Внешние данные означают данные, защищенные отсоединенной подписью, которая не включена в поле eContent подписи CAdES. При вычислении хэш-значения contentTimestamp и archiveTimestamp также вычисляется хэш-значение на основе внешних данных. Алгоритмы, используемые в отсоединенной подписи, могут потерять стойкость в будущем, поэтому целостность внешних данных также нужно защитить с помощью archiveTimestamp. ПРИМЕЧАНИЕ 2. Существует небольшое отличие в обработке атрибутов content-timestamp и archivetimestamp, если подпись присоединена к данным. В этом случае content-timestamp вычисляется на основе необработанных данных (без тега и длины ASN.1), а archive-timestamp вычисляется для всех прочитанных данных. 9 10 11 12 13 14 15 16 17 18 19 ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение Л (справочное). Изменения по сравнению с предыдущей версией Л.1 Изменения до версии 1.7.4 В документ внесены следующие основные изменения: • название документа изменено в соответствии с названием XAdES; • словарь, использованный в настоящем документе, согласован со словарем, использованным в XAdES; • идентификаторы объектов из модулей ASN.1 изменены по следующим причинам: - включены идентификаторы объектов модулей ASN.1 из документов RFC 2560 [3] и RFC 3161 [7]; - так как документы RFC 5280 [i.35] и RFC 3369 [i.36] были заменены документами RFC 3280 [2] и RFC 3852 [4] соответственно, не было необходимости ссылаться на идентификаторы объектов модулей ASN.1 из документов RFC 3280 [2] и RFC 3852 [4] вместо идентификаторов объектов модулей ASN.1 из документов RFC 5280 [i.35] и RFC 3369 [i.36]; • если хэш-значение регламента подписи неизвестно, то, по договоренности, sigPolicyHash содержит все нули; • использование атрибута signing-certificate-v2 ESS добавлено для применения алгоритмов хэширования, отличных от SHA-1, в сертификатах хэширования вместо атрибута other-signing-certificate; • идентификатор объекта архивного штампа времени был изменен, чтобы избежать проблем с обратной совместимостью и упростить обработку; • различные редакторские правки для согласования со спецификацией RFC. Л.2 Изменение между версиями 1.7.4 и 1.8.1 В документ внесены следующие основные изменения: • подробно описано вычисление атрибута content-timestamp; • добавлена возможность добавления взаимозаменяемости алгоритмов хэширования в штампы времени; • предоставлены инструкции по использованию атрибутов complete-certificate-references со службой OCSP; • предоставлены инструкции по использованию атрибутов, определенных в данном документе с «чистым» CMS; • добавлено приложение, посвященное вычислению хэш-значений штампа времени; • исправлен пункт Б.3, чтобы сделать штампы времени необязательными для CAdES-A. Л.3 Изменения между версиями 1.8.1 и 1.8.3 • подробно описаны требования соответствия для подписей CAdES-BES; • исправление в приложении А.1: SignaturePolicy исправлено на SignaturePolicyIdentifier. ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) Приложение М (справочное). Список литературы • IETF RFC 2246 (1999) «Протокол TLS версии 1.0» (The TLS Protocol Version 1.0). • IETF RFC 3447 (2003) «PKCS №1: криптографические спецификации RSA версии 2.1» (PKCS #1: RSA Cryptography Specifications Version 2.1). • ETSI TS 102 023 «Электронные подписи и инфраструктуры (ESI); требования политики для служб штампов времени» (Electronic Signatures and Infrastructures (ESI); Policy requirements for time-stamping authorities). • Рекомендация XMLDSIG W3C/IETF (февраль 2002 г.): «Синтаксис и обработка подписей XML» (XMLSignature Syntax and Processing). • Рекомендация МСЭ-Т X.690 (2002) «Правила кодирования ASN.1 в информационных технологиях: спецификация базовых (BER), канонических (СER) и отличительных (DER) правил кодирования» (Information technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)). ETSI ETSI TS 101 733, версия 1.8.3 (2011-01) История документа История документа VI.1.3 Май 2000 г. Публикация как ES 201 733 VI.2.2 Декабрь 2000 г. Публикация VI.3.1 Февраль 2002 г. Публикация VI.4.0 Сентябрь 2002 г. Публикация VI.5.1 Декабрь 2003 г. VI.6.3 Сентябрь 2005 г. Публикация VI.7.3 Январь 2007 г. Публикация VI.7.4 Июль 2008 г. Публикация VI.8.1 Ноябрь 2009 г. Публикация VI.8.3 Январь 2011 г. Публикация Публикация ETSI