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


CAdES-A in the present document.В данном документе такой подход называется вложенным форматом CAdES-A



бет14/17
Дата29.02.2016
өлшемі2.44 Mb.
#34652
1   ...   9   10   11   12   13   14   15   16   17
CAdES-A in the present document.<}89{>В данном документе такой подход называется вложенным форматом CAdES-A.<0}
{0>C.5<}0{>В.5<0} {0>Multiple Signatures<}100{>Множество подписей<0}

{0>Some electronic signatures may only be valid if they bear more than one signature.<}0{>Некоторые электронные подписи могут быть действительны, только если они содержат несколько подписей.<0} {0>This is generally the case when a contract is signed between two parties.<}0{>Обычно это происходит при подписании контракта между двумя сторонами.<0} {0>The ordering of the signatures may or may not be important, i.e. one may or may not need to be applied before the other.<}0{>Порядок применения подписей может быть как важен, так и не важен.<0}

{0>Several forms of multiple and counter signatures need to be supported, which fall into two basic categories:<}0{>Может потребоваться поддержка нескольких форм множественных и удостоверяющих подписей, которые делятся на две основные категории:<0}

  • {0>independent signatures;<}67{>независимые подписи;<0}

  • {0>embedded signatures.<}67{>встроенные подписи.<0}

{0>Independent signatures are parallel signatures where the ordering of the signatures is not important.<}0{>Независимые подписи – это параллельные подписи, для которых порядок не имеет значения.<0} {0>The capability to have more than one independent signature over the same data is provided.<}0{>Существует возможность использования нескольких независимых подписей для одних и тех же данных.<0}

{0>Embedded signatures are applied one after the other and are used where the order in which the signatures are applied is important.<}0{>Встроенные подписи применяются одна за другой и используются, если порядок применения подписей важен.<0} {0>The capability to sign over signed data is provided.<}0{>При этом существует возможность подписи уже подписанных данных.<0}

{0>These forms are described in clause 5.13.<}0{>Эти формы описаны в пункте 5.13.<0} {0>All other multiple signature schemes, e.g. a signed document with a countersignature, double countersignatures, or multiple signatures, can be reduced to one or more occurrences of the above two cases.<}0{>Все другие схемы множественных подписей, таких как подписанный документ с удостоверяющей подписью, двойная удостоверяющая подпись или множество подписей, можно свести к одному или нескольким описанным выше случаям.<0}
{0>Annex D (informative):<}100{>Приложение Г (справочное).<0}

{0>Data Protocols to Interoperate with TSPs<}100{>Протоколы данных для взаимодействия с поставщиками доверенных услуг<0}

{0>D.1<}0{>Г.1<0} {0>Operational Protocols<}100{>Оперативные протоколы<0}

{0>The following protocols can be used by signers and verifiers to interoperate with Trusted Service Providers during the electronic signature creation and validation.<}0{>Подписывающие и проверяющие стороны могут использовать следующие протоколы для взаимодействия с поставщиками доверенных услуг во время создания и проверки электронных подписей.<0}

{0>D.1.1<}0{>Г.1.1<0} {0>Certificate Retrieval<}100{>Извлечение сертификата<0}

{0>User certificates, CA certificates and cross-certificates, can be retrieved from a repository using the Lightweight Directory Access Protocol as defined in RFC 3494 [i.10], with the schema defined in RFC 4523 [i.11].<}0{>Сертификаты пользователей, центра сертификации и перекрестные сертификаты можно извлечь из репозитория с помощью протокола LDAP, как определено в документе RFC 3494 [i.10], с использованием схемы, описанной в документе RFC 4523 [i.11].<0}

{0>D.1.2<}100{>Г.1.2<0} {0>CRL Retrieval<}100{>Извлечение списка отзыва сертификатов<0}

{0>Certificate revocation lists, including authority revocation lists and partial CRL variants, can be retrieved from a repository using the Lightweight Directory Access Protocol, as defined in RFC 3494 [i.10], with the schema defined in RFC 4523 [i.11].<}79{>Списки отзыва сертификатов, в том числе списки отзыва центров сертификации и частичные списки отзыва сертификатов, можно извлечь из репозитория с помощью протокола LDAP, как определено в документе RFC 3494 [i.10], с использованием схемы, описанной в документе RFC 4523 [i.11].<0}

{0>D.1.3<}0{>Г.1.3<0} {0>Online Certificate Status<}100{>Оперативный статус сертификата<0}

{0>As an alternative to the use of certificate revocation lists, the status of a certificate can be checked using the Online Certificate Status Protocol (OCSP), as defined in RFC 2560 [3].<}0{>В качестве альтернативы использованию списков отзыва сертификатов статус сертификата можно проверить с помощью протокола проверки состояния сертификата в режиме реального времени (OCSP), как указано в документе RFC 2560 [3].<0}

{0>D.1.4<}100{>Г.1.4<0} {0>Time-Stamping<}100{>Штампы времени<0}

{0>The time-stamping service can be accessed using the Time-Stamping Protocol defined in RFC 3161 [7].<}0{>Доступ к службе штампов времени можно получить с помощью протокола TSP, определенного в документе RFC 3161 [7].<0}
{0>D.2<}100{>Г.2<0} {0>Management Protocols<}100{>Протоколы управления<0}

{0>Signers and verifiers can use the following management protocols to manage the use of certificates.<}0{>Подписывающие и проверяющие стороны могут использовать следующие протоколы управления для контроля использования сертификатов.<0}

{0>D.2.1<}100{>Г.2.1<0} {0>Request for Certificate Revocation<}100{>Запрос на отзыв сертификата<0}

{0>Request for a certificate to be revoked can be made using the revocation request and response messages defined in RFC 4210 [i.12].<}0{>Запросить отзыв сертификата можно, используя сообщения запроса и ответа отзыва, определенные в документе RFC 4210 [i.12].<0}
{0>Annex E (informative):<}100{>Приложение Д (справочное).<0}

{0>Security Considerations<}100{>Вопросы безопасности<0}

{0>E.1<}0{>Д.1<0} {0>Protection of Private Key<}100{>Защита закрытого ключа<0}

{0>The security of the electronic signature mechanism defined in the present document depends on the privacy of the signer's private key.<}0{>Безопасность механизма электронной подписи, определенного в данном документе, зависит от безопасности закрытого ключа подписывающей стороны.<0} {0>Implementations should take steps to ensure that private keys cannot be compromised.<}0{>Реализации данного механизма должны принимать меры для защиты закрытых ключей от компрометации.<0}
{0>E.2<}100{>Д.2<0} {0>Choice of Algorithms<}100{>Выбор алгоритмов<0}

{0>Implementers should be aware that cryptographic algorithms become weaker with time.<}0{>При реализации механизма электронной подписи следует помнить, что стойкость криптографических алгоритмов с течением времени ослабевает.<0} {0>As new cryptoanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce.<}0{>По мере разработки новых методов криптоанализа и наращивания вычислительной мощности компьютеров трудозатраты для взлома определенного криптографического алгоритма снижаются.<0} {0>Therefore, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted.<}0{>Поэтому реализации криптографических алгоритмов должны быть модульными и обеспечивать оперативное включение новых алгоритмов.<0} {0>That is, implementers should be prepared for the set of mandatory-to-implement algorithms to change over time.<}0{>Т. е. следует быть готовым к тому, что набор обязательных к реализации алгоритмов со временем изменится.<0}

{0>Annex F (informative):<}100{>Приложение Е (справочное).<0}

{0>Example Structured Contents and MIME<}100{>Пример структурированного содержимого и использования формата MIME<0}

{0>F.1<}99{>Е.3<0} {0>Use of MIME to Encode Data<}100{>Использование MIME для кодирования данных<0}

{0>The signed content may be structured using MIME (Multipurpose Internet Mail Extensions - RFC 2045 [6]).<}0{>Подписанное содержимое может быть структурировано с помощью формата MIME (многоцелевые расширения электронной почты, документ RFC 2045 [6]).<0} {0>Whilst the MIME structure was initially developed for Internet email, it has a number of features that make it useful to provide a common structure for encoding a range of electronic documents and other multi-media data (e.g. photographs, video).<}0{>Хотя структура MIME изначально была разработана для электронной почты, она обладает рядом характеристик, которые делают ее полезной при кодировании различных электронных документов и других мультимедийных данных (например, фотографий и видео).<0} {0>These features include:<}77{>К ним относятся следующие характеристики:<0}



  • {0>providing a means of signalling the type of "object" being carried (e.g. text, image, ZIP file, application data);<}0{>предоставление средств для указания типа передаваемого «объекта» (например, текст, изображение, ZIP-файл, данные приложения);<0}

  • {0>providing a means of associating a file name with an object;<}0{>предоставление средств для связи имени файла с объектом;<0}

  • {0>associating several independent objects (e.g. a document and image) to form a multi-part object;<}0{>связь нескольких независимых объектов (например, документа и изображения) для формирования составного объекта;<0}

  • {0>handling data encoded in text or binary and, if necessary, re-encoding the binary as text.<}0{>обработка данных, закодированных в текстовом или двоичном формате, и, если необходимо, перекодирование двоичных данных в текст.<0} {0>When encoding a single object, MIME consists of:<}100{>При кодировании одного объекта данные MIME состоят из следующих компонентов:<0}

  • {0>header information, followed by;<}0{>сведения заголовка;<0}

  • {0>encoded content.<}67{>кодированное содержимое.<0}

{0>This structure can be extended to support multi-part content.<}0{>Эту структуру можно расширить для поддержки составного содержимого.<0}

{0>F.1.1<}0{>Е.1.1<0} {0>Header Information<}100{>Данные заголовка<0}

{0>A MIME header includes:<}0{>Заголовок MIME содержит следующие данные.<0} {0>MIME Version information:<}0{>Сведения о версии MIME:<0}

{0>e.g.:<}0{>например,<0} {0>MIME-Version:<}0{>MIME-Version:<0} 1.0

{0>Content type information, which includes information describing the content sufficient for it to be presented to a user or application process, as required.<}0{>Сведения о типе информации, включающие информацию, описывающую содержимое в степени, достаточной для ее представления пользователю или приложению.<0} {0>This includes information on the "media type" (e.g. text, image, audio) or whether the data is for passing to a particular type of application.<}0{>К ним относятся сведения о типе мультимедийных данных (например, текст, изображение, звук) или указание того, что данные передаются для определенного типа приложения.<0} {0>In the case of text, the content type includes information on the character set used.<}0{>В случае с текстовыми данными тип содержимого содержит информацию об использованном наборе символов.<0}

{0>e.g. Content-Type:<}0{>Например, Content-Type:<0} {0>text/plain; charset="us-ascii"<}0{>text/plain; charset="us-ascii"<0}

{0>Content-encoding information, which defines how the content is encoded (see below about encoding supported by MIME).<}0{>Информация о формате кодирования содержимого, которая определяет способ кодирования данных (сведения о форматах кодирования, поддерживаемых MIME, см. далее).<0}

{0>Other information about the content, such as a description or an associated file name.<}0{>Другая информация о содержимом, например описание или связанное с ним имя файла.<0}

{0>An example MIME header for text object is:<}0{>Пример заголовка MIME для текстового объекта:<0}

Mime-Version: 1.0

Content-Type: text/plain; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable



{0>An example MIME header for a binary file containing a PDF document is:<}0{>Пример заголовка MIME для двоичного файла, содержащего документ PDF:<0}

Content-Type: application/pdf

Content-Transfer-Encoding: base64

Content-Description: JCFV201.pdf



Content-Disposition: filename="JCFV201.pdf"

{0>F.1.2<}0{>Е.1.2<0} {0>Content Encoding<}100{>Кодирование содержимого<0}

{0>MIME supports a range of mechanisms for encoding both text and binary data.<}0{>MIME поддерживает ряд механизмов для кодирования текстовых и двоичных данных.<0}

{0>Text data can be carried transparently as lines of text data encoded in 7- or 8-bit ASCII characters.<}0{>Текстовые данные можно передавать открыто как строки текстовых данных в виде 7- или 8-битных символов ASCII.<0} {0>MIME also includes a "quoted-printable" encoding that converts characters other than the basic ASCII into an ASCII sequence.<}0{>MIME также поддерживает кодировку вида «Допущено к печати», которая преобразует символы, отличные от базовых символов ASCII, в ASCII-последовательность.<0}

{0>Binary can either be carried:<}0{>Двоичные данные могут передаваться следующими способами:<0}

  • {0>transparently as 8-bit octets; or<}0{>открыто, в виде 8-битных октетов;<0}

  • {0>converted to a basic set of characters using a system called Base64.<}0{>с преобразованием в базовый набор символов с помощью системы Base64.<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>As there are some mail relays that can only handle 7-bit ASCII, Base64 encoding is usually used on the Internet.<}0{>Так как существуют ретрансляторы электронной почты, которые могут обрабатывать только 7-битные символы ASCII, кодирование Base64 обычно используется в Интернете.<0}

{0>F.1.3<}0{>Е.1.3<0} {0>Multi-Part Content<}100{>Составное содержимое<0}

{0>Several objects (e.g. text and a file attachment) can be associated together using a special "multi-part" content type.<}0{>Несколько объектов (например, текст и вложенный файл) можно связать друг с другом с помощью специального типа «составного» (multi-part) содержимого.<0} {0>This is indicated by the content type "multipart" with an indication of the string to be used indicating a separation between each part.<}0{>Для этого используется тип содержимого multipart с указанием строки, которая будет использоваться для разделения каждой части содержимого.<0}

{0>In addition to a header for the overall multipart content, each part includes its own header information indicating the inner content type and encoding.<}0{>Помимо заголовка для всего составного содержимого каждая его часть содержит собственный заголовок, определяющий внутренний тип содержимого и формат кодирования.<0}

{0>An example of a multipart content is:<}0{>Пример составного содержимого:<0}

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

{0>Multipart content can be nested.<}0{>Составное содержимое может быть вложенным.<0} {0>So a set of associated objects (e.g. HTML text and images) can be handled as a single attachment to another object (e.g. text).<}0{>Таким образом, набор связанных объектов (например, текст HTML и изображения) можно обработать как одно вложение в другом объекте (например, текстовом).<0}

{0>The Content-Type from each part of the MIME message indicates the type of content.<}0{>Поле Content-Type каждой части сообщения MIME указывает тип содержимого.<0}
{0>F.2<}0{>Е.2<0} {0>S/MIME<}100{>S/MIME<0}

{0>The specific use of MIME to carry CMS (extended as defined in the present document) secured data is called S/MIME (see RFC 3851 [i.13]).<}0{>Специальное использование формата MIME для передачи защищенных данных CMS (с расширением, указанным в настоящем документе) называется S/MIME (см. документ RFC 3851 [i.13]).<0}



{0>Figure F.1:<}99{>Рисунок Е.1.<0} {0>Illustration of relation of using S/MIME<}0{>Схема связи с использованием S/MIME<0}

{0>S/MIME carries electronic signatures as either:<}0{>S/MIME передает электронные подписи следующими способами:<0}

{0>an "application/pkcs7-mime" object with the CMS carried as binary attachment (PKCS7 is the name of the early version of CMS).<}0{>как объект application/pkcs7-mime с данными CMS в виде двоичного вложения (PKCS7 – имя предыдущей версии CMS);<0}

- {0>The signed data may be included in the SignedData, which itself may be included in a single S/MIME object.<}0{>подписанные данные могут быть включены в структуру SignedData, которая может быть включена в один объект S/MIME.<0} {0>See RFC 3851 [i.13], clause 3.4.2:<}0{>См. документ RFC 3851 [i.13], пункт 3.4.2:<0} {0>"Signing Using application/pkcs7-mime with SignedData" and figure F.2 hereafter.<}100{>«Подпись с использованием application/pkcs7-mime и структуры SignedData» и рис. Е.2 ниже.<0}

{0>or<}0{>или<0}

{0>a "multipart/signed" object with the signed data and the signature encoded as separate MIME objects.<}0{>как объект multipart/signed с подписанными данными и подписью, закодированными как отдельные объекты MIME;<0}

- {0>The signed data is not included in the SignedData, and the CMS structure only includes the signature.<}0{>подписанные данные не включаются в структуру SignedData, а структура CMS содержит только подпись.<0} {0>See RFC 3851 [i.13], clause 3.4.3:<}97{>См. документ RFC 3851 [i.13], пункт 3.4.3:<0} {0>"Signing Using the multipart/signed Format" and figure F.3 hereafter.<}100{>«Подпись с использованием формата multipart/signed» и рис. Е.3 ниже.<0}



{0>Figure F.2:<}99{>Рисунок Е.2.<0} {0>Signing Using application/pkcs7-mime<}0{>Подпись с использованием application/pkcs7-mime<0}

{0>F.2.1<}0{>Е.2.1<0} {0>Using application/pkcs7-mime<}100{>Использование application/pkcs7-mime<0}

{0>This approach is similar to handling signed data as any other binary file attachment.<}0{>Этот подход аналогичен обработке подписанных данных, как любого другого вложенного двоичного файла.<0} {0>An example of signed data encoded using this approach is:<}0{>Пример подписанных данных, закодированных с использованием этого подхода:<0}

Content-Type: application/pkcs7-mime; smime-type=signed-data;

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=smime.p7m

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75

{0>F.2.2<}0{>Е.2.2<0} {0>Using application/pkcs7-signature<}100{>Использование application/pkcs7-signature<0}

{0>CMS also supports an alternative structure where the signature and data being protected are separate MIME objects carried within a single message.<}0{>CMS также поддерживает альтернативную структуру, в которой подпись и защищаемые данные являются отдельными объектами MIME, которые передаются в одном сообщении.<0} {0>In this case, the signed data is not included in the SignedData, and the CMS structure only includes the signature.<}86{>В этом случае подписанные данные не включаются в структуру SignedData, а структура CMS содержит только подпись.<0} {0>See RFC 3851 [i.13], clause 3.4.3:<}100{>См. документ RFC 3851 [i.13], пункт 3.4.3:<0} {0>"Signing Using the multipart/signed Format" and figure F.3 hereafter.<}100{>«Подпись с использованием формата multipart/signed» и рис. Е.3 ниже.<0}

{0>An example of signed data encoded using this approach is:<}100{>Пример подписанных данных, закодированных с использованием этого подхода:<0}

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



{0>With this second approach, the signed data passes through the CMS process and is carried as part of a multiple-parts signed MIME structure, as illustrated in figure F.3.<}0{>При использовании второго подхода подписанные данные проходят через процесс CMS и передаются как часть подписанной составной структуры MIME, как показано на рис. Е.3.<0} {0>The CMS structure just holds the electronic signature.<}0{>Структура CMS содержит только электронную подпись.<0}



{0>

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




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

    Басты бет