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



жүктеу/скачать 2.44 Mb.
бет15/17
Дата29.02.2016
өлшемі2.44 Mb.
#34652
1   ...   9   10   11   12   13   14   15   16   17
Figure F.3:<}99{>Рисунок Е.3.<0} {0>Signing Using application/pkcs7-signature<}88{>Подпись с использованием application/pkcs7-signature<0}

{0>This second approach (multipart/signed) has the advantage that the signed data can be decoded by any MIME-compatible system even if it does not recognize CMS-encoded electronic signatures.<}0{>У второго подхода с использованием multipart/signed есть преимущество, которое состоит в том, что подписанные данные может декодировать любая система, совместимая с MIME, даже если она не распознает электронные подписи, закодированные CMS.<0}
{0>Annex G (informative):<}100{>Приложение Ж (справочное).<0}

{0>Relationship to the European Directive and EESSI<}100{>Связь с Европейской директивой и инициативой EESSI<0}

{0>G.1<}0{>Ж.1<0} {0>Introduction<}100{>Введение<0}

{0>This annex provides an indication of the relationship between electronic signatures created under the present document and requirements under the European Parliament and Council Directive on a Community framework for electronic signatures [i.5].<}0{>В данном приложении описывается связь электронных подписей, созданных в соответствии с настоящим документом, и требований директивы Европейского парламента и Совета, посвященной электронным подписям [i.5].<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>Legal advice should be sought on the specific national legislation regarding use of electronic signatures.<}0{>Для получения дополнительных сведений о национальных законодательных требованиях, касающихся использования электронных подписей, необходима юридическая консультация.<0}

{0>The present document is one of a set of standards that has been defined under the "European Electronic Signature Standardization Initiative" (EESSI) for electronic signature products and solutions compliant with the European Directive for Electronic Signatures [i.5].<}100{>Настоящий документ – это один из наборов стандартов, определенных согласно «Европейской инициативе по стандартизации электронных подписей» (EESSI) и посвященных продуктам и решениям для использования электронных подписей, совместимых с Европейской директивой по электронным подписям [i.5].<0}
{0>G.2<}0{>Ж.2<0} {0>Electronic Signatures and the Directive<}100{>Электронные подписи и директива<0}

{0>This Directive [i.5] defines electronic signatures as:<}0{>В данной директиве [i.5] электронные подписи определены как:<0}

• {0>"data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication".<}84{>«данные в электронном виде, которые присоединены или логически связаны с другими электронными данными и которые служат методом проверки подлинности».<0}



{0>The Directive [i.5] states that an electronic signature should not be denied "legal effectiveness and admissibility as evidence in legal proceedings" solely on the grounds that it is in electronic form.<}0{>Директива [i.5] указывает, что электронная подпись не должна лишаться «юридического действия и приемлемости в качестве доказательства в юридических процессах» только на основании того, что она представлена в электронной форме.<0}

{0>The Directive [i.5] identifies an electronic signature as having equivalence to a hand-written signature if it meets specific criteria:<}0{>Директива [i.5] определяет электронную подпись как эквивалентную собственноручной подписи, если она соответствует определенным критериям.<0}

• {0>It is an "advanced electronic signature" with the following properties:<}0{>Это «усовершенствованная электронная подпись» со следующими свойствами:<0}



  1. {0>it is uniquely linked to the signatory;<}0{>она уникально связана с подписывающей стороной;<0}

  2. {0>it is capable of identifying the signatory;<}63{>она позволяет идентифицировать подписывающую сторону;<0}

  3. {0>it is created using means that the signatory can maintain under his sole control; and<}0{>она создана с помощью средств, которые контролируются только подписывающей стороной;<0}

  4. {0>it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable.<}0{>она связана с данными так, что любое последующее изменение данных можно обнаружить.<0}




  • {0>It is based on a certificate that meets detailed criteria given in annex I of the Directive [i.5] and is issued by a "certification-service-provider" that meets requirements given in annex II of the Directive [i.5].<}0{>Она основана на сертификате, который соответствует подробным критериям, указанным в приложении I директивы [i.5], и выдается «поставщиком услуг сертификации», соответствующим требованиям, указанным в приложении II директивы [i.5].<0} {0>Such a certificate is referred to as a "qualified certificate".<}0{>Такой сертификат называется «квалифицированным сертификатом».<0}

  • {0>It is created by a "device", for which detailed criteria are given in annex III of the Directive [i.5].<}0{>Она создается «устройством», подробные критерии для которого указаны в приложении III директивы [i.5].<0} {0>Such a device is referred to a "secure-signature-creation device".<}60{>Такое устройство называется «устройством для безопасного создания подписи».<0}

{0>This form of electronic signature is referred to as a "qualified electronic signature" in EESSI (see below).<}0{>Такая форма электронной подписи называется «квалифицированной электронной подписью» в EESSI (см. далее).<0}
{0>G.3<}0{>Ж.3<0} {0>ETSI Electronic Signature Formats and the Directive<}100{>Форматы электронной подписи ETSI и директива<0}

{0>An electronic signature created in accordance with the present document is:<}0{>Электронная подпись, созданная в соответствии с данным документом:<0}

  1. {0>considered to be an "electronic signature" under the terms of the Directive [i.5];<}0{>считается «электронной подписью» согласно условиям директивы [i.5];<0}

  2. {0>considered to be an "advanced electronic signature" under the terms of the Directive [i.5];<}96{>считается «усовершенствованной электронной подписью» согласно условиям директивы [i.5];<0}

  3. {0>considered to be a "Qualified Electronic Signature", provided the additional requirements in annexes I, II, and III of the Directive [i.5] are met.<}0{>считается «квалифицированной электронной подписью», если выполнены дополнительные требования, указанные в приложениях I, II и III директивы [i.5].<0} {0>The requirements in annexes I, II, and III of the Directive [i.5] are outside the scope of the present document, and are subject to standardization elsewhere.<}0{>Требования, указанные в приложениях I, II и III директивы [i.5], выходят за рамки данного документа и регламентируются в других стандартах.<0}



{0>G.4<}0{>Ж.4<0} {0>EESSI Standards and Classes of Electronic Signature<}100{>Стандарты EESSI и классы электронных подписей<0}

{0>G.4.1<}0{>Ж.4.1<0} {0>Structure of EESSI Standardization<}100{>Структура стандартов EESSI<0}

{0>EESSI looks at standards in several areas.<}0{>EESSI рассматривает стандарты в нескольких областях.<0} {0>See the ETSI and CEN web sites for the latest list of standards and their versions:<}0{>Последний список стандартов и их версий см. на сайтах ETSI и CEN:<0}

  • {0>use of X.509 public key certificates as qualified certificates;<}0{>использование сертификатов открытых ключей X.509 в качестве квалифицированных сертификатов;<0}

  • {0>security Management and Certificate Policy for CSPs Issuing Qualified Certificates;<}0{>управление безопасностью и регламент сертификатов для поставщиков служб шифрования, выдающих квалифицированные сертификаты;<0}

  • {0>security requirements for trustworthy systems used by CSPs Issuing Qualified Certificates;<}0{>требования безопасности для надежных систем, используемые поставщиками служб шифрования, выдающими квалифицированные сертификаты;<0}

  • {0>security requirements for Secure Signature Creation Devices;<}0{>требования безопасности для устройств безопасного создания подписей;<0}

  • {0>security requirements for Signature Creation Systems;<}72{>требования безопасности для систем создания подписей;<0}

  • {0>procedures for Electronic Signature Verification;<}0{>процедуры проверки электронной подписи;<0}

  • {0>electronic signature syntax and encoding formats;<}0{>синтаксис и форматы кодирования электронных подписей;<0}

  • {0>protocol to interoperate with a Time-Stamping Authority;<}0{>протокол для взаимодействия со службой штампов времени;<0}

  • {0>Policy requirements for Time-Stamping Authorities; and<}0{>требования регламента для служб штампов времени;<0}

  • {0>XML electronic signature formats.<}60{>форматы электронных подписей XML.<0}

{0>Each of these standards addresses a range of requirements including the requirements, of Qualified Electronic Signatures, as specified in article 5.1 of the Directive [i.5].<}0{>Каждый из этих стандартов описывает ряд требований, в том числе требования для квалифицированных электронных подписей, как указано в статье 5.1 директивы [i.5].<0} {0>However, some of them also address general requirements of electronic signatures for business and electronic commerce, which all fall into the category of article 5.2 of the Directive [i.5].<}100{>Однако некоторые из них также посвящены общим требованиям для электронных подписей, используемых для бизнеса и электронной коммерции, которые подпадают под категорию статьи 5.2 директивы [i.5].<0} {0>Such variation in the requirements may be identified either as different levels or different options.<}0{>Такую вариативность требований можно определить как разные уровни или разные варианты использования.<0}

{0>G.4.2<}0{>Ж.4.2<0} {0>Classes of Electronic Signatures<}100{>Классы электронных подписей<0}

{0>Since some of these standards address a range of requirements, it may be useful to identify a set of standards to address a specific business need.<}0{>Так как некоторые из этих стандартов описывают определенный спектр требований, рекомендуется определить набор стандартов для решения конкретных бизнес-задач.<0} {0>Such a set of standards and their uses define a class of electronic signature.<}0{>Такой набор стандартов и их применение определяют класс электронных подписей.<0} {0>The first class already identified is the qualified electronic signature, fulfilling the requirements of article 5.1 of the Directive [i.5].<}0{>Уже определенный первый класс – это квалифицированная электронная подпись, соответствующая требованиям 5.1 директивы [i.5].<0}

{0>A limited number of "classes of electronic signatures" and corresponding profiles could be defined, in close cooperation with actors on the market (business, users, suppliers).<}0{>Можно определить ограниченный набор «классов электронных подписей» и соответствующих профилей в тесном сотрудничестве с действующими лицами на рынке (компании, пользователи, поставщики).<0} {0>The need for such standards is envisaged, in addition to those for qualified electronic signatures, in areas such as:<}0{>Потребность в таких стандартах (помимо квалифицированных электронных подписей) возникает в таких областях, как:<0}

  • {0>different classes of electronic signatures with long-term validity;<}0{>разные классы долгосрочных электронных подписей;<0}

  • {0>electronic signatures for business transactions with limited value.<}0{>электронные подписи для бизнес-транзакций с ограниченной ценностью.<0}

{0>G.4.3<}0{>Ж.4.3<0} {0>Electronic Signature Classes and the ETSI Electronic Signature Format<}100{>Классы электронных подписей и формат электронной подписи ETSI<0}

{0>The electronic signature format defined in the present document is applicable to the EESSI area "electronic signature and encoding formats".<}0{>Формат электронной подписи, определенный в настоящем документе, применим к области EESSI – «форматы электронной подписи и кодирования».<0}

{0>An electronic signature produced by a signer (see clause 5 and conformance clause 10.1) is applicable to the proposed class of electronic signature:<}0{>Электронная подпись, созданная подписывающей стороной (см. пункты 5 и 10.1), применима к следующему классу электронных подписей:<0} {0>"qualified electronic signatures fulfilling article 5.1".<}0{>«квалифицированные электронные подписи, соответствующие требованиям статьи 5.1»<0}

{0>With the addition of attributes by the verifier (see clause 6 and conformance clause 10.2) the qualified electronic signature supports the long-term validity.<}0{>При добавлении атрибутов проверяющей стороной (см.пункты 6 и 10.2) квалифицированная электронная подпись становится долгосрочной.<0}
{0>Annex H (informative):<}100{>Приложение З (справочное).<0}

{0>APIs for the Generation and Verification of Electronic<}87{>Интерфейсы API для формирования и проверки маркеров<0}

{0>Signatures Tokens<}0{>электронных подписей<0}

{0>While the present document describes the data format of an electronic signature, the question is whether there exist PIs (Application Programming Interfaces) able to manipulate these structures.<}0{>Несмотря на то, что в данном документе описывается формат электронной подписи, возникает вопрос о существовании программных интерфейсов (API) для управления такими структурами.<0} {0>At least two such APIs have been efined; one set by the IETF and another set by the OMG (Object Management Group).<}0{>Определено, по крайней мере, два таких интерфейса API: один, заданный группой инженерной поддержки Интернета (IETF), и другой, определенный Группой управления объектами (OMG).<0}

{0>H.1<}100{>З.1<0} {0>Data Framing<}100{>Кадры данных<0}

{0>In order to be able to use either of these APIs, it will be necessary to frame the previously defined electronic signature ata structures using a mechanism-independent token format.<}0{>Для использования этих интерфейсов требуется разбить ранее определенные структуры данных электронной подписи на кадры с помощью формата маркеров, независимого от механизмов реализации.<0} {0>Clause 3.1 of RFC 2743 [i.14] specifies a mechanism-ndependent level of encapsulating representation for the initial token of a GSS-API context establishment sequence, ncorporating an identifier of the mechanism type to be used on that context and enabling tokens to be interpreted nambiguously.<}0{>В пункте 3.1 документа RFC 2743 [i.14] описывается независимый от механизмов уровень инкапсуляции исходного маркера последовательности контекста GSS-API, использующий идентификатор типа механизма, который будет применяться в этом контексте и позволяющий однозначно интерпретировать маркеры.<0}

{0>In order to be processable by these APIs, all electronic signature data formats that are defined in the present document re framed following that description.<}0{>Чтобы эти интерфейсы могли обработать все форматы данных электронной подписи, определенные в настоящем документе, они разбиваются на кадры в соответствии со следующим описанием.<0}

{0>The encoding format for the token tag is derived from ASN.1 and DER, but its concrete representation is defined irectly in terms of octets rather than at the ASN.1 level, in order to facilitate interoperable implementation without use f general ASN.1 processing code.<}0{>Формат кодирования тега маркера получен из ASN.1 и DER, но его конкретное представление определено непосредственно в форме октетов, а не на уровне ASN.1, для обеспечения совместимой реализации без использования общего кода обработки ASN.1.<0} {0>The token tag consists of the following elements, in order:<}0{>Тег маркера состоит из следующих элементов (в указанном порядке):<0}

  1. {0>0x60 -- Tag for RFC 2743 [i.14] SEQUENCE; indicates that constructed form, definite length encoding follows.<}0{>0x60 – тег для последовательности (SEQUENCE) из документа RFC 2743 [i.14]; указывает, что далее следует кодированная форма заданной длины;<0}

  2. {0>Token-length octets, specifying length of subsequent data (i.e. the summed lengths of elements 3 to 5 in this list, and of the mechanism-defined token object following the tag).<}0{>октеты, определяющие длину последующих данных (т. е. суммированную длину элементов 3-5 из этого списка, а также объект маркера, определенного используемым механизмом, следующий за тегом).<0} {0>This element comprises a variable number of octets:<}0{>Этот элемент состоит из переменного числа октетов:<0}




  • {0>If the indicated value is less than 128, it is represented in a single octet with bit 8 (high order) set to "0" and the remaining bits representing the value.<}0{>если указанное значение меньше 128, оно представляется одним октетом, восьмой (старший) бит которого задан как 0, а оставшиеся биты представляют само значение;<0}

  • {0>If the indicated value is 128 or more, it is represented in two or more octets, with bit 8 of the first octet set to "1" and the remaining bits of the first octet specifying the number of additional octets.<}0{>если указанное значение больше или равно 128, оно представлено двумя или более октетами, где восьмой бит первого октета задан как 1, а оставшиеся биты первого октета указывают число дополнительных октетов;<0} {0>The subsequent octets carry the value, 8 bits per octet, most significant digit first.<}0{>последующие октеты содержат значение, по 8 бит на октет, начиная со старшего бита;<0} {0>The minimum number of octets is used to encode the length (i.e. no octets representing leading zeros are included within the length encoding).<}0{>для кодирования длины используется минимальное число октетов (т. е. в кодировку длины не включаются октеты, представляющие начальные нули).<0}




  1. {0>0x06 -- Tag for OBJECT IDENTIFIER.<}0{>0x06 – тег для идентификатора объекта (OBJECT IDENTIFIER);<0}

  2. {0>Object identifier length -- length (number of octets) of the encoded object identifier contained in element 5, encoded per rules as described in 2a) and 2b) above.<}0{>длина идентификатора объекта – длина (число октетов) идентификатора объекта, который содержится в элементе 5, закодированного согласно правилам, описанным в пунктах 2а и 2б выше;<0}

  3. {0>Object identifier octets -- variable number of octets, encoded per ASN.1 BER rules:<}0{>Октеты идентификатора объекта – переменное число октетов, закодированных по правилам ASN.1 BER:<0}

- {0>The first octet contains the sum of two values:<}0{>первый октет содержит сумму двух значений:<0}

  1. {0>the top-level object identifier component, multiplied by 40 (decimal); and<}0{>компонент идентификатора объекта верхнего уровня, умноженный на 40 (в десятичном формате);<0}

  2. {0>the second-level object identifier component.<}0{>компонент идентификатора объекта второго уровня.<0}

{0>This special case is the only point within an object identifier encoding where a single octet represents contents of more than one component.<}0{>Это единственный случай, когда при кодировании идентификатора объекта один октет представляет содержимое нескольких компонентов.<0}

- {0>Subsequent octets, if required, encode successively lower components in the represented object identifier.<}0{>Последующие октеты при необходимости последовательно кодируют младшие компоненты в представленном идентификаторе объекта.<0} {0>A component's encoding may span multiple octets, encoding 7 bits per octet (most significant bits first) and with bit 8 set to "1" on all but the final octet in the component's encoding.<}0{>Кодирование компонента может занимать несколько октетов, по 7 бит на октет (старшие биты идут первыми), а восьмой бит равен 1 для всех октетов кроме последнего.<0} {0>The minimum number of octets is used to encode each component (i.e. no octets representing leading zeros are included within a component's encoding).<}83{>Для кодирования каждого компонента используется минимальное число октетов (т. е. в кодировку компонента не включаются октеты, представляющие начальные нули).<0}



{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>In many implementations, elements 3 to 5 may be stored and referenced as a contiguous string constant.<}0{>Во многих реализациях элементы 3-5 могут храниться и указываться как смежные строковые константы.<0}

{0>The token tag is immediately followed by a mechanism-defined token object.<}0{>Тег маркера идет сразу после объекта маркера, определяемого механизмом.<0} {0>Note that no independent size specifier intervenes following the object identifier value to indicate the size of the mechanism-defined token object.<}0{>Учтите, что никакой независимый указатель размера не изменяет следующее значение идентификатора объекта для указания размера объекта маркера, определяемого механизмом.<0}

{0>Tokens conforming to the present document have the following OID in order to be processable by IDUP-APIs:<}0{>Маркеры, соответствующие требованиям настоящего документа, включают следующий идентификатор объекта (OID) для обработки интерфейсами IDUP-API:<0}

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) }


{0>H.2<}100{>З.2<0} {0>IDUP-GSS-APIs Defined by the IETF<}100{>Интерфейсы IDUP-GSS-API, определенные IETF<0}

{0>The IETF CAT WG produced in December 1998, an RFC (RFC 2479 [i.15]) under the name of IDUP-GSS-API (Independent Data Unit Protection) able to handle the electronic signature data format defined in the present document.<}0{>Рабочая группа IETF CAT в декабре 1998 г. представила документ RFC 2479 [i.15], описывающий интерфейс IDUP-GSS-API (Independent Data Unit Protection, независимая защита модулей данных), позволяющий обрабатывать формат данных электронной подписи, определенный в настоящем документе.<0}

{0>The IDUP-GSS-API includes support for non-repudiation services.<}0{>Интерфейс IDUP-GSS-API поддерживает службы, гарантирующие невозможность отказа от обязательств.<0} {0>It supports evidence generation, where "evidence" is information that either by itself, or when used in conjunction with other information, is used to establish proof about an event or action, as well as evidence verification.<}0{>Он поддерживает формирование свидетельств (где «свидетельство» – это информация, которая сама по себе или вместе с другой информацией используется для предоставления доказательства выполнения события или действия), а также проверку свидетельств.<0}

{0>IDUP supports various types of evidences.<}0{>IDUP поддерживает разные типы доказательств.<0} {0>All the types defined in IDUP are supported in the present document through the commitment-type parameter.<}0{>Все типы, определенные в IDUP, поддерживаются данным документом с помощью параметра commitment-type.<0}

{0>Clause 2.3.3 of IDUP describes the specific calls needed to handle evidence ("EV" calls).<}0{>В пункте 2.3.3 IDUP описываются вызовы, необходимые для обработки доказательств (вызовы EV).<0} {0>The "EV" group of calls provides a simple, high-level interface to underlying IDUP mechanisms when application developers need to deal with only evidence:<}0{>Группа вызовов EV предоставляет простой высокоуровневый интерфейс для взаимодействия с соответствующими механизмами IDUP, когда разработчики приложения сталкиваются с единственным доказательством:<0} {0>not with encryption or integrity services.<}0{>без шифрования и служб обеспечения целостности данных.<0}

{0>All generations and verification are performed according to the content of a
жүктеу/скачать 2.44 Mb.

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



©dereksiz.org 2024
әкімшілігінің қараңыз
    Басты бет