TS 102 176-1-2007 Электронные подписи и инфраструктура (ESI); Алгоритмы и параметры безопасной электронной подписи; Часть 1: Хэш-функции и асимметричные алгоритмы (V2.0.0)
«Настоящий документ предназначен для поддержки расширенных электронных подписей и соответствующей инфраструктуры. Настоящий документ определяет список хэш-функций и список схем подписей@, а также рекомендуемые комбинации хэш-функций и схем подписей в форме «» наборы подписей". Основными критериями включения алгоритма в настоящий документ являются: алгоритм считается безопасным; алгоритм широко используется; и на алгоритм можно легко ссылаться (например, посредством OID). Это не означает, что другие хеш-функции и наборы подписей не могут использоваться@, но либо они не соответствуют вышеуказанным критериям, либо их безопасность не была оценена.В документе также содержатся рекомендации по схемам подписей хэш-функций@ и наборам подписей, которые будут использоваться со структурами данных, используемыми в контексте электронных подписей. Для каждой структуры данных@ указан набор используемых алгоритмов. Каждый набор идентифицируется идентификатором, который представляет собой либо OID (идентификатор объекта), либо URI/URN. Использование таких идентификаторов необходимо для обеспечения совместимости. Чтобы обеспечить обмен данными@, в документе упоминаются алгоритмы в виде OID и URI/URN вместе с параметрами алгоритма. К эмитентам и пользователям структур данных применяются разные требования, чтобы обеспечить функциональную совместимость. В документах RFC используются термины ДОЛЖНО@ СЛЕДУЕТ@ МОЖЕТ@ РЕКОМЕНДУЕТСЯ для обеспечения совместимости. Та же терминология используется в настоящем документе (см. RFC 2119 [25]). Эмитенты структур данных (например, CSP @ CRL Issuers @ OCSP респонденты @ TSU) должны знать алгоритмы и размеры ключей, которые они ДОЛЖНЫ или МОГУТ поддерживать. ДОЛЖЕН быть хотя бы один алгоритм, рекомендуемый для поддержки @, но может быть и несколько. Пользователи структур данных (то есть лица, подписывающие или проверяющие электронные подписи) должны знать алгоритмы и размеры ключей, которые они ДОЛЖНЫ или МОГУТ поддерживать. Для пользователей и для каждой структуры данных@ должен существовать по крайней мере один поддерживаемый алгоритм@, но может быть и более одного. Эти требования перечислены в приложении А. В приложении Б представлена историческая информация о рекомендуемых алгоритмах хеш-функций и размерах ключей для генерации и проверки электронных подписей. Это приложение будет периодически обновляться. Приложение C предоставляет дополнительную информацию о создании модуля RSA. Приложение D содержит дополнительную информацию о создании параметров области эллиптических кривых. Приложение E посвящено генерации случайных данных. В приложении F перечислены идентификаторы алгоритмов, определенные в различных документах. В приложении G представлен краткий обзор стандартов ISO/IEC 10118-3 [3] и ISO/IEC 9796-2 [17]. Приложение H содержит некоторые рекомендации по поддержанию подписи. В Приложении I перечислены основные изменения по сравнению с предыдущими версиями. Настоящий документ определяет набор алгоритмов (т.е. хэш-функции, схемы подписи и наборы подписей) и соответствующие параметры, которые рекомендуется использовать. Если такие алгоритмы используются в соответствии с контекстом, в котором предполагается их использование, то можно предположить разумный уровень безопасности. Алгоритмы, определенные в настоящем документе, можно использовать, в частности, со следующими документами: TS 101 733 [18]: «Электронные подписи и инфраструктуры (ESI); Форматы электронной подписи""; TS 101 903 [19]: «Усовершенствованные электронные подписи XML (XAdES)»»; ПРИМЕЧАНИЕ. Язык XML определен в RFC 3275 [10]. TS 101 861 [20]: «Профиль временной метки»»; TS 101 456 [33]: «Электронные подписи и инфраструктуры (ESI); Требования политики к органам по сертификации, выдающим квалифицированные сертификаты""; TS 102 042 [34]: «Электронные подписи и инфраструктуры (ESI); Требования политики к органам сертификации, выдающим сертификаты открытых ключей""; CWA 14169 [35]: «Устройства создания безопасных подписей EAL 4+»»»»; CWA 14170 [36]: «Требования безопасности для приложений создания подписей»»; CWA 14171 [37]: ««Процедуры проверки электронной подписи»»; CWA 14167-1 [38]: «Требования безопасности для надежных систем управления сертификатами для электронных подписей – Часть 1: Требования безопасности системы»»; CWA 14167-2 [39]: «Требования безопасности для надежных систем управления сертификатами для электронных подписей. Часть 2. Криптографический модуль для операций подписи CSP с резервным копированием — профиль защиты»»; CWA 14167-3 [40]: «Требования безопасности для надежных систем управления сертификатами для электронных подписей. Часть 3. Криптографический модуль для служб генерации ключей CSP. Профиль защиты (CMCKG-PP)»»; CWA 14167-4 [41]: «Требования безопасности для надежных систем управления сертификатами для электронных подписей. Часть 4. Криптографический модуль для операций подписи CSP. Профиль защиты — CMCSO PP»»; RFC 3280 [2]: «Профиль сертификата инфраструктуры открытых ключей Интернета X.509 и списка отзыва сертификатов (CRL)»»; RFC 3281 [21]: «Профиль сертификата атрибутов Интернета для авторизации»»; RFC 3161 [9]: (2001): «Протокол временных меток инфраструктуры открытых ключей X.509 Интернета (TSP)»»; RFC 2560 [22]: «Протокол статуса онлайн-сертификата инфраструктуры открытых ключей Интернета X.509 — OCSP»». Вопросы, связанные с патентами, выходят за рамки настоящего документа».
TS 102 176-1-2007 История
2011TS 102 176-1-2011 Электронные подписи и инфраструктура (ESI); Алгоритмы и параметры безопасной электронной подписи; Часть 1: Хэш-функции и асимметричные алгоритмы (V2.1.1)
2007TS 102 176-1-2007 Электронные подписи и инфраструктура (ESI); Алгоритмы и параметры безопасной электронной подписи; Часть 1: Хэш-функции и асимметричные алгоритмы (V2.0.0)
2005TS 102 176-1-2005 Электронные подписи и инфраструктура (ESI); Алгоритмы и параметры безопасной электронной подписи; Часть 1: Хэш-функции и асимметричные алгоритмы (V1.2.1)