Электронные подписи и инфраструктуры (esi); усовершенствованные электронные подписи cms (CAdES)


NR policy that is referenced in the context.Все операции создания и проверки выполняются в соответствии с содержимым политики NR



бет16/17
Дата29.02.2016
өлшемі2.44 Mb.
#34652
1   ...   9   10   11   12   13   14   15   16   17
NR policy that is referenced in the context.<}0{>Все операции создания и проверки выполняются в соответствии с содержимым политики NR, указанной в контексте.<0}

{0>Get_token_details is used to return the attributes that correspond to a given input token to an application.<}0{>Get_token_details используется для возврата в приложение атрибутов, соответствующих заданному входному маркеру.<0} {0>Since IDUP-GSS-API tokens are meant to be opaque to the calling application, this function allows the application to determine information about the token without having to violate the opaqueness intention of IDUP.<}0{>Так как маркеры IDUP-GSS-API должны быть непрозрачными для вызывающего приложения, эта функция позволяет приложению получить сведения о маркере без нарушения непрозрачности IDUP.<0} {0>Of primary importance is the mechanism type, which the application can then use as input to the IDUP_Establish_Env() call in order to establish the correct environment in which to have the token processed.<}0{>Очень большое значение имеет тип механизма, который приложение может использовать как входные данные для вызова функции IDUP_Establish_Env() для определения правильной среды, в которой необходимо обработать маркер.<0}

{0>Generate_token generates a non-repudiation token using the current environment.<}0{>Функция Generate_token создает маркер невозможности отказа с использованием текущей среды.<0}

{0>Verify_evidence verifies the evidence token using the current environment.<}0{>Функция Verify_evidence проверяет маркер свидетельства с помощью текущей среды.<0} {0>This operation returns a major_status code that can be used to determine whether the evidence contained in a token is complete (i.e. can be successfully verified (perhaps years) later).<}0{>Эта операция возвращает код major_status, который можно использовать для определения того, является ли свидетельство в маркере полным (т. е. его можно проверить позже, даже через несколько лет).<0} {0>If a token's evidence is not complete, the token can be passed to another API, form_complete_pidu, to complete it.<}0{>Если доказательство маркера неполное, маркер можно передать другому интерфейсу API, form_complete_pidu для его дополнения.<0} {0>This happens when a status "conditionally valid" is returned.<}0{>Это происходит при возврате статуса «условно действительно» (conditionally valid).<0} {0>That status corresponds to the status "validation incomplete" of the present document.<}0{>Это соответствует статусу «незавершенная проверка» (validation incomplete), определенному в настоящем документе.<0}

{0>Form_complete_PIDU is used primarily when the evidence token itself does not contain all the data required for its verification, and it is anticipated that some of the data not stored in the token may become unavailable during the interval between generation of the evidence token and verification unless it is stored in the token.<}0{>Form_complete_PIDU используется в основном, если маркер свидетельства не содержит все данные, необходимые для проверки, и предполагается, что некоторые данные, хранящиеся за пределами маркера, могут стать недоступными в интервале между созданием и проверкой маркера свидетельства, если они не хранятся в самом маркере.<0} {0>The Form_Complete_PIDU operation gathers the missing information and includes it in the token so that verification can be guaranteed to be possible at any future time.<}0{>Операция Form_Complete_PIDU собирает недостающие сведения и включает их в маркер, что позволяет гарантировать возможность проверки в будущем.<0}
{0>H.3<}100{>З.3<0} {0>CORBA Security Interfaces Defined by the OMG<}100{>Интерфейсы безопасности CORBA, определенные OMG<0}

{0>Non-repudiation interfaces have been defined in "CORBA Security", a document produced by the OMG (Object Management Group).<}0{>Интерфейсы невозможности отказа определены в документе CORBA Security, созданном Группой управления объектами (OMG).<0} {0>These interfaces are described in IDL (Interface Definition Language) and are optional.<}0{>Эти интерфейсы описаны на языке IDL и являются необязательными.<0}

{0>The handling of "tokens" supporting non-repudiation is done through the following interfaces:<}0{>Обработка «маркеров», поддерживающих невозможность отказа, достигается за счет следующих интерфейсов:<0}

  • {0>set_NR_features specifies the features to apply to future evidence generation and verification operations;<}0{>set_NR_features определяет функции, применяемые к будущим операциям создания и проверки свидетельства;<0}

  • {0>get_NR_features returns the features that will be applied to future evidence generation and verification operations;<}72{>get_NR_features возвращает функции, применяемые к будущим операциям создания и проверки свидетельства;<0}

  • {0>generate_token generates a non-repudiation token using the current non-repudiation features;<}75{>Generate_token создает маркер невозможности отказа с помощью текущих функций обеспечения невозможности отказа;<0}

  • {0>verify_evidence verifies the evidence token using the current non-repudiation features;<}70{>verify_evidence проверяет маркер свидетельства с помощью текущих функций обеспечения невозможности отказа;<0}

  • {0>get_tokens_details returns information about an input non-repudiation token.<}0{>get_tokens_details возвращает сведения о входном маркере невозможности отказа.<0} {0>The information returned depends upon the type of token;<}0{>Возвращаемая информация зависит от типа маркера.<0}

  • {0>form_complete_evidence is used when the evidence token itself does not contain all the data required for its verification, and it is anticipated that some of the data not stored in the token may become unavailable during the interval between generation of the evidence token and verification unless it is stored in the token.<}97{>form_complete_evidence используется, если маркер свидетельства не содержит все данные, необходимые для проверки, и предполагается, что некоторые данные, хранящиеся за пределами маркера, могут стать недоступными в интервале между созданием и проверкой маркера свидетельства .<0} {0>The form_complete_evidence operation gathers the missing information and includes it in the token so that verification can be guaranteed to be possible at any future time.<}99{>Операция form_Complete_evidence собирает недостающие сведения и включает их в маркер, что позволяет гарантировать возможность проверки в будущем.<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>The similarity between the two sets of APIs is noticeable.<}0{>Сходство двух наборов интерфейсов API очевидно.<0}
{0>Annex I (informative):<}100{>Приложение И (справочное).<0} {0>Cryptographic Algorithms<}100{>Криптографические алгоритмы<0}

{0>RFC 3370 [10] describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS).<}0{>Документ RFC 3370 [10] описывает соглашения по использованию нескольких криптографических алгоритмов с синтаксисом CMS.<0} {0>Only the hashing and signing algorithms are appropriate for use with the present document.<}0{>Только алгоритмы хэширования и подписи подходят для использования вместе с данным документом.<0}

{0>Since the publication of RFC 3370 [10], MD5 has been broken.<}0{>После публикации документа RFC 3370 [10] алгоритм MD5 был взломан.<0} {0>This algorithm is no longer considered appropriate and has been deleted from the list of algorithms.<}0{>Он больше не считается соответствующим требованиям и удален из списка алгоритмов.<0}
{0>I.1<}0{>И.1<0} {0>Digest Algorithms<}100{>Алгоритмы хэширования<0}

1.1.1 {0>SHA-1<}100{>SHA-1<0}



{0>The SHA-1 digest algorithm is defined in FIPS Pub 180-2 [i.39].<}0{>Алгоритм хэширования SHA-1 определен в документе FIPS Pub 180-2 [i.39].<0} {0>The algorithm identifier for SHA-1 is:<}63{>Идентификатор алгоритма SHA-1:<0}

sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }



{0>The AlgorithmIdentifier parameters field is optional.<}0{>Поле параметров AlgorithmIdentifier является необязательным.<0} {0>If present, the parameters field contains an ASN.1 NULL.<}0{>Если оно присутствует, то содержит значение ASN.1 NULL.<0} {0>Implementations should accept SHA-1 AlgorithmIdentifiers with absent parameters as well as NULL parameters.<}65{>Приложения должны принимать структуру AlgorithmIdentifiers как с отсутствующими параметрами, так и со значением NULL.<0} {0>Implementations should generate SHA-1 AlgorithmIdentifiers with NULL parameters.<}0{>Приложения должны создавать структуру SHA-1 AlgorithmIdentifiers с параметрами, имеющими значение NULL.<0}

1.1.2 {0>General<}100{>Общие сведения<0}



{0>The following is a selection of work that has been done in the area of digest algorithms or, as they are often called, hash functions:<}0{>Далее представлены материалы, описывающие работу, проделанную в сфере алгоритмов хэширования или, как их еще называют, функций хэширования:<0}

  • {0>ISO/IEC 10118-1 (1994) [i.16]:<}0{>ИСО/МЭК 10118-1 (1994) [i.16]<0} {0>"Information technology - Security techniques - Hash-functions -Part 1:<}100{>«Информационные технологии – безопасные методы – функции хэширования – часть 1. Общие понятия» (Information technology - Security techniques - Hash-functions - Part 1:<0} {0>General".<}100{>General).<0} {0>ISO/IEC 10118-1 [i.16] contains definitions and describes basic concepts.<}0{>Документ ИСО/МЭК 10118-1 [i.16] содержит определения и описывает базовые концепции.<0}

  • {0>ISO/IEC 10118-2 (1994) [i.17]:<}0{>ИСО/МЭК 10118-2 (1994) [i.17]<0} {0>"Information technology - Security techniques - Hash-functions -<}80{>«Информационные технологии – безопасные методы – функции хэширования – часть 2. Функции хэширования с использованием алгоритма с блоком в n бит» (Information technology - Security techniques - Hash-functions -<0}

{0>Part 2:<}0{>Part 2:<0} {0>Hash-functions using an n-bit block cipher algorithm".<}94{>Hash-functions using an n-bit block cipher algorithm).<0} {0>ISO/IEC 10118-2 [i.17] specifies two ways to construct a hash-function from a block cipher.<}0{>Документ ИСО/МЭК 10118-2 [i.17] определяет два способа формирования функции хэширования на основе блочного шифра.<0}

{0>ISO/IEC 10118-3 (1997) [i.18]:<}0{>ИСО/МЭК 10118-3 (1997) [i.18]<0} {0>"Information technology - Security techniques - Hash-functions -<}100{>«Информационные технологии – безопасные методы – функции хэширования – часть 3. Выделенные функции хэширования» (Information technology - Security techniques - Hash-functions -<0}



{0>Part 3:<}100{>Part 3:<0} {0>Dedicated hash-functions".<}100{>Dedicated hash-functions).<0} {0>ISO/IEC 10118-3 [i.18] specifies the following dedicated hash-functions:<}0{>Документ ИСО/МЭК 10118-3 [i.18] определяет следующие выделенные функции хэширования:<0}

  • {0>SHA-1 (FIPS 180-1);<}0{>SHA-1 (FIPS 180-1);<0}

  • {0>RIPEMD-128;<}0{>RIPEMD-128;<0}

  • {0>RIPEMD-160.<}0{>RIPEMD-160.<0}




  • {0>ISO/IEC 10118-4 (1998) [i.19]:<}0{>ИСО/МЭК 10118-4 (1998) [i.19]<0} {0>"Information technology - Security techniques - Hash-functions -Part 4:<}100{>«Информационные технологии – безопасные методы – функции хэширования – часть 4. Функции хэширования с использованием арифметики в остаточных классах» (Information technology - Security techniques - Hash-functions - Part 4:<0} {0>Hash-functions using modular arithmetic".<}100{>Hash-functions using modular arithmetic).<0}

  • {0>FIPS Publication 180-2 (2002) [i.39]:<}0{>Публикация FIPS 180-2 (2002) [i.39]<0} {0>"Secure Hash Standard SHS".<}92{>«Безопасный стандарт хэширования SHS» (Secure Hash Standard SHS).<0} {0>FIPS 180-2 four secure hash algorithms -SHA-1, SHA-256, SHA-384, and SHA-512. The SHA-1 algorithm was first published in 1993, was slightly revised in 1995 and renamed SHA-1 in FIPS 180-1.<}100{>В документе FIPS 180-2 описаны четыре алгоритма хэширования: SHA-1, SHA-256, SHA-384 и SHA-512. Алгоритм SHA-1 был впервые опубликован в 1993 г., слегка изменен в 1995 г. и переименован в SHA-1 в документе FIPS 180-1.<0}

  • {0>ANSI X9.30-2 (1997) [i.20]:<}0{>ANSI X9.30-2 (1997) [i.20]<0} {0>"Public Key Cryptography Using Irreversible Algorithms - Part 2:<}100{>«Шифрование с открытым ключом с использованием необратимых алгоритмов – часть 2. Алгоритм безопасного хэширования (SHA-1)» (Public Key Cryptography Using Irreversible Algorithms - Part 2:<0} {0>The Secure Hash Algorithm (SHA-1)".<}100{>The Secure Hash Algorithm (SHA-1)).<0} {0>X9.30-2 specifies the ANSI-Version of SHA-1.<}0{>В документе X9.30-2 описывается ANSI-версия алгоритма SHA-1.<0}

  • {0>ANSI X9.31-2 (1996) [i.21]:<}0{>ANSI X9.31-2 (1996) [i.21]<0} {0>"Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry - Part 2:<}100{>«Шифрование с открытым ключом с использованием обратимых алгоритмов для финансовой отрасли – часть 2. Алгоритмы хэширования» (Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry - Part 2:<0} {0>Hash Algorithms".<}100{>Hash Algorithms).<0} {0>X9.31-2 [i.21] specifies hash algorithms.<}0{>В документе X9.31-2 [i.21] описываются алгоритмы хэширования.<0}


{0>I.2<}0{>И.2<0} {0>Digital Signature Algorithms<}100{>Алгоритмы цифровой подписи<0}

И.2.1 {0>DSA<}100{>DSA<0}



{0>The DSA signature algorithm is defined in FIPS Pub 186. DSA is always used with the SHA-1 message digest algorithm.<}0{>Алгоритм подписи DSA определен в документе FIPS Pub 186. DSA всегда используется с алгоритмом хэширования сообщений SHA-1.<0} {0>The algorithm identifier for DSA is:<}72{>Идентификатор алгоритма DSA:<0}

id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 }



{0>The AlgorithmIdentifier parameters field is not present.<}76{>Поле параметров AlgorithmIdentifier отсутствует.<0}

И.2.2 {0>RSA<}100{>RSA<0}



{0>The RSA signature algorithm is defined in RFC 3447 [i.22].<}0{>Алгоритм подписи RSA определен в документе RFC 3447 [i.22].<0} {0>RFC 3370 [10] specifies the use of the RSA signature algorithm with the SHA-1 algorithm.<}0{>Документ RFC 3370 [10] описывает использование алгоритма подписи RSA с алгоритмом хэширования SHA-1.<0} {0>The algorithm identifier for RSA with SHA-1 is:<}82{>Идентификатор алгоритма RSA с SHA-1:<0}

Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }



{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>RFC 3370 [10] recommends that MD5 not be used for new implementations.<}0{>Документ RFC 3370 [10] не рекомендует использовать алгоритм MD5 в новых приложениях.<0}

И.2.3 {0>General<}100{>Общие сведения<0}



{0>The following is a selection of work that has been done in the area of digital signature mechanisms:<}0{>Далее представлены материалы, описывающие работу, проделанную в сфере механизмов цифровой подписи.<0}

  • {0>FIPS Publication 186-2 (2000):<}78{>Публикация FIPS 186-2 (2000)<0} {0>"Digital Signature Standard (DSS)".<}73{>Digital Signature Standard (DSS).<0} {0>NIST's Digital Signature Algorithm (DSA) is a variant of ElGamal Discrete Logarithm-based digital signature mechanism.<}0{>Алгоритм цифровой подписи (DSA) Национального института стандартов и технологий (NIST) – это вариант механизма цифровой подписи ElGamal, основанного на дискретном логарифме.<0} {0>The DSA requires a 160-bit hash-function and mandates SHA-1.<}0{>Для алгоритма DSA требуется 160-битная функция хэширования и обязательное использование алгоритма SHA-1.<0}

  • {0>IEEE 1363 [i.23] (2000):<}0{>IEEE 1363 [i.23] (2000)<0} {0>"Standard Specifications for Public-Key Cryptography".<}95{>Standard Specifications For Public Key Cryptography.<0} {0>IEEE 1363 [i.23] contains mechanisms for digital signatures, key establishment, and encipherment based on three families of public key schemes:<}0{>Документ IEEE 1363 [i.23] описывает механизмы цифровых подписей, ввода ключей в действие и шифрования на основе трех семейств схем открытых ключей:<0}




  • {0>"Conventional" Discrete Logarithm (DL)-based techniques, i.e. Diffie-Hellman (DH) key agreement, Menezes-Qu-Vanstone (MQV) key agreement, the Digital Signature Algorithm (DSA), and Nyberg-Rueppel (NR) digital signatures;<}0{>«традиционные» методы на основе дискретных логарифмов (DL), т. е. алгоритм Диффи-Хеллмана (DH), алгоритм Менезеса-Кью-Вэнстоуна (MQV), алгоритм цифровой подписи (DSA) и цифровые подписи Нюберга-Рюппеля (NR);<0}

  • {0>Elliptic Curve (EC)-based variants of the DL-mechanisms specified above, i.e. EC-DH, EC-MQV, ECDSA, and EC-NR.<}0{>варианты DL-механизмов, описанных выше, на основе эллиптической кривой (EC), т. е. EC-DH, EC-MQV, ECDSA и EC-NR.<0} {0>For elliptic curves, implementation options include mod p and characteristic 2 with polynomial or normal basis representation;<}0{>К вариантам реализации с эллиптическими кривыми относятся варианты с вычислением модуля простого числа (mod p) и характеристикой 2 с полиномным или нормальным базисным представлением;<0}

  • {0>Integer Factoring (IF)-based techniques, including RSA encryption, RSA digital signatures, and RSA-based key transport.<}0{>методы на основе целочисленной факторизации (IF), в том числе шифрование RSA, цифровые подписи RSA и передача ключей на основе RSA.<0}




  • {0>ISO/IEC 9796 [i.24]:<}0{>ИСО/МЭК 9796 [i.24]<0} {0>"Information technology - Security techniques - Digital signature scheme giving message recovery".<}98{>Information technology - Security techniques - Digital signature schemes giving message recovery.<0} {0>ISO/IEC 9796 [i.24] specifies a digital signature mechanism based on the RSA public-key technique and a specifically designed redundancy function.<}0{>Документ ИСО/МЭК 9796 [i.24] описывает механизм цифровой подписи, основанный на методе открытых ключей RSA и специально созданной функции избыточности.<0}

  • {0>ISO/IEC 9796-2 [i.25]:<}0{>ИСО/МЭК 9796-2 [i.25]<0} {0>"Information technology - Security techniques - Digital signature schemes giving message recovery - Part 2:<}100{>Information technology - Security techniques - Digital signature schemes giving message recovery - Part 2:<0} {0>Integer factorization based mechanisms".<}100{>Integer factorization based mechanisms.<0} {0>ISO/IEC 9796-2 [i.25] specifies digital signature mechanisms with partial message recovery that are also based on the RSA technique but make use of a hash-function.<}0{>Документ ИСО/МЭК 9796-2 [i.25] описывает механизмы цифровой подписи с частичным восстановлением сообщения, которые также основаны на алгоритме RSA, но используют функцию хэширования.<0}

  • {0>ISO/IEC 9796-3 [i.26]:<}91{>ИСО/МЭК 9796-3 [i.26]<0} {0>"Digital signature schemes giving message recovery - Part 4:<}62{>Digital signature schemes giving message recovery - Part 4:<0} {0>Discrete logarithm based mechanisms".<}100{>Discrete logarithm based mechanisms.<0} {0>ISO/IEC 9796-3 [i.26] specifies digital signature mechanisms with partial message recovery that are based on Discrete Logarithm techniques.<}0{>Документ ИСО/МЭК 9796-3 [i.26] описывает механизмы цифровой подписи с частичным восстановлением сообщения, которые основаны на использовании дискретных логарифмов.<0} {0>The document includes the Nyberg-Rueppel scheme.<}0{>Данный документ содержит схему Нюберга-Рюппеля.<0}

  • {0>ISO/IEC 14888-1 [i.27] (1998):<}0{>ИСО/МЭК 14888-1 [i.27] (1998)<0} {0>"Information technology - Security techniques - Digital signatures with appendix - Part 1:<}100{>Information technology - Security techniques - Digital signatures with appendix - Part 1:<0} {0>General".<}100{>General.<0} {0>ISO/IEC 14888-1 [i.27] contains definitions and describes the basic concepts of digital signatures with appendix.<}65{>Документ ИСО/МЭК 14888-1 [i.27] содержит определения и описывает базовые концепции цифровых подписей с дополнениями.<0}

{0>ISO/IEC 14888-2 [i.28] (1999):<}91{>ИСО/МЭК 14888-2 [i.28] (1999)<0} {0>"Information technology - Security techniques - Digital signatures with appendix - Part 2:<}100{>Information technology - Security techniques - Digital signatures with appendix - Part 2:<0} {0>Identity-based mechanisms ".<}67{>Identity-based mechanisms.<0} {0>ISO/IEC 14888-2 [i.28] specifies digital signature schemes with appendix that make use of identity-based keying material.<}0{>Документ ИСО/МЭК 14888-2 [i.28] описывает схемы цифровых подписей с дополнениями, которые используют ключевой материал на основе удостоверений.<0} {0>The document includes the zero-knowledge techniques of Fiat-Shamir and Guillou-Quisquater.<}0{>Данный документ также содержит описание методов с нулевым разглашением Фиата-Шамира и Гиллу-Кискатра.<0}

  • {0>ISO/IEC 14888-3 [i.29] (1998):<}94{>ИСО/МЭК 14888-3 [i.29] (1998)<0} {0>"Information technology - Security techniques - Digital signatures with appendix - Part 3:<}100{>Information technology - Security techniques - Digital signatures with appendix - Part 3:<0} {0>Certificate-based mechanisms".<}84{>Certificate-based mechanisms.<0} {0>ISO/IEC 14888-3 [i.29] specifies digital signature schemes with appendix that make use of certificate-based keying material.<}93{>Документ ИСО/МЭК 14888-3 [i.29] описывает схемы цифровых подписей с дополнениями, которые используют ключевой материал на основе сертификатов.<0} {0>The document includes five schemes:<}0{>Данный документ содержит пять схем:<0}




  • {0>DSA;<}0{>DSA;<0}

  • {0>ECDSA, an elliptic curve-based analog of NIST's Digital Signature Algorithm;<}0{>ECDSA, аналог алгоритма DSA NIST на основе эллиптических кривых;<0}

  • {0>Pointcheval-Vaudeney signatures;<}0{>подписи Пойнтчевалу-Воденэ;<0}

  • {0>RSA signatures;<}67{>подписи RSA;<0}

  • {0>ESIGN.<}0{>ESIGN.<0}




  • {0>ISO/IEC 15946-2 [i.37] (2002):<}88{>ИСО/МЭК 15946-2 [i.37] (2002)<0} {0>"Information technology - Security techniques - Cryptographic techniques based on elliptic curves - Part 2:<}99{>Information technology - Security techniques – Cryptographic techniques based on elliptic curves - Part 2:<0} {0>Digital signatures".<}100{>Digital signatures.<0}

  • {0>ISO/IEC 11770-3 [i.30] (2002) specifies digital signature schemes with appendix using elliptic curves.<}0{>Документ ИСО/МЭК 11770-3 [i.30] (2002) описывает схемы цифровых подписей с дополнениями, используя эллиптические кривые.<0} {0>The document includes two schemes:<}84{>Данный документ содержит две схемы:<0}




  • {0>ECDSA, an elliptic curve-based analog of NIST's Digital Signature Algorithm;<}100{>ECDSA, аналог алгоритма DSA NIST на основе эллиптических кривых;<0}

  • {0>EC-AMV. an elliptic curve-based analog of the Agnew-Muller-Vanstone signature algorithm.<}0{>EC-AMV, аналог алгоритма Эгнью-Мюллера-Вэнстоуна на основе эллиптических кривых.<0}




  • {0>ANSI X9.TR 31 [i.40] (2005):<}0{>ANSI X9.TR 31 [i.40] (2005)<0} {0>"Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms, Includes Supplement (2009)".<}100{>Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms, Includes Supplement (2009).<0} {0>ANSI X9.31-1 [i.41] specifies a digital signature mechanism with appendix using the RSA public key technique.<}0{>Документ ANSI X9.31-1 [i.41] описывает механизм цифровых подписей с дополнениями, используя открытый ключ RSA.<0}

  • {0>ANSI X9.30.1 [i.31] (1997):<}0{>ANSI X9.30.1 [i.31] (1997)<0} {0>"Public Key Cryptography Using Irreversible Algorithms - Part 1:<}100{>Public Key Cryptography Using Irreversible Algorithms - Part 1:<0} {0>The RSA Digital Signature Algorithm".<}0{>The RSA Digital Signature Algorithm.<0} {0>ANSI X9.30.1 [i.31] specifies the DSA, NIST's Digital Signature Algorithm.<}0{>Документ ANSI X9.30.1 [i.31] описывает алгоритм цифровой подписи NIST (DSA).<0}

  • {0>ANSI X9.62 [i.32] (2005):<}0{>ANSI X9.62 [i.32] (2005)<0} {0>"Public Key Cryptography for the Financial Services Industry for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA)".<}0{>Public Key Cryptography for the Financial Services Industry for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA).<0}

{0>ANSI X9.62 [i.32] specifies the Elliptic Curve Digital Signature Algorithm, an analog of NIST's Digital Signature Algorithm (DSA) using elliptic curves.<}0{>Документ ANSI X9.62 [i.32] описывает алгоритм цифровой подписи в форме эллиптической кривой, аналог алгоритма цифровой подписи NIST (DSA), использующего эллиптические кривые.<0} {0>The appendices provide tutorial information on the underlying mathematics for elliptic curve cryptography and many examples.<}0{>В приложениях приводится математическое обоснование криптографических механизмов с использованием эллиптических кривых, а также множество примеров.<0}
{0>Annex J (informative):<}100{>Приложение Й (справочное).<0} {0>Guidance on Naming<}100{>Рекомендации по именованию<0}

{0>J.1<}0{>Й.1<0} {0>Allocation of Names<}100{>Выделение имен<0}

{0>The subject name is allocated through a registration scheme administered through a Registration Authority (RA) to ensure uniqueness.<}0{>Имя субъекта выделяется с использованием схемы регистрации, которой управляет центр регистрации (RA), для обеспечения уникальности имени.<0} {0>This RA may be an independent body or a function carried out by the Certification Authority.<}0{>Этот центр регистрации может быть независимым органом или его функции может выполнять центр сертификации.<0}

{0>In addition to ensuring uniqueness, the RA verifies that the name allocated properly identifies the applicant and that authentication checks are carried out to protect against masquerade.<}0{>Помимо обеспечения уникальности имени центр регистрации проверяет, правильно ли выделенное имя идентифицирует подателя заявки и проводятся ли проверка подлинности для предотвращения подделки.<0}

{0>The name allocated by an RA is based on registration information provided by, or relating to, the applicant (e.g. his personal name, date of birth, residence address) and information allocated by the RA.<}0{>Имя, выделенное центром регистрации, основано на регистрационных данных, предоставленных заявителем или связанных с ним (таких как имя, дата рождения, адрес проживания), а также информации, предоставленной центром регистрации.<0} {0>Three variations commonly exist:<}0{>Обычно используются три варианта:<0}

  • {0>the name is based entirely on registration information, which uniquely identifies the applicant (e.g. "Pierre Durand (born on) July 6, 1956");<}0{>имя основано только на регистрационных данных, которые уникально идентифицируют заявителя (например, «Сергей Иванов, дата рождения: 6 июля 1956 г.»);<0}

  • {0>the name is based on registration information, with the addition of qualifiers added by the registration authority to ensure uniqueness (e.g. "Pierre Durand 12");<}0{>имя основано на регистрационных данных и квалификаторах, добавленных центром регистрации для обеспечения уникальности («Сергей Иванов 12»);<0}

  • {0>the registration information is kept private by the registration authority and the registration authority allocates a "pseudonym".<}0{>регистрационные данные хранятся центром регистрации конфиденциально, при этом центр регистрации выделяет «псевдоним».<0}


{0>J.2<}100{>Й.2<0} {0>Providing Access to Registration Information<}100{>Предоставление доступа к сведениям о регистрации<0}

{0>Under certain circumstances, it may be necessary for information used during registration, but not published in the certificate, to be made available to third parties (e.g. to an arbitrator to resolve a dispute or for law enforcement).<}0{>В определенных обстоятельствах может потребоваться, чтобы информация, использованная во время регистрация, но не опубликованная в сертификате, была доступна третьим лицам (например, арбитру для разрешения конфликта или правоохранительным органам).<0} {0>This registration information is likely to include personal and sensitive information.<}0{>Такие регистрационные данные, скорее всего, содержат личные и конфиденциальные данные.<0}

{0>Thus, the RA needs to establish a policy for:<}0{>Таким образом центр регистрации должен установить политику, определяющую следующие условия:<0}

  • {0>whether the registration information should be disclosed;<}0{>следует ли предоставлять доступ к регистрационным данным;<0}

  • {0>to whom such information should be disclosed;<}63{>кому следует предоставлять доступ к регистрационным данным;<0}

  • {0>under what circumstances such information should be disclosed.<}63{>в каких случаях следует предоставлять доступ к регистрационным данным.<0}

{0>This policy may be different whether the RA is being used only within a company or for public use.<}0{>Эта политика может отличаться в зависимости от того, используется ли центр регистрации только внутри компании или публично.<0} {0>The policy will have to take into account national legislation and in particular any data protection and privacy legislation.<}0{>Политика должна учитывать национальное законодательство и любые законы, связанные с защитой данных и конфиденциальности.<0}

{0>Currently, the provision of access to registration is a local matter for the RA.<}0{>На данный момент предоставление доступа к регистрационным данным является локальной задачей центра регистрации.<0} {0>However, if open access is required, standard protocols, such as HTTP - RFC 2616 [i.33] (Internet Web Access Protocol), may be employed with the addition of security mechanisms necessary to meet the data protection requirements (e.g. Transport Layer Security -RFC 4346 [i.34]) with client authentication.<}0{>Но при необходимости открытого доступа можно использовать стандартные протоколы, такие как HTTP, как определено в документе RFC 2616 [i.33] (протокол доступа через Интернет), с дополнительными механизмами безопасности, необходимыми для выполнения требований по защите данных (например, протокол TLS, описанный в документе RFC 4346 [i.34]), с проверкой подлинности клиента.<0}
{0>J.3<}100{>Й.3<0} {0>Naming Schemes<}100{>Схемы именования<0}

{0>J.3.1<}100{>Й.3.1<0} {0>Naming Schemes for Individual Citizens<}100{>Схемы именования для отдельных граждан<0}

{0>In some cases, the subject name that is contained in a public key certificate may not be meaningful enough.<}0{>В некоторых случаях имя субъекта, которое содержится в сертификате открытого ключа, может быть недостаточно однозначным.<0} {0>This may happen because of the existence of homonyms or because of the use of pseudonyms.<}0{>Это может произойти из-за существования омонимов или использования псевдонимов.<0} {0>A distinction could be made if more attributes were present.<}0{>Отличить имена можно при наличии дополнительных атрибутов.<0} {0>However, adding more attributes to a public key certificate placed in a public repository would be going against the privacy protection requirements.<}0{>Однако добавление дополнительных атрибутов в сертификат открытого ключа, размещенного в открытом репозитории, противоречит требованиям по защите конфиденциальности.<0} {0>In any case, the Registration Authority will get information at the time of registration, but not all that information will be placed in the certificate.<}0{>В любом случае центр регистрации получит информацию в ходе регистрации, но не все данные будут размещены в сертификате.<0} {0>In order to achieve a balance between these two opposite requirements, the hash values of some additional attributes can be placed in a public key certificate.<}0{>Для достижения баланса этих двух противоречивых требований в сертификате открытого ключа можно разместить хэш-значения некоторых дополнительных атрибутов.<0} {0>When the certificate owner provides these additional attributes, then they can be verified.<}0{>Когда владелец сертификата предоставит эти атрибуты, их можно будет проверить.<0} {0>Using biometrics attributes may unambiguously identify a person.<}0{>Использование биометрических атрибутов позволяет однозначно идентифицировать человека.<0} {0>Examples of biometrics attributes that can be used include:<}0{>Примеры биометрических атрибутов, которые можно использовать:<0} {0>a picture or a manual signature from the certificate owner.<}0{>фотография или собственноручная подпись владельца сертификата.<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>Using hash values protects privacy only if the possible inputs are large enough.<}0{>Использование хэш-значений защищает конфиденциальность, только при достаточно большом размере возможных входных данных.<0} {0>For example, using the hash of a person's social security number is generally not sufficient since it can easily be reversed.<}0{>Например, применение хэш-значения номера социального страхования человека, как правило, недостаточно, так как из него можно легко восстановить исходное значение.<0}

{0>A picture can be used if the verifier once met the person and later on wants to verify that the certificate that he or she got relates to the person whom was met.<}0{>Фотографию можно использовать, если проверяющая сторона встречалась с человеком лично и хочет убедиться, что полученный сертификат связан с этим человеком.<0} {0>In such a case, at the first exchange, the picture is sent, and the hash contained in the certificate may be used by the verifier to verify that it is the right person.<}0{>В таком случае при первом обмене данными отправляется фотография, а проверяющая сторона может использовать хэш-значение в сертификате, чтобы проверить, тот ли этот человек.<0} {0>At the next exchange, the picture does not need to be sent again.<}0{>При следующем обмене данными фотографию отправлять не требуется.<0} {0>A manual signature may be used if a signed document has been received beforehand.<}0{>Собственноручную подпись можно использовать, если до этого был получен подписанный документ.<0} {0>In such a case, at the first exchange, the drawing of the manual signature is sent, and the hash contained in the certificate may be used by the verifier to verify that it is the right manual signature.<}85{>В таком случае при первом обмене данными отправляется изображение собственноручной подписи, а проверяющая сторона может использовать хэш-значение в сертификате, чтобы проверить, совпадает ли ручная подпись с присланной.<0} {0>At the next exchange, the manual signature does not need to be sent again.<}89{>При следующем обмене данными отправлять ручную подпись не требуется.<0}

{0>J.3.2<}100{>Й.3.2<0} {0>Naming Schemes for Employees of an Organization<}100{>Схемы именования для сотрудников организации<0}

{0>The name of an employee within an organization is likely to be some combination of the name of the organization and the identifier of the employee within that organization.<}0{>Имя сотрудника организации, скорее всего, представляет собой сочетание названия организации и идентификатора сотрудника в этой организации.<0}

{0>An organization name is usually a registered name, i.e. business or trading name used in day-to-day business.<}0{>Название организации обычно является зарегистрированным именем, т. е. названием компании, используемым в деловых операциях.<0} {0>This name is registered by a Naming Authority, which guarantees that the organization's registered name is unambiguous and cannot be confused with another organization.<}0{>Это имя регистрируется центром именования, который гарантирует, что зарегистрированное название организации является однозначным и его нельзя спутать с названием другой организации.<0} {0>In order to get more information about a given registered organization name, it is necessary to go back to a publicly available directory maintained by the Naming Authority.<}0{>Для получения дополнительной информации о зарегистрированном имени организации необходимо вернуться в общедоступный каталог, поддерживаемый центром именования.<0}

{0>The identifier may be a name or a pseudonym (e.g. a nickname or an employee number).<}0{>Идентификатор может быть именем или псевдонимом (например, прозвищем или номером сотрудника).<0} {0>When it is a name, it is supposed to be descriptive enough to unambiguously identify the person.<}0{>Если это имя, то предполагается, что оно достаточно информативное для однозначной идентификации человека.<0} {0>When it is a pseudonym, the certificate does not disclose the identity of the person.<}0{>Если это псевдоним, сертификат не разглашает личность человека.<0} {0>However, it ensures that the person has been correctly authenticated at the time of registration and therefore may be eligible to some advantages implicitly or explicitly obtained through the possession of the certificate.<}0{>Однако он обеспечивает правильную проверку подлинности человека во время регистрации, который может получить определенные права, явно или косвенно получаемые при владении сертификатом.<0} {0>In either case, however, this can be insufficient because of the existence of homonyms.<}0{>В любом случае этого может быть недостаточно из-за существования омонимов.<0}

{0>Placing more attributes in the certificate may be one solution, for example, by giving the organization unit of the person or the name of a city where the office is located.<}0{>Одним из решений может быть размещение дополнительных атрибутов в сертификате, например, можно указать для организации название города, в котором она расположена.<0} {0>However, the more information is placed in the certificate, the more problems arise if there is a change in the organization structure or the place of work.<}0{>Однако чем больше информации в сертификате, тем больше проблем возникает при изменении структуры организации или места работы.<0} {0>So this may not be the best solution.<}0{>Это может быть не самым лучшим решением.<0} {0>An alternative is to provide more attributes (like the organization unit and the place of work) through access to a directory maintained by the company.<}0{>Альтернативный способ – указать дополнительные атрибуты (подразделение и место работы) с помощью доступа к каталогу, который поддерживается компанией.<0} {0>It is likely, that at the time of registration, the Registration Authority got more information than what was placed in the certificate, if such additional information is placed in a repository accessible only to the organization.<}0{>Вероятно, что во время регистрации центр регистрации получил больше информации, чем размещено в сертификате, если такая дополнительная информация хранится в репозитории, доступном только для организации.<0}
{0>Annex K (informative):<}100{>Приложение К (справочное).<0} {0>Time-stamp hash calculation<}100{>Вычисление хэш-значения штампа времени<0}

{0>Tables K.1 to K.3 describe attributes included in the time-stamped hash calculation which is the value of messageImprint field within TimeStampToken for the time-stamps defined in the main body of the present document.<}0{>В таблицах К.1-К.3 описываются атрибуты, участвующие при вычислении хэш-значения со штампом времени, равные значению поля messageImprint структуры TimeStampToken для штампов времени, определенных в данном документе.<0}

{0>Table K.1:<}0{>Таблица К.1.<0} {0>The identification of attributes from which the hash is calculated<}0{>Идентификация атрибутов, используемых для вычисления хэш-значения<0}

{0>Type of Timestamp<}0{>Тип штампа времени<0}

{0>Identification<}0{>Идентификация<0}

id-aa-ets-contentTimestamp

D

lid-aa-signatureTimeStampToken

1

S


lid-aa-ets-escTimeStamp

1

C


|id-aa-ets-certCRLTimestamp

|

R


id-aa-ets-archiveTimestamp

A


Достарыңызбен бөлісу:
1   ...   9   10   11   12   13   14   15   16   17




©dereksiz.org 2024
әкімшілігінің қараңыз

    Басты бет