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



жүктеу/скачать 2.44 Mb.
бет12/17
Дата29.02.2016
өлшемі2.44 Mb.
#34652
1   ...   9   10   11   12   13   14   15   16   17
Figure B.5:<}99{>Рисунок Б.5.<0} {0>Illustration of CAdES-A<}100{>Схема формата CAdES-A<0}

{0>B.4<}100{>Б.4<0} {0>Example Validation Sequence<}100{>Пример проверочной последовательности<0}

{0>As described earlier, the signer or initial verifier may collect all the additional data that forms the electronic signature. figure B.6 and the subsequent description describe how the validation process may build up a complete electronic signature over time.<}0{>Как было описано ранее, подписывающая сторона или первоначальная проверяющая сторона может собрать все дополнительные данные, формирующие электронную подпись. На рис. Б.6 и далее описывается, как с помощью процесса проверки можно сформировать полную электронную подпись с течением времени.<0}



{0>Figure B.6:<}99{>Рисунок Б.6.<0} {0>Illustration of a CAdES validation sequence<}67{>Схема проверочной последовательности CAdES<0}

{0>Soon after receiving the electronic signature (CAdES) from the signer (1), the digital signature value may be checked; the validation process will usually at least add a time-stamp (2), unless the signer has provided one which is trusted by the verifier.<}0{>Вскоре после получения электронной подписи (CAdES) от подписывающей стороны (1) можно проверить значение цифровой подписи. Процесс проверки обычно добавляет по крайней мере один штамп времени (2), если подписывающая сторона не предоставила штамп времени, которому доверяет проверяющая сторона.<0} {0>The validation process may also validate the electronic signature using additional data (e.g. certificates, CRL, etc.) provided by Trusted Service Providers.<}0{>В процессе проверки можно также проверить электронную подпись с использованием дополнительных данных (например, сертификатов, списка отзыва сертификатов и т.д.), предоставленных поставщиком доверенных услуг.<0} {0>When applicable, the validation process will also need to conform to the requirements specified in a signature policy.<}0{>Если это возможно, процесс проверки должен соответствовать требованиям регламента подписи.<0} {0>If the validation process is validation incomplete, then the output from this stage is the CAdES-T.<}0{>Если в процессе проверка не завершается, то результатом работы процессы является подпись CAdES-T.<0}

{0>To ascertain the validity status as Valid or Invalid and communicate that to the user (4), all the additional data required to validate the CAdES-C needs to be available (e.g. the complete certificate and revocation information).<}0{>Для подтверждения действительного или недействительного статуса и передачи этих сведений пользователю (4), все дополнительные данные, необходимые для проверки CAdES-C, должны быть доступны (например, полные данные о сертификатах и списках отзыва).<0}

{0>Once the data needed to complete validation data references (CAdES-C) is available, then the validation process should:<}0{>Когда полный набор проверочных данных (CAdES-C) становится доступен, в процессе проверки следует выполнить следующие действия:<0}

  • {0>obtain all the necessary additional certificates and revocation status information;<}0{>получить все необходимые дополнительные сертификаты и данные о статусе отзыва;<0}

  • {0>complete all the validation checks on the ES using the complete certificate and revocation information (if a time-stamp is not already present, this may be added at the same stage, combining the CAdES-T and CAdES-C processes);<}0{>завершить все проверки электронной подписи с помощью полных данных о сертификатах и информации об отзыве (если штампа времени нет, его можно добавить на этом этапе, объединив процессы формирования CAdES-T и CAdES-C);<0}

  • {0>record the complete certificate and revocation references (3);<}0{>записать полные ссылки на сертификаты и списки отзыва (3);<0}

  • {0>indicate the validity status to the user (4).<}0{>уведомить пользователя о статусе подписи (4).<0}

{0>At the same time as the validation process creates the CAdES-C, the validation process may provide and/or record the values of certificates and revocation status information used in CAdES-C (5).<}0{>В то же время, когда в процессе проверки создается подпись CAdES-C, процесс может предоставить и/или записать значения сертификатов и списков отзыва, используемые в CAdES-C (5).<0} {0>The end result is called CAdES-X Long.<}100{>Конечный результат называется CAdES-X Long.<0}

{0>This is illustrated in figure B.7.<}0{>Это показано на рис. Б.7.<0}



{0>Figure B.7:<}99{>Рисунок Б.7.<0} {0>Illustration of a CAdES validation sequence with CAdES-X Long<}0{>Схема проверочной последовательности с CAdES-X Long<0}

{0>When the validation process creates the CAdES-C, it may also create extended forms of validation data.<}0{>Когда в процессе проверки создается подпись CAdES-C, также могут создаваться расширенные формы проверочных данных.<0} {0>A first alternative is to time-stamp all data forming the CAdES-X Type 1. This is illustrated in figure B.8.<}0{>Первым вариантом является применение штампа времени ко всем данным, формируя CAdES-X Type 1. Это показано на рис. Б.8.<0}





{0>Figure B.8:<}99{>Рисунок Б.8.<0} {0>Illustration of a CAdES with eXtended validation data - CAdES-X Type 1<}66{>Схема подписи CAdES с расширенными проверочными данными (CAdES-X Type 1)<0}

{0>Another alternative is to time-stamp the certificate and revocation information references used to validate the electronic signature (but not the signature) (6).<}0{>Другим вариантом является применение штампа времени к данным о сертификатах и списках отзыва для проверки электронной подписи (но не к самой подписи) (6).<0} {0>The end result is called CAdES-X Type 2.<}83{>Конечный результат называется CAdES-X Type 2.<0}

{0>This is illustrated in figure B.9.<}99{>Это показано на рис. Б.9.<0}



{0>Figure B.9:<}99{>Рисунок Б.9.<0} {0>Illustration of a CAdES with eXtended validation data - CAdES-X Type 2<}100{>Схема подписи CAdES с расширенными проверочными данными (CAdES-X Type 2)<0}

{0>Before the algorithms used in any of the electronic signatures become or are likely to be compromised or rendered vulnerable in the future, it may be necessary to time-stamp the entire electronic signature, including all the values of th validation and user data as an ES with Archive validation data (CAdES-A) (7).<}0{>До того, как алгоритмы, используемые в какой-либо из этих электронных подписей, будут скомпрометированы или, возможно, станут уязвимыми в будущем, может понадобиться применить штамп времени ко всей электронной подписи, в том числе ко всем проверочным и пользовательским данным, и сформировать электронную подпись с архивными проверочными данными (CAdES-A) (7).<0}

{0>A CAdES-A is illustrated in figure B.10.<}100{>Подпись CAdES-A показана на рис. Б.10.<0}


{0>Figure B.10:<}99{>Рисунок Б.10.<0} {0>Illustration of a CAdES A<}80{>Схема подписи CAdES-A<0}

{0>B.5<}100{>Б.5<0} {0>Additional Optional Features<}100{>Дополнительные необязательные компоненты<0}

{0>The present document also defines additional optional features to:<}0{>В настоящем документе также определены дополнительные компоненты, используемые для следующих целей:<0}

  • {0>indicate a commitment type being made by the signer;<}0{>указание типа обязательств подписывающей стороны;<0}

  • {0>indicate the claimed time when the signature was done;<}0{>указание заявленного времени создания подписи;<0}

  • {0>indicate the claimed location of the signer;<}0{>указание заявленного местоположения подписывающей стороны;<0}

  • {0>indicate the claimed or certified role under which a signature was created;<}0{>указание заявленной или сертифицированной роли, от имени которой была создана подпись;<0}

  • {0>support counter signatures;<}0{>поддержка удостоверяющих подписей;<0}

  • {0>support multiple signatures.<}67{>поддержка множества подписей.<0}


{0>Annex C (informative):<}100{>Приложение В (справочное).<0} {0>General Description<}100{>Общее описание<0}

{0>This annex explains some of the concepts and provides the rationale for normative parts of the present document.<}0{>В данном приложении описываются концепции нормативных частей данного документа и приводится их обоснование.<0}

{0>The specification below includes a description of why and when each component of an electronic signature is useful, with a brief description of the vulnerabilities and threats and the manner by which they are countered.<}0{>Спецификация, приведенная ниже, содержит описание того, почему и когда каждый компонент электронной подписи является полезным, с кратким описанием уязвимостей и угроз, а также способов защиты от них.<0}
{0>C.1<}99{>В.1<0} {0>The Signature Policy<}100{>Регламент подписи<0}

{0>The signature policy is a set of rules for the creation and validation of an electronic signature, under which the signature can be determined to be valid.<}0{>Регламент подписи – это набор правил для создания и проверки электронной подписи, с помощью которых можно определить действительность подписи.<0} {0>A given legal/contractual context may recognize a particular signature policy as meeting its requirements.<}0{>В данном юридическом и договорном контексте под регламентом подписи может пониматься соответствие требованиям.<0} {0>A signature policy may be issued, for example, by a party relying on the electronic signatures and selected by the signer for use with that relying party.<}0{>Регламент подписи может быть выдан, например, стороной, использующей электронные подписи, и выбран подписывающей стороной для взаимодействия с первой стороной.<0} {0>Alternatively, a signature policy may be established through an electronic trading association for use amongst its members.<}0{>Или же регламент подписи может сформировать торговая ассоциация и его должны будут использовать все ее члены.<0} {0>Both the signer and verifier use the same signature policy.<}0{>Подписывающая и проверяющая стороны следуют одному регламенту подписи.<0}

{0>The signature policy may be explicitly identified or may be implied by the semantics of the data being signed and other external data, like a contract being referenced, which itself refers to a signature policy.<}0{>Регламент подписи может быть явно идентифицирован или определен неявно семантикой подписываемых данных и других внешних данных, например, договора, на который приводится ссылка и который сам ссылается на регламент подписи.<0}

{0>An explicit signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation.<}0{>У явного регламента подписи есть глобальная уникальная ссылка, которая привязана к электронной подписи подписывающей стороной при вычислении подписи.<0}

{0>The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied.<}0{>Регламент подписи должен быть доступен в читабельном виде, чтобы можно было оценить, как он выполняет требования юридического и договорного контекста, в котором он применяется.<0} {0>To facilitate the automatic processing of an electronic signature, the parts of the signature policy, which specify the electronic rules for the creation and validation of the electronic signature, also need to be comprehensively defined and in a computer-processable form.<}0{>Для реализации автоматической обработки электронной подписи те части регламента, которые определяют электронные правила создания и проверки электронной подписи, также должны быть подробно определены в виде, поддерживающем компьютерную обработку.<0}

{0>The signature policy thus includes the following:<}0{>Таким образом, регламент подписи включает в себя следующие компоненты:<0}

  • {0>rules that apply to technical validation of a particular signature;<}0{>правила, применяемые к технической проверке определенной подписи;<0}

  • {0>rules that may be implied through adoption of Certificate Policies that apply to the electronic signature (e.g. rules for ensuring the secrecy of the private signing key);<}0{>правила, которые могут неявно подразумеваться при принятии регламентов сертификатов, применяемых к электронной подписи (например, правила обеспечения секретности закрытого ключа подписи); <0}

  • {0>rules that relate to the environment used by the signer, e.g. the use of an agreed CAD (Card Accepting Device) used in conjunction with a smart card.<}0{>правила, относящиеся к среде, используемой подписывающей стороной, например, использование оговоренного устройства приема карт (CAD) вместе с пластиковой картой.<0}

{0>For example, the major rules required for technical validation can include:<}0{>Например, к числу основных правил, необходимых для технической проверки, могут относиться следующие правила:<0}

  • {0>recognized root keys or "top-level certification authorities";<}0{>признанные корневые ключи или «центры сертификации верхнего уровня»;<0}

  • {0>acceptable certificate policies (if any);<}0{>приемлемые регламенты сертификатов (если существуют);<0}

  • {0>necessary certificate extensions and values (if any);<}60{>необходимые расширения и значения сертификатов (если существуют);<0}

  • {0>the need for the revocation status for each component of the certification tree;<}0{>необходимость статуса отзыва для каждого компонента дерева сертификации;<0}

  • {0>acceptable TSAs (if time-stamp tokens are being used);<}0{>приемлемые службы штампов времени (если используются штампы времени);<0}

  • {0>acceptable organizations for keeping the audit trails with time-marks (if time-marking is being used);<}0{>приемлемые организации для хранения журналов аудита с метками времени (если используются метки времени);<0}

  • {0>acceptable AAs (if any are being used); and<}0{>приемлемые атрибутные центры (если они используются);<0}

  • {0>rules defining the components of the electronic signature that have to be provided by the signer with data required by the verifier when required to provide long-term proof.<}0{>правила, определяющие компоненты электронной подписи, которые должна предоставить подписывающая сторона, и данные, требуемые проверяющей стороной для обеспечения долгосрочной проверки подписи.<0}


{0>C.2<}100{>В.2<0} {0>Signed Information<}100{>Подписанная информация<0}

{0>The information being signed may be defined as a MIME-encapsulated message that can be used to signal the format of the content in order to select the right display or application.<}0{>Подписываемая информация может быть определена как сообщение в формате MIME, которое можно использовать для указания формата содержимого и выбора правильного способа его отображения или приложения для его обработки.<0} {0>It can be composed of formatted data, free text, or fields from an electronic form (e-form).<}0{>Информация может состоять из форматированных данных, произвольного текста или полей электронной формы (e-form).<0} {0>For example, the Adobe™ format "pdf" or the eXtensible Mark up Language (XML) may be used.<}0{>Например, может использоваться формат PDF компании Adobe™ или язык XML.<0} {0>Annex D defines how the content may be structured to indicate the type of signed data using MIME.<}0{>В приложении Г показано, как может структурироваться содержимое для указания типа подписанных данных с помощью MIME.<0}
{0>C.3<}100{>В.3<0} {0>Components of an Electronic Signature<}100{>Компоненты электронной подписи<0}

{0>C.3.1<}100{>В.3.1<0} {0>Reference to the Signature Policy<}100{>Ссылка на регламент подписи<0}

{0>When two independent parties want to evaluate an electronic signature, it is fundamental that they get the same result.<}0{>Если две независимые стороны хотят оценить электронную подпись, они обязательно должны получить одинаковый результат.<0} {0>This requirement can be met using comprehensive signature policies that ensure consistency of signature validation.<}0{>Это требование можно выполнить с помощью подробных регламентов подписей, обеспечивающих согласованность проверки подписи.<0} {0>Signature policies can be identified implicitly by the data being signed, or they can be explicitly identified using the CAdES-EPES form of electronic signature; the CAdES-EPES mandates a consistent signature policy to be used by both the signer and verifier.<}0{>Регламенты подписи могут быть определены неявно, с помощью подписываемых данных, или определены явно, с помощью формата CAdES-EPES, который требует использовать один регламент подписи проверяющей и подписывающей сторонами.<0}

{0>By signing over the Signature Policy Identifier in the CAdES-EPES, the signer explicitly indicates that he or she has applied the signature policy in creating the signature.<}0{>Подписывая идентификатор регламента подписи в CAdES-EPES, подписывающая сторона явно указывает, что она применила регламент подписи при ее создании.<0}

{0>In order to unambiguously identify the details of an explicit signature policy that is to be used to verify a CAdES-EPES, the signature, an identifier, and hash of the "Signature policy" is part of the signed data.<}0{>Для однозначного определения сведений о явном регламенте подписи, который должен использоваться для проверки подписи CAdES-EPES, подпись, идентификатор и хэш-значение регламента подписи должны входить в число подписываемых данных.<0} {0>Additional information about the explicit policy (e.g. web reference to the document) may be carried as "qualifiers" to the Signature Policy Identifier.<}0{>Дополнительные сведения о явном регламенте (например, ссылка на документ в Интернете) могут передаваться как «квалификаторы» для идентификатора регламента подписи.<0}

{0>In order to unambiguously identify the authority responsible for defining an explicit signature policy, the "Signature policy" can be signed.<}0{>Для однозначного определения уполномоченного лица, отвечающего за определение явного регламента подписи, можно подписать регламент подписи.<0}

{0>C.3.2<}0{>В.3.2<0} {0>Commitment Type Indication<}100{>Указание вида обязательств<0}

{0>The commitment type can be indicated in the electronic signature either:<}0{>Тип обязательств можно указать в электронной подписи двумя способами:<0}

  • {0>explicitly using a "commitment type indication" in the electronic signature;<}0{>явно используя атрибут commitment-type-indication в электронной подписи;<0}

  • {0>implicitly or explicitly from the semantics of the signed data.<}0{>определив, явно или неявно, из семантики подписываемых данных.<0}

{0>If the indicated commitment type is explicit using a "commitment type indication" in the electronic signature, acceptance of a verified signature implies acceptance of the semantics of that commitment type.<}0{>Если тип обязательства указан явно с помощью соответствующего атрибута в электронной подписи, принятие проверенной подписи подразумевает принятие семантики этого типа обязательства.<0} {0>The semantics of explicit commitment type indications may be subject to signer and verifier agreement, specified as part of the signature policy, or registered for generic use across multiple policies.<}0{>Семантика явного указания типа обязательства может быть предметом договора между подписывающей и проверяющей стороной, может быть указана как часть регламента подписи или зарегистрирована для общего использования во множестве регламентов.<0}

{0>If a CAdES-EPES electronic signature format is used and the electronic signature includes a commitment type indication other than one of those recognized under the signature policy, the signature is treated as invalid.<}0{>Если используется формат электронной подписи CAdES-EPES и электронная подпись содержит указание типа обязательства, нераспознаваемое регламентом подписи, подпись считается недействительной.<0}

{0>How commitment is indicated using the semantics of the data being signed is outside the scope of the present document.<}0{>Сведения о том, как обязательства указываются с помощью семантики подписываемых данных, выходят за рамки данного документа.<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>Examples of commitment indicated through the semantics of the data being signed are:<}0{>Примеры обязательств, указанных с помощью семантики подписываемых данных:<0}

  • {0>an explicit commitment made by the signer indicated by the type of data being signed over.<}0{>явное обязательство, взятое на себя подписывающей стороной и указанное типом подписываемых данных;<0} {0>Thus, the data structure being signed can have an explicit commitment within the context of the application (e.g. EDIFACT purchase order);<}0{>таким образом, структура подписываемых данных может содержать явное обязательство в контексте приложения (например, заказ на покупку по стандарту EDIFACT);<0}

  • {0>an implicit commitment that is a commitment made by the signer because the data being signed over has specific semantics (meaning), which is only interpretable by humans (i.e. free text).<}0{>неявное обязательство, взятое на себя подписывающей стороной, так как подписываемые данные обладали определенной семантикой (значением), которая может быть интерпретирована только человеком (т. е. произвольный текст).<0}

{0>C.3.3<}0{>В.3.3<0} {0>Certificate Identifier from the Signer<}100{>Идентификатор сертификата от подписывающей стороны<0}

{0>In many real-life environments, users will be able to get from different CAs or even from the same CA, different certificates containing the same public key for different names.<}0{>Во многих реальных средах пользователи могут получить от разных центров сертификации и даже от одного центра сертификации разные сертификаты с одинаковым открытым ключом для различных имен.<0} {0>The prime advantage is that a user can use the same private key for different purposes.<}0{>Основное преимущество состоит в том, что пользователь может применять один закрытый ключ для разных целей.<0} {0>Multiple use of the private key is an advantage when a smart card is used to protect the private key, since the storage of a smart card is always limited.<}0{>Многократное использование закрытого ключа является преимуществом, если пластиковая карта применяется для защиты закрытого ключа, так как объем хранилища карты всегда ограничен.<0} {0>When several CAs are involved, each different certificate may contain a different identity, e.g. as a citizen of a nation or as an employee from a company.<}0{>Если используются несколько центров сертификации, каждый сертификат может содержать отдельное удостоверение, например гражданина страны или сотрудника компании.<0} {0>Thus, when a private key is used for various purposes, the certificate is needed to clarify the context in which the private key was used when generating the signature.<}0{>Таким образом, если закрытый ключ используется для разных целей, сертификат нужен для разъяснения контекста, в котором закрытый ключ использовался при создании подписи.<0} {0>Where there is the possibility that multiple private keys are used, it is necessary for the signer to indicate to the verifier the precise certificate to be used.<}0{>Если есть возможность использования нескольких закрытых ключей, подписывающая сторона должна указать проверяющей стороне конкретный используемый сертификат.<0}

{0>Many current schemes simply add the certificate after the signed data and thus are vulnerable to substitution attacks.<}0{>Многие текущие схемы просто добавляют сертификат после подписанных данных и, следовательно, уязвимы для атак подмены.<0} {0>If the certificate from the signer was simply appended to the signature and thus not protected by the signature, anyone could substitute one certificate for another, and the message would appear to be signed by someone else.<}0{>Если сертификат от подписывающей стороны просто добавлен к подписи и не защищен подписью, то кто угодно может заменить его на другой сертификат, при этом будет казаться, что сообщение подписано кем-то другим.<0} {0>In order to counter this kind of attack, the identifier of the signer has to be protected by the digital signature from the signer.<}0{>Для защиты от такого типа атак идентификатор подписывающей стороны должен быть защищен цифровой подписью.<0}

{0>In order to unambiguously identify the certificate to be used for the verification of the signature, an identifier of the certificate from the signer is part of the signed data.<}0{>Для однозначной идентификации сертификата, используемого для проверки подписи, идентификатор сертификата от подписывающей стороны должен входить в подписываемые данные.<0}

{0>C.3.4<}0{>В.3.4<0} {0>Role Attributes<}100{>Атрибуты роли<0}

{0>While the name of the signer is important, the position of the signer within a company or an organization is of paramount importance as well.<}0{>Несмотря на значимость имени подписывающей стороны, должность этой стороны в компании или организации не менее важна.<0} {0>Some information (i.e. a contract) may only be valid if signed by a user in a particular role, e.g. a Sales Director.<}0{>Определенная информация (например, договор) может быть действительна, только если она подписана стороной с определенной ролью, например, директором по продажам.<0} {0>In many cases, who the sales Director really is, is not that important, but being sure that the signer is empowered by his company to be the Sales Director is fundamental.<}0{>Во многих случаях не важно, кто является директором по продажам, но важна уверенность в том, что компания предоставила подписывающей стороне полномочия директора по продажам.<0}

{0>The present document defines two different ways for providing this feature:<}0{>В настоящем документе определены два способа реализации такой функциональности:<0}

  • {0>by placing a claimed role name in the CMS signed attributes field;<}0{>за счет размещения заявленного имени роли в поле подписанных атрибутов CMS;<0}

  • {0>by placing an attribute certificate containing a certified role name in the CMS signed attributes field.<}67{>за счет размещения атрибута с сертифицированным именем роли в поле подписанных атрибутов CMS.<0}

{0>NOTE:<}100{>ПРИМЕЧАНИЕ.<0} {0>Another possible approach would have been to use additional attributes containing the roles name(s) in the signer's identity certificate.<}0{>Другой возможный подход заключается в использовании дополнительных атрибутов с именами ролей в сертификате удостоверения подписывающей стороны.<0} {0>However, it was decided not to follow this approach as it significantly complicates the management of certificates.<}0{>Однако было принято решение не использовать этот подход, так как он значительно усложняет управление сертификатами.<0} {0>For example, by using separate certificates for the signer's identity and roles means new identity keys need not be issued if a user's role changes.<}0{>Например, при использовании отдельных сертификатов для удостоверения и ролей подписывающей стороны нет необходимости выдавать новые ключи удостоверения при изменении роли пользователя.<0}

{0>C.3.4.1<}0{>В.3.4.1<0} {0>Claimed Role<}100{>Заявленная роль<0}

{0>The signer may be trusted to state his own role without any certificate to corroborate this claim; in which case, the claimed role can be added to the signature as a signed attribute.<}0{>Подписывающей стороне можно доверить указывать собственную роль без какого-либо сертификата, ее подтверждающего. В этом случае заявленную роль можно добавить в подпись как подписанный атрибут.<0}

{0>C.3.4.2<}0{>В.3.4.2<0} {0>Certified Role<}100{>Сертифицированная роль<0}

{0>Unlike public key certificates that bind an identifier to a public key, Attribute Certificates bind the identifier of a certificate to some attributes, like a role.<}0{>В отличие от сертификатов открытых ключей, привязывающих идентификатор к открытыму ключу, атрибутные сертификаты привязывают идентификатор сертификата к определенным атрибутам, таким как роль.<0} {0>An Attribute Certificate is NOT issued by a CA but by an Attribute Authority (AA).<}0{>Атрибутный сертификат выдается НЕ центром сертификации (CA), а атрибутным центром (AA).<0} {0>The Attribute Authority, in most cases, might be under the control of an organization or a company that is best placed to know which attributes are relevant for which individual.<}0{>В большинстве случаев атрибутный центр может находиться под контролем организации или компании, которая лучше всех осведомлена о том, какие атрибуты относятся к каким лицам.<0} {0>The Attribute Authority may use or point to public key certificates issued by any CA, provided that the appropriate trust may be placed in that CA.<}0{>Атрибутный центр может использовать сертификаты открытых ключей, выданные любым центром сертификации, или указывать на них, если соответствующее отношение доверия может быть установлено с этим центром сертификации.<0} {0>Attribute Certificates may have various periods of validity.<}0{>У атрибутных сертификатов могут быть различные периоды действия.<0} {0>That period may be quite short, e.g. one day.<}0{>Эти периоды могут быть довольно короткими, например, длиться один день.<0} {0>While this requires that a new Attribute Certificate be obtained every day, valid for that day, this can be advantageous since revocation of such certificates may not be needed.<}0{>Хотя в этом случае необходимо получать новый атрибутный сертификат каждый день, здесь тоже есть свои преимущества, так как отзыв таких сертификатов может не требоваться.<0} {0>When signing, the signer will have to specify which Attribute Certificate it selects.<}0{>При подписании данных подписывающая сторона должна будет указать, какой атрибутный сертификат она выбирает.<0} {0>In order to do so, the Attribute Certificate will have to be included in the signed data in order to be protected by the digital signature from the signer.<}0{>Для этого атрибутный сертификат нужно будет включить в подписываемые данные, чтобы обеспечить защиту цифровой подписью подписывающей стороной.<0}

{0>In order to unambiguously identify the attribute certificate(s) to be used for the verification of the signature, an identifier of the attribute certificate(s) from the signer is part of the signed data.<}87{>Для однозначной идентификации атрибутных сертификатов, используемых для проверки подписи, идентификатор атрибутных сертификатов от подписывающей стороны должен входить в подписываемые данные.<0}

{0>C.3.5<}0{>В.3.5<0} {0>Signer Location<}100{>Местоположение подписывающей стороны<0}

{0>In some transactions, the purported location of the signer at the time he or she applies his signature may need to be indicated.<}0{>В некоторых транзакциях может потребоваться указать местоположение подписывающей стороны во время применения подписи.<0} {0>For this reason, an optional location indicator can be included.<}0{>Поэтому в подпись может быть включен дополнительный индикатор местоположения.<0}

{0>In order to provide indication of the location of the signer at the time he or she applied his signature, a location attribute may be included in the signature.<}0{>Для указания местоположения подписывающей стороны во время применения подписи в нее может быть включен соответствующий атрибут (location).<0}

{0>C.3.6<}0{>В.3.6<0} {0>Signing Time<}100{>Время подписания<0}

{0>The present document provides the capability to include a claimed signing time as an attribute of an electronic signature.<}0{>Данный документ предоставляет возможность включать заявленное время подписания как атрибут электронной подписи.<0}

{0>Using this attribute, a signer may sign over a time that is the claimed signing time.<}0{>С помощью этого атрибута подписывающая сторона может указать заявленное время подписания.<0} {0>When an ES with Time is created (CAdES-T), then either a trusted time-stamp is obtained and added to the ES or a trusted time-mark exists in an audit trail.<}0{>При создании электронной подписи со временем (CAdES-T) доверенный штамп времени извлекается и добавляется в электронную подпись, или же журнал аудита содержит доверенную метку времени.<0} {0>When a verifier accepts a signature, he can check the two times are within acceptable limits.<}0{>Когда проверяющая сторона принимает подпись, она может проверить, входят ли указанные значения времени в приемлемые границы.<0}

{0>A further optional attribute is defined in the present document to time-stamp the content and to provide proof of the existence of the content, at the time indicated by the time-stamp token.<}0{>Еще один необязательный атрибут определен в данном документе для применения штампа времени к содержимому и предоставления доказательства существования содержимого на момент, указанный штампом времени.<0}

{0>Using this optional attribute, a trusted secure time may be obtained before the document is signed and included under the digital signature.<}0{>С помощью этого атрибута перед подписанием документа можно получить доверенное время и включить его в цифровую подпись.<0} {0>This solution requires an online connection to a trusted time-stamping service before generating the signature and may not represent the precise signing time, since it can be obtained in advance.<}0{>Для этого требуется подключиться к службе штампов времени до создания подписи, при этом значение времени может представлять собой неточное время подписи, так как оно может быть получено заранее.<0} {0>However, this optional attribute may be used by the signer to prove that the signed object existed before the date included in the time-stamp (see clause 5.11.4).<}0{>Однако этот необязательный атрибут может использоваться подписывающей стороной, чтобы доказать, что подписанный объект существовал до даты, указанной в штампе времени (см. пункт 5.11.4).<0}

{0>C.3.7<}0{>В.3.7<0} {0>Content Format<}100{>Формат содержимого<0}

{0>When presenting signed data to a human user, it may be important that there is no ambiguity as to the presentation of the signed information to the relying party.<}0{>При представлении подписанных данных пользователю (человеку) важно отсутствие неоднозначности, как и при представлении подписанной информации проверяющей стороне.<0} {0>In order for the appropriate representation (text, sound, or video) to be selected by the relying party when data (as opposed to data that has been further signed or encrypted) is encapsulated in the SignedData (indicated by the eContentType within EncapsulatedContentInfo being set to id-data), further typing information should be used to identify the type of document being signed.<}0{>Для выбора адекватного представления данных (в виде текста, звука или видео) проверяющей стороной, когда данные (в отличие от данных, которые в дальнейшем подписываются или шифруются) встраиваются в структуру SignedData (если значение eContentType в поле EncapsulatedContentInfo равно id-data), следует использовать следующую информацию для определения типа подписываемого документа.<0} {0>This is generally achieved using the MIME content typing and encoding mechanism defined in RFC 2045 [6]).<}0{>В большинстве случаев для этого применяется типизация содержимого и механизм кодирования MIME, определенные в документе RFC 2045 [6]).<0} {0>Further information on the use of MIME is given in annex F.<}0{>Дополнительные сведения об использовании формата MIME представлены в приложении Е.<0}

{0>C.3.8<}0{>В.3.8<0} {0>content-hints<}100{>Атрибут content-hints<0}

{0>The contents-hints attribute provides information on the innermost signed content of a multi-layer message where one content is encapsulated in another.<}99{>Атрибут content-hints предоставляет сведения о наиболее глубоко вложенном подписанном содержимом многоуровневого сообщения, в котором одно содержимое встроено в другое.<0} {0>This may be useful if the signed data is itself encrypted.<}0{>Это может быть полезно, если подписанные данные зашифрованы.<0}

{0>C.3.9<}0{>В.3.9<0} {0>Content Cross-Referencing<}100{>Перекрестные ссылки на содержимое<0}

{0>When presenting a signed data is in relation to another signed data, it may be important to identify the signed data to which it relates.<}0{>При представлении подписанных данных в отношении других подписанных данных может быть необходимо определить связь между ними.<0} {0>The content-reference and content-identifier attributes, as defined in ESS (RFC 2634 [5]), provide the ability to link a request and reply messages in an exchange between two parties.<}65{>Атрибуты content-reference и content-identifier, как определено в ESS (RFC 2634 [5]), предоставляют способ привязки сообщений запроса и ответа при обмене данными между двумя сторонами.<0}
{0>C.4<}0{>В.4<0} {0>Components of Validation Data<}100{>Компоненты проверочных данных<0}

{0>C.4.1<}0{>В.4.1<0} {0>Revocation Status Information<}100{>Информация о статусе отзыва<0}

{0>A verifier will have to ascertain that the certificate of the signer was valid at the time of the signature.<}0{>Проверяющая сторона должна убедиться, что сертификат подписывающей стороны был действителен во время создания подписи.<0} {0>This can be done by either:<}0{>Этого можно добиться следующими способами:<0}

  • {0>using Certificate Revocation Lists (CRLs);<}73{>с помощью списков отзыва сертификатов (CRL);<0}

  • {0>using responses from an online certificate status server (for example, obtained through the OCSP protocol).<}0{>с помощью ответов от службы проверки статуса сертификатов в реальном времени (например, полученных по протоколу OCSP).<0}

{0>NOTE 1:<}100{>ПРИМЕЧАНИЕ 1.<0} {0>The time of the signature may not be known, so time-stamping or time-marking may be used to provide the time indication of when it was known that the signature existed.<}100{>Время подписи может быть неизвестно, поэтому штампы или метки времени могут использоваться для указания момента времени, когда подпись существовала.<0}

{0>NOTE 2:<}100{>ПРИМЕЧАНИЕ 2.<0} {0>When validating an electronic signature and checking revocation status information, if a "grace period" is required, it needs to be suitably long enough to allow the involved authority to process a "last-minute" revocation request and for the request to propagate through the revocation system.<}0{>Если при проверке электронной подписи и данных о статусе отзыва необходим период отсрочки, он должен быть достаточно длительным, чтобы соответствующая служба смогла обработать последний запрос на отзыв сертификата, а запрос распространился в системе отзыва.<0} {0>This grace period is to be added to the time included with the time-stamp token or the time-mark and thus the revocation status information should be captured after the end of the grace period.<}0{>Этот период отсрочки должен добавляться ко времени, указанному в штампе или метке времени, и, следовательно, данные о статусе отзыва должны быть получены после завершения периода отсрочки.<0}

{0>C.4.1.1<}0{>В.4.1.1<0} {0>CRL Information<}100{>Сведения CRL<0}

{0>When using CRLs to get revocation information, a verifier will have to make sure that he or she gets, at the time of the first verification, the appropriate certificate revocation information from the signer's CA.<}0{>При использовании списков отзыва сертификатов для получения сведений об отозванных сертификатах проверяющая сторона должна убедиться, что на момент первой проверки она получает эти сведения от центра сертификации подписывающей стороны.<0} {0>This should be done as soon as possible to minimize the time delay between the generation and verification of the signature.<}0{>Это должно быть сделано в кратчайшие сроки для минимизации задержки между созданием и проверкой подписи.<0} {0>However, a "grace period" is required to allow CAs time to process revocation requests.<}0{>Однако для того, чтобы центры сертификации обработали запросы на отзыв сертификатов, требуется период отсрочки.<0} {0>For example, a revocation request may arrive at a CA just before issuing the next CRL, and there may not enough time to include the revised revocation status information.<}0{>Например, запрос на отзыв может поступить в центр сертификации как раз перед выдачей следующего списка отзыва сертификатов, а времени на включение обновленной информации об отозванных сертификатах может быть недостаточно.<0} {0>This involves checking that the signer certificate serial number is not included in the CRL.<}0{>Этот процесс также включает проверку того, что серийный номер сертификата подписывающей стороны не включен в список отзыва сертификатов.<0} {0>Either the signer, the initial verifier, or a subsequent verifier may obtain this CRL.<}0{>Как подписывающая сторона, так и первоначальная проверяющая сторона или последующая проверяющая сторона могут получить этот список.<0} {0>If obtained by the signer, then it is conveyed to the verifier.<}0{>Если список получает подписывающая сторона, то он передается проверяющей стороне.<0} {0>It may be convenient to archive the CRL for ease of subsequent verification or arbitration.<}0{>Для упрощения последующей проверки или арбитража можно заархивировать список отзыва сертификатов.<0} {0>Alternatively, provided the CRL is archived elsewhere, which is accessible for the purpose of arbitration, then the serial number of the CRL used may be archived together with the verified electronic signature as a CAdES-C form.<}0{>Или же, если список заархивирован в другом месте, что допустимо для арбитража, серийный номер использованного списка может быть заархивирован вместе с проверенной электронной подписью в формате CAdES-C.<0}

{0>Even if the certificate serial number appears in the CRL with the status "suspended" (i.e. on hold), the signature is not to be deemed as valid since a suspended certificate is not supposed to be used even by its rightful owner.<}0{>Даже если серийный номер сертификата есть в списке отзыва со статусом «приостановлен» (suspended), подпись не должна считаться действительной, так как приостановленный сертификат не должен использоваться даже своим полноправным владельцем.<0}

{0>C.4.1.2<}0{>В.4.1.2<0} {0>OCSP Information<}100{>Сведения OCSP<0}

{0>When using OCSP to get revocation information, a verifier will have to make sure that he or she gets, at the time of the first verification, an OCSP response that contains the status "valid".<}74{>При использовании службы OCSP для получения сведений об отозванных сертификатах проверяющая сторона должна убедиться, что на момент первой проверки она получает ответ OCSP с действительным статусом.<0} {0>This should be done as soon as possible after the generation of the signature, still providing a "grace period" suitable enough to allow the involved authority to process a "last-minute" revocation request.<}0{>Это должно быть сделано в кратчайшие сроки после создания подписи, но при этом должен быть предоставлен период отсрочки, достаточный для того, чтобы соответствующая служба смогла обработать последние запросы на отзыв сертификата.<0} {0>The signer, the verifier, or any other third party may fetch this OCSP response.<}0{>Подписывающая, проверяющая или третья сторона могут получить этот ответ OCSP.<0} {0>Since OCSP responses are transient and thus are not archived by any TSP, including CA, it is the responsibility of every verifier to make sure that it is stored in a safe place.<}0{>Так как ответы OCSP являются временными и не архивируются поставщиками доверенных услуг, в том числе центром сертификации, каждая проверяющая сторона должна убедиться, что они хранятся в надежном месте.<0} {0>The simplest way is to store them associated with the electronic signature.<}0{>Проще всего сохранить их с привязкой к электронной подписи.<0} {0>An alternative would be to store them so that they can then be easily retrieved and incorporate references to them in the electronic signature itself as a CAdES-C form.<}0{>Альтернативный метод – хранить ответы OCSP так, чтобы их можно было легко извлекать и встраивать ссылки на них в электронную подпись формата CAdES-C.<0}

{0>In the same way as for the case of the CRL, it may happen that the certificate is declared as invalid but with the secondary status "suspended".<}0{>Так же, как и при использовании списка отзыва сертификатов, сертификат может быть объявлен недействительным, но с дополнительным статусом «приостановлен» (suspended).<0} {0>In such a case, the same comment as for the CRL applies.<}0{>В этом случае применим такой же комментарий, что и для списка отзыва сертификатов.<0}

{0>C.4.2<}0{>В.4.2<0} {0>Certification Path<}100{>Путь сертификации<0}

{0>A verifier may have to ascertain that the certification path was valid, at the time of the signature, up to a trust point, according to the:<}0{>Проверяющей стороне может потребоваться убедиться в действительности пути сертификации на момент создания подписи вплоть до точки доверия в соответствии с:<0}

  • {0>naming constraints;<}0{>ограничениями именования;<0}

  • {0>certificate policy constraints;<}0{>ограничениями регламента сертификата;<0}

  • {0>signature policy, when applicable.<}0{>регламентом подписи, если он применим.<0}

{0>Since the time of the signature cannot be known with certainty, an upper limit of it should be used as indicated by either the time-stamp or time-mark.<}0{>Так как время подписи нельзя знать точно, следует использовать верхний предел времени, указанный штампом или меткой времени.<0}

{0>In this case, it will be necessary to capture all the certificates from the certification path, starting with those from the signer and ending up with those of the self-signed certificate from one trusted root; when applicable, this may be specified as part of the Signature Policy.<}0{>В этом случае необходимо получить все сертификаты в пути сертификации, начиная с сертификатов подписывающей стороны и заканчивая самозаверенным сертификатом доверенного корневого центра сертификации. Если это возможно, эти сведения указываются как часть регламента подписи.<0} {0>In addition, it will be necessary to capture the Certificate Authority Revocation Lists (CARLs) to prove that none of the CAs from the chain was revoked at the time of the signature.<}0{>Кроме того, необходимо получить списки отзыва центров сертификации (CARL), чтобы доказать, что ни один из центров сертификации из цепочки не был отозван на момент создания подписи.<0} {0>Again, all this material may be incorporated in the electronic signature (ES X forms).<}0{>Опять же, весь этот материал может быть встроен в электронную подпись (формы ES X).<0} {0>An alternative would be to store this information so that it can be easily retrieved and incorporate references to it in the electronic signature itself as a CAdES-C form.<}84{>Альтернативой может быть хранение этих данных так, чтобы их можно было легко извлекать и встраивать ссылки на них в электронную подпись формата CAdES-C.<0}

{0>C.4.3<}0{>В.4.3<0} {0>Time-Stamping for Long Life of Signatures<}100{>Штампы времени для долгосрочного использования подписей<0}

{0>An important property for long-standing signatures is that a signature, having been found once to be valid, will continue to be so months or years later.<}0{>Важным свойством долгосрочных подписей является то, если подпись была признана действительной, она будет оставаться действительной через несколько месяцев и даже лет.<0}

{0>A signer, verifier, or both may be required to provide, on request, proof that a digital signature was created or verified during the validity period of all the certificates that make up the certificate path.<}0{>У подписывающей стороны, проверяющей стороны или обеих этих сторон могут потребовать доказательство того, что цифровая подпись была создана или проверена в течение периода действия всех сертификатов, составляющих путь сертификации.<0} {0>In this case, the signer, verifier, or both will also be required to provide proof that the signer's certificate and all the CA certificates used to form a valid certification path were not revoked when the signature was created or verified.<}0{>В этом случае подписывающая сторона, проверяющая сторона или обе эти стороны также должны будут предоставить доказательство того, что сертификат подписывающей стороны и все сертификаты центра сертификации, используемые для формирования действительной цепочки сертификации, не были отозваны на момент времени создания или проверки подписи.<0}

{0>It would be quite unacceptable to consider a signature as invalid even if the keys or certificates were later compromised.<}0{>Будет крайне трудно признать подпись недействительной, даже если использованные ключи или сертификаты были скомпрометированы в дальнейшем.<0} {0>Thus, there is a need to be able to demonstrate that the signature keys were valid at the time that the signature was created to provide long-term evidence of the validity of a signature.<}0{>Таким образом, существует необходимость иметь возможность продемонстрировать, что ключи подписи были действительны на момент ее создания, чтобы предоставить долгосрочное свидетельство действительности подписи.<0}

{0>It could be the case that a certificate was valid at the time of the signature but revoked some time later.<}0{>Может возникнуть ситуация, когда сертификат был действителен на момент создания подписи, но был отозван после этого.<0} {0>In this event, evidence will be provided that the document was signed before the signing key was revoked.<}0{>В таком случае должно быть предоставлено доказательство того, что документ был подписан до отзыва ключа подписи.<0} {0>Time-stamping by a Time-Stamping Authority (TSA) can provide such evidence.<}0{>Такое доказательство можно получить с помощью штампов времени от службы штампов времени (TSA).<0} {0>A time-stamp is obtained by sending the hash value of the given data to the TSA.<}0{>Штамп времени формируется за счет отправки хэш-значения указанных данных в службу штампов времени.<0} {0>The returned "time-stamp" is a signed document that contains the hash value, the identity of the TSA, and the time of stamping.<}0{>Возвращенный «штамп времени» – это подписанный документ, содержащий это хэш-значение, удостоверение службы штампов времени и время применения штампа.<0} {0>This proves that the given data existed before the time of stamping.<}0{>Это доказывает, что указанные данные существовали до применения штампа времени.<0} {0>Time-stamping a digital signature (by sending a hash of the signature to the TSA) before the revocation of the signer's private key provides evidence that the signature had been created before the certificate was revoked.<}0{>Применение штампа времени к цифровой подписи (за счет отправки хэш-значения службе штампов времени) перед отзывом закрытого ключа подписывающей стороны позволяет предоставить доказательство того, что подпись была создана до отзыва сертификата.<0}

{0>If a recipient wants to hold a valid electronic signature, he will have to ensure that he has obtained a valid time-stamp for it before that key (and any key involved in the validation) is revoked.<}0{>Если получатель хочет принять действительную электронную подпись, он должен убедиться, что получил действительный штамп времени подписи до отзыва этого ключа (и любого другого ключа, используемого для проверки).<0} {0>The sooner the time-stamp is obtained after the signing time, the better.<}0{>Чем быстрее будет получен штамп времени после времени создания подписи, тем лучше.<0} {0>Any time-stamp or time-mark that is taken after the expiration date of any certificate in the certification path has no value in proving the validity of a signature.<}0{>Любой штамп времени или любая метка времени, созданная после истечения срока действия любого сертификата в пути сертификации, не имеет ценности для доказательства действительности подписи.<0}

{0>It is important to note that signatures may be generated "off-line" and time-stamped at a later time by anyone, for example, by the signer or any recipient interested in the value of the signature.<}0{>Следует отметить, что подписи могут быть созданы в автономном режиме, а штампы времени могут быть применены кем угодно в дальнейшем, например подписывающей стороной или любым получателем, заинтересованным в действительности подписи.<0} {0>The time-stamp can thus be provided by the signer, together with the signed document, or obtained by the recipient following receipt of the signed document.<}0{>Таким образом, можно предоставить штамп времени подписывающей стороне вместе с подписанным документом, или же он будет принят получателем после получения подписанного документа.<0}

{0>The time-stamp is NOT a component of the Basic Electronic Signature, but it is the essential component of the ES with Time.<}0{>Штамп времени НЕ ЯВЛЯЕТСЯ компонентом простой электронной подписи, но при этом он является важным компонентом электронной подписи со значением времени.<0}

{0>It is required, in the present document, that if a signer's digital signature value is to be time-stamped, the time-stamp token is issued by a trusted source, known as a Time-Stamping Authority.<}0{>В соответствии с данным документом при применении штампа времени к цифровой подписи подписывающей стороны штамп времени выдается доверенным источником, который называют службой штампов времени.<0}

{0>The present document requires that the signer's digital signature value be time-stamped by a trusted source before the electronic signature can become an ES with Complete validation data.<}0{>Согласно данному документу, для того, чтобы электронная подпись стала считаться подписью с полными проверочными данными, к цифровой подписи должен быть применен штамп времени от доверенного источника.<0} {0>Acceptable TSAs may be specified in a Signature Validation Policy.<}0{>Допустимые службы штампов времени могут быть указаны в регламенте проверки подписи.<0}

{0>This technique is referred to as
жүктеу/скачать 2.44 Mb.

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



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