Network Working Group D. Pinkas
Request for Comments: 3126 Integris
Category: Informational J. Ross
N. Pope
Security & Standards
September 2001
Electronic Signature Formats
for long term electronic signatures
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature).
この文書では、長期間にわたって有効であり続けることができる電子署名の形式を定義します。これは、署名者又は検証当事者は後（すなわち、署名の妥当性をrepudiates）拒否しようとしても、その有効性に関して証拠を含みます。
The format can be considered as an extension to RFC 2630 and RFC 2634, where, when appropriate additional signed and unsigned attributes have been defined.
フォーマットは、適切な追加の符号付きおよび符号なしの属性が定義されている、RFC 2630及びRFC 2634の拡張として考えることができます。
The contents of this Informational RFC is technically equivalent to ETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org
この情報のRFCの内容は、ETSI TS 101 733 V.1.2.2に技術的に同等です。 ETSI TSは、ETSIの著作権（C）の下にあります。このETSIの成果の個々のコピーがhttp://www.etsi.orgからダウンロードすることができます
Table of Contents
目次
1. Introduction 4 2 Overview 5 2.1 Aim 5 2.2 Basis of Present Document 5 2.3 Major Parties 6 2.4 Electronic Signatures and Validation Data 7 2.5 Forms of Validation Data 8 2.6 Extended Forms of Validation Data 11 2.7 Archive Validation Data 13 2.8 Arbitration 15 2.9 Validation Process 15 2.10 Example Validation Sequence 16 2.11 Additional optional features 21 3. Data structure of an Electronic Signature 22 3.1 General Syntax 22 3.2 Data Content Type 22 3.3 Signed-data Content Type 22 3.4 SignedData Type 22 3.5 EncapsulatedContentInfo Type 23 3.6 SignerInfo Type 23 3.6.1 Message Digest Calculation Process 23 3.6.2 Message Signature Generation Process 24 3.6.3 Message Signature Verification Process 24 3.7 CMS Imported Mandatory Present Attributes 24 3.7.1 Content Type 24 3.7.2 Message Digest 24 3.7.3 Signing Time 24 3.8 Alternative Signing Certificate Attributes 24 3.8.1 ESS Signing Certificate Attribute Definition 25 3.8.2 Other Signing Certificate Attribute Definition 25 3.9 Additional Mandatory Attributes 26 3.9.1 Signature policy Identifier 26 3.10 CMS Imported Optional Attributes 28 3.10.1 Countersignature 29 3.11 ESS Imported Optional Attributes 29 3.11.1 Content Reference Attribute 29 3.11.2 Content Identifier Attribute 29 3.11.3 Content Hints Attribute 29 3.12 Additional Optional Attributes 30 3.12.1 Commitment Type Indication Attribute 30 3.12.2 Signer Location attribute 32 3.12.3 Signer Attributes attribute 33 3.12.4 Content Time-Stamp attribute 34 3.13 Support for Multiple Signatures 34 3.13.1 Independent Signatures 34 3.13.2 Embedded Signatures 34
1.はじめに4 2概要5 2.1目的本明細書の5つの2.2基礎5つの2.3主要政党6人の2.4電子署名及び検証データの検証データの検証データ8つの2.6拡張フォーム11 2.7アーカイブの検証の7 2.5構成するデータ13 2.8仲裁15 2.9バリデーション電子署名の21 3.データ構造22 3.1一般的な構文22 3.2データコンテンツタイプ22 3.3符号付きデータのコンテンツタイプ22は、3.4のSignedDataタイプ22 3.5 EncapsulatedContentInfoタイプ23 3.6のSignerInfoタイプ23 3.6プロセス15 2.10実施例検証シーケンス16 2.11その他のオプション機能0.1メッセージダイジェスト計算処理23 3.6.2メッセージ署名生成プロセス24 3.6.3メッセージ署名検証プロセス24 3.7 CMSインポート必須現在は24 3.7.1コンテンツの種類24 3.7.2メッセージダイジェスト24 3.7.3署名時刻24 3.8代替属性証明書は24 3.8.1 ESS署名証明書属性定義25 3.8.2その他の署名証明書の属性定義25 3.9追加の属性署名必須は26 3.9.1署名ポリシー識別子26 3.10 CMSインポートオプションは、28 3.10.1副署29 3.11 ESSインポートオプションの属性属性属性29の3.11.1コンテンツ参照属性29 3.11.2コンテンツ識別子属性29の3.11.3コンテンツのヒントは、29 3.12追加属性オプションは30 3.12.1コミットメントタイプ表示は、署名者の場所は、32の3.12.3署名者の属性は、複数の署名のための33 3.12.4コンテンツタイムスタンプ属性34 3.13サポート34人の3.13.1独立した署名は34 3.13.2組み込み属性属性30 3.12.2属性属性署名34
4. Validation Data 35 4.1 Electronic Signature Time-Stamp 36 4.1.1 Signature Time-Stamp Attribute Definition 36 4.2 Complete Validation Data 37 4.2.1 Complete Certificate Refs Attribute Definition 38 4.2.2 Complete Revocation Refs Attribute Definition 38 4.3 Extended Validation Data 40 4.3.1 Certificate Values Attribute Definition 40 4.3.2 Revocation Values Attribute Definition 41 4.3.3 ES-C Time-Stamp Attribute Definition 42 4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 42 4.4 Archive Validation Data 43 4.4.1 Archive Time-Stamp Attribute Definition 43 5. Security Considerations 44 5.1 Protection of Private Key 44 5.2 Choice of Algorithms 44 6. Conformance Requirements 45 6.1 Signer 45 6.2 Verifier using time-stamping 46 6.3 Verifier using secure records 46 7. References 47 8. Authors' Addresses 48 Annex A (normative): ASN.1 Definitions 49 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 49 A.2 Definitions Using X.680 1997 ASN.1 Syntax 57 Annex B (informative): General Description 66 B.1 The Signature Policy 66 B.2 Signed Information 67 B.3 Components of an Electronic Signature 68 B.3.1 Reference to the Signature Policy 68 B.3.2 Commitment Type Indication 69 B.3.3 Certificate Identifier from the Signer 69 B.3.4. Role Attributes 70 B.3.4.1 Claimed Role 71 B.3.4.2 Certified Role 71 B.3.5 Signer Location 72 B.3.6 Signing Time 72 B.3.7 Content Format 73 B.4 Components of Validation Data 73 B.4.1 Revocation Status Information 73 B.4.2 CRL Information 74 B.4.3 OCSP Information 74 B.4.4 Certification Path 75 B.4.5 Time-Stamping for Long Life of Signature 76 B.4.6 Time-Stamping before CA Key Compromises 77 B.4.6.1 Time-Stamping the ES with Complete validation data 77 B.4.6.2 Time-Stamping Certificates and Revocation Information 78 B.4.7 Time-Stamping for Long Life of Signature 79
4.検証データ35 4.1電子署名タイムスタンプ36 4.1.1署名タイムスタンプ属性定義36 4.2完全な検証データ37 4.2.1完全な証明書は、参考文献38本の定義4.2.2完全失効参考文献は、定義38 4.3拡張検証データ40属性属性4.3.1証明書の値は、定義40の4.3.2失効値が定義41個の4.3.3 ES-Cタイムスタンプ属性定義42 4.3.4タイムスタンプ付きの証明書およびCRLは、定義42 4.4アーカイブの検証データ43 4.4.1アーカイブ時間属性属性属性安全な、レコード46の7.参考47本の8.著者のを使用してタイムスタンプ46 6.3検証を使用したアルゴリズム44の秘密鍵44 5.2選択6.適合性要件45 6.1署名者45 6.2検証の定義43 5.セキュリティについての考慮事項44 5.1保護属性-stamp 48附属書A（規定）アドレス：ASN.1定義X.208（1988）ASN.1構文を使用した49のA.1定義X.680 1997 ASN.1構文57附属書B（参考）を使用して49のA.2定義：一般D escription 66 B.1電子署名の67のB.3コンポーネント情報署名署名ポリシー66 B.2署名者69 Bから署名ポリシー68 B.3.2コミットメントタイプ表示69 B.3.3証明書識別子に68 B.3.1参照.3.4。役割は、70 B.3.4.1主張役割を属性71 B.3.4.2認定役割71 B.3.5署名者の場所72 B.3.6署名時間72 B.3.7コンテンツフォーマットの検証データ73 B.4.1失効ステータスの73のB.4コンポーネント情報73 B.4.2 CRL情報74 B.4.3 OCSP情報74 B.4.4証明書のパスの長寿命化のための75 B.4.5タイムスタンプ署名76 B.4.6タイムスタンプCAキー妥協77 B.4.6.1時間 - 前完全な検証データ77 B.4.6.2タイムスタンプ証明書と署名79の長寿命化のための失効情報78 B.4.7タイムスタンプでESをスタンピング
B.4.8 Reference to Additional Data 80 B.4.9 Time-Stamping for Mutual Recognition 80 B.4.10 TSA Key Compromise 81 B.5 Multiple Signatures 81 Annex C (informative): Identifiers and roles 82 C.1 Signer Name Forms 82 C.2 TSP Name Forms 82 C.3 Roles and Signer Attributes 83 Full Copyright Statement 84
相互承認80 B.4.10 TSA鍵の危殆用追加データ80 B.4.9タイムスタンプへB.4.8リファレンス81人のB.5複数の署名81附属書C（参考）：識別子とロール82 C.1署名者の名前は、82 C.フォーム2 TSP名前は82のC.3の役割を形成し、署名者は83完全な著作権声明84属性
This document is intended to cover electronic signatures for various types of transactions, including business transactions (e.g., purchase requisition, contract, and invoice applications) where long term validity of such signatures is important. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates, see [ISONR]) the validity of the signature).
この文書は、そのような署名の長期的な有効性が重要である（例えば、購買依頼、契約、および請求書のアプリケーション）のビジネス取引を含む取引の様々なタイプのための電子署名をカバーすることを意図しています。これは、署名者又は検証当事者は、それ以降）（即ち、repudiates、[ISONR]参照）署名の正当性を否定しようとしても、その有効性に関して証拠を含みます。
Electronic signatures can be used for any transaction between an individual and a company, between two companies, between an individual and a governmental body, etc. This document is independent of any environment. It can be applied to any environment e.g., smart cards, GSM SIM cards, special programs for electronic signatures etc.
電子署名は、この文書では、どのような環境には依存しないなど個人や政府機関の間で、両社の間で、個人と会社との間の取引に使用することができます。これは、例えば、スマートカードは、GSM SIMカード、電子署名のための特別なプログラム等の任意の環境に適用することができます
An electronic signature produced in accordance with this document provides evidence that can be processed to get confidence that some commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role.
この文書に従って製造された電子署名は、いくつかのコミットメントを明示的識別子の下で署名者によって、与えられた時間に、署名ポリシーの下で承認されたという確信を得るために処理できる証拠を提供し、例えば、名前や仮名、そして、役割をオプションで。
The European Directive on a community framework for Electronic Signatures defines an electronic signature as: "data in electronic form which is attached to or logically associated with other electronic data and which serves as a method of authentication". An electronic signature as used in the current document is a form of advanced electronic signature as defined in the Directive.
「に付着または論理的に認証方式として機能する他の電子データに関連付けされた電子形式のデータ」：電子署名のためのコミュニティ・フレームワーク上の欧州指令は、のように電子署名を定義します。指令で定義されるように、現在のドキュメントで使用される電子署名は、高度な電子署名の形態です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、（図示のように、大文字で）この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" は可能になっています[RFC2119]で説明されるように解釈されます。
2 Overview
2概要
The aim of this document is to define an Electronic Signature (ES) that remains valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (repudiates) the validity of the signature.
このドキュメントの目的は、長期間有効なまま電子署名（ES）を定義することです。これは、署名者または検証当事者が後で（repudiates）署名の正当性を否定しようとした場合でも、その有効性に関して、証拠が含まれています。
This document specifies the use of trusted service providers (e.g., Time-Stamping Authorities (TSA)), and the data that needs to be archived (e.g., cross certificates and revocation lists) to meet the requirements of long term electronic signatures. An electronic signature defined by this document can be used for arbitration in case of a dispute between the signer and verifier, which may occur at some later time, even years later. This document uses a signature policy, referenced by the signer, as the basis for establishing the validity of an electronic signature.
この文書は、信頼できるサービスプロバイダ（例えば、タイムスタンプ局（TSA））の使用を指定し、長期電子署名の要件を満たすためにアーカイブする（例えば、クロス証明書と失効リスト）を必要とするデータ。このドキュメントによって定義された電子署名は、何年も後に、いくつかの後の時点で発生する可能性があり、署名者と検証者との間の紛争の場合に仲裁のために使用することができます。この文書は、電子署名の有効性を確立するための基礎として、署名者によって参照される署名ポリシーを使用します。
This document is based on the use of public key cryptography to produce digital signatures, supported by public key certificates.
この文書は、公開鍵証明書でサポートされているデジタル署名を生成するために、公開鍵暗号方式を使用することに基づいています。
A Public key certificate is a public keys of a user, together with some other information, rendered unforgeable by encipherment with the private key of the Certification Authority (CA) which issued it (ITU-T Recommendation X.509 [1]).
公開鍵証明書が一緒にそれを発行した認証局（CA）の秘密鍵で暗号化によって偽造は不可能にいくつかの他の情報と、利用者の公開鍵である（ITU-T勧告X.509 [1]）。
This document also specifies the uses of time-stamping services to prove the validity of a signature long after the normal lifetime of critical elements of an electronic signature and to support non-repudiation. It also, as an option, defines the use of additional time-stamps to provide very long-term protection against key compromise or weakened algorithms.
この文書はまた、長い電子署名の重要な要素の通常の寿命後に署名の正当性を証明すると否認防止をサポートするためにタイムスタンプサービスの使用を指定します。また、オプションとして、鍵の危殆化または弱体化アルゴリズムに対して非常に長期的な保護を提供するために追加のタイムスタンプの使用を定義します。
This document builds on existing standards that are widely adopted. This includes:
この文書では、広く採用されている既存の標準に基づいています。これも：
* RFC 2459 [RFC2459] Internet X.509 Public Key Infrastructure
Certificate and CRL Profile (PKIX);
* RFC 2630 [CMS] Crytographic Message Syntax (CMS);
* RFC 2634 [ESS] Enhanced Security Services (ESS);
* RFC 2439 [OCSP] One-line Certificate Status Protocol (OCSP);
* ITU-T Recommendation X.509 [1] Authentication framework;
* RFC (to be published) [TSP] PKIX Time Stamping protocol (TSP).
NOTE: See clause 8 for a full set of references.
注：参照のフルセットのための句8を参照してください。
The following are the major parties involved in a business transaction supported by electronic signatures as defined in this document:
以下は、この文書で定義されている電子署名によってサポートされるビジネス・トランザクションに関与する主要な政党です。
* the Signer;
* the Verifier;
* the Arbitrator;
* Trusted Service Providers (TSP).
A Signer is an entity that initially creates the electronic signature. When the signer digitally signs over data using the prescribed format, this represents a commitment on behalf of the signing entity to the data being signed.
署名者は、最初に電子署名を生成するエンティティです。署名者は、デジタル所定のフォーマットを使用してデータ上に署名する場合、これは、署名されるデータに署名エンティティの代わりにコミットメントを表します。
A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1 [13]). Within the context of this document this is an entity that validates an electronic signature. An arbitrator, is an entity which arbitrates disputes between a signer and a verifier when there is a disagreement on the validity of a digital signature.
検証者は、証拠を検証するエンティティです。 （ISO / IEC 13888から1 [13]）。本文書の文脈において、これは電子署名を検証するエンティティです。仲裁は、デジタル署名の有効性に不一致がある場合、署名者と検証者との間の紛争を調停エンティティです。
Trusted Service Providers (TSPs) are one or more entities that help to build trust relationships between the signer and verifier. Use of some specific TSP services MAY be mandated by signature policy. TSP supporting services may provide the following information: user certificates, cross-certificates, time-stamping tokens, CRLs, ARLs, OCSP responses.
信頼できるサービスプロバイダー（TSPのは）署名者と検証の間に信頼関係を構築するのに役立つ一つ以上のエンティティです。いくつかの特定のTSPサービスの利用には、署名ポリシーによって義務付けられるかもしれません。ユーザー証明書、クロス証明書、タイムスタンプトークン、CRLを、ARLs、OCSPの応答：TSPのサポートサービスは、以下の情報を提供することができます。
The following TSPs are used to support the validation or the verification of electronic signatures:
次のTSPは、検証や電子署名の検証をサポートするために使用されています。
* Certification Authorities;
* Registration Authorities;
* Repository Authorities (e.g., a Directory);
* Time-Stamping Authorities;
* One-line Certificate Status Protocol responders;
* Attribute Authorities;
* Signature Policy Issuers.
Certification Authorities provide users with public key certificates.
認証機関は、公開鍵証明書をユーザーに提供します。
Registration Authorities allows the registration of entities before a CA generates certificates.
CAが証明書を生成する前に、登録機関は、エンティティの登録を可能にします。
Repository Authorities publish CRLs issued by CAs, cross-certificates (i.e., CA certificates) issued by CAs, signature policies issued by Signature Policy Issuers and optionally public key certificates (i.e., leaf certificates) issued by CAs.
リポジトリ当局は、CAによって発行されたCAS、相互認証（即ち、CA証明書）、署名ポリシー発行者および必要に応じて公開鍵証明書のCAによって発行された（すなわち、リーフ証明書）によって発行された署名ポリシーによって発行されたCRLを公開します。
Time-Stamping Authorities attest that some data was formed before a given trusted time.
タイムスタンプ当局は、一部のデータが与えられ、信頼できる時間前に形成されたことを証明します。
One-line Certificate Status Protocol responders (OSCP responders) provide information about the status (i.e., revoked, not revoked, unknown) of a particular certificate.
ワンライン証明書状態プロトコルレスポンダ（OSCPレスポンダ）は、特定の証明書の状態（すなわち、取り消され、失効していない、未知の）に関する情報を提供します。
A Signature Policy Issuer issues signatures policies that define the technical and procedural requirements for electronic signature creation, validation and verification, in order to meet a particular business need.
署名ポリシー発行者は、特定のビジネスニーズを満たすために、電子署名の作成、妥当性確認及び検証のための技術的および手続き上の要件を定義する署名ポリシーを発行します。
Attributes Authorities provide users with attributes linked to public key certificates
当局は、公開鍵証明書にリンクされた属性をユーザーに提供する属性
Validation of an electronic signature in accordance with this document requires:
この文書による電子署名の検証が必要です。
* The electronic signature; this includes:
*電子署名。これも：
- the signature policy;
- the signed user data;
- the digital signature;
- other signed attributes provided by the signer;
- other unsigned attributes provided by the signer.
Validation data which is the additional data needed to validate the electronic signature; this includes:
電子署名を検証するために必要な追加データである検証データ。これも：
- certificates references;
- certificates;
- revocation status information references;
- revocation status information;
- time-stamps from Time Stamping Authorities (TSAs).
* The signature policy specifies the technical requirements on signature creation and validation in order to meet a particular business need. A given legal/contractual context may recognize a particular signature policy as meeting its requirements.
*署名ポリシーは、特定のビジネスニーズを満たすために、署名の作成と検証に関する技術的要件を指定します。与えられた法的/契約コンテキストは、その要件を満たすように特定の署名ポリシーを認識することができます。
For example: a specific signature policy may be recognized by court of law as meeting the requirements of the European Directive for electronic commerce. A signature policy may be written using a formal notation like ASN.1 or in an informal free text form provided the rules of the policy are clearly identified. However, for a given signature policy there shall be one definitive form which has a unique binary encoded value.
たとえば、次のように特定の署名ポリシーは、電子商取引のための欧州指令の要件を満たすものとして裁判所によって認識することができます。署名ポリシーはASN.1のようなまたはポリシーのルールが明確に識別される設け非公式フリーテキスト形式で正式な表記法を使用して記述することができます。しかし、与えられた署名ポリシーに一意のバイナリ符号化された値を有するもの決定的な形態が存在しなければなりません。
Signed user data is the user's data that is signed.
署名されたユーザデータが署名されたユーザーのデータです。
The Digital Signature is the digital signature applied over the following attributes provided by the signer:
デジタル署名は、署名者によって提供される以下の属性の上に適用デジタル署名です。
* hash of the user data (message digest);
* signature Policy Identifier;
* other signed attributes
The other signed attributes include any additional information which must be signed to conform to the signature policy or this document (e.g., signing time).
他の署名された属性は、署名ポリシー、またはこの文書（例えば、時間署名）に適合するように署名しなければならない任意の追加情報を含みます。
According to the requirements of a specific signature policy in use, various Validation Data shall be collected and attached to or associated with the signature structure by the signer and/or the verifier. The validation data includes CA certificates as well as revocation status information in the form of certificate revocation lists (CRLs) or certificate status information provided by an on-line service. Additional data also includes time-stamps and other time related data used to provide evidence of the timing of given events. It is required, as a minimum, that either the signer or verifier obtains a time-stamp over the signer's signature or a secure time record of the electronic signature must be maintained. Such secure records must not be undetectably modified and must record the time close to when the signature was first validated.
使用中の特定の署名ポリシーの要件に応じて、様々な検証データが収集され、取り付けられ、または、署名者及び/又は検証者によって署名構造に関連付けられなければなりません。検証データは、CA証明書と同様に、オンラインサービスによって提供される証明書失効リスト（CRL）または証明書ステータス情報の形で失効状態情報を含みます。追加データはまた、タイムスタンプおよび特定のイベントのタイミングの証拠を提供するために使用される他の時間に関連するデータを含んでいます。署名者または検証のいずれかが、署名者の署名や電子署名の安全な時間記録を超えるタイムスタンプを維持しなければならないことを取得し、最低限として、必要とされます。このような安全なレコードが検出不可能に変更してはならないと署名が最初に検証されたときに近いタイムを記録しなければなりません。
An electronic signature may exist in many forms including:
電子署名は、以下を含む多くの形態で存在することができます。
* the Electronic Signature (ES), which includes the digital signature and other basic information provided by the signer;
*デジタル署名と署名者によって提供される他の基本的な情報を含む電子署名（ES）。
* the ES with Time-Stamp (ES-T), which adds a time-stamp to the Electronic Signature, to take initial steps towards providing long term validity;
*電子署名にタイムスタンプを追加するタイムスタンプ（ES-T）、とのESは、長期的な有効性を提供することを目的初期段階を取ります。
* the ES with Complete validation data (ES-C), which adds to the ES-T references to the complete set of data supporting the validity of the electronic signature (i.e., revocation status information).
*電子署名の有効性（すなわち、失効状態情報）を支援するデータの完全なセットにES-T参照に追加完全な検証データ（ES-C）、を有するES。
The signer must provide at least the ES form, but in some cases may decide to provide the ES-T form and in the extreme case could provide the ES-C form. If the signer does not provide ES-T, the verifier must either create the ES-T on first receipt of an electronic signature or shall keep a secure time record of the ES. Either of these two approaches provide independent evidence of the existence of the signature at the time it was first verified which should be near the time it was created, and so protects against later repudiation of the existence of the signature. If the signer does not provide ES-C the verifier must create the ES-C when the complete set of revocation and other validation data is available.
署名者は、少なくともES形を提供しなければならないが、いくつかのケースではES-Tの形態を提供することを決定してもよいし、極端な場合にはES-C形を提供することができます。署名者は、ES-Tを提供しない場合、検証者は、電子署名の最初の領収書にES-Tを作成する必要がありますいずれかまたはESの安全な時間の記録を保持しなければなりません。これら2つのアプローチのどちらかは、それが作成された時間の近くにある必要があり、それが最初に確認された時点での署名の有無とは無関係に証拠を提供し、その署名の存在の後の否認から保護します。署名者は、ES-Cを提供していない場合は失効し、他の検証データの完全なセットが利用可能な場合、検証は、ES-Cを作成する必要があります。
The ES satisfies the legal requirements for electronic signatures as defined in the European Directive on electronic signatures, see Annex C for further discussion on relationship of this document to the Directive. It provides basic authentication and integrity protection and can be created without accessing on-line (time-stamping) services. However, without the addition of a time-stamp or a secure time record the electronic signature does not protect against the threat that the signer later denies having created the electronic signature (i.e., does not provide non-repudiation of its existence).
電子署名に欧州指令で定義されたESは、電子署名のための法的要件を満たし、指令へのこのドキュメントの関係についてさらなる議論については、附属書Cを参照してください。これは、基本的な認証と完全性保護を提供し、オンライン（タイムスタンプ）のサービスにアクセスすることなく作成することができます。しかしながら、タイムスタンプまたはセキュア時間レコードを添加せずに、電子署名は、署名者が後に（すなわち、その存在の否認防止を提供しない）電子署名を作成した拒否脅威から保護しません。
The ES-T time-stamp or time record should be created close to the time that ES was created to provide protection against repudiation. At this time all the data needed to complete the validation may not be available but what information is readily available may be used to carry out some of the initial checks. For example, only part of the revocation information may be available for verification at that point in time. Generally, the ES-C form cannot be created at the same time as the ES, as it is necessary to allow time for any revocation information to be captured. Also, if a certificate is found to be temporarily suspended, it will be necessary to wait until the end of the suspension period.
ES-Tタイムスタンプまたは時間記録はESを否認に対する保護を提供するために作成された時刻に近い作成する必要があります。この時点で検証を完了するために必要なすべてのデータが使用できない場合がありますが、どのような情報容易に利用可能であるが、初期チェックの一部を実行するために使用することができます。例えば、失効情報の一部のみがその時点での検証のために利用可能であってもよいです。任意の失効情報を捕捉するための時間を可能にするために必要であるように、一般的に、ES-C形は、ESと同時に作成することができません。証明書を一時的に中断されることが見出された場合にも、停止期間が終了するまで待つことが必要であろう。
The signer should only create the ES-C in situations where it was prepared to wait for a sufficient length of time after creating the ES form before dispatching the ES-C. This, however, has the advantage that the verifier can be presented with the complete set of data supporting the validity of the ES.
署名者は、ES-Cをディスパッチする前に、ESフォームを作成した後の時間の十分な長さを待つように調製した状況ではES-Cを作成する必要があります。これは、しかし、検証はESの有効性を裏付けるデータの完全なセットを提示することができるという利点があります。
Support for ES-C by the verifier is mandated (see clause 6 for specific conformance requirements).
検証者によってES-Cのサポートは、（特定の適合性要件について句6を参照）が義務付けられています。
An Electronic Signature (ES), with the additional validation data forming the ES-T and ES-C is illustrated in Figure 1:
追加の検証データはES-TおよびES-Cを形成した電子署名（ES）は、図1に示されています。
+------------------------------------------------------------ES-C-----+
|+--------------------------------------------ES-T-----+ |
||+------Elect.Signature (ES)----------+ +------------+| +-----------+|
|||+---------+ +----------+ +---------+| |Time-Stamp || |Complete ||
||||Signature| | Other | | Digital || |over digital|| |certificate||
||||Policy ID| | Signed | |Signature|| |signature || |and ||
|||| | |Attributes| | || +------------+| |revocation ||
|||+---------+ +----------+ +---------+| | |references ||
||+------------------------------------+ | +-----------+|
|+-----------------------------------------------------+ |
+---------------------------------------------------------------------+
Figure 1: Illustration of an ES, ES-T and ES-C
図1：ES、ES-TおよびES-Cのイラスト
The verifiers conformance requirements of an ES with a time-stamp of the digital signature is defined in subclause 6.2.
デジタル署名のタイムスタンプとESの検証適合要件は、箇条6.2で定義されています。
The ES on its own satisfies the legal requirements for electronic signatures as defined in the European Directive on electronic signatures. The signers conformance requirements of an ES are defined in subclause 6.1, and are met using a structure as indicated in figure 2:
独自の満たしのES電子署名に欧州指令で定義されている電子署名のための法的要件。 ESの署名者の適合性要件は、6.1節で定義され、図2に示すような構造を使用して満たされます。
+------Elect.Signature (ES)-----------|
|+---------+ +----------+ +---------+ |
||Signature| | Other | | Digital | |
||Policy ID| | Signed | |Signature| |
|| | |Attributes| | | |
|+---------+ +----------+ +---------+ |
|+-----------------------------------+|
Figure 2: Illustration of an ES
図2：ESのイラスト
Where there are requirements for long term signatures without time-stamping the digital signature, then a secure record is needed of the time of verification in association with the electronic signature (i.e., both must be securely recorded). In addition the certificates and revocation information used at the time of verification should to be recorded as indicated in figure 3 as an ES-C(bis).
次いで、セキュア記録を電子署名（すなわち、両方を確実に記録しなければならない）に関連して検証時間の必要とされるタイムスタンプ、デジタル署名をすることなく、長期署名の要件は、どこにあります。また、証明書と照合時に使用される失効情報は、ES-C（ビス）として図3に示されるように記録されるべきです。
+-------------------------------------------------------ES-C-----+
| |
| +------Elect.Signature (ES)----------+| +-----------+|
| |+---------+ +----------+ +---------+|| |Complete ||
| ||Signature| | Other | | Digital ||| |certificate||
| ||Policy ID| | Signed | |Signature||| |and ||
| || | |Attributes| | ||| |revocation ||
| |+---------+ +----------+ +---------+|| |references ||
| +------------------------------------+| +-----------+|
| |
+----------------------------------------------------------------+
Figure 3: Illustration of an ES-C(bis)
図3：ES-C（アップ）のイラスト
The verifiers conformance requirements of an ES-C(bis) is defined in subclause 6.3.
ES-C（ビス）の検証適合要件は、箇条6.3で定義されています。
Note: A time-stamp attached to the electronic signature or a secure time record helps to protect the validity of the signature even if some of the verification data associated with the signature become compromised AFTER the signature was generated. The time-stamp or a secure time record provides evidence that the signature was generated BEFORE the event of compromise; hence the signature will maintain its validity status.
注意：電子署名や、セキュア時間記録に添付タイムスタンプは、検証データの一部が、署名が生成した後危うくなっ署名に関連付けられている場合でも、署名の有効性を保護するのに役立ちます。タイムスタンプまたはセキュア時間記録は、署名が妥協のイベントの前に生成されたという証拠を提供します。したがって、署名は、その有効性ステータスを維持します。
The complete validation data (ES-C) described above may be extended to form an ES with eXtended validation data (ES-X) to meet following additional requirements.
上記完全な検証データ（ES-C）は、追加の要件以下満たすように拡張された検証データとES（ES-X）を形成するように拡張することができます。
Firstly, when the verifier does not has access to,
まず、検証がアクセス権を持っていない場合、
* the signer's certificate, * all the CA certificates that make up the full certification path, * all the associated revocation status information, as referenced in the ES-C.
*署名者の証明書、* ES-Cで参照されるように、完全な証明書パス、*、関連するすべての失効状態情報を構成するすべてのCA証明書。
then the values of these certificates and revocation information may be added to the ES-C. This form of extended validation data is called a X-Long.
次いで、これらの証明書及び失効情報の値は、ES-Cを添加してもよいです。拡張検証データのこの形式は、X-ロングと呼ばれています。
Secondly, if there is a risk that any CA keys used in the certificate chain may be compromised, then it is necessary to additionally time-stamp the validation data by either:
証明書チェーンで使用される任意のCAキーが損なわれるおそれがある場合には第二に、それはいずれかによって、さらに、タイムスタンプの検証データが必要です。
* time-stamping all the validation data as held with the ES(ES-C), this eXtended validation data is called a Type 1 X-Time-Stamp; or * time-stamping individual reference data as used for complete validation.
*タイムスタンプすべての検証データをES（ES-C）で開催されたように、この拡張された検証データは、タイプ1 X-タイムスタンプと呼ばれます。または*タイムスタンプ個々の参照データを完全に検証するために使用されます。
This form of eXtended validation data is called a Type 2 X-Time-Stamp.
拡張検証データのこの形式は、タイプ2のX-タイムスタンプと呼ばれています。
NOTE: The advantages/drawbacks for Type 1 and Type 2 X-Time-Stamp are discussed in this document (see clause B.4.6.)
注：タイプ1のための利点/欠点および2 X-タイムスタンプを入力し、この文書に記載されている（節B.4.6を参照）。
If all the above conditions occur then a combination of the two formats above may be used. This form of eXtended validation data is called a X-Long-Time-Stamped.
上記のすべての条件が次に発生した場合、上記二つのフォーマットの組み合わせを使用することができます。拡張検証データのこの形式は、X-長期タイムスタンプと呼ばれています。
Support for the extended forms of validation data is optional.
検証データの拡張形式のサポートはオプションです。
An Electronic Signature (ES) , with the additional validation data forming the ES-X long is illustrated in Figure 4:
追加の検証データが長いES-Xを形成した電子署名（ES）は、図4に示されています。
+-------------------------------------------------------- ES-X Long--+
|+---------------------------------------- EC-C --------+ |
||+---- Elect.Signature (ES)----+ +--------+| +--------+ |
|||+-------+-+-------+-+-------+| +----------+|Complete|| |Complete| |
||||Signa- | |Other | |Digital|| |Time-Stamp||certi- || |certi- | |
||||ture | |Signed | |Signa- || |over ||ficate || |ficate | |
||||Policy | |Attri- | |ture || |digital ||and || |and | |
||||ID | |butes | | || |signature ||revoc. || |revoc. | |
|||+-------+ +-------+ +-------+| +----------+|refs || |data | |
||+-----------------------------+ +--------+| +--------+ |
|+------------------------------------------------------+ |
+--------------------------------------------------------------------+
Figure 4: Illustration of an ES and ES-X long.
図4：ESおよびES-X長のイラスト。
An Electronic Signature (ES) , with the additional validation data forming the eXtended Validation Data - Type 1 is illustrated in Figure 5:
拡張検証データを構成する追加の検証データと電子署名（ES）は、 - タイプ1は、図5に示されています。
+----------------------------------------------------------- ES-X 1 -+
|+----------------------------------------- EC-C --------+ |
|| +---- Elect.Signature (ES)----+ +--------+| +-------+ |
|| |+-------+ +-------+ +-------+| +----------+|Complete|| | | |
|| ||Signa- | |Other | |Digital|| |Time-Stamp||certifi-|| | Time- | |
|| ||ture | |Signed | |Signa- || |over ||cate and|| | stamp | |
|| ||Policy | |Attri- | |ture || |digital ||revoc. || | over | |
|| ||ID | |butes | | || |signature ||refs || | CES | |
|| |+-------+ +-------+ +-------+| +----------+| || | | |
|| +-----------------------------+ +--------+| +-------+ |
|+-------------------------------------------------------+ |
+--------------------------------------------------------------------+
Figure 5: Illustration of ES with ES-X Type 1
図5：ES-Xタイプ1とESのイラスト
An Electronic Signature (ES) , with the additional validation data forming the eXtended Validation Data - Type 2 is illustrated in Figure 6:
拡張検証データを構成する追加の検証データと電子署名（ES）は、 - タイプ2は、図6に示されています。
+--------------------------------------------------------- ES-X 2 ---+
|+---------------------------------------- EC-C --------+ |
||+---- Elect.Signature (ES)----+ +--------+| +--------+ |
|||+-------+ +-------+ +-------+| +----------+|Complete|| |Times | |
||||Signa- | |Other | |Digital|| |Time-Stamp||certs || |Stamp | |
||||ture | |Signed | |Signa- || |over ||and || |over | |
||||Policy | |Attri- | |ture || |digital ||revoc. || |Complete| |
||||ID | |butes | | || |signature ||refs || |certs | |
|||+-------+ +-------+ +-------+| +----------+| || |and | |
||+-----------------------------+ +--------+| |revoc. | |
|| | |refs | |
|+------------------------------------------------------+ +--------+ |
+--------------------------------------------------------------------+
Figure 6: Illustration of ES with ES-X Type 2
図6：ES-X型2とESのイラスト
Before the algorithms, keys and other cryptographic data used at the time the ES-C was built become weak and the cryptographic functions become vulnerable, or the certificates supporting previous time-stamps expires, the signed data, the ES-C and any additional information (ES-X) should be time-stamped. If possible this should use stronger algorithms (or longer key lengths) than in the original time-stamp.
アルゴリズム、キーおよびES-Cを構築した時に使用される他の暗号データが弱くなり、暗号化機能が脆弱になる、または前タイムスタンプをサポートしている証明書の有効期限が切れる前に、署名されたデータ、ES-Cおよび追加情報（ES-X）は、タイムスタンプでなければなりません。可能な場合、これは、元のタイムスタンプよりも強力なアルゴリズム（または長いキーの長さ）を使用する必要があります。
This additional data and time-stamp is called Archive Validation Data (ES-A). The Time-Stamping process may be repeated every time the protection used to time-stamp a previous ES-A become weak. An ES-A may thus bear multiple embedded time stamps.
この追加データとタイムスタンプはアーカイブの検証データ（ES-A）と呼ばれています。タイムスタンプのプロセスは、保護が弱くなるタイムスタンプ前回のES-Aに使用するたびに繰り返されてもよいです。 ES-Aは、このように複数の埋め込まれたタイムスタンプを有していてもよいです。
An example of an Electronic Signature (ES), with the additional validation data for the ES-C and ES-X forming the ES-A is illustrated in Figure 7.
ES-CおよびES-Aを形成するES-Xのための追加の検証データと電子署名（ES）の例が図7に示されています。
+-------------------------------- ES-A --------- ----------+
| +-------------------- ES-A -----------------+ |
| | +--------- ES-X -------------- + | |
| | |..............................| +-----+ | +-----+ |
| | |..............................| |Time | | |Time | |
| | |..............................| |Stamp| | |Stamp| |
| | | | +-----+ | +-----+ |
| | +----------------------------- + | |
| +-------------------------------------------+ |
+----------------------------------------------------------+
Figure 7: Illustration of ES -A
図7：ES -Aのイラスト
Support for ES-A is optional.
ES-Aのサポートはオプションです。
The ES-C may be used for arbitration should there be a dispute between the signer and verifier, provided that:
署名者と検証者との間の紛争が存在すべきであるES-Cを調停するために使用することができる、それを提供しました。
* a copy of the signature policy referenced by the signer is available;
*署名者によって参照される署名ポリシーのコピーが利用可能です。
* the arbitrator knows where to retrieve the signer's certificate (if not already present), all the cross-certificates and the required CRLs and/or OCSPs responses referenced in the ES-C;
*仲裁人はここで、（まだ存在しない場合）、すべてのクロス証明書とES-Cで参照必要なのCRLおよび/またはOCSPs応答を署名者の証明書を取得するために知っています。
* none of the issuing key from the certificate chain have ever been compromised;
*証明書チェーンから発行キーのどれもこれまで危険にさらされていません。
* the cryptography used at the time the ES-C was built has not been broken at the time the arbitration is performed.
* ES-Cを構築した時に使用される暗号化は、アービトレーションが行われた時点で破壊されていません。
When the second condition is not met, then the plaintiff must provide an ES-X Long.
第2の条件が満たされない場合は、その後、原告は、ES-Xロングを提供する必要があります。
When it is known by some external means that the third condition is not met, then the plaintiff must provide an ES-X Time-Stamped.
それは第三の条件が満たされていないことを、いくつかの外部の手段で知られている場合は、その後、原告は、ES-Xタイムスタンプを提供する必要があります。
When the two previous conditions are not met, the plaintiff must provide the two above information (i.e., an ES-X Time-Stamped and Long).
前の2つの条件が満たされていない場合、原告は、二つの上記情報（即ち、ES-Xタイムスタンプとロング）を提供しなければなりません。
When the last condition is not met, the plaintiff must provide an ES-A.
最後の条件が満たされない場合には、原告は、ES-Aを提供する必要があります。
It should be noticed that a verifier may need to get two time stamps at two different instants of time: one soon after the generation of the ES and one soon after some grace period allowing any entity from the certification chain to declare a key compromise.
すぐに証明書チェーンから任意のエンティティが鍵の危殆化を宣言することができ、いくつかの猶予期間の後、すぐにESの世代次々と1：検証は時間の二つの異なる瞬間に2つのタイムスタンプを取得する必要があるかもしれないことに注意すべきです。
The Validation Process validates an electronic signature in accordance with the requirements of the signature policy. The output status of the validation process can be:
検証プロセスは、署名ポリシーの要件に応じて、電子署名を検証します。検証プロセスの出力状態を指定できます。
* valid;
* invalid;
* incomplete verification.
A Valid response indicates that the signature has passed verification and it complies with the signature validation policy.
有効な応答は、署名が検証に合格しており、それは、署名検証ポリシーに準拠していることを示しています。
A signature validation policy is a part of the signature policy which specifies the technical requirements on the signer in creating a signature and verifier when validating a signature.
署名検証ポリシーは、署名を検証する際、署名と検証を作成する署名者の技術要件を指定署名ポリシーの一部です。
An Invalid response indicates that either the signature format is incorrect or that the digital signature value fails verification (e.g., the integrity checks on the digital signature value fails or any of the certificates on which the digital signature verification depends is known to be invalid or revoked).
無効な応答が署名フォーマットのいずれかが間違っているか、デジタル署名値が検証に失敗したこと（例えば、デジタル署名値の整合性チェックが失敗した場合や、デジタル署名の検証が依存する証明書のいずれかが無効であることが知られているか、または取り消されていることを示しています）。
An Incomplete Validation response indicates that the format and digital signature verifications have not failed but there is insufficient information to determine if the electronic signature is valid under the signature policy. This can include situations where additional information, which does not effect the validity of the digital signature value, may be available but is invalid.
不完全な検証応答の形式とデジタル署名の検証が失敗していないことを示しているが、電子署名が署名ポリシーの下で有効であるかどうかを判断するのに十分な情報があります。これは、デジタル署名値の有効性に影響しない追加情報が、利用可能であるが、無効である可能性のある状況を含むことができます。
In the case of Incomplete Validation, it may be possible to request that the electronic signature be checked again at a later date when additional validation information might become available. Also, in the case of incomplete validation, additional information may be made available to the application or user, thus allowing the application or user to decide what to do with partially correct electronic signatures.
不完全な検証の場合は、電子署名が追加の検証情報が利用可能になるかもしれない、後日改めて確認することを要求することも可能です。また、不完全な検証の場合には、追加情報は、このように部分的に正しい電子署名をどのように処理するかを決定するために、アプリケーションまたはユーザを可能にするアプリケーションまたはユーザに利用可能にすることができます。
The validation process may also output validation data:
検証プロセスは、出力検証データをことがあります。
* a signature time-stamp;
* the complete validation data;
* the archive validation data.
Figure 8, and subsequent description, describes how the validation process may build up a complete electronic signature over time.
図8、およびそれに続く説明は、検証プロセスが経時的に完全な電子署名を構築することができる方法について説明します。
Soon after receiving the electronic signature (ES) from the signer (1), the digital signature value may be checked, the validation process must at least add a time-stamp (2), unless the signer has provided one which is trusted by the verifier. The validation process may also validate the electronic signature, as required under the identified signature policy, using additional data (e.g., certificates, CRL, etc.) provided by trusted service providers. If the validation process is not complete then the output from this stage is the ES-T.
（1）、デジタル署名値をチェックすることができる署名者が信頼されるものを提供していない限りすぐに、署名者から電子署名（ES）を受信した後、検証プロセスは、少なくとも、（2）タイムスタンプを追加する必要があります検証。識別された署名ポリシーの下で、必要に応じて検証プロセスはまた、信頼できるサービスプロバイダによって提供される追加データ（例えば、証明書、CRLなど）を用いて、電子署名を検証することができます。検証プロセスが完了していない場合、このステージからの出力は、ES-Tです。
When all the additional data (e.g., the complete certificate and revocation information) necessary to validate the electronic signature first becomes available, then the validation process:
ときにすべての追加データ（例えば、完全な証明書及び失効情報）第一の電子署名を検証する必要は次に、検証プロセス、利用可能になります。
* obtains all the necessary additional certificate and revocation status information;
*すべての必要な追加の証明書及び失効ステータス情報を取得し、
* completes 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 ES-T and ES-C process);
*完全な証明書失効情報（タイムスタンプが存在しない場合、これはES-TおよびES-Cプロセスを組み合わせる同じ段階で添加してもよい）を用いて、ESのすべての検証チェックを完了する。
* records the complete certificate and revocation references (3);
*完全な証明書や失効の参照を記録する（3）。
* indicates the validity status to the user (4).
*ユーザー（4）への有効性ステータスを示します。
+----------------------------------------- ES-C ----------+
|+----------------------------- ES-T --------+ |
||+--- Elect.Signature (ES) ----+ | +--------+ |
|||+-------+ +-------+ +-------+|+----------+| |Complete| |
||||Signa- | |Other | |Digital|||Time-Stamp|| |certifi-| |
||||ture | |Signed | |Signa- |||over || |cate and| |
||||Policy | |Attri- | |ture |||digital || |revoca- | |
||||ID | |butes | | |||signature || |tion | |
|||+-------+ +-------+ +-------+|+----------+| |referen-| |
||+------------\----------------+ ^ | |ces | |
|| \ | | +--------+ |
|| \ 1 / | ^ |
|+----------------\----------------/---------+ | |
+------------------\--------------/--------------- /------+
\ /2 ----3------/
+----------+ | / /
| Signed |\ v / |
|User data | \ +--------------------+ +------------+
+----------+ \--->| Validation Process |---> |- Valid |
+---|--^-------|--^--+ 4 |- Invalid |
| | | | |- Validation|
v | v | | Incomplete|
+---------+ +--------+ +------------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure 8: Illustration of an ES with Complete validation data (ES-C)
図8：完全な検証データとESのイラストレーション（ES-C）
At the same time as the validation process creates the ES-C, the validation process may provide and/or record the values of certificates and revocation status information used in ES-C, called the ES-X Long (5). This is illustrated in figure 9:
検証プロセスは、ES-Cを作成すると同時に、検証プロセスが提供するおよび/またはES-Cに使用される証明書失効状態情報の値を記録することができる、ES-Xロングと呼ばれる（5）。これは、図9に例示されています。
+----------------------------------------------------- ES-X ---------+
|+---------------------------------------- ES-C --------+ +--------+ |
||+--- Elect.Signature (ES) ----+ +--------+ | |Complete| |
|||+-------+ +-------+ +-------+|+----------+|Complete| | |certifi-| |
||||Signa- | |Other | |Digital|||Time-Stamp||certifi-| | |cate | |
||||ture | |Signed | |Signa- |||over ||cate and| | |and | |
||||Policy | |Attri- | |ture |||digital ||revoca- | | |revoca- | |
||||ID | |butes | | |||signature ||tion | | |tion | |
|||+-------+ +---|---+ +-------+|+----------+|referen-| | |Data | |
||+--------------\--------------+ ^ |ces | | +--------+ |
|| \ | +--------+ | ^ |
|| \ 1 2/ ^ | | |
|+------------------\--------------/------------|-------+ / |
+--------------------\------------/------------/-------------/-------+
\ / ---3----/ /
+----------+ | / / ------------5-----/
| Signed |\ v | | /
|User data | \ +--------------------+ +-----------+
+----------+ \--->| Validation Process |---> | - Valid |
+---|--^-------|--^--+ 4 | - Invalid |
| | | | +-----------+
v | v |
+---------+ +--------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure 9: Illustration ES with eXtended validation data (Long)
図9：拡張された検証データとイラストES（ロング）
When the validation process creates the ES-C it may also create extended forms of validation data. A first alternative is to time-stamp all data forming the Type 1 X-Time-Stamp (6). This is illustrated in figure 10:
検証プロセスは、ES-Cを作成するとき、それはまた、検証データの拡張されたフォームを作成することができます。最初の選択肢は、すべてのデータが1型X-タイムスタンプ（6）を形成するタイムスタンプです。これを図10に示します。
+----------------------------------------------------- ES-X -------+
|+---------------------------------------- ES-C --------+ +------+ |
||+--- Elect.Signature (ES) ----+ +--------+ | |Time- | |
|||+-------+ +-------+ +-------+|+----------+|Complete| | |Stamp | |
||||Signa- | |Other | |Digital|||Time-Stamp||certifi-| | |over | |
||||ture | |Signed | |Signa- |||over ||cate and| | |CES | |
||||Policy | |Attri- | |ture |||digital ||revoca- | | +------+ |
||||ID | |butes | | |||signature ||tion | | ^ |
|||+-------+ +--|----+ +-------+|+----------+|referen-| | | |
||+-------------|---------------+ ^ |ces | | | |
|| | | +--------+ | | |
|| \ 1 2/ ^ | | |
|+----------------\------------------/----------|-------+ | |
+------------------\----------------/-----------/-------------/----+
\ / ----3---/ /
+----------+ | / / ---------------6---/
| Signed |\ v | | /
|User data | \ +--------------------+ +-----------+
+----------+ \--->| Validation Process |---> | - Valid |
+---|--^-------|--^--+ 4 | - Invalid |
| | | | +-----------+
v | v |
+---------+ +--------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure 10: Illustration of ES with eXtended validation data - Type 1 X-Time-Stamp
図10：拡張された検証データとESのイラスト - タイプ1 X-タイムスタンプ
Another alternative is to time-stamp the certificate and revocation information references used to validate the electronic signature (but not the signature) (6'); this is called Type 2 X-Time-Stamped. This is illustrated in figure 11:
別の代替は、タイムスタンプ、電子署名（ただし署名）（6' ）を検証するために使用される証明書と失効情報の参照です。これは、タイプ2のX-タイムスタンプと呼ばれています。これを図11に示します。
+----------------------------------------------------- ES-X -----------+
|+---------------------------------------- ES-C --------+ +----------+ |
||+--- Elect.Signature (ES) ----+ +--------+ | |Time-Stamp| |
|||+-------+ +-------+ +-------+|+----------+|Complete| | |over | |
||||Signa- | |Other | |Digital|||Time-Stamp||certifi-| | |Complete | |
||||ture | |Signed | |Signa- |||over ||cate and| | |Certifi- | |
||||Policy | |Attri- | |ture |||digital ||revoc. | | |cate and | |
||||ID | |butes | | |||signature ||refs | | |revoc. | |
|||+-------+ +---^---+ +-------+|+----^-----++---^----+ | |refs | |
||+--------------\--------------+ | | | +----------+ |
|+----------------\------------------/-----------|------+ ^ |
+----------------1-\----------------/-----------/--------------|-------+
\ / -----3---/ |
+----------+ | 2/ / ---------------6'-----/
| Signed |\ v | | /
|User data | \ +--------------------+ +-----------+
+----------+ \--->| Validation Process |---> | - Valid |
+---|--^-------|--^--+ 4 | - Invalid |
| | | | +-----------+
v | v |
+---------+ +--------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure 11: Illustration of ES with eXtended validation data - Type 2 X-Time-Stamp
図11：拡張された検証データとESのイラスト - タイプ2のX-タイムスタンプ
Before the algorithms used in any of electronic signatures become or are likely, to be compromised or rendered vulnerable in the future, it is necessary to time-stamp the entire electronic signature, including all the values of the validation and user data as an ES with Archive validation data (ES-A)
電子署名のいずれかで使用されるアルゴリズムは、将来的に損なわ又は脆弱レンダリングする、になるか、そうなる前に、それが持つESとして検証およびユーザデータの全ての値を含む全体の電子署名、タイムスタンプに必要ですアーカイブ検証データ（ES-A）
An ES-A is illustrated in figure 12:
ES-Aは、図12に示されています。
-------------------------------------------- ES-A --------------------+
----------------------------------------------------------------+ |
+------------------------------- EC-C --------++-----+ | |
| ||Time-| | |
|+-- Elect.Signature (ES) -+ +--------+||Stamp| +-------+ |
||+------++-------++-------|+------+|Complete|||over | Complete| |
|||Signa-||Other ||Digital||Time- ||certifi-|||CES | |certi- |+----|
|||ture ||Signed ||Signa- ||Stamp ||cate and||+-----+ |ficate |Arch-|
|||Policy||Attri- ||ture ||over ||revoca- ||+------+ |and |ive |
|||ID ||butes || ||digit.||tion |||Time- | |revoca-|Time |
||+------++---|---++-------||signa-||referen-|||Stamp-| |tion |stamp|
|+------------|------------+|ture ||ces |||over | |data |+----|
| | +------++--------+|Complete\+-------+ ^ |
| | ^ ^ ||cert. | | | |
+-------------|----------------|---------|----+|and rev| | | |
\ | / |refs. | | | |
\ | / +-------+ | | |
-----------------\-------------|-------/------------------------+ | |
+----------+ \ | / / |
| Signed | \2 |3 / /--------------7-------/ |
|User data | \ | | / |
+-------\--+ \ | | / |
---------\------------|--------|----|---/-----------------------------+
\ v | | |
1\ +--------------------+ +-----------+
\------>| Validation Process |---> | - Valid |
+---|--^-------|--^--+ 4 | - Invalid |
| | | | +-----------+
v | v |
+---------+ +--------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure 12: Illustration of an ES with Archive validation data (ES-A)
図12：アーカイブの検証データとESのイラストレーション（ES-A）
This document also defines additional optional features of an electronic signature to:
この文書は、電子署名の付加的なオプション機能を定義します。
* indicate a commitment type being made by the signer;
* indicate the role under which a signature was created;
* support multiple signatures.
This clause uses and builds upon the Cryptographic Message Syntax (CMS), as defined in RFC 2630 [CMS], and Enhanced Security Services (ESS), as defined in RFC 2634 [ESS]. The overall structure of Electronic Signature is as defined in [CMS]. The Electronic Signature (ES) uses attributes defined in [CMS], [ESS] and this document. This document defines in full the ES attributes which it uses and are not defined elsewhere.
RFC 2634 [ESS]で定義されているこの句は、使用しており、RFC 2630 [CMS]で定義されるように、暗号メッセージ構文（CMS）上に構築し、拡張セキュリティサービス（ESS）。 [CMS]で定義されるように電子署名の全体的な構造です。電子署名（ES）は、[CMS]で定義された属性、[ESS]この文書を使用しています。このドキュメントは、完全な形でそれを使用して、他の場所で定義されていないESの属性を定義します。
The mandated set of attributes and the digital signature value is defined as the minimum Electronic Signature (ES) required by this document. A signature policy MAY mandate other signed attributes to be present.
属性の義務付けセットとデジタル署名値は、このドキュメントによって必要とされる最小の電子署名（ES）として定義されます。署名ポリシーが存在することが、他の署名の属性を強制するかもしれません。
The general syntax of the ES is as defined in [CMS].
[CMS]で定義されているESの一般的な構文は次のとおりです。
The data content type of the ES is as defined in [CMS].
[CMS]で定義されるようにESのデータのコンテンツタイプがあります。
The data content type is intended to refer to arbitrary octet strings, such as ASCII text files; the interpretation is left to the application. Such strings need not have any internal structure (although they could have their own ASN.1 definition or other structure).
データのコンテンツタイプは、ASCIIテキストファイルなどの任意のオクテット文字列、を指すことが意図されます。解釈はアプリケーションに任されています。このような文字列は、（彼らは自分のASN.1定義または他の構造を持っている可能性が）任意の内部構造を持っている必要はありません。
The Signed-data content type of the ES is as defined in [CMS].
[CMS]で定義されるようにESの符号付きデータのコンテンツタイプがあります。
The signed-data content type consists of a content of any type and zero or more signature values. Any number of signers in parallel can sign any type of content. The typical application of the signed-data content type represents one signer's digital signature on content of the data content type.
署名されたデータのコンテンツタイプは、任意のタイプおよびゼロ以上の署名値の内容で構成されています。並行して署名者の任意の数のコンテンツの任意のタイプに署名することができます。署名されたデータコンテンツタイプの典型的なアプリケーションは、データのコンテンツタイプのコンテンツ上の一人の署名者のデジタル署名を表します。
To make sure that the verifier uses the right certificate, this document mandates that the hash of the signers certificate is always included in the Signing Certificate signed attribute.
検証は、右の証明書を使用していることを確認するために、署名者証明書のハッシュは、常に署名証明書に含まれているこの文書の義務は、属性に署名しました。
The syntax of the SignedData type of the ES is as defined in [CMS].
ESののSignedDataタイプの構文は[CMS]で定義されます。
The fields of type SignedData have the meanings defined [CMS] except that:
タイプのSignedDataのフィールドは、ことを除いて、[CMS]で定義された意味を持っています：
* version is the syntax version number. The value of version must be 3.
*バージョンは構文バージョン番号です。バージョンの値は3でなければなりません。
* The identification of signer's certificate used to create the signature is always present as a signed attribute.
*署名を作成するために使用される署名者の証明書の識別は常に符号付き属性として存在します。
* The degenerate case where there are no signers is not valid in this document.
*無署名者が存在しない縮退場合は、この文書では有効ではありません。
The syntax of the EncapsulatedContentInfo a type of the ES is as defined in [CMS].
[CMS]で定義されるようEncapsulatedContentInfoの構文ESのタイプです。
For the purpose of long term validation as defined by this document, it is advisable that either the eContent is present, or the data which is signed is archived in such as way as to preserve the any data encoding. It is important that the OCTET STRING used to generate the signature remains the same every time either the verifier or an arbitrator validates the signature.
このドキュメントによって定義されるような長期検証のためには、いずれかのe-コンテンツが存在する、または署名されたデータはデータ・エンコーディングを保存するような方法などにアーカイブされることが推奨されます。署名を生成するために使用されるオクテット文字列が検証または仲裁人のどちらかが署名を検証するたびに同じままであることが重要です。
The degenerate case where there are no signers is not valid in this document.
何の署名者が存在しない縮退場合は、この文書では有効ではありません。
The syntax of the SignerInfo a type of the ES is as defined in [CMS].
[CMS]で定義されているのSignerInfoの構文ESのタイプです。
Per-signer information is represented in the type SignerInfo. In the case of multiple independent signatures, there is an instance of this field for each signer.
ごとの署名者情報がタイプのSignerInfoで表されます。複数の独立した署名の場合には、各署名者のためにこのフィールドのインスタンスがあります。
The fields of type SignerInfo have the meanings defined in [CMS] except that signedAttributes must, as a minimum, contain the following attributes:
タイプのSignerInfoのフィールドはsignedAttributesのは、最低限、以下の属性を含まなければならないことを除いて、[CMS]で定義された意味を有します。
* ContentType as defined in clause 3.7.1. * MessageDigest as defined in clause 3.7.2. * SigningTime as defined in clause 3.7.3. * SigningCertificate as defined in clause 3.8.1. * SignaturePolicyId as defined in clause 3.9.1.
*句3.7.1で定義されたContentType。 *のMessageDigest節3.7.2で定義されています。 *句3.7.3で定義されているようSigningTime。 *句3.8.1で定義されているようSigningCertificate。 * SignaturePolicyId節3.9.1で定義されています。
The message digest calculation process is as defined in [CMS].
[CMS]で定義されるように、メッセージダイジェスト計算プロセスです。
The input to the digital signature generation process is as defined in [CMS].
[CMS]で定義されるようにデジタル署名生成処理に入力されます。
The procedures for CMS signed data validation are as defined in [CMS] and enhanced in this document.
CMSのための手順は、[CMS]で定義され、本書で強化通りであるデータの検証を署名しました。
The input to the signature verification process includes the signer's public key verified as correct using either the ESS Signing Certificate attribute or the Other Signing Certificate attribute.
署名検証プロセスへの入力は、ESS署名証明書属性またはその他の署名証明書の属性のいずれかを使用して正しいとして検証署名者の公開鍵を含んでいます。
The following attributes MUST be present with the signed-data defined by this document. The attributes are defined in [CMS].
以下の属性は、この文書によって定義された署名されたデータと共に存在していなければなりません。属性は、[CMS]で定義されています。
The syntax of the content-type attribute type of the ES is as defined in [CMS].
[CMS]で定義されているESのコンテンツタイプの属性タイプの構文は次のとおりです。
The syntax of the message-digest attribute type of the ES is as defined in [CMS].
ESのメッセージダイジェスト属性タイプの構文は[CMS]で定義されます。
The syntax of the message-digest attribute type of the ES is as defined in [CMS] and further qualified by this document.
[CMS]で定義されており、この文書によってさらに修飾としてESのメッセージダイジェスト属性タイプの構文は次のとおりです。
The signing-time attribute type specifies the time at which the signer claims to have performed the signing process.
署名時の属性タイプは署名者が署名プロセスを実行したと主張した時刻を指定します。
This present document recommends the use of GeneralizedTime.
この本書は、GeneralizedTimeの使用を推奨しています。
One, and only one, of the following two alternative attributes MUST be present with the signed-data defined by this document to identify the signing certificate. Both attributes include an identifier and a hash of the signing certificate. The first, which is adopted in existing standards, may be only used with the SHA-1 hashing algorithm. The other shall be used when other hashing algorithms are to be supported.
この文書によって定義された署名されたデータは、署名証明書を識別すると、次の二つの別の属性のいずれか一方のみが存在していなければなりません。両方の属性は、識別子と署名証明書のハッシュを含みます。既存の標準に採用され、最初は、唯一のSHA-1ハッシュアルゴリズムと共に使用することができます。他のハッシュアルゴリズムをサポートする場合、他のを使用しなければなりません。
The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of authorization certificates to be used in verifying a signature.
署名証明書属性は、単純な置換と再発行攻撃を防ぐために、署名の検証に使用する認証証明書の制限されたセットを可能にするように設計されています。
The syntax of the signing certificate attribute type of the ES is as defined in [ESS], and further qualified and profile in this document.
[ESS]で定義されており、この文書では、さらに修飾してプロファイルとしてESの署名証明書の属性タイプの構文は次のとおりです。
The ESS signing certificate attribute must be a signed attribute.
ESS署名証明書属性は署名している属性でなければなりません。
This document mandates the presence of this attribute as a signed CMS attribute, and the sequence must not be empty. The certificate used to verify the signature must be identified in the sequence, the Signature Validation Policy may mandate other certificate references to be present, that may include all the certificates up to the point of trust. The encoding of the ESSCertID for this certificate must include the issuerSerial field.
このドキュメントでは、署名したCMS属性としてこの属性が存在することを義務付け、およびシーケンスが空にすることはできません。署名を検証するために使用される証明書の順序で識別されなければならない、署名検証ポリシーは、信頼のポイントまでのすべての証明書を含むことができる、存在する他の証明書への参照を強制することができます。この証明書のESSCertIDのエンコーディングはissuerSerialフィールドを含める必要があります。
The issuerAndSerialNumber present in the SignerInfo must be consistent with issuerSerial field. The certificate identified must be used during the signature verification process. If the hash of the certificate does not match the certificate used to verify the signature, the signature must be considered invalid.
SignerInfoでissuerAndSerialNumberの存在はissuerSerialフィールドと一致していなければなりません。同定された証明書は、署名検証処理の間に使用されなければなりません。証明書のハッシュが署名を検証するために使用される証明書と一致しない場合、署名は無効と見なされなければなりません。
The sequence of policy information field is not used in this document.
ポリシー情報フィールドの順序は、このドキュメントで使用されていません。
NOTE: Where an attribute certificate is used by the signer to associate a role, or other attributes of the signer, with the electronic signature this is placed in the Signer Attribute attribute as defined in clause 3.12.3.
注：属性証明書は節3.12.3で定義され、これは署名者属性属性に配置された電子署名と、役割、または署名者の他の属性を関連付けるために、署名者によって使用されます。
The following attribute is identical to the ESS SigningCertificate defined above except that this attribute can be used with hashing algorithms other than SHA-1.
次の属性は、この属性は、SHA-1以外のハッシュアルゴリズムで使用することができることを除いて上記で定義されたESS SigningCertificateと同一です。
This attribute must be used in the same manner as defined above for the ESS SigningCertificate attribute.
ESS SigningCertificate属性について上で定義したように、この属性は、同じ方法で使用されなければなりません。
The following object identifier identifies the signing certificate attribute:
以下のオブジェクト識別子は署名証明書属性を識別します。
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 19 }
The signing certificate attribute value has the ASN.1 syntax OtherSigningCertificate
署名証明書の属性値はASN.1構文がありOtherSigningCertificate
OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THIS DOCUMENT
}
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL
}
OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue
}
OtherHashValue ::= OCTET STRING
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue
}
This document mandates that a reference to the signature policy, is included in the signedData, this reference is either explicitly identified or implied by the semantics of the signed content and other external data. A signature policy defines the rules for creation and validation of an electronic signature, is included as a signed attribute with every signature. The signature policy identifier must be a signed attribute.
署名ポリシーへの参照が、たsignedDataに含まれ、この文書の義務は、この参照は明示的に署名されたコンテンツや他の外部データのセマンティクスによって識別または暗示されています。署名ポリシーは、電子署名の生成及び検証のためのルールを定義し、すべての署名で署名属性として含まれます。署名ポリシー識別子は署名している属性でなければなりません。
The following object identifier identifies the signature policy identifier attribute:
以下のオブジェクト識別子は、署名ポリシー識別子の属性を識別する。
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 }
Signature-policy-identifier attribute values have ASN.1 type SignaturePolicyIdentifier.
署名ポリシー識別子の属性値はASN.1タイプSignaturePolicyIdentifierを持っています。
SignaturePolicyIdentifier ::= CHOICE{
SignaturePolicyId SignaturePolicyId,
SignaturePolicyImplied SignaturePolicyImplied }
SignaturePolicyId ::= SEQUENCE {
sigPolicyIdentifier SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL
}
SignaturePolicyImplied ::= NULL
The presence of the NULL type indicates that the signature policy is implied by the semantics of the signed data and other external data.
NULL型の存在は、署名ポリシーは、署名されたデータと他の外部データのセマンティクスによって暗示されていることを示します。
The sigPolicyId field contains an object-identifier which uniquely identifies a specific version of the signature policy. The syntax of this field is as follows:
sigPolicyIdフィールドは、一意の署名ポリシーの特定のバージョンを識別するオブジェクト識別子を含みます。次のようにこのフィールドの構文は次のとおりです。
SigPolicyId ::= OBJECT IDENTIFIER
The sigPolicyHash field contains the identifier of the hash algorithm and the hash of the value of the signature policy.
sigPolicyHashフィールドは、ハッシュアルゴリズムの識別子と署名ポリシーの値のハッシュを含んでいます。
If the signature policy is defined using a computer processable notation like ASN.1, then the hash is calculated on the value without the outer type and length fields and the hashing algorithm must be as specified in the field signPolicyHshAlg.
署名ポリシーはASN.1のようなコンピュータ処理可能な表記を使用して定義されている場合、フィールドsignPolicyHshAlgで指定され、その後、ハッシュは、外側型と長さフィールドとハッシュアルゴリズムなし値に基づいて計算されなければなりません。
If the signature policy is defined using another structure, the type of structure and the hashing algorithm must be either specified as part of the signature policy, or indicated using a signature policy qualifier.
署名ポリシーは別の構造を使用して定義されている場合、構造体の種類及びハッシュアルゴリズムのいずれかの署名ポリシーの一部として指定された、又は署名ポリシー修飾子を使用して示さなければなりません。
SigPolicyHash ::= OtherHashAlgAndValue
A signature policy identifier may be qualified with other information about the qualifier. The semantics and syntax of the qualifier is as associated with the object-identifier in the sigPolicyQualifierId field. The general syntax of this qualifier is as follows:
署名ポリシー識別子は、修飾子に関する他の情報で修飾されてもよいです。セマンティクスと修飾子の構文は次のようにsigPolicyQualifierIdフィールドのオブジェクト識別子に関連付けられています。次のようにこの修飾子の一般的な構文は次のとおりです。
SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId
}
This document specifies the following qualifiers:
このドキュメントでは、次の修飾子を指定します。
* spuri: This contains the web URI or URL reference to the signature policy
* spuri：これは、署名ポリシーにウェブURIまたはURLの参照が含まれています
* spUserNotice: This contains a user notice which should be displayed whenever the signature is validated.
* spUserNotice：これは、署名が検証されたときに表示されるべきユーザ通知を含んでいます。
-- sigpolicyQualifierIds defined in this document
- この文書で定義されsigpolicyQualifierIds
SigPolicyQualifierId ::= OBJECT IDENTIFIER
id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 }
SPuri ::= IA5String
id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 2 }
SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL
}
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER
}
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200))
}
The following attributes MAY be present with the signed-data defined by this document. The attributes are defined in ref [CMS] and are imported into this specification and were appropriate qualified and profiling by this document.
以下の属性は、この文書で定義された署名データで存在しているかもしれません。属性は、参考文献[CMS]で定義されており、この仕様にインポートして、この文書による適切な資格とプロファイリングしたされています。
The syntax of the countersignature attribute type of the ES is as defined in [CMS]. The countersignature attribute must be an unsigned attribute.
[CMS]で定義されているESの副署属性タイプの構文は次のとおりです。副署属性は未署名の属性でなければなりません。
The following attributes MAY be present with the signed-data defined by this document. The attributes are defined in ref [ESS] and are imported into this specification and were appropriate qualified and profiling by this document.
以下の属性は、この文書で定義された署名データで存在しているかもしれません。属性は、参考文献[ESS]で定義され、本明細書にインポートし、この文書による適切な修飾およびプロファイリングたれます。
The content reference attribute is a link from one SignedData to another. It may be used to link a reply to the original message to which it refers, or to incorporate by reference one SignedData into another.
コンテンツ参照属性は、1のSignedDataから他へのリンクです。参照する元のメッセージへの返信をリンクする、または別に参照ずつのSignedDataを組み込むために使用されてもよいです。
The content reference attribute MUST be used as defined in [ESS]. The content reference MUST be a signed attribute.
[ESS]で定義されるようにコンテンツ参照属性を使用しなければなりません。コンテンツの参照が署名している属性でなければなりません。
The syntax of the content reference attribute type of the ES is as defined in [ESS].
ESの内容参照属性タイプの構文は[ESS]で定義されます。
The content identifier attribute provides an identifier for the signed content for use when reference may be later required to that content, for example in the content reference attribute in other signed data sent later.
参照して後で後で送信他の署名されたデータのコンテンツ参照属性、例えば、そのコンテンツに必要とされ得る場合、コンテンツ識別子属性を使用するための署名されたコンテンツの識別子を提供します。
The content identifier must be a signed attribute.
コンテンツ識別子は署名している属性でなければなりません。
The syntax of the content identifier attribute type of the ES is as defined in [ESS].
[ESS]で定義されるようにESのコンテンツ識別子属性タイプの構文です。
The minimal signedContentIdentifier should contain a concatenation of user-specific identification information (such as a user name or public keying material identification information), a GeneralizedTime string, and a random number.
最小signedContentIdentifierは、GeneralizedTimeの列、及び乱数（例えば、ユーザ名またはパブリックキーイングマテリアル識別情報として）ユーザ固有の識別情報の連結を含むべきです。
The content hints attribute provides information that describes the format of the signed content. It may be used by the signer to indicate to a verifier the precise format that MUST be used to present the data (e.g., text, voice, video) to a verifier. This attribute MUST be present when it is mandatory to present the signed data to human users on verification.
コンテンツのヒント属性が署名したコンテンツのフォーマットを記述した情報を提供します。検証者に検証者にデータ（例えば、テキスト、音声、ビデオ）を提示するために使用されなければならない正確なフォーマットを示すために署名者によって使用されてもよいです。検証上の人間のユーザに署名されたデータを提示するために必須である場合は、この属性が存在しなければなりません。
The syntax of the content hints attribute type of the ES is as defined in ESS (RFC 2634, section 2.9 [9]).
コンテンツのヒントの構文はESのタイプ属性ESS（RFC 2634、セクション2.9 [9]）で定義される通りです。
When used to indicate the precise format of the data to be presented to the user the following rules apply:
データの正確な形式を示すために使用される場合、以下の規則が適用され、ユーザに提示します。
The contentType (defined in RFC 2630 [8]) indicates the type of the associated content. It is an object identifier (i.e., a unique string of integers) assigned by an authority that defines the content type.
contentTypeの（RFC 2630で定義された[8]）は関連するコンテンツのタイプを示します。これは、コンテンツタイプを定義する権限によって割り当てられたオブジェクト識別子（すなわち、整数の一意の文字列）です。
The UTF8String shall define the presentation format. The format may be defined by MIME types as indicated below.
UTF8Stringをプレゼンテーション形式を定義しなければなりません。以下に示すようなフォーマットは、MIMEタイプによって定義することができます。
Note 1: The contentType can be id-data defined in CMS (RFC 2630 [8]). The UTF8String can be used to indicate the encoding of the data, like MIME type. RFC 2045 [25] provides a common structure for encoding a range of electronic documents and other multi-media types, see annex B for further information, a system supporting verification of electronic signature may present information to users in the form identified by the MIME type.
注1：のcontentTypeがCMSで定義されているIDデータとすることができる（RFC 2630 [8]）。 UTF8StringをMIMEタイプのようなデータの符号化を示すために使用することができます。 RFC 2045 [25]詳細については付録Bを参照して、電子文書及び他のマルチメディアタイプの範囲を符号化するための一般的な構造を提供する、MIMEタイプによって識別された形式でユーザに情報を提示することができる電子署名の検証をサポートするシステム。
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
There may be situation were a signer wants to explicitly indicate to a verifier that by signing the data, it illustrates a type of commitment on behalf of the signer. The commitmentTypeIndication attribute conveys such information.
状況があるかもしれません署名者が明示的にデータに署名することによって、それは署名者に代わって約束の種類を示して検証者に指示したいと考えていました。 commitmentTypeIndication属性は、このような情報を伝えます。
The commitmentTypeIndication attribute must be a signed attribute.
commitmentTypeIndication属性は署名している属性でなければなりません。
The commitment type may be:
コミットメントのタイプは次のようになります。
* defined as part of the signature policy, in which case the commitment type has precise semantics that is defined as part of the signature policy.
*コミットメントタイプが署名ポリシーの一部として定義されている正確な意味を有している場合には、署名ポリシーの一部として定義されます。
* be a registered type, in which case the commitment type has precise semantics defined by registration, under the rules of the registration authority. Such a registration authority may be a trading association or a legislative authority.
*コミットメントタイプが登録機関の規則の下で、登録によって定義された正確な意味を持っている場合には登録型の、こと。このような登録機関は、取引協会や立法機関です。
The signature policy specifies a set of attributes that it "recognizes". This "recognized" set includes all those commitment types defined as part of the signature policy as well as any externally defined commitment types that the policy may choose to recognize. Only recognized commitment types are allowed in this field.
署名ポリシーは、それが「認識」する一連の属性を指定します。この「認識」セットは、すべての署名ポリシーの一部として定義されたコミットメントの種類だけでなく、ポリシーが認識することを選択する可能性のある外部で定義されたコミットメントタイプが含まれています。のみ認識コミットメントタイプはこのフィールドで許可されています。
The following object identifier identifies the commitment type indication attribute:
以下のオブジェクト識別子は、コミットメントタイプ表示属性を識別します。
id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}
Commitment-Type-Indication attribute values have ASN.1 type CommitmentTypeIndication.
コミットメント型-表示属性値はASN.1タイプCommitmentTypeIndicationを持っています。
CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
CommitmentTypeQualifier OPTIONAL
}
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeQualifier ::= SEQUENCE {
commitmentTypeIdentifier CommitmentTypeIdentifier,
qualifier ANY DEFINED BY
commitmentTypeIdentifier
}
The use of any qualifiers to the commitment type is outside the scope of this document.
コミットメント型への修飾子の使用は、このドキュメントの範囲外です。
The following generic commitment types are defined in this document:
次の一般的なコミットメントの種類は、この文書で定義されています。
id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 1}
id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 2} id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 3}
id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 4}
id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 5}
id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 6}
These generic commitment types have the following meaning:
これらの一般的なコミットメントの種類は以下の意味があります。
Proof of origin indicates that the signer recognizes to have created, approved and sent the message.
起源の証拠は、署名者が承認し、作成したと認識し、メッセージを送ったことを示しています。
Proof of receipt indicates that signer recognizes to have received the content of the message.
領収書の証明は署名者がメッセージの内容を受けていると認識していることを示しています。
Proof of delivery indicates that the TSP providing that indication has delivered a message in a local store accessible to the recipient of the message.
配達証明は、その指示を提供TSPは、メッセージの受信者にアクセス可能なローカルストアにメッセージを配信したことを示しています。
Proof of sender indicates that the entity providing that indication has sent the message (but not necessarily created it).
送信者の証明は、その指示を提供エンティティがメッセージを送信した（しかし必ずしもそれを作成していない）を有していることを示しています。
Proof of approval indicates that the signer has approved the content of the message.
承認の証明は署名者がメッセージの内容を承認したことを示しています。
Proof of creation indicates that the signer has created the message (but not necessarily approved, nor sent it).
創造の証拠は、署名者がメッセージを作成した（が、必ずしも承認し、またそれを送られていない）していることを示しています。
The signer-location attribute is an attribute which specifies a mnemonic for an address associated with the signer at a particular geographical (e.g., city) location. The mnemonic is registered in the country in which the signer is located and is used in the provision of the Public Telegram Service (according to ITU-T Recommendation F.1 [PTS]).
署名者ロケーション属性は、特定の地理的（例えば、都市）の位置で署名者に関連付けられたアドレスのニーモニックを指定する属性です。ニーモニックは、（ITU-T勧告F.1 [PTS]に記載）署名者が位置し、公共の電信サービスの提供に使用される国に登録されています。
The signer-location attribute must be a signed attribute.
署名者-location属性は署名している属性でなければなりません。
The following object identifier identifies the signer-location attribute:
以下のオブジェクト識別子は、署名者、場所属性を識別する。
id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17}
Signer-location attribute values have ASN.1 type SignerLocation.
署名者-location属性値はASN.1タイプSignerLocationを持っています。
SignerLocation ::= SEQUENCE {
-- at least one of the following must be present
countryName [0] DirectoryString OPTIONAL,
-- as used to name a Country in X.500
localityName [1] DirectoryString OPTIONAL,
-- as used to name a locality in X.500
postalAdddress [2] PostalAddress OPTIONAL
}
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString
The signer-attributes attribute is an attribute which specifies additional attributes of the signer (e.g., role).
属性 - 属性は、署名者は、署名者（例えば、役割）の追加属性を指定する属性です。
It may be either:
これは、いずれであってもよいです。
* claimed attributes of the signer; or * certified attributes of the signer;
*署名者の属性を主張。または*署名者の属性を認定。
The signer-attributes attribute must be a signed attribute.
署名者の属性属性は署名している属性でなければなりません。
The following object identifier identifies the signer-attribute attribute:
以下のオブジェクト識別子は署名者属性属性を識別します。
id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}
signer-attribute attribute values have ASN.1 type SignerAttribute.
署名者属性値はASN.1タイプSignerAttributeを持っている属性。
SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes
}
ClaimedAttributes ::= SEQUENCE OF Attribute
CertifiedAttributes ::= AttributeCertificate
-- as defined in X.509 : see section 10.3
NOTE: The claimed and certified attribute are imported from ITU-T Recommendations X.501 [16] and ITU-T Recommendation X.509:Draft Amendment on Certificate Extensions, October 1999.
注：主張と認定属性はITU-T勧告X.501から輸入されている[16]とITU-T勧告X.509：証明書エクステンション、1999年10月に改正案。
The content time-stamp attribute is an attribute which is the time-stamp of the signed data content before it is signed.
コンテンツタイムスタンプ属性は、それが署名される前に署名されたデータの内容のタイムスタンプである属性です。
The content time-stamp attribute must be a signed attribute.
コンテンツタイムスタンプ属性は署名している属性でなければなりません。
The following object identifier identifies the signer-attribute attribute:
以下のオブジェクト識別子は署名者属性属性を識別します。
id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 20}
Content time-stamp attribute values have ASN.1 type ContentTimestamp:
ContentTimestamp::= TimeStampToken
The value of messageImprint field within TimeStampToken must be a hash of the value of eContent field within encapContentInfo within the signedData.
TimeStampTokenの中messageImprintフィールドの値がたsignedData内encapContentInfo内のeContentフィールドの値のハッシュでなければなりません。
For further information and definition of TimeStampToken see [TSP].
TimeStampTokenのの詳細および定義については、[TSP]を参照してください。
Multiple independent signatures are supported by independent SignerInfo from each signer.
複数の独立したシグネチャは、各署名者からの独立のSignerInfoによって支持されています。
Each SignerInfo must include all the attributes required under this document and must be processed independently by the verifier.
各のSignerInfoは、この文書の下に必要なすべての属性を含まなければならないと検証によって独立して処理する必要があります。
Multiple embedded signatures are supported using the counter-signature unsigned attribute (see clause 3.10.1). Each counter signature is carried in Countersignature held as an unsigned attribute to the SignerInfo to which the counter-signature is applied.
複数の埋め込まれた署名は、カウンタ署名符号なし属性（項3.10.1を参照）を使用してサポートされています。各カウンタ署名は、カウンタ署名が適用されるのSignerInfoに未署名の属性として保持副署で運ばれます。
This clause specifies the validation data structures which builds on the electronic signature specified in clause 3. This includes:
この句は、句これには3で指定された電子署名に基づいて構築検証データ構造を指定します。
* Time-Stamp applied to the electronic signature value.
*タイムスタンプは、電子署名の値に適用されます。
* Complete validation data which comprises the time-stamp of the signature value, plus references to all the certificates and revocation information used for full validation of the electronic signature.
*完全な検証署名値のタイムスタンプを含むデータ、プラス電子署名の完全な検証のために使用されるすべての証明書と失効情報への参照。
The following optional eXtended forms of validation data are also defined:
検証データの次のオプションの拡張された形も定義されています。
* X-timestamp: There are two types of time-stamp used in extended validation data defined by this document.
* X-タイムスタンプ：この文書で定義された拡張検証データに使用されるタイムスタンプの2種類があります。
- Type 1 -Time-Stamp which comprises a time-stamp over the ES with Complete validation data (ES-C).
- 完全な検証データ（ES-C）を用いてESオーバータイムスタンプを含むタイプ1 - 時刻スタンプ。
- Type 2 X-Time-Stamp which comprises of a time-stamp over the certification path references and the revocation information references used to support the ES-C.
- 認証パス参照とES-Cをサポートするために使用される失効情報の参照上のタイムスタンプの含む2型X-タイムスタンプ。
* X-Long: This comprises a Complete validation data plus the actual values of all the certificates and revocation information used in the ES-C.
* X-ロング：これは完全な検証データに加えてES-Cで使用されるすべての証明書及び失効情報の実際の値を含みます。
* X-Long-Time-Stamp: This comprises a Type 1 or Type 2 X-Timestamp plus the actual values of all the certificates and revocation information used in the ES-C.
* X-長時間スタンプ：これは、1型または2型X-タイムスタンププラスES-Cで使用されるすべての証明書失効情報の実際の値を含みます。
This clause also specifies the data structures used in Archive validation data:
また、この句はアーカイブの検証データで使用されるデータ構造を指定しています。
* Archive validation data comprises a Complete validation data, the certificate and revocation values (as in a X-Long validation data), any other existing X-timestamps, plus the Signed User data and an additional archive time-stamp over all that data. An archive time-stamp may be repeatedly applied after long periods to maintain validity when electronic signature and timestamping algorithms weaken.
*アーカイブの検証データは、完全な検証データ、証明書失効値（X-ロング検証データのように）、他の既存のX-タイムスタンプ、プラス署名ユーザーデータとすべてのデータの上に追加のアーカイブタイムスタンプを含みます。アーカイブタイムスタンプを繰り返し、電子署名とタイムスタンプアルゴリズムが弱体化する際の有効性を維持するために、長い期間の後に適用することができます。
The additional data required to create the forms of electronic signature identified above is carried as unsigned attributes associated with an individual signature by being placed in the unsignedAttrs field of SignerInfo. Thus all the attributes defined in clause 4 are unsigned attributes.
上記識別された電子署名のフォームを作成するために必要な追加データはのSignerInfoのunsignedAttrsフィールドに配置されることにより、個々の署名に関連付けられている符号なし属性として実施されます。したがって、4節で定義されたすべての属性は未署名の属性です。
NOTE: Where multiple signatures are to be supported, as described in clause 3.13, each signature has a separate SignerInfo. Thus, each signature requires its own unsigned attribute values to create ES-T, ES-C etc.
注：3.13節に記載されるように複数の署名は、サポートされる、各署名は別々のSignerInfoを有しています。したがって、各シグネチャは、ES-T、ES-C等を作成するために、独自の符号なしの属性値が必要
An Electronic Signature with Timestamp is an Electronic Signature for which part, but not all, of the additional data required for validation is available (e.g., some certificates and revocation information is available but not all).
タイムスタンプと電子署名がどの部分に対する電子署名であり、全てではないが、検証に必要な追加データ（例えば、いくつかの証明書失効情報が利用可能なすべてではない）で入手可能です。
The minimum structure Timestamp validation data is the Signature Timestamp Attribute as defined in clause 4.1.1 over the ES signature value.
ES署名値以上節4.1.1で定義されている最小の構造タイムスタンプ検証データは、署名タイムスタンプ属性です。
The Signature Timestamp attribute is timestamp of the signature value. It is an unsigned attribute. Several instances of this attribute from different TSAs may occur with an electronic signature.
署名タイムスタンプ属性は、署名値のタイムスタンプです。これは、未署名の属性です。別のTSAからこの属性のいくつかのインスタンスは、電子署名で起こり得ます。
The Signature Validation Policy specifies, in the signatureTimestampDelay field of TimestampTrustConditions, a maximum acceptable time difference which is allowed between the time indicated in the signing time attribute and the time indicated by the Signature Timestamp attribute. If this delay is exceeded then the electronic signature must be considered as invalid.
署名検証ポリシーTimestampTrustConditions、署名時間属性に示された時間および署名タイムスタンプ属性が示す時刻との間に許可される最大許容時間差のsignatureTimestampDelayフィールドに、指定します。この遅延を超えた場合は、電子署名が無効であると考えなければなりません。
The following object identifier identifies the Signature Timestamp attribute:
以下のオブジェクト識別子は、署名タイムスタンプ属性を識別する。
id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 14}
The Signature timestamp attribute value has ASN.1 type SignatureTimeStampToken.
署名タイムスタンプ属性値はASN.1タイプSignatureTimeStampTokenを持っています。
SignatureTimeStampToken ::= TimeStampToken
The value of messageImprint field within TimeStampToken must be a hash of the value of signature field within SignerInfo for the signedData being timestamped.
TimeStampTokenの内messageImprintフィールドの値は、たsignedDataがタイムスタンプであるためのSignerInfo内の署名フィールドの値のハッシュでなければなりません。
For further information and definition of TimeStampToken see [TSP].
TimeStampTokenのの詳細および定義については、[TSP]を参照してください。
An electronic signature with complete validation data is an Electronic Signature for which all the additional data required for validation (i.e., all certificates and revocation information) is available. Complete validation data (ES-C) build on the electronic signature Time-Stamp as defined above.
完全な検証データと電子署名は、検証（すなわち、すべての証明書及び失効情報）のために必要なすべての追加データが使用可能な電子署名です。完全な検証データ（ES-C）上記で定義した電子署名タイムスタンプの上に構築。
The minimum structure of a Complete validation data is:
完全な検証データの最小構成は次のとおりです。
* the Signature Time-Stamp Attribute, as defined in clause 4.1.1;
* Complete Certificate Refs, as defined in clause 4.2.1;
* Complete Revocation Refs, as defined in clause 4.2.2.
The Complete validation data MAY also include the following additional information, forming a X-Long validation data, for use if later validation processes may not have access to this information:
完全な検証データは、後で検証プロセスがこの情報へのアクセスを持っていない可能性がある場合に使用するために、X-ロング検証データを形成し、以下の追加情報を含むことができます。
* Complete Certificate Values, as defined in clause 4.2.3; * Complete Revocation Values, as defined in clause 4.2.4.
*完全な証明書の値、節4.2.3で定義されています。 *完全な失効値、節4.2.4で定義されています。
The Complete validation data MAY also include one of the following additional attributes, forming a X-Time-Stamp validation data, to provide additional protection against later CA compromise and provide integrity of the validation data used:
完全な検証データは、後でCAの妥協案に対する追加の保護を提供し、使用検証データの整合性を提供するために、X-タイムスタンプの検証データを形成し、以下の追加属性の一つを含むことがあります。
* ES-C Time-Stamp, as defined in clause 4.2.5; or * Time-Stamped Certificates and CRLs references, as defined in clause 4.2.6.
* ES-C節4.2.5で定義されているタイムスタンプ、。または*タイムスタンプ付きの証明書およびCRLの参照、節4.2.6で定義されています。
NOTE 1: As long as the CA's are trusted such that these keys cannot be compromised or the cryptography used broken, the ES-C provides long term proof of a valid electronic signature.
注1：限り、これらの鍵が危殆化または暗号が破ら使用できないことをCAのような信頼されているように、ES-Cは、有効な電子署名の長期的な証拠を提供します。
A valid electronic signature is an electronic signature which passes validation according to a signature validation policy.
有効な電子署名は、署名検証ポリシーに従って検証を通過した電子署名です。
NOTE 2: The ES-C provides the following important property for long standing signatures; that is having been found once to be valid, must continue to be so months or years later. Long after the validity period of the certificates have expired, or after the user key has been compromised.
注2：ES-Cは、長年の署名のために、以下の重要な特性を提供します。それが有効であると、一度発見されたされているので、数ヶ月または数年後であり続けなければなりません。ロング証明書の有効期間の後に期限が切れている、またはユーザーのキーが侵害された後。
The Complete Certificate Refs attribute is an unsigned attribute. It references the full set of CA certificates that have been used to validate a ES with Complete validation data (ES-C) up to (but not including) the signer's certificate. Only a single instance of this attribute must occur with an electronic signature.
完全な証明書参考文献属性は未署名の属性です。これは、完全な検証データ（ES-C）署名者の証明書（は含まない）までにESを検証するために使用されているCA証明書の完全なセットを参照します。この属性の単一のインスタンスだけが電子署名を行う必要があります。
Note: The signer's certified is referenced in the signing certificate attribute (see clause 3.1).
注意：署名者の署名証明書属性で参照される認定（節3.1を参照）。
id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}
The complete certificate refs attribute value has the ASN.1 syntax CompleteCertificateRefs.
完全な証明書、参考文献には、値はASN.1構文CompleteCertificateRefsを持っている属性。
CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID
OTHERCertID is defined in clause 3.8.2.
OTHERCertIDは節3.8.2で定義されています。
The IssuerSerial that must be present in OTHERCertID. The certHash must match the hash of the certificate referenced.
OTHERCertIDに存在している必要がありIssuerSerial。 CERTHASHは、参照された証明書のハッシュと一致する必要があります。
NOTE: Copies of the certificate values may be held using the Certificate Values attribute defined in clause 4.3.1.
注：証明書の値のコピーは値が節4.3.1で定義された属性証明書を使用して開催することができます。
The Complete Revocation Refs attribute is an unsigned attribute. Only a single instance of this attribute must occur with an electronic signature. It references the full set of the CRL or OCSP responses that have been used in the validation of the signer and CA certificates used in ES with Complete validation data.
完全失効参考文献属性は未署名の属性です。この属性の単一のインスタンスだけが電子署名を行う必要があります。これは、完全な検証データとESで使用される署名者とCA証明書の検証に使用されているCRLまたはOCSP応答のフルセットを参照します。
The following object identifier identifies the CompleteRevocationRefs attribute:
以下のオブジェクト識別子はCompleteRevocationRefs属性を識別します。
id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}
The complete revocation refs attribute value has the ASN.1 syntax CompleteRevocationRefs.
完全失効レフリーは、値はASN.1構文CompleteRevocationRefsを持っている属性。
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL
}
CompleteRevocationRefs must contain one CrlOcspRef for the signing certificate, followed by one for each OTHERCertID in the CompleteCertificateRefs attribute. The second and subsequent CrlOcspRef fields must be in the same order as the OTHERCertID to which they relate. At least one of CRLListID or OcspListID or OtherRevRefs should be present for all but the "trusted" CA of the certificate path.
CompleteRevocationRefsはCompleteCertificateRefs属性内の各OTHERCertIDに1つに続いて署名証明書のための1 CrlOcspRefを、含まれている必要があります。目以降CrlOcspRefフィールドは、それらが関連するOTHERCertIDと同じ順序でなければなりません。 CRLListIDまたはOcspListIDまたはOtherRevRefsの少なくとも一つは、証明書パスの「信頼できる」CAが、すべてのために存在しなければなりません。
CRLListID ::= SEQUENCE {
crls SEQUENCE OF CrlValidatedID}
CrlValidatedID ::= SEQUENCE {
crlHash OtherHash,
crlIdentifier CrlIdentifier OPTIONAL}
CrlIdentifier ::= SEQUENCE {
crlissuer Name,
crlIssuedTime UTCTime,
crlNumber INTEGER OPTIONAL
}
OcspListID ::= SEQUENCE {
ocspResponses SEQUENCE OF OcspResponsesID}
OcspResponsesID ::= SEQUENCE {
ocspIdentifier OcspIdentifier,
ocspRepHash OtherHash OPTIONAL
}
OcspIdentifier ::= SEQUENCE {
ocspResponderID ResponderID,
-- As in OCSP response data
producedAt GeneralizedTime
-- As in OCSP response data
}
When creating an crlValidatedID, the crlHash is computed over the entire DER encoded CRL including the signature. The crlIdentifier would normally be present unless the CRL can be inferred from other information.
crlValidatedIDを作成する場合、crlHashは署名を含む全体のDER符号化されたCRLにわたって計算されます。 CRLは、他の情報から推測することができない限り、crlIdentifierは、通常存在するであろう。
The crlIdentifier is to identify the CRL using the issuer name and the CRL issued time which must correspond to the time "thisUpdate" contained in the issued CRL. The crlListID attribute is an unsigned attribute. In the case that the identified CRL is a Delta CRL then references to the set of CRLs to provide a complete revocation list must be included.
crlIdentifierは、発行者名を使用してCRLを特定することで、CRLが発行されたCRLに含まれる「thisUpdateの」時間に対応しなければならない時間を発行しました。 crlListID属性は未署名の属性です。識別CRLはデルタCRLである場合には、完全な失効リストを提供するのCRLのセットへの参照が含まれている必要があります。
The OcspIdentifier is to identify the OSCP response using the issuer name and the time of issue of the OCSP response which must correspond to the time "producedAt" contained in the issued OCSP response. Since it may be needed to make the difference between two OCSP responses received within the same second, then the hash of the response contained in the OcspResponsesID may be needed to solve the ambiguity.
OcspIdentifierは、発行者名と発行されるOCSP応答に含まれる時間「producedAt」に対応している必要がありOCSP応答の問題の時間を使ってOSCP応答を識別することです。同じ秒以内に受信した2つのOCSPレスポンスの間の違いを確認するために必要とされる可能性があるので、次にOcspResponsesIDに含まれる応答のハッシュは、曖昧さを解決するために必要とされるかもしれません。
NOTE: Copies of the CRL and OCSP responses values may be held using the Revocation Values attribute defined in clause 4.3.2.
注：CRLおよびOCSP応答値のコピーが失効値は節4.3.2で定義された属性を使用して開催することができます。
OtherRevRefs ::= SEQUENCE {
otherRevRefType OtherRevRefType,
otherRevRefs ANY DEFINED BY otherRevRefType
}
OtherRevRefType ::= OBJECT IDENTIFIER
The syntax and semantics of other revocation references is outside the scope of this document. The definition of the syntax of the other form of revocation information is as identified by OtherRevRefType.
他の取消し参照の構文と意味は、このドキュメントの範囲外です。 OtherRevRefTypeによって識別される失効情報の他の形式の構文の定義です。
The Certificate Values attribute is an unsigned attribute. Only a single instance of this attribute must occur with an electronic signature. It holds the values of certificates referenced in the CompleteCertificateRefs attribute.
値は、属性証明書が未署名の属性です。この属性の単一のインスタンスだけが電子署名を行う必要があります。それはCompleteCertificateRefs属性で参照証明書の値を保持します。
Note: If an Attribute Certificate is used, it is not provided in this structure but must be provided by the signer as a signer-attributes attribute (see clause 12.3).
注意：属性は、証明書を使用している場合は、この構造に提供されていないが、署名者の属性は、属性として（節12.3を参照）、署名者によって提供されなければなりません。
The following object identifier identifies the CertificateValues attribute:
以下のオブジェクト識別子はCertificateValues属性を識別します。
id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}
The certificate values attribute value has the ASN.1 syntax CertificateValues.
証明書の値は、値がASN.1構文CertificateValuesを持っている属性。
CertificateValues ::= SEQUENCE OF Certificate
Certificate is defined in RFC2459 and ITU-T Recommendation X.509 [1])
証明書は、RFC2459で定義されているITU-T勧告X.509 [1]）
The Revocation Values attribute is an unsigned attribute. Only a single instance of this attribute must occur with an electronic signature. It holds the values of CRLs and OCSP referenced in the CompleteRevocationRefs attribute.
失効値は、未署名の属性である属性。この属性の単一のインスタンスだけが電子署名を行う必要があります。それはCompleteRevocationRefs属性で参照のCRLおよびOCSPの値を保持します。
The following object identifier identifies the Revocation Values attribute:
以下のオブジェクト識別子は、値は属性失効を識別します。
id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 24}
The revocation values attribute value has the ASN.1 syntax RevocationValues.
失効値は、値がASN.1構文RevocationValuesを持っている属性。
RevocationValues ::= SEQUENCE {
crlVals [0] SEQUENCE OF CertificateList OPTIONAL,
ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
otherRevVals [2] OtherRevVals
}
OtherRevVals ::= SEQUENCE {
otherRevValType OtherRevValType,
otherRevVals ANY DEFINED BY otherRevValType
}
OtherRevValType ::= OBJECT IDENTIFIER
The syntax and semantics of the other revocation values is outside the scope of this document. The definition of the syntax of the other form of revocation information is as identified by OtherRevRefType.
他の取消し値の構文と意味は、このドキュメントの範囲外です。 OtherRevRefTypeによって識別される失効情報の他の形式の構文の定義です。
CertificateList is defined in RFC 2459 [RFC2459] and in ITU-T Recommendation X.509 [X509]).
CertificateListのは、RFC 2459 [RFC2459]およびITU-T勧告X.509で定義されている[X509]）。
BasicOCSPResponse is defined in RFC 2560 [OCSP].
BasicOCSPResponseは、RFC 2560 [OCSP]で定義されています。
This attribute is used for the Type 1 X-Time-Stamped validation data. The ES-C Time-Stamp attribute is an unsigned attribute. It is time-stamp of a hash of the electronic signature and the complete validation data (ES-C). It is a special purpose TimeStampToken Attribute which time-stamps the ES-C. Several instances instance of this attribute may occur with an electronic signature from different TSAs.
この属性は、タイプ1のX-タイムスタンプの検証データに使用されます。 ES-Cタイムスタンプ属性は未署名の属性です。これは、電子署名のハッシュと完全な検証データ（ES-C）のタイムスタンプです。それは特別な目的のTimeStampTokenの属性タイムスタンプES-Cです。この属性の複数のインスタンスのインスタンスが異なるのTSAからの電子署名で起こり得ます。
The following object identifier identifies the ES-C Time-Stamp attribute:
以下のオブジェクト識別子は、ES-Cタイムスタンプ属性を識別します。
id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 25}
The ES-C time-stamp attribute value has the ASN.1 syntax ESCTimeStampToken.
ES-Cタイムスタンプ属性値はASN.1構文ESCTimeStampTokenを持っています。
ESCTimeStampToken ::= TimeStampToken
The value of messageImprint field within TimeStampToken must be a hash of the concatenated values (without the type or length encoding for that value) of the following data objects as present in the ES with Complete validation data (ES-C):
TimeStampTokenの内messageImprintフィールドの値は、完全な検証データ（ES-C）を有するES内に存在するとして、次のデータオブジェクトの連結された値（その値のタイプ又はレングス符号化なし）のハッシュでなければなりません。
* signature field within SignerInfo;
*のSignerInfo内の署名フィールドと
* SignatureTimeStampToken attribute;
* SignatureTimeStampToken属性。
* CompleteCertificateRefs attribute;
* CompleteCertificateRefs属性。
* CompleteRevocationRefs attribute.
* CompleteRevocationRefs属性。
For further information and definition of the Time Stamp Token see [TSP].
タイムスタンプの詳細および定義については、トークンは、[TSP]を参照してください。
This attribute is used for the Type 2 X-Time-Stamp validation data. A TimestampedCertsCRLsRef attribute is an unsigned attribute. It is a list of referenced certificates and OCSP responses/CRLs which are been time-stamped to protect against certain CA compromises. Its syntax is as follows:
この属性は、タイプ2のX-タイムスタンプの検証データに使用されます。 TimestampedCertsCRLsRef属性は未署名の属性です。これは、タイムスタンプ、特定のCAの妥協から保護するためになっている参照証明書およびOCSP応答/ CRLの一覧です。構文は次のとおりです。
The following object identifier identifies the TimestampedCertsCRLsRef attribute:
以下のオブジェクト識別子はTimestampedCertsCRLsRef属性を識別します。
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 26}
The attribute value has the ASN.1 syntax TimestampedCertsCRLs.
属性値はASN.1構文TimestampedCertsCRLsを持っています。
TimestampedCertsCRLs ::= TimeStampToken
The value of messageImprint field within TimeStampToken must be a hash of the concatenated values (without the type or length encoding for that value) of the following data objects as present in the ES with Complete validation data (ES-C):
TimeStampTokenの内messageImprintフィールドの値は、完全な検証データ（ES-C）を有するES内に存在するとして、次のデータオブジェクトの連結された値（その値のタイプ又はレングス符号化なし）のハッシュでなければなりません。
* CompleteCertificateRefs attribute; * CompleteRevocationRefs attribute.
* CompleteCertificateRefs属性。 * CompleteRevocationRefs属性。
Where an electronic signature is required to last for a very long time, and a the time-stamp on an electronic signature is in danger of being invalidated due to algorithm weakness or limits in the validity period of the TSA certificate, then it may be required to time-stamp the electronic signature several times. When this is required an archive time-stamp attribute may be required. This time-stamp may be repeatedly applied over a period of time.
電子署名は、非常に長い時間続くことが必要であり、電子署名のタイムスタンプはTSA証明書の有効期間に起因するアルゴリズムの弱さや限界まで無効にされる恐れがあり、それが必要になることがある場合タイムスタンプへの電子署名数回。これが必要な場合はアーカイブタイムスタンプ属性が必要な場合があります。このタイムスタンプは、繰り返しの期間にわたって適用されてもよいです。
The Archive Time-Stamp attribute is time-stamp of the user data and the entire electronic signature. If the Certificate values and Revocation Values attributes are not present these attributes must be added to the electronic signature prior to the time-stamp. The Archive Time-Stamp attribute is an unsigned attribute. Several instances of this attribute may occur with on electronic signature both over time and from different TSAs.
アーカイブタイムスタンプ属性は、ユーザーのデータと全体の電子署名のタイムスタンプです。証明書の値と失効が値ならば、これらの属性を提示されていない属性は、タイムスタンプの前に電子署名を追加する必要があります。アーカイブタイムスタンプ属性は未署名の属性です。この属性のいくつかのインスタンスは、時間の経過と異なるのTSAの両方から電子署名上で発生することがあります。
The following object identifier identifies the Nested Archive Time-Stamp attribute:
以下のオブジェクト識別子は、ネストされたアーカイブタイムスタンプ属性を識別します。
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 27}
Archive time-stamp attribute values have the ASN.1 syntax ArchiveTimeStampToken
アーカイブタイムスタンプ属性値はASN.1構文を持ってArchiveTimeStampToken
ArchiveTimeStampToken ::= TimeStampToken
The value of messageImprint field within Time-StampToken must be a hash of the concatenated values (without the type or length encoding for that value) of the following data objects as present in the electronic signature:
時間StampToken内messageImprintフィールドの値は、電子署名に存在するとして、次のデータオブジェクトの連結された値（その値のタイプ又はレングス符号化なし）のハッシュでなければなりません。
* encapContentInfo eContent OCTET STRING;
* signedAttributes;
* signature field within SignerInfo;
* SignatureTimeStampToken attribute;
* CompleteCertificateRefs attribute;
* CompleteRevocationData attribute;
* CertificateValues attribute
(If not already present this information must be included in
the ES-A);
* RevocationValues attribute
(If not already present this information must be included in
the ES-A);
* ESCTimeStampToken attribute if present;
* TimestampedCertsCRLs attribute if present;
* any previous ArchiveTimeStampToken attributes.
For further information and definition of TimeStampToken see [TSP]
TimeStampTokenのの詳細および定義については[TSP]を参照
The time-stamp should be created using stronger algorithms (or longer key lengths) than in the original electronic signatures.
タイムスタンプは、元の電子署名でより強いアルゴリズム（またはより長い鍵の長さ）を使用して作成されるべきです。
The security of the electronic signature mechanism defined in this document depends on the privacy of the signer's private key. Implementations must take steps to ensure that private keys cannot be compromised.
この文書で定義された電子署名メカニズムのセキュリティは、署名者の秘密鍵のプライバシーに依存します。実装は秘密鍵が危殆化することができないことを保証するための措置をとる必要があります。
Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptoanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Therefore, cryptographic algorithm implementations should be modular allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of mandatory to implement algorithms to change over time.
実装者は、暗号化アルゴリズムは、時間とともに弱くなることに注意する必要があります。新しい暗号解読技術が開発され、コンピューティング性能が向上しているように、特定の暗号アルゴリズムを破る仕事率が低下します。したがって、暗号アルゴリズムの実装を容易に挿入するモジュラー可能新しいアルゴリズムであるべきです。これは、実装者は、時間の経過とともに変化するアルゴリズムを実装するために必須のセットのために準備されるべきです。
This document only defines conformance requirements up to a ES with Complete validation data (ES-C). This means that none of the extended and archive forms of Electronic Signature (ES-X, ES-A) need to be implemented to get conformance to this standard.
この文書は、完全な検証データ（ES-C）を用いてESへの適合要件を定義します。これは、電子署名の拡張およびアーカイブ形式のいずれも（ES-X、ES-A）は、この規格への適合を得るために実施する必要はないことを意味します。
This document mandates support for elements of the signature policy.
このドキュメントでは、署名ポリシーの要素のサポートを義務付け。
A system supporting signers according to this document must, at a minimum, support generation of an electronic signature consisting of the following components:
この文書に係る署名者をサポートするシステムは、最低限、次の成分からなる電子署名の生成をサポートしなければなりません。
* The general CMS syntax and content type as defined in RFC 2630 (see clauses 4.1 and 4.2).
*一般的なCMS構文およびコンテンツタイプをRFC 2630で定義されている（節4.1および4.2を参照）。
* CMS SignedData as defined in RFC 2630 with version set to 3 and at least one SignerInfo must be present (see clauses 4.3, 4.4, 4.5, 4.6).
* CMSのSignedData 3に設定されたバージョンとRFC 2630で定義されており、少なくとも一つのSignerInfoは（4.6、4.3節、4.4、4.5を参照）存在しなければならないように。
* The following CMS Attributes as defined in RFC 2630:
*以下のCMSは、RFC 2630で定義されている属性：
- ContentType; This must always be present (see clause 3.7.1);
- ContentTypeを;これは常に存在していなければならない（3.7.1節を参照）。
- MessageDigest; This must always be present (see clause 3.7.2);
- メッセージダイジェスト;これは常に存在していなければならない（3.7.2節を参照）。
- SigningTime; This must always be present (see clause 3.7.3).
- SigningTime;これは、常に（節3.7.3を参照）存在している必要があります。
* The following ESS Attributes as defined in RFC 2634:
RFC 2634で定義されている*以下ESS属性：
- SigningCertificate: This must be set as defined in clauses 3.8.1 and 3.8.2.
- SigningCertificate：節3.8.1と3.8.2で定義されている。これは、設定する必要があります。
* The following Attributes as defined in clause 3.9:
*句3.9で定義された次の属性は：
- SignaturePolicyIdentifier; This must always be present.
- SignaturePolicyIdentifier;これは、常に存在する必要があります。
* Public Key Certificates as defined in ITU-T Recommendation X.509 [1] and profiled in RFC 2459 [7] (see clause 9.1).
*公開鍵証明書は、ITU-T勧告X.509で定義されるように[1]とRFC 2459で紹介[7]（節9.1を参照）。
A system supporting verifiers according to this document with time-stamping facilities must, at a minimum, support:
タイムスタンプ機能を使用してこの文書に係る検証をサポートするシステムなければならない最低限のサポート：
* Verification of the mandated components of an electronic signature, as defined in clause 5.1.
*節5.1で定義されている電子署名の義務成分の検証。
* Signature Time-Stamp attribute, as defined in clause 4.1.1.
*署名タイムスタンプ属性、節4.1.1で定義されています。
* Complete Certificate Refs attribute, as defined in clause 4.2.1.
*完全な証明書参考文献は、節4.2.1で定義されているように、属性。
* Complete Revocation Refs Attribute, as defined in clause 4.2.2.
*完全失効参考文献属性、節4.2.2で定義されています。
* Public Key Certificates, as defined in ITU-T Recommendation X.509 and profiled in RFC 2459.
*公開鍵証明書、ITU-T勧告X.509で定義され、RFC 2459でプロファイルとして。
* Either of:
* のどちらか：
- Certificate Revocation Lists, as defined in ITU-T Recommendation X.509 [1] and profiled in RFC 2459 [7]; or
- 証明書失効リスト、[1] ITU-T勧告X.509で定義され、RFC 2459でプロファイルとして[7]。または
- On-line Certificate Status Protocol responses, as defined in RFC 2560.
- オンライン証明書状態プロトコルの応答、RFC 2560で定義されています。
A system supporting verifiers according to the present document shall, at a minimum, support:
本文書に係る検証をサポートするシステム者は、最低でも、サポート。
* Verification of the mandated components of an electronic signature, as defined in subclause 5.1.
*箇条5.1で定義されている電子署名の義務成分の検証。
* Complete Certificate Refs attribute, as defined in subclause 4.2.1.
*サブ節4.2.1で定義された証明書参考文献は、属性を完了します。
* Complete Revocation Refs Attribute, as defined in subclause 9.2.2.
*完全失効参考文献属性、サブ節9.2.2で定義されています。
* A record shall be maintained, which cannot be undetectably modified, of the electronic signature and the time when the signature was first validated using the referenced certificates and revocation information.
*レコードが検出できない電子署名と署名が最初に参照証明書及び失効情報を使用して検証した時間を、変更することができない、維持しなければなりません。
* Public Key Certificates, as defined in ITU-T Recommendation X.509 [1] and profiled in RFC 2459 [7] (see subclause 10.1).
[1] ITU-T勧告X.509で定義され、RFC 2459でプロファイルとして*公開鍵証明書は、[7]（10.1副次参照します）。
* Either of:
* のどちらか：
- Certificate Revocation Lists, as defined in ITU-T Recommendation X.509 [1] and profiled in RFC 2459 [7] Or
- ITU-T勧告X.509で定義されている証明書失効リスト、[1] RFC 2459で紹介[7]又は
- On-line Certificate Status Protocol, as defined in RFC 2560 [8] (see subclause 10.3).
- オンライン証明書ステータスプロトコルは、RFC 2560で定義されるように[8]（10.3副次参照します）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、 "S / MIMEのためのセキュリティサービスの強化"、RFC 2634、1999年6月。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "On-line Status Certificate Protocol", RFC 2560, June 1999.
[OCSP]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "オンラインステータス認証プロトコル"、RFC 2560、1999年6月。
[TSP] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[TSP]アダムス、C.、カイン、P.、ピンカス、D.とR. Zuccherato、 "インターネットX.509公開鍵インフラストラクチャタイムスタンププロトコル（TSP）"、RFC 3161、2001年8月。
[PTS] Public Telegram Service. ITU-T Recommendation F1.
[PTS]公共の電信サービス。 ITU-T勧告F1。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459] Housley氏、R.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネットX.509公開鍵インフラストラクチャ、証明書とCRLプロファイル"、RFC 2459、1999年1月。
[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release.
[PKCS9] RSA Laboratories社、 "公開鍵暗号規格（PKCS）"、RSAデータセキュリティ社は、カリフォルニア州レッドウッド・シティ、1993年11月リリース。
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997.
[ISONR] ISO / IEC 10181から5：オープンシステムのセキュリティフレームワーク。否認防止の枠組み。 1997年4月。
[TS101733] ETSI Standard TS 101 733 V.1.2.2 (2000-12) Electronic Signature Formats. Note: copies of ETSI TS 101 733 can be freely downloaded from the ETSI web site www.etsi.org.
[TS101733] ETSI標準TS 101 733 V.1.2.2（2000-12）電子署名フォーマット。注意：ETSI TS 101 733のコピーは自由にETSIのウェブサイトwww.etsi.orgからダウンロードすることができます。
This Informational RFC has been produced in ETSI TC-SEC.
この情報のRFCは、ETSI TC-SECで生産されています。
ETSI F-06921 Sophia Antipolis, Cedex - FRANCE 650 Route des Lucioles - Sophia Antipolis Valbonne - France Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 secretariat@etsi.fr http://www.etsi.org
ETSI、F-06921ソフィアアンティポリス、セデックス - FRANCE 650ルートデLucioles - ソフィアアンティポリスヴァルボンヌ - France電話：+33 4 92 94 42 00ファックス：+33 4 93 65 47 16 secretariat@etsi.frのhttp：//www.etsi .ORG
Contact Point
コンタクトポイント
Harri Rasilainen ETSI 650 Route des Lucioles F-06921 Sophia Antipolis, Cedex FRANCE
ハッリ・Rasilainen ETSI 650ルートデLucioles F-06921ソフィアアンティポリスセデックスFRANCE
EMail: harri.rasilainen@etsi.fr
メールアドレス：harri.rasilainen@etsi.fr
Denis Pinkas Integris 68, Route de Versailles 78434 Louveciennes CEDEX FRANCE
デニスピンカスIntegris 68、ルート・ド・ベルサイユ78434ルーヴシエンヌFRANCE CEDEX
EMail: Denis.Pinkas@bull.net
メールアドレス：Denis.Pinkas@bull.net
John Ross Security & Standards 192 Moulsham Street Chelmsford, Essex CM2 0LG United Kingdom
ジョン・ロスセキュリティ・規格192 Moulshamストリートチェルムズフォード、エセックスCM2 0LGイギリス
EMail: ross@secstan.com
メールアドレス：ross@secstan.com
Nick Pope Security & Standards 192 Moulsham Street Chelmsford, Essex CM2 0LG United Kingdom
ニック・ポープセキュリティ・規格192 Moulshamストリートチェルムズフォード、エセックスCM2 0LGイギリス
EMail: pope@secstan.com
メールアドレス：pope@secstan.com
Annex A (normative): ASN.1 Definitions
附属書A（規定）：ASN.1定義
This annex provides a summary of all the ASN.1 syntax definitions for new syntax defined in this document.
この附属書は、この文書で定義された新しい構文のためのすべてのASN.1構文定義の概要を提供します。
A.1 Definitions Using X.208 (1988) ASN.1 Syntax
A.1定義X.208（1988）ASN.1構文を使用しました
NOTE: The ASN.1 module defined in clause A.1 has precedence over that defined in Annex A-2 in the case of any conflict.
注：節A.1に定義されたASN.1モジュールは、任意の矛盾する場合には、附属書A-2で定義されたものよりも優先されます。
ETS-ElectronicSignatureFormats-88syntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 5}
ETS-ElectronicSignatureFormats-88syntax {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）ID-MOD（0）5}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS All -
- すべてのエクスポート -
IMPORTS
輸入
-- Crypographic Message Syntax (CMS): RFC 2630
- 暗号メッセージ構文（CMS）：RFC 2630
ContentInfo, ContentType, id-data, id-signedData, SignedData, EncapsulatedContentInfo, SignerInfo, id-contentType, id-messageDigest, MessageDigest, id-signingTime, SigningTime, id-countersignature, Countersignature
ContentInfo、ContentTypeを、IDデータ、ID-たsignedData、のSignedData、EncapsulatedContentInfo、のSignerInfo、ID-のcontentType、ID-するMessageDigest、するMessageDigest、ID-signingTime、SigningTime、ID-副署、副署
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
暗号メッセージ構文FROM {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）CMS（1）}
-- ESS Defined attributes: RFC 2634 -- (Enhanced Security Services for S/MIME)
- ESS定義された属性：RFC 2634 - （S / MIMEのための強化されたセキュリティサービス）
id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-contentReference, ContentReference, id-aa-contentIdentifier, ContentIdentifier
ID-AA-signingCertificate、SigningCertificate、IssuerSerial、ID-AA-contentReference、ContentReference、ID-AA-contentIdentifier、ContentIdentifier
FROM ExtendedSecurityServices { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
ExtendedSecurityServices {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）ESS（2）} FROM
-- Internet X.509 Public Key Infrastructure -- Certificate and CRL Profile: RFC 2459
- インターネットX.509公開鍵基盤 - 証明書とCRLプロフィール：RFC 2459
Certificate, AlgorithmIdentifier, CertificateList, Name, GeneralNames, GeneralName, DirectoryString,Attribute,
証明書、のAlgorithmIdentifier、CertificateListの、名前、GeneralNames、のGeneralName、DirectoryString、属性、
AttributeTypeAndValue, AttributeType, AttributeValue, PolicyInformation, BMPString, UTF8String
AttributeTypeAndValue、AttributeTypeで、AttributeValueの、PolicyInformation、BMPString、UTF8Stringを
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
PKIX1Explicit88 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-明示-88（1）} FROM
-- X.509 '97 Authentication Framework
- X.509 '97認証フレームワーク
AttributeCertificate
AttributeCertificate
FROM AuthenticationFramework {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}
AuthenticationFramework FROM {関節-ISO-CCITTのDS（5）モジュール（1）authenticationFramework（7）3}
-- The imported AttributeCertificate is defined using the X.680 1997 -- ASN.1 Syntax, -- an equivalent using the 88 ASN.1 syntax may be used.
- ASN.1構文、 - - を使用することができる88 ASN.1構文を使用して、同等のインポートAttributeCertificateはX.680 1997を使用して定義されます。
-- OCSP 2560
- OCSP 2560
BasicOCSPResponse, ResponderID
BasicOCSPResponse、ResponderID
FROM OCSP {-- OID not assigned -- }
{ - 割り当てられていないOID - } OCSP FROM
-- Time Stamp Protocol Work in Progress
- 進行中のタイムスタンププロトコルの仕事
TimeStampToken
TimeStampTokenの
FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
PKIXTSP FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-TSP（13）}
-- S/MIME Object Identifier arcs used in this document
-- ===================================================
-- S/MIME OID arc used in this document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier
-- Definitions of Object Identifier arcs used in this document
-- ===========================================================
-- The allocation of OIDs to specific objects are given below with the -- associated ASN.1 syntax definition
- 関連するASN.1構文の定義 - 特定のオブジェクトへのOIDの割り当てをして以下に与えられます。
-- OID used referencing electronic signature mechanisms based on this -- standard for use with the IDUP API (see annex D)
- OIDは、これに基づいて電子署名メカニズムを参照する使用 - IDUP APIで使用するための標準（付属書Dを参照のこと）
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) }
-- CMS Attributes Defined in this document
-- =======================================
-- Mandatory Electronic Signature Attributes
- 必須の電子署名の属性
-- OtherSigningCertificate
- OtherSigningCertificate
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 19 }
OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THIS DOCUMENT
}
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL
}
OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue
}
OtherHashValue ::= OCTET STRING
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue
}
-- Signature Policy Identifier
- 署名方針識別子
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 }
"SignaturePolicy CHOICE { SignaturePolicyId SignaturePolicyId, SignaturePolicyImplied SignaturePolicyImplied }
「SignaturePolicy CHOICE {SignaturePolicyId SignaturePolicyId、SignaturePolicyImplied SignaturePolicyImplied}
SignaturePolicyId ::= SEQUENCE {
sigPolicyIdentifier SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL
}
SignaturePolicyImplied ::= NULL
SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyHash ::= OtherHashAlgAndValue
SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId
}
SigPolicyQualifierId ::=
OBJECT IDENTIFIER
id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 }
SPuri ::= IA5String
id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 2 }
SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL }
NoticeReference OPTIONAL、explicitTextの表示テキストOPTIONAL} noticeRef
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER
}
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200))
}
-- Optional Electronic Signature Attributes
- オプションの電子署名の属性
-- Commitment Type
- コミットメントタイプ
id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}
CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
CommitmentTypeQualifier OPTIONAL
}
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeQualifier ::= SEQUENCE {
commitmentTypeIdentifier CommitmentTypeIdentifier,
qualifier ANY DEFINED BY commitmentTypeIdentifier
}
id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 1}
id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 2}
id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 3}
id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member- body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 4}
id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 5}
id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
cti(6) 6}
-- Signer Location
- サインレンタル
id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 17}
SignerLocation ::= SEQUENCE {
-- at least one of the following must be present
countryName [0] DirectoryString OPTIONAL,
-- as used to name a Country in X.500
localityName [1] DirectoryString OPTIONAL,
-- as used to name a locality in X.500
postalAdddress [2] PostalAddress OPTIONAL
}
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString
-- Signer Attributes
- 署名者の属性
id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}
SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes
}
ClaimedAttributes ::= SEQUENCE OF Attribute
CertifiedAttributes ::= AttributeCertificate -- as defined in X.509 :
see section 10.3
-- Content Time-Stamp
- コンテンツタイムスタンプ
id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 20}
ContentTimestamp::= TimeStampToken
-- Validation Data
- 検証データ
-- Signature Time-Stamp
- 署名のタイムスタンプ
id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 14}
SignatureTimeStampToken ::= TimeStampToken
-- Complete Certificate Refs.
- 証明書参考文献を完了します。
id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}
CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID
-- Complete Revocation Refs
- 完全失効参考文献
id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 22}
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL
}
CRLListID ::= SEQUENCE {
crls SEQUENCE OF CrlValidatedID}
CrlValidatedID ::= SEQUENCE {
crlHash OtherHash,
crlIdentifier CrlIdentifier OPTIONAL
}
CrlIdentifier ::= SEQUENCE {
crlissuer Name,
crlIssuedTime UTCTime,
crlNumber INTEGER OPTIONAL
}
OcspListID ::= SEQUENCE {
ocspResponses SEQUENCE OF OcspResponsesID}
OcspResponsesID OF ocspResponses SEQUENCE}
OcspResponsesID ::= SEQUENCE {
ocspIdentifier OcspIdentifier,
ocspRepHash OtherHash OPTIONAL
}
OcspIdentifier ::= SEQUENCE {
ocspResponderID ResponderID,
-- as in OCSP response data
producedAt GeneralizedTime
-- as in OCSP response data
}
OtherRevRefs ::= SEQUENCE {
otherRevRefType OtherRevRefType,
otherRevRefs ANY DEFINED BY otherRevRefType
}
OtherRevRefType ::= OBJECT IDENTIFIER
-- Certificate Values
- 証明書の値
id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}
CertificateValues ::= SEQUENCE OF Certificate
-- Certificate Revocation Values
- 証明書失効値
id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 24}
RevocationValues ::= SEQUENCE {
crlVals [0] SEQUENCE OF CertificateList OPTIONAL,
ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
otherRevVals [2] OtherRevVals
}
OtherRevVals ::= SEQUENCE {
otherRevValType OtherRevValType,
otherRevVals ANY DEFINED BY otherRevValType
}
OtherRevValType ::= OBJECT IDENTIFIER
-- ES-C Time-Stamp id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25}
ESCTimeStampToken ::= TimeStampToken
-- Time-Stamped Certificates and CRLs
- タイムスタンプ付きの証明書およびCRL
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 26}
TimestampedCertsCRLs ::= TimeStampToken
-- Archive Time-Stamp
- アーカイブタイムスタンプ
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 27}
ArchiveTimeStampToken ::= TimeStampToken
END -- ETS-ElectronicSignatureFormats-88syntax --
END - ETS-電子署名フォーマット-88構文 -
A.2 Definitions Using X.680 1997 ASN.1 Syntax
X.680 1997 ASN.1構文を使用したA.2の定義
NOTE: The ASN.1 module defined in clause A.1 has precedence over that defined in clause A.2 in the case of any conflict.
注：節A.1で定義されたASN.1モジュールは、いずれの紛争の場合の節A.2に定義されているものよりも優先されます。
ETS-ElectronicSignatureFormats-97Syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 6}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS All -
- すべてのエクスポート -
IMPORTS
輸入
-- Cryptographic Message Syntax (CMS): RFC 2630
- 暗号メッセージ構文（CMS）：RFC 2630
ContentInfo, ContentType, id-data, id-signedData, SignedData, EncapsulatedContentInfo, SignerInfo, id-contentType, id-messageDigest, MessageDigest, id-signingTime, SigningTime, id-countersignature, Countersignature
ContentInfo、ContentTypeを、IDデータ、ID-たsignedData、のSignedData、EncapsulatedContentInfo、のSignerInfo、ID-のcontentType、ID-するMessageDigest、するMessageDigest、ID-signingTime、SigningTime、ID-副署、副署
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
暗号メッセージ構文FROM {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）CMS（1）}
-- ESS Defined attributes: RFC 2634 (Enhanced Security Services -- for S/MIME)
- ESS定義された属性：RFC 2634（拡張セキュリティサービス - S / MIME用）
id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-contentReference, ContentReference, id-aa-contentIdentifier, ContentIdentifier
ID-AA-signingCertificate、SigningCertificate、IssuerSerial、ID-AA-contentReference、ContentReference、ID-AA-contentIdentifier、ContentIdentifier
FROM ExtendedSecurityServices { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
ExtendedSecurityServices {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）ESS（2）} FROM
-- Internet X.509 Public Key Infrastructure - - Certificate and CRL Profile:RFC 2459
- インターネットX.509公開鍵基盤 - - 証明書とCRLプロフィール：RFC 2459
Certificate, AlgorithmIdentifier, CertificateList, Name, GeneralNames, GeneralName, DirectoryString, Attribute, AttributeTypeAndValue, AttributeType, AttributeValue, PolicyInformation.
証明書、のAlgorithmIdentifier、CertificateListの、名前、GeneralNames、のGeneralName、DirectoryString、属性、AttributeTypeAndValue、AttributeTypeで、AttributeValueの、PolicyInformation。
FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
PKIX1Explicit93 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-明示-88（1）} FROM
-- X.509 '97 Authentication Framework
- X.509 '97認証フレームワーク
AttributeCertificate
AttributeCertificate
FROM AuthenticationFramework {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}
AuthenticationFramework FROM {関節-ISO-CCITTのDS（5）モジュール（1）authenticationFramework（7）3}
-- OCSP 2560
- OCSP 2560
BasicOCSPResponse, ResponderID
BasicOCSPResponse、ResponderID
FROM OCSP
OCSP FROM
-- { OID not assigned }
- {OID割り当てられていません}
-- Time Stamp Protocol Work in Progress TimeStampToken
- プログレスTimeStampTokenの中にタイムスタンププロトコルの仕事
FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
PKIXTSP FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-TSP（13）}
-- S/MIME Object Identifier arcs used in this document
-- ===================================================
-- S/MIME OID arc used in this document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier
-- Definitions of Object Identifier arcs used in this document
-- ===========================================================
-- The allocation of OIDs to specific objects are given below with the -- associated ASN.1 syntax definition
- 関連するASN.1構文の定義 - 特定のオブジェクトへのOIDの割り当てをして以下に与えられます。
-- OID used referencing electronic signature mechanisms based on this -- standard for use with the IDUP API (see annex D)
- OIDは、これに基づいて電子署名メカニズムを参照する使用 - IDUP APIで使用するための標準（付属書Dを参照のこと）
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) }
-- CMS Attributes Defined in this document
-- =======================================
-- Mandatory Electronic Signature Attributes -- OtherSigningCertificate
- 必須の電子署名属性 - OtherSigningCertificate
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 19 }
OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THIS DOCUMENT
}
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL
}
OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue
}
OtherHashValue ::= OCTET STRING
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue
}
-- Signature Policy Identifier
- 署名方針識別子
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 }
"SignaturePolicy CHOICE { SignaturePolicyId SignaturePolicyId, SignaturePolicyImplied SignaturePolicyImplied }
「SignaturePolicy CHOICE {SignaturePolicyId SignaturePolicyId、SignaturePolicyImplied SignaturePolicyImplied}
SignaturePolicyId ::= SEQUENCE {
sigPolicyIdentifier SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL
}
SignaturePolicyImplied ::= NULL
SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyHash ::= OtherHashAlgAndValue
SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id
({SupportedSigPolicyQualifiers}),
qualifier SIG-POLICY-QUALIFIER.&Qualifier
({SupportedSigPolicyQualifiers}
{@sigPolicyQualifierId})OPTIONAL }
SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::=
{ noticeToUser | pointerToSigPolSpec }
SIG-POLICY-QUALIFIER ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Qualifier OPTIONAL }
WITH SYNTAX { SIG-POLICY-QUALIFIER-ID &id [SIG-QUALIFIER-TYPE &Qualifier] }
構文{SIG-POLICY-QUALIFIER-ID＆ID [SIG-QUALIFIER-TYPE＆修飾子]} WITH
noticeToUser SIG-POLICY-QUALIFIER ::= {
SIG-POLICY-QUALIFIER-ID id-sqt-unotice SIG-QUALIFIER-TYPE
SPUserNotice
}
pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= {
SIG-POLICY-QUALIFIER-ID id-sqt-uri SIG-QUALIFIER-TYPE SPuri }
id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 }
SPuri ::= IA5String
id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 2 }
SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL
}
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER
}
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200))
}
-- Optional Electronic Signature Attributes
- オプションの電子署名の属性
-- Commitment Type id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}
CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
CommitmentTypeQualifier
OPTIONAL}
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeQualifier ::= SEQUENCE {
commitmentQualifierId COMMITMENT-QUALIFIER.&id,
qualifier COMMITMENT-QUALIFIER.&Qualifier
OPTIONAL }
COMMITMENT-QUALIFIER ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Qualifier OPTIONAL }
WITH SYNTAX {
COMMITMENT-QUALIFIER-ID &id
[COMMITMENT-TYPE &Qualifier] }
id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 1}
id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 2}
id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 3}
id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 4}
id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 5}
id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) cti(6) 6}
-- Signer Location id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17}
SignerLocation ::= SEQUENCE {
-- at least one of the following must be present
countryName [0] DirectoryString OPTIONAL,
-- As used to name a Country in X.500
localityName [1] DirectoryString OPTIONAL,
-- As used to name a locality in X.500
postalAdddress [2] PostalAddress OPTIONAL }
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString
-- Signer Attributes
- 署名者の属性
id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}
SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes }
ClaimedAttributes ::= SEQUENCE OF Attribute
CertifiedAttributes ::= AttributeCertificate
-- As defined in X.509 : see section 10.3
-- Content Time-Stamp
- コンテンツタイムスタンプ
id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 20}
ContentTimestamp::= TimeStampToken
-- Validation Data
- 検証データ
-- Signature Time-Stamp
- 署名のタイムスタンプ
id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 14}
SignatureTimeStampToken ::= TimeStampToken
-- Complete Certificate Refs.
- 証明書参考文献を完了します。
id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}
米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）ID-AA（2）21}
CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID
-- Complete Revocation Refs
- 完全失効参考文献
id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL
}
CRLListID ::= SEQUENCE {
crls SEQUENCE OF CrlValidatedID}
CrlValidatedID ::= SEQUENCE {
crlHash OtherHash,
crlIdentifier CrlIdentifier OPTIONAL}
CrlIdentifier ::= SEQUENCE {
crlissuer Name,
crlIssuedTime UTCTime,
crlNumber INTEGER OPTIONAL
}
OcspListID ::= SEQUENCE {
ocspResponses SEQUENCE OF OcspResponsesID}
OcspResponsesID ::= SEQUENCE {
ocspIdentifier OcspIdentifier,
ocspRepHash OtherHash OPTIONAL
}
OcspIdentifier ::= SEQUENCE {
ocspResponderID ResponderID,
-- As in OCSP response data
producedAt GeneralizedTime
-- As in OCSP response data
}
OtherRevRefs ::= SEQUENCE {
otherRevRefType OTHER-REVOCATION-REF.&id,
otherRevRefs OTHER-REVOCATION-REF.&Type
}
｝
OTHER-REVOCATION-REF ::= CLASS {
&Type,
&id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX {
&Type ID &id }
-- Certificate Values
- 証明書の値
id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}
CertificateValues ::= SEQUENCE OF Certificate
-- Certificate Revocation Values
- 証明書失効値
id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1)
member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 24}
RevocationValues ::= SEQUENCE {
crlVals [0] SEQUENCE OF CertificateList OPTIONAL,
ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
otherRevVals [2] OtherRevVals }
OtherRevVals ::= SEQUENCE {
otherRevValType OTHER-REVOCATION-VAL.&id,
otherRevVals OTHER-REVOCATION-VAL.&Type
}
OTHER-REVOCATION-VAL ::= CLASS {
&Type,
&id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX {
&Type ID &id }
-- ES-C Time-Stamp
- ES-Cタイムスタンプ
id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 25}
ESCTimeStampToken ::= TimeStampToken
-- Time-Stamped Certificates and CRLs
- タイムスタンプ付きの証明書およびCRL
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 26}
TimestampedCertsCRLs ::= TimeStampToken
-- Archive Time-Stamp
- アーカイブタイムスタンプ
id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1)
member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 27}
ArchiveTimeStampToken ::= TimeStampToken
END -- ETS-ElectronicSignatureFormats-97Syntax
END - ETS-ElectronicSignatureFormats-97Syntax
Annex B (informative): General Description
附属書B（参考）：一般的な説明
This annex captures the concepts that apply to this document and the rational for the elements of the specification defined using ASN.1 in the main text of this document.
この附属書は、この文書とこの文書の本文にASN.1を使用して定義された仕様の要素のための合理的に適用される概念をキャプチャします。
The specification below includes a description why the component is needed, with a brief description of the vulnerabilities and threats and the manner by which they are countered.
仕様は以下のコンポーネントが脆弱性および脅威の簡単な説明及びそれらが相殺される方法で、必要とされる理由の説明を含みます。
B.1 The Signature Policy
B.1署名ポリシー
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. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. 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. Alternatively, a signature policy may be established through an electronic trading association for use amongst its members. Both the signer and verifier use the same signature policy.
署名ポリシーは、署名が有効であると判断することができるの下で電子署名の生成及び検証のためのルールのセットです。与えられた法的/契約コンテキストは、その要件を満たすように特定の署名ポリシーを認識することができます。署名ポリシーは、電子署名に依拠当事者によって、例えば、発行され、その信頼当事者と使用するための署名者によって選択されてもよいです。あるいは、署名ポリシーは、そのメンバーの間で使用するための電子取引協会によって確立されてもよいです。署名者と検証者の両方が同じ署名ポリシーを使用します。
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.
署名ポリシーは、明示的に識別してもよいし、署名されたデータ自体は署名ポリシーを指す参照されている契約のような他の外部データのセマンティクスによって暗示されてもよいです。
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.
明示的な署名ポリシーは、署名計算の一部として、署名者の電子署名に結合している、グローバルに一意の参照を有します。
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. 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 needs to be in a computer processable form.
署名ポリシーは、適用された法的及び契約コンテキストの要件を満たすように評価することができるように人間が読める形式で利用可能である必要があります。電子署名の自動処理を容易にするために、電子署名の生成および検証のために電子規則を指定署名ポリシーの部分は、コンピュータ処理可能形式であることが必要です。
The signature policy thus includes the following:
署名ポリシーは、このように次のものが含まれます。
* Information about the signature policy that can be displayed to the signer or the verifiers. * Rules, which apply to functionality, covered by this document (referred to as the Signature Validation Policy). * Rules which 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). * Rules, which 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.
*署名者または検証者に表示することができます署名ポリシーに関する情報。この文書によって覆わ機能に適用*ルールは、（署名検証ポリシーと呼ばれます）。 *電子署名に適用する証明書ポリシーの採用により暗示することができるルール（例えば、秘密署名鍵の秘匿性を確保するためのルール）。 *署名者によって使用される環境に関連する規則、例えば、スマートカードと組み合わせて使用同意したCAD（カード受付装置）の使用。
An explicit Signature Validation Policy may be structured so that it can be computer processable. Any format of the signature validation policy is allowed by this document. However, for a given explicit signature policy there must be one definitive form that has a unique binary encoded value.
それは、コンピュータ処理可能になるように、明示的な署名の確認ポリシーを構成してもよいです。署名検証ポリシーのいずれかの形式は、この文書で許可されています。しかし、与えられた明示的な署名ポリシーの一意のバイナリ符号化された値を有するもの決定的な形態が存在しなければなりません。
The Signature Validation Policy includes rules regarding use of TSPs (CA, Attribute Authorities, Time Stamping Authorities) as well as rules defining the components of the electronic signature that must be provided by the signer with data required by the verifier to provide long term proof.
署名検証ポリシーのTSPの使用（CA、権限属性、タイムスタンプ機関）ならびに長期的証拠を提供するために、検証に必要なデータと署名者によって提供されなければならない電子署名のコンポーネントを定義するルールに関するルールを含みます。
B.2 Signed Information
B.2署名情報
The information being signed may be defined as a MIME-encapsulated message which can be used to signal the format of the content in order to select the right display or application. It can be composed of formatted text (e.g., EDIFACT), free text or of fields from an electronic form (e-form). For example, the Adobe(tm) format "pdf" may be used or the eXtensible Mark up Language (XML).
署名される情報は、権利表示又はアプリケーションを選択するためにコンテンツのフォーマットを通知するために使用することができるMIMEでカプセル化されたメッセージとして定義することができます。これは、テキスト形式（例えば、EDIFACT）、フリーテキストまたは電子フォーム（電子フォーム）からのフィールドで構成することができます。例えば、アドビシステムズ社（TM）形式「PDF」を使用してもよいし、拡張マークアップ言語（XML）。
B.3 Components of an Electronic Signature
電子署名のB.3コンポーネント
B.3.1 Reference to the Signature Policy
署名ポリシーへB.3.1リファレンス
The definition of electronic signature includes: "a commitment has been explicitly endorsed under a "Signature policy", at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role".
電子署名の定義は、「識別子、例えば、名前または仮名、および任意のロールの下で署名者によって、所定の時間に、 『署名ポリシー』コミットメントが明示的に下に承認されました」。
When two independent parties want to evaluate an electronic signature, it is fundamental that they get the same result. To meet this requirement same signature policy must be used by the signer and verifier.
二つの独立した当事者が電子署名を評価したい場合には、彼らが同じ結果を得ることを基本です。この要件同じ署名ポリシーを満たすために、署名者と検証で使用する必要があります。
The signature policy may be explicitly identified or may be implied by the semantics of the data being signed and other external data which designate the signature policy to be used.
署名ポリシーは、明示的に識別してもよいし、署名され、署名ポリシーを指定する他の外部データを使用するデータの意味論によって暗示されてもよいです。
By signing over the signature policy identifier the signer explicitly indicates that he or she has applied the signature policy in creating the signature. Thus, undertakes any explicit or implied commitments.
署名ポリシー識別子の上に署名することにより、署名者は、明示的に彼または彼女が署名を作成する際に署名ポリシーを適用していることを示しています。このように、明示的または暗黙の約束を行っています。
In order to unambiguously identify an explicit signature policy that is to be used to verify the signature an identifier and hash of the "Signature policy" shall be part of the signed data. Additional information about the explicit policy (e.g., web reference to the document) may be carried as "qualifiers" to the signature policy identifier.
一義的識別子と「署名ポリシー」のハッシュ署名を検証するために使用される明示的な署名ポリシーを識別するために署名されたデータの一部でなければなりません。明示的ポリシー（文書に例えば、ウェブ参照）に関する追加情報は、署名ポリシー識別子を「修飾子」として実施することができます。
When the signature policy not explicitly identified, but is implied by the semantics of the data being signed, then the signature will include a signature policy identifier that indicates that the signature policy is implied. In this case the verification rules must be determined by using other external data which will designate the signature policy to be used. If it may be determined from the context that all the documents to be verified refer to the same signature policy, then that policy may be predetermined or fixed within the application.
署名ポリシーが明示的に識別されたが、署名されるデータのセマンティクスによって暗示されていない場合、その後の署名は、署名ポリシーが暗示されていることを示す署名ポリシーの識別子を含むことになります。この場合、検証ルールは、使用する署名ポリシーを指定するであろう他の外部データを用いて決定されなければなりません。それが確認されるすべての文書が同じ署名ポリシーを参照してコンテキストから決定することができる場合、そのポリシーは、所定の又はアプリケーション内に固定されてもよいです。
In order to identify unambiguously the "Signature Validation Policy" to be used to verify the signature an identifier and hash of the "Signature policy" must be part of the signed data. Additional information about the policy (e.g., web reference to the document) may be carried as "qualifiers" to the signature policy identifier.
明確に「署名ポリシー」の識別子ハッシュが署名されたデータの一部でなければならない署名を検証するために使用される「署名検証ポリシー」を識別するために。ポリシー（文書に例えば、ウェブ参照）に関する追加情報は、署名ポリシー識別子を「修飾子」として実施することができます。
B.3.2 Commitment Type Indication
B.3.2コミットメントタイプ表示
The definition of electronic signature includes: "a commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role".
電子署名の定義は、「コミットメントを明示的識別子、例えば、名前または仮名、および任意のロールの下で署名者によって、所与の時間に、署名ポリシーの下で承認されました」。
The commitment type can be indicated in the electronic signature either:
コミットメントタイプは、電子署名のいずれかで示すことができます。
* explicitly using a "commitment type indication" in the electronic signature;
*明示的に電子署名における「コミットメントタイプ表示」を使用して、
* implicitly or explicitly from the semantics of the signed data.
*暗黙的または明示的に署名されたデータの意味から。
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. The semantics of explicit commitment types indications must be specified either as part of the signature policy or may be registered for generic use across multiple policies.
示されたコミットメントタイプが電子署名の「コミットメントタイプ指示」を使用して明示的であれば、検証署名の受け入れは、そのコミットメントタイプの意味論の受け入れを意味しています。明示的なコミットメントタイプ表示の意味は、いずれかの署名ポリシーの一部として指定しなければならないか、または複数のポリシー間で一般的な使用のために登録することができます。
If a signature includes a commitment type indication other than one of those recognized under the signature policy the signature must be treated as invalid.
署名は、署名が無効として扱われなければならない署名ポリシーの下で認識されるものの以外のコミットメントタイプの指示を含む場合。
How commitment is indicated using the semantics of the data being signed is outside the scope of this document.
どのようなコミットメントが署名されているデータのセマンティクスを使用して示され、このドキュメントの範囲外です。
NOTE: Examples of commitment indicated through the semantics of the data being signed, are:
注：署名されているデータの意味論によって示されたコミットメントの例としては、以下のとおりです。
* An explicit commitment made by the signer indicated by the type of data being signed over. Thus, the data structure being signed can have an explicit commitment within the context of the application (e.g., EDIFACT purchase order).
*データの種類によって示さ署名者によって行われた明示的なコミットメントは、上署名されます。このように、署名されるデータ構造は、アプリケーション（例えば、EDIFACTの購入注文）のコンテキスト内で明示的なコミットメントを有することができます。
* An implicit commitment which 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).
*人間によってのみ解釈され、データがオーバー署名されているので、署名者によって行われたコミットメントが特定の意味は（意味）がある暗黙の約束、（すなわち、フリーテキスト）。
B.3.3 Certificate Identifier from the Signer
署名者からB.3.3証明書識別子
The definition of the ETSI electronic signature includes: "a commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role."
ETSI電子署名の定義は、「コミットメントが明示的識別子、例えば、名前または仮名、および必要に応じて役割の下に署名者によって、所与の時間に、署名ポリシーの下で承認されました。」
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. The prime advantage is that a user can use the same private key for different purposes. 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. When several CAs are involved, each different certificate may contain a different identity, e.g., as a national or as an employee from a company. 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. Where there is the possibility of multiple use of private keys it is necessary for the signer to indicate to the verifier the precise certificate to be used.
多くの実際の生活環境では、ユーザーが異なるCAから、あるいは同じCAから取得することができます、別の名前に同じ公開鍵を含む証明書が異なります。プライム利点は、ユーザが異なる目的のために同じ秘密鍵を使用することができるということです。スマートカードのストレージが常に限られているため、秘密鍵の複数使用は、スマートカードが秘密鍵を保護するために使用されるという利点があります。いくつかのCAが含まれている場合は、それぞれ異なる証明書は、国家や企業から従業員などとして、例えば、異なるIDが含まれていてもよいです。秘密鍵は様々な目的に使用する場合したがって、証明書は、署名を生成する際に、秘密鍵が使用されたコンテキストを明確にするために必要とされます。秘密鍵の複数使用の可能性がある場合、署名者は、検証に使用される精密な証明書を示すことが必要です。
Many current schemes simply add the certificate after the signed data and thus are subject to various substitution attacks. An example of a substitution attack is a "bad" CA that would issue a certificate to someone with the public key of someone else. If the certificate from the signer was simply appended to the signature and thus not protected by the signature, any one could substitute one certificate by another and the message would appear to be signed by some one else.
現在の多くのスキームは、単純に署名されたデータの後に証明書を追加し、これ様々な置換攻撃の対象となっています。置換攻撃の例は、他の誰かの公開鍵を持つ人に証明書を発行し、「悪い」CAです。署名者の証明書が単に署名に付加し、従って署名によって保護されていなかった場合、いずれかが別のものの証明書を置き換えることができ、メッセージは他のいくつかのいずれかによって署名されるように思われます。
In order to counter this kind of attack, the identifier of the signer has to be protected by the digital signature from the signer.
この種の攻撃に対抗するために、署名者の識別子は、署名者からのデジタル署名によって保護されなければなりません。
Although it does not provide the same advantages as the previous technique, another technique to counter that threat has been identified. It requires all CAs to perform a Proof Of Possession of the private key at the time of registration. The problem with that technique is that it does not provide any guarantee at the time of verification and only some proof "after the event" may be obtained, if and only if the CA keeps the Proof Of Possession in audit trail.
それは、以前の技術と同じ利点を提供していませんが、その脅威に対抗するために、別の技術が同定されています。これは、登録時に秘密鍵を所有していることの証明を行うために、すべてのCAが必要です。その技術の問題点は、検証時にいずれかの保証を提供していないと、CAは、監査証跡に所持の証明を保持した場合にのみ場合は、「イベントの後」のみいくつかの証拠は、入手することができるということです。
In order to identify unambiguously the certificate to be used for the verification of the signature an identifier of the certificate from the signer must be part of the signed data.
明確署名の検証署名者の証明書の識別に使用される証明書を識別するために署名されたデータの一部でなければなりません。
B.3.4 Role Attributes
B.3.4役割の属性
The definition of electronic signature includes: "a commitment has been explicitly endorsed under a non repudiation security policy, at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role."
電子署名の定義は、「コミットメントが明示的識別子、例えば、名前または仮名、および必要に応じて役割の下に署名者によって、所与の時間に、否認防止のセキュリティポリシーの下で承認されました。」
While the name of the signer is important, the position of the signer within a company or an organization can be even more important. Some contracts may only be valid if signed by a user in a particular role, e.g., a Sales Director. In many cases whom 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.
署名者の名前は重要であるが、会社や組織内の署名者の位置が一層重要になることがあります。特定の役割、例えば、セールスディレクターで、ユーザが署名した場合、一部の契約にのみ有効です。多くの場合、誰営業部長は本当に、その重要ではなく、署名者はセールスディレクターが基本であることを彼の会社によって権限を与えられていることを確認しています。
This document defines two different ways for providing this feature:
この文書では、この機能を提供するための2つの異なる方法を定義します。
* by placing a claimed role name in the CMS signed attributes field;
* CMSに記載のロール名を配置することにより、属性フィールドに署名しました。
* by placing a attribute certificate containing a certified role name in the CMS signed attributes field.
* CMSに認定されたロール名を含む属性証明書を配置することにより、属性フィールドに署名しました。
NOTE: Another possible approach would have been to use additional attributes containing the roles name(s) in the signer's certificate. However, it was decided not to follow this approach as it breaks the basic philosophy of the certificate being issued for one primary purpose. Also, by using separate certificates for management of the signer's identity certificate and management of additional roles can simplify the management, as new identity keys need not be issued if a use of role is to be changed.
注：別の可能なアプローチは、署名者の証明書に役割名（複数可）を含む追加の属性を使用することであっただろう。しかし、それは1主な目的のために発行された証明書の基本的な考え方を壊すとして、このアプローチに従うことではないことを決めました。また、役割の使用を変更する場合、新しいアイデンティティ・キーが発行する必要がないよう、管理を簡素化することができ、追加の役割の署名者の身元証明書の管理と管理のために別々の証明書を使用します。
B.3.4.1 Claimed Role
B.3.4.1主張役割
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.
署名者はこの主張を裏付けるためにすべての証明書なしで自分の役割を述べるために信頼することができます。この場合に記載役割は、署名された属性として署名に追加することができます。
B.3.4.2 Certified Role
B.3.4.2認定役割
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. An Attribute Certificate is NOT issued by a CA but by an Attribute Authority (AA). The Attribute Authority will be most of the time under the control of an organization or a company that is best placed to know which attributes are relevant for which individual.
公開鍵に識別子を結合し、公開鍵証明書とは異なり、属性証明書は、役割のように、いくつかの属性に証明書の識別子をバインドします。属性証明書は、CAによってではなく、属性認証局（AA）によって発行されていません。属性権限は、組織または最高のどの個々に関連する属性を知るために配置された会社の管理下にほとんどの時間になります。
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. Attribute Certificates may have various periods of validity. That period may be quite short, e.g., one day. While this requires that a new Attribute Certificate is obtained every day, valid for that day, this can be advantageous since revocation of such certificates may not be needed. When signing, the signer will have to specify which Attribute Certificate it selects. In order to do so, a reference to the Attribute Certificate will have to be included in the signed data in order to be protected by the digital signature from the signer.
当局は、任意のCAが発行した公開鍵証明書を使用したり、ポイントも属性は、適切な信頼は、そのCAに配置することができることを提供しました属性証明書は、有効性の様々な期間を有することができます。その期間は、例えば、1日はかなり短くてもよいです。これは新しい属性証明書は、その日のために有効な、毎日得ていることが必要ですが、このような証明書の失効が必要とされない可能性があるため、これは有利です。署名するとき、署名者は、証明書は、それが選択した属性を指定する必要があります。そうするために、属性証明書への言及は、署名者からのデジタル署名で保護するために、署名されたデータに含まれなければなりません。
In order to identify unambiguously the attribute certificate(s) to be used for the verification of the signature an identifier of the attribute certificate(s) from the signer must be part of the signed data.
明確署名の検証に使用される属性証明書（複数可）を識別するために署名者からの属性証明書（複数可）の識別子は、署名されたデータの一部でなければなりません。
B.3.5 Signer Location
B.3.5署名者の場所
In some transactions the purported location of the signer at the time he or she applies his signature may need to be indicated. For this reason an optional location indicator must be able to be included.
いくつかの取引では、彼または彼女は彼の署名を適用する際に、署名者の主張場所を示すことが必要になる場合があります。このため、オプションの位置インジケータが含まれることができなければなりません。
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.
一度署名者の位置の表示を提供するために彼または彼女は、場所属性が署名に含まれる彼の署名を適用します。
B.3.6 Signing Time
B.3.6署名タイム
The definition of electronic signature includes: "a commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role."
電子署名の定義は、「コミットメントが明示的識別子、例えば、名前または仮名、および必要に応じて役割の下に署名者によって、所与の時間に、署名ポリシーの下で承認されました。」
There are several ways to address this problem. The solution adopted in this document is to sign over a time which the signer claims is the signing time (i.e., claimed signing time) and to require a trusted time stamp to be obtained when building a ES with Time-Stamp. When a verifier accepts a signature, the two times must be within acceptable limits.
この問題に対処する方法はいくつかあります。この文書に採用溶液（すなわち、時間に署名記載）及びタイムスタンプとESを構築するときに得られる信頼できるタイムスタンプを要求する署名者の特許請求の範囲は、署名時間である時間に亘って署名することです。検証者は、署名を受け付けた場合、2回許容範囲内でなければなりません。
The solution that is adopted in this document offers the major advantage that electronic signatures can be generated without any on-line connection to a trusted time source (i.e., they may be generated off-line).
本書で採用されている解決策は、電子署名が信頼できる時間ソース（すなわち、それらはオフラインで生成されてもよい）へのオンライン接続することなく生成することができるという大きな利点を提供します。
Thus two dates and two signatures are required:
したがって、2つの日付と2人の署名が必要です。
* a signing time indicated by the signer and which is part of the data signed by the signer (i.e., part of the basic electronic signature);
*署名者とそれによって示される署名時刻が署名者によって署名されたデータ（すなわち、基本的な電子署名の一部）の一部です。
* a time indicated by a Time-Stamping Authority (TSA) which is signed over the digital signature value of the basic electronic signature. The signer, verifier or both may obtain the TSA time-stamp.
*基本的な電子署名のデジタル署名値より署名され、タイムスタンプ局（TSA）によって示された時間。署名者、検証または両方は、TSAのタイムスタンプを取得することができます。
In order for an electronic signature to be valid under a signature policy, it must be time-stamped by a TSA where the signing time as indicated by the signer and the time of time stamping as indicated by a TSA must be "close enough" to meet the requirements of the signature validation policy.
署名ポリシーの下で有効であるために、電子署名のためのためには、署名者によって示された時間の時間がTSAによって示されるようにスタンピングとして署名時間が「十分に近い」ものでなければならないTSAによってタイムスタンプでなければなりません署名検証ポリシーの要件を満たしています。
"Close enough" means a few minutes, hours or even days according to the "Signature Validation Policy".
「十分に近い」「署名検証の方針」によると、数分、数時間または数日を意味します。
NOTE: The need for Time-Stamping is further explained in clause B.4.5. A further optional attribute is defined in this document to time-stamp the content, to provide proof of the existence of the content, at the time indicated by the time-stamp.
注：タイムスタンプの必要性はさらに節B.4.5で説明されています。さらにオプションの属性は、タイムスタンプによって示される時刻に、コンテンツの存在の証拠を提供するために、コンテンツのタイムスタンプこの文書で定義されています。
Using this optional attribute a trusted secure time may be obtained before the document is signed and included under the digital signature. This solution requires an on-line 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. 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 3.12.3, Content Time-Stamp).
文書が署名およびデジタル署名の下に含まれる前に、このオプションの属性を信頼できるセキュア時間を使用して得ることができます。この溶液は、署名を生成する前に、信頼できるタイムスタンプサービスへのオンライン接続を必要とし、それを事前に得ることができるので、正確な署名時間を表していてもよいです。ただし、このオプションの属性は、署名されたオブジェクトは（3.12.3、コンテンツタイムスタンプを参照）、タイムスタンプに含まれた日付より前に存在したことを証明するために、署名者が使用することができます。
Also, the signing time should be between the time indicated by this time-stamp and time indicated by the ES-T time-stamp.
また、署名時間は、ES-Tのタイムスタンプによって示され、このタイムスタンプ及び時間によって示される時間の間であるべきです。
B.3.7 Content Format
B.3.7コンテンツフォーマット
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. In order for the appropriate representation (text, sound or video) to be selected by the relying party a content hint may be indicated by the signer. If a relying party system does not use the format specified in the content hints to present the data to the relying party, the electronic signature may not be valid.
人間のユーザに署名されたデータを提示する場合には、証明書利用者に署名した情報の提示に関しては何の曖昧さがないことが重要です。依拠当事者によって選択される適切な表現（テキスト、音声またはビデオ）ためには、コンテンツのヒントは、署名者によって示されてもよいです。証明書利用者のシステムは、証明書利用者にデータを提示するコンテンツのヒントで指定された形式を使用していない場合は、電子署名が有効でない場合があります。
B.4 Components of Validation Data
検証データのB.4コンポーネント
B.4.1 Revocation Status Information
B.4.1失効ステータス情報
A verifier will have to prove that the certificate of the signer was valid at the time of the signature. This can be done by either:
検証者は、署名者の証明書が署名の時点で有効であったことを証明する必要があります。これは、いずれかの方法で行うことができます。
* using Certificate Revocation Lists (CRLs);
*証明書失効リスト（CRL）を使用しました。
* using responses from an on-line certificate status server (for example; obtained through the OCSP protocol).
*オンライン証明書ステータスサーバからの応答を使用して（例えば、OCSPプロトコルを介して得られます）。
B.4.2 CRL Information
B.4.2 CRL情報
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. This should be done as soon as possible to minimize the time delay between the generation and verification of the signature. This involves checking that the signer certificate serial number is not included in the CRL. The signer, the verifier or any other third party may obtain either this CRL. If obtained by the signer, then it must be conveyed to the verifier. It may be convenient to archive the CRL for ease of subsequent verification or arbitration.
失効情報を取得するために、CRLを使用している場合、彼または彼女は最初の検証時に署名者のCAから適切な証明書の失効情報を取得することを、検証者は、確認する必要がありますこれは、署名の生成と検証間の時間遅延を最小限に抑えるために、できるだけ早く行われるべきです。これは、署名者の証明書のシリアル番号がCRLに含まれていないことを確認する必要。署名者、検証者、またはその他の第三者のいずれか、このCRLを取得することができます。署名者によって得られた場合、それは検証者に伝えなければなりません。その後の検証や仲裁を容易にするためにCRLをアーカイブすると便利かもしれません。
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.
あるいは、CRLを仲裁する目的のためにアクセス可能である他の場所にアーカイブされて設けられ、その後、使用CRLのシリアル番号を確認する電子署名と一緒にアーカイブすることができます。
It may happen that the certificate serial number appears in the CRL but with the status "suspended" (i.e., on hold). In such a case, the electronic signature is not yet valid, since it is not possible to know whether the certificate will or will not be revoked at the end of the suspension period. If a decision has to be taken immediately then the signature has to be considered as invalid. If a decision can wait until the end of the suspension period, then two cases are possible:
証明書のシリアル番号がCRLに表示されていることが起こるが、ステータスが（すなわち、保留に）「一時停止」とのこと。証明書又は停止期間の終了時に失効されることはありませんかどうかを知ることができないので、このような場合には、電子署名は、まだ有効ではありません。決定はすぐに注意しなければならない場合、署名は無効であると考慮しなければなりません。決定は停止期間が終了するまで待つことができる場合には、2つのケースが考えられます。
* the certificate serial number has disappeared from the list and thus the certificate can be considered as valid and that CRL must be captured and archived either by the verifier or elsewhere and be kept accessible for the purpose of arbitration.
*証明書のシリアル番号がリストから消えてしまったので、証明書は有効であるとみなすことができると、そのCRLは、キャプチャされ、検証者または他の場所のいずれかにアーカイブおよび仲裁のためにアクセス可能に保持されなければなりません。
* the certificate serial number has been maintained on the list with the status definitively revoked and thus the electronic signature must be considered as invalid and discarded.
*証明書のシリアル番号が決定的に失効した状態でリストに維持されているので、電子署名は無効とみなされ、廃棄されなければなりません。
At this point the verifier may be convinced that he or she got a valid signature, but is not yet in a position to prove at a later time that the signature was verified as valid. Before addressing this point, an alternative to CRL is to use OCSP responses.
この時点で、ベリファイアは、彼または彼女は有効な署名を得たと確信することができるが、署名が有効であると確認されたことを後で証明する立場にはまだありません。この点を対処する前に、CRLの代わりに、OCSP応答を使用することです。
B.4.3 OCSP Information
B.4.3 OCSP情報
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". This should be done as soon as possible after the generation of the signature. The signer, the verifier or any other third party may fetch this OCSP response. Since OSCP 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. The simplest way is to store them associated with the electronic signature. An alternative would be to store them in some storage so that they can then be easily retrieved.
失効情報を取得するためにOCSPを使用した場合、検証は、彼または彼女は最初の検証「有効」の状態が含まれているOCSP応答の時間になることを確認する必要があります。これは、署名の生成後にできるだけ早く行う必要があります。署名者、検証やその他の第三者は、このOCSP応答をフェッチすることがあります。 OSCP応答は一過性であり、したがって、CAを含む任意のTSPによってアーカイブされていないので、それはすべての検証の責任は、それが安全な場所に格納されていることを確認することです。最も簡単な方法は、彼らが電子署名に関連付けられて格納することです。代替は、彼らはその後、容易に検索できるように、いくつかのストレージに保存することです。
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".
CRLの場合と同じようにして、証明書が無効であると宣言したが、第二の状態で「中断」されることが起こり得ます。
In such a case, the electronic signature is not yet valid, since it is not possible to know whether the certificate will or will not be revoked at the end of the suspension period. If a decision has to be taken immediately then the electronic signature has to be considered as invalid. If a decision can wait until the end of the suspension period, then two cases are possible:
証明書又は停止期間の終了時に失効されることはありませんかどうかを知ることができないので、このような場合には、電子署名は、まだ有効ではありません。決定はすぐに注意しなければならない場合は、電子署名が無効であると考慮しなければなりません。決定は停止期間が終了するまで待つことができる場合には、2つのケースが考えられます。
* An OCSP response with a valid status is obtained at a later date and thus the certificate can be considered as valid and that OCSP response must be captured.
*有効なステータスを持つOCSP応答は後日得られるので、証明書は有効であるとみなすことができると、そのOCSP応答が捕獲されなければなりません。
* An OCSP response with an invalid status is obtained with a secondary status indicating that the certificate is definitively revoked and thus the electronic signature must be considered as invalid and discarded.
*無効状態とOCSP応答は、証明書が決定的に取り消され、従って、電子署名が無効とみなされ、廃棄されなければならないことを示す二次の状態で得られます。
As in the CRL case, at this point, the verifier may be convinced that he or she got a valid signature, but is not yet in a position to prove at a later time that the signature was verified as valid.
CRLの場合のように、この時点では、検証は、彼または彼女は有効な署名を得たが、署名が有効であると確認されたことを後で証明する立場にいないことを確信することがあります。
B.4.4 Certification Path
B.4.4証明書のパス
A verifier will have to prove that the certification path was valid, at the time of the signature, up to a trust point according to the naming constraints and the certificate policy constraints from the "Signature Validation Policy". 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 of the "Signature Validation Policy". In addition, it will be necessary to capture the Authority Revocation Lists (ARLs) to prove than none of the CAs from the chain was revoked at the time of the signature.
検証者は、証明書パスは、「署名確認ポリシー」から命名制約と証明書ポリシーの制約に応じて、最大信頼ポイントに、署名の時点で、有効であったことを証明する必要があります。証明書パスからすべての証明書、署名者からのもので始まり、「署名検証ポリシー」の1つの信頼されたルートから自己署名証明書のものと終わるをキャプチャする必要があります。また、署名時に取り消された鎖からCAのどれよりも証明する権限失効リスト（ARLs）を捕捉するために必要であろう。
As in the OCSP case, at this point, the verifier may be convinced that he or she got a valid signature, but is not yet in a position to prove at a later time that the signature was verified as valid.
OCSPの場合のように、この時点では、検証は、彼または彼女は有効な署名を得たが、署名が有効であると確認されたことを後で証明する立場にいないことを確信することがあります。
B.4.5 Time-Stamping for Long Life of Signature
署名の長寿命化のためのB.4.5タイムスタンプ
An important property for long standing signatures is that a signature, having been found once to be valid, must continue to be so months or years later.
長年の署名のための重要な特性は有効であると、一度発見された、署名ということなので、数ヶ月または数年後であり続けなければなりません。
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 the all the certificates that make up the certificate path. In this case, the signer, verifier or both will also be required to provide proof that all the user and CA certificates used were not revoked when the signature was created or verified.
署名者、検証者またはその両方は、要求のデジタル署名が作成されるか、または証明書パスを構成するすべての証明書の有効期間中に確認されたことの証明を提供するために必要とされ得ます。この場合には、署名者、検証者、またはその両方はまた、署名が作成または確認された場合に使用されるすべてのユーザおよびCA証明書が失効していなかったことの証拠を提供するために必要とされるであろう。
It would be quite unacceptable, to consider a signature as invalid even if the keys or certificates were later compromised. Thus there is a need to be able to demonstrate that the signature keys was valid around the time that the signature was created to provide long term evidence of the validity of a signature.
それは、かなり受け入れられない鍵や証明書が後危険にさらされた場合でも、署名は無効として検討します。したがって、署名鍵は署名は、署名の有効性の長期的な証拠を提供するために作成された時期に有効であったことを実証することができるようにする必要があります。
It could be the case that a certificate was valid at the time of the signature but revoked some time later. In this event, evidence must be provided that the document was signed before the signing key was revoked.
これは、証明書が署名の時点で有効であったが、後いくつかの時間を取り消された場合である可能性があります。このイベントでは、証拠が署名鍵が取り消された前に、文書が署名されたことを提供しなければなりません。
Time-Stamping by a Time Stamping Authority (TSA) can provide such evidence. A time stamp is obtained by sending the hash value of the given data to the TSA. The returned "time-stamp" is a signed document that contains the hash value, the identity of the TSA, and the time of stamping. This proves that the given data existed before the time of stamping. 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 has been created before the key was revoked.
タイムスタンプ局（TSA）によるタイムスタンプは、そのような証拠を提供することができます。タイムスタンプは、TSAに与えられたデータのハッシュ値を送信することによって得られます。返された「タイムスタンプは、」ハッシュ値、TSAのアイデンティティ、およびスタンプの時間が含まれている署名された文書です。これは、与えられたデータは、スタンプの時間の前に存在していたことを証明しています。タイムスタンプ署名者の秘密鍵の失効前に（TSAへの署名のハッシュを送信することにより）デジタル署名は、キーが取り消された前の署名が作成されているという証拠を提供します。
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. The sooner the time-stamp is obtained after the signing time, the better.
受信者が有効な電子署名を保持したい場合、彼は彼がそのキー（および検証に関わる任意のキー）の前に、そのための有効なタイムスタンプを取得していることを確認する必要があります取り消されます。早くタイムスタンプが良く、署名時間後に得られます。
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. 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.
署名は、「オフライン」を生成し、署名または署名の値に興味が受信者によって、例えば、誰によって後でタイムスタンプされてもよいことに留意することが重要です。タイムスタンプは、このように署名された文書と一緒に署名者によって提供され、または署名された文書の受領後、受信者によって得ることができます。
The time stamp is NOT a component of the Electronic Signature, but the essential component of the ES with Time-Stamp.
タイムスタンプは、電子署名のコンポーネントが、タイムスタンプを持つESの必須成分ではありません。
It is required in this document that signer's digital signature value is time-stamped by a trusted source, known as a Time-Stamping Authority.
署名者のデジタル署名値は、タイムスタンプタイムスタンプ局として知られている信頼できるソースであること、この文書で必要とされます。
This document requires that the signer's digital signature value is time-stamped by a trusted source before the electronic signature can become a ES with Complete validation data (ES-C). The acceptable TSAs are specified in the Signature Validation Policy.
この文書では、署名者のデジタル署名値は、タイムスタンプ、電子署名は、完全な検証データ（ES-C）を有するESになることができる前に、信頼できるソースによるものであることを必要とします。許容のTSAは、署名確認ポリシーで指定されています。
Should both the signer and verifier be required to time-stamp the signature value to meet the requirements of the signature policy, the signature policy MAY specify a permitted time delay between the two time stamps.
署名者と検証者の両方が、タイムスタンプに署名ポリシーの要件を満たすために署名値を必要としなければならない、署名ポリシーは、2つのタイムスタンプ間の許容遅延時間を指定するかもしれません。
B.4.6 Time-Stamping before CA Key Compromises
CAキー妥協前B.4.6タイムスタンプ
Time-Stamped extended electronic signatures are needed when there is a requirement to safeguard against the possibility of a CA key in the certificate chain ever being compromised. A verifier may be required to provide on request, proof that the certification path and the revocation information used a the time of the signature were valid, even in the case where one of the issuing keys or OCSP responder keys is later compromised.
これまでに侵害される証明書チェーンにおけるCAキーの可能性から保護するための要件がある場合には、タイムスタンプ付きの拡張電子署名が必要とされています。検証者は、証明書パスと失効情報が署名の時間を使用することも証明発行キーまたはOCSPレスポンダキーのいずれかが後に危険にさらされた場合に、有効であったリクエストに応じて提供することが要求されてもよいです。
The current document defines two ways of using time-stamps to protect against this compromise:
現在のドキュメントには、この妥協から保護するためにタイムスタンプを使用しての二つの方法が定義されています。
* Time-Stamp the ES with Complete validation data, when an OCSP response is used to get the status of the certificate from the signer.
*タイムスタンプOCSP応答が署名者からの証明書のステータスを取得するために使用された完全な検証データとのES。
* Time-Stamp only the certification path and revocation information references when a CRL is used to get the status of the certificate from the signer.
CRLは署名者の証明書のステータスを取得するために使用される*タイムスタンプのみの証明パス及び失効情報の参照。
NOTE: the signer, verifier or both may obtain the time-stamp.
注：署名者、検証または両方のタイムスタンプを取得することができます。
B.4.6.1 Time-Stamping the ES with Complete validation data
完全な検証データとB.4.6.1タイムスタンプES
When an OCSP response is used, it is necessary to time stamp in particular that response in the case the key from the responder would be compromised. Since the information contained in the OCSP response is user specific and time specific, an individual time stamp is needed for every signature received. Instead of placing the time stamp only over the certification path references and the revocation information references, which include the OCSP response, the time stamp is placed on the ES-C. Since the certification path and revocation information references are included in the ES with Complete validation data they are also protected. For the same cryptographic price, this provides an integrity mechanism over the ES with Complete validation data. Any modification can be immediately detected. It should be noticed that other means of protecting/detecting the integrity of the ES with Complete Validation Data exist and could be used.
OCSP応答が使用される場合、それは応答場合にレスポンダから鍵が危険にさらされることを具体的にタイムスタンプする必要があります。 OCSPレスポンスに含まれる情報は、ユーザ特定および特定の時間であるため、個々のタイムスタンプは、受信されたすべての署名のために必要とされます。代わりのみOCSPレスポンスを含む認証パス参照と失効情報の参照、上にタイムスタンプを配置する、タイムスタンプは、ES-C上に配置されます。証明書パスと失効情報の参照が完全な検証データとESに含まれているので、彼らはまた、保護されています。同じ暗号価格については、これは完全な検証データを持つESオーバー整合性のメカニズムを提供します。任意の変更は、即座に検出することができます。完全な検証データとESの整合性を検出/保護の他の手段が存在し、使用することができることに注意すべきです。
Although the technique requires a time stamp for every signature, it is well suited for individual users wishing to have an integrity protected copy of all the validated signatures they have received.
技術はすべての署名のタイムスタンプが必要ですが、それは彼らが受け取ったすべての検証署名の完全性を保護コピーを持っているしたい個々のユーザーに適しています。
By time-stamping the complete electronic signature, including the digital signature as well as the references to the certificates and revocation status information used to support validation of that signature, the time-stamp ensures that there is no ambiguity in the means of validating that signature.
タイムスタンプデジタル署名を含む完全な電子署名、ならびにその署名の検証をサポートするために使用される証明書失効ステータス情報への参照をすることによって、タイムスタンプは、その署名を検証する手段、曖昧さのないことを保証します。
This technique is referred to as ES with eXtended validation data (ES-X), type 1 Time-Stamped in this document.
この技術は、拡張された検証データとES（ES-X）、タイプ1タイムスタンプ本書で呼ばれます。
NOTE: Trust is achieved in the references by including a hash of the data being referenced.
注：トラストは、参照されているデータのハッシュを含むことにより、参考文献に達成されます。
If it is desired for any reason to keep a copy of the additional data being referenced, the additional data may be attached to the electronic signature, in which case the electronic signature becomes a ES-X Long as defined by this document.
それが参照される追加的なデータのコピーを保持するための任意の理由のために所望される場合、追加のデータは、この文書によって定義されるように電子署名は、ES-Xロングとなる場合には、電子署名に取り付けることができます。
A ES-X Long Time-Stamped is simply the concatenation of a ES-X Time-Stamped with a copy of the additional data being referenced.
ES-Xロングタイムスタンプは、単純に参照されるES-Xの追加データのコピーでタイムスタンプ付きの連結です。
B.4.6.2 Time-Stamping Certificates and Revocation Information
B.4.6.2タイムスタンプ証明書と失効情報
References Time-Stamping each ES with Complete validation data as defined above may not be efficient, particularly when the same set of CA certificates and CRL information is used to validate many signatures.
参照タイムスタンプは、それぞれCA証明書およびCRL情報の同じセットは、多くの署名を検証するために使用される場合は特に、効率的ではないかもしれない上で定義した通りの完全な検証データとES。
Time-Stamping CA certificates will stop any attacker from issuing bogus CA certificates that could be claimed to existing before the CA key was compromised. Any bogus time-stamped CA certificates will show that the certificate was created after the legitimate CA key was compromised. In the same way, time-stamping CA CRLs, will stop any attacker from issuing bogus CA CRLs which could be claimed to existing before the CA key was compromised.
タイムスタンプのCA証明書は、CAの鍵が侵害された前に、既存に請求することができた偽のCA証明書を発行するすべての攻撃を停止します。任意の偽のタイムスタンプ付きのCA証明書が正当なCA鍵が侵害された後、証明書が作成されたことが示されます。同様に、タイムスタンプCAのCRLは、CAの鍵が侵害された前に、既存に請求することができた偽のCAのCRLを発行するすべての攻撃を停止します。
Time-Stamping of commonly used certificates and CRLs can be done centrally, e.g., inside a company or by a service provider. This method reduces the amount of data the verifier has to time-stamp, for example it could reduce to just one time stamp per day (i.e., in the case were all the signers use the same CA and the CRL applies for the whole day). The information that needs to be time stamped is not the actual certificates and CRLs but the unambiguous references to those certificates and CRLs.
一般的に使用される証明書とCRLのタイムスタンプは、例えば、社内またはサービスプロバイダにより、一元的に行うことができます。この方法は、（すなわち、ケース内のすべての署名者が同じCAを使用して、CRLは一日のために適用される）検証は、タイムスタンプを持つ例えば、それは一日あたり一度だけスタンプに減らすことができるデータの量を減らします。タイムスタンプにする必要がある情報は、実際の証明書とCRLが、それらの証明書とCRLへの明確な言及はありません。
To comply with extended validation data, type 2 Time-stamped, this document requires the following:
拡張された検証データに準拠するために、2型タイムスタンプは、この文書には、次のものが必要です。
* All the CA certificates references and revocation information references (i.e., CRLs) used in validating the ES-C are covered by one or more time-stamp.
* ES-Cを検証で使用されるすべてのCA証明書参照と失効情報の参照（すなわち、CRLは）一つ以上のタイムスタンプによって覆われています。
Thus a ES-C with a time-stamp signature value at time T1, can be proved valid if all the CA and CRL references are time-stamped at time T1+.
すべてのCAとCRL参照がタイムスタンプ時刻T1の+である場合、このように、時刻T1のタイムスタンプ署名値を持つES-Cは、有効な証明することができます。
B.4.7 Time-Stamping for Long Life of Signature
署名の長寿命化のためのB.4.7タイムスタンプ
Advances in computing increase the probability of being able to break algorithms and compromise keys. There is therefore a requirement to be able to protect electronic signatures against this probability.
コンピューティングの進歩は、アルゴリズムと妥協キーを破ることができるという可能性を高めます。この確率に対して電子署名を保護することができるようにする必要性が存在します。
Over a period of time weaknesses may occur in the cryptographic algorithms used to create an electronic signature (e.g., due to the time available for cryptoanalysis, or improvements in cryptoanalytical techniques). Before this such weaknesses become likely, a verifier should take extra measures to maintain the validity of the electronic signature. Several techniques could be used to achieve this goal depending on the nature of the weakened cryptography. In order to simplify, a single technique, called Archive validation data, covering all the cases is being used in this document.
時間の弱点の期間にわたって電子（暗号解読のために利用可能な時間のために、例えば、またはcryptoanalytical技術の改善）署名を作成するために使用される暗号アルゴリズムで行うことができます。このように弱点がそうなる前に、検証者は、電子署名の有効性を維持するために余分な措置を講じなければなりません。いくつかの技術が弱体化し、暗号の性質に応じて、この目標を達成するために使用することができます。簡単にするために、すべてのケースをカバーするアーカイブ検証データと呼ばれる単一の技術は、本文書で使用されています。
Archive validation data consists of the Complete validation data and the complete certificate and revocation data, time stamped together with the electronic signature. The Archive validation data is necessary if the hash function and the crypto algorithms that were used to create the signature are no longer secure. Also, if it cannot be assumed that the hash function used by the Time Stamping Authority is secure, then nested time-stamps of Archived Electronic Signature are required.
アーカイブ検証データは、電子署名と一緒にスタンプ完全な検証データと完全な証明書や失効データ、時間で構成されています。ハッシュ関数および署名を作成するために使用された暗号化アルゴリズムは、もはや安全である場合はアーカイブの検証データは必要ありません。アーカイブされた電子署名のそれがタイムスタンプ局によって使用されるハッシュ関数は安全であると仮定することができない場合も、その後、ネストされたタイムスタンプが必要です。
The potential for Trusted Service Provider (TSP) key compromise should be significantly lower than user keys, because TSP(s) are expected to use stronger cryptography and better key protection. It can be expected that new algorithms (or old ones with greater key lengths) will be used. In such a case, a sequence of time-stamps will protect against forgery. Each time-stamp needs to be affixed before either the compromise of the signing key or of the cracking of the algorithms used by the TSA. TSAs (Time-Stamping Authorities) should have long keys (e.g., which at the time of drafting this document was 2048 bits for the signing RSA algorithm) and/or a "good" or different algorithm.
TSP（複数可）強い暗号とより良い鍵の保護を使用することが期待されているので、信頼できるサービスプロバイダー（TSP）キー妥協の可能性は、ユーザーのキーよりも大幅に低くすべきです。新しいアルゴリズム（またはそれ以上の鍵長が古いもの）が使用されることを期待することができます。そのような場合には、タイムスタンプのシーケンスは、偽造から保護します。各タイムスタンプは、署名鍵の危殆前またはTSAによって使用されるアルゴリズムの割れを貼付する必要があります。 TSA（タイムスタンプ当局は）および/または「良い」又は別のアルゴリズム（この文書を起草する時に2048署名RSAアルゴリズムのためのビットであった例えば、）長いキーを有していなければなりません。
Nested time-stamps will also protect the verifier against key compromise or cracking the algorithm on the old electronic signatures.
ネストされたタイムスタンプは、キーの妥協や古い電子署名のアルゴリズムを割れに対する検証を保護します。
The process will need to be performed and iterated before the cryptographic algorithms used for generating the previous time stamp are no longer secure. Archive validation data may thus bear multiple embedded time stamps.
前回のタイムスタンプを生成するために使用される暗号化アルゴリズムは、もはや安全である前処理を行うと反復する必要はありません。アーカイブ検証データは、このように複数の埋め込まれたタイムスタンプを有していてもよいです。
B.4.8 Reference to Additional Data
追加データへB.4.8参照
Using type 1 or 2 of Time-Stamped extended validation data verifiers still needs to keep track of all the components that were used to validate the signature, in order to be able to retrieve them again later on. These components may be archived by an external source like a trusted service provider, in which case referenced information that is provided as part of the ES with Complete validation data (ES-C) is adequate. The actual certificates and CRL information reference in the ES-C can be gathered when needed for arbitration.
1型またはタイムスタンプ拡張検証データ検証の2を使用すると、さらに後に再びそれらを取得できるようにするために、署名を検証するために使用されたすべてのコンポーネントを追跡する必要があります。これらのコンポーネントは、完全な検証データ（ES-C）とESの一部として提供される場合、参照情報が適切である、信頼できるサービスプロバイダのような外部ソースによってアーカイブされてもよいです。調停のために必要な場合ES-Cの実際の証明書およびCRL情報の参照を収集することができます。
B.4.9 Time-Stamping for Mutual Recognition
相互承認のためのB.4.9タイムスタンプ
In some business scenarios both the signer and the verifier need to time-stamp their own copy of the signature value. Ideally the two time-stamps should be as close as possible to each other.
署名者と検証の両方をする必要があるいくつかのビジネスシナリオでは、署名値の独自のコピーをタイムスタンプ。理想的には、2つのタイムスタンプは、互いにできるだけ近くでなければなりません。
Example: A contract is signed by two parties A and B representing their respective organizations, to time-stamp the signer and verifier data two approaches are possible:
例：契約がタイムスタンプを、それぞれの組織を表す2人の当事者A及びBによって署名され、署名者と検証データ二つのアプローチが可能です。
* under the terms of the contract pre-defined common "trusted" TSA may be used;
*契約の条件の下で一般的な事前定義されたがTSAを使用することができる「信頼できます」。
* if both organizations run their own time-stamping services, A and B can have the transaction time-stamped by these two time-stamping services. In the latter case, the electronic signature will only be considered as valid, if both time-stamps were obtained in due time (i.e., there should not be a long delay between obtaining the two time-stamps). Thus, neither A nor B can repudiate the signing time indicated by their own time-stamping service.
*両組織は、自分の時間スタンピングサービスを実行する場合、AとBは、タイムスタンプ、これらの2つの時間スタンプサービスによってトランザクションを持つことができます。両方のタイムスタンプが期限（すなわち、二つのタイムスタンプを取得する間に長い遅延があってはならない）で得られた場合は後者の場合には、電子署名のみ、有効と考えます。したがって、AもBもが独自のタイムスタンプサービスによって示される署名時刻を否認することができます。
Therefore, A and B do not need to agree on a common "trusted" TSA to get a valid transaction.
したがって、AとBが共通に同意する必要はありません有効なトランザクションを取得するためにTSAを「信頼できます」。
It is important to note that signatures may be generated "off-line" and time-stamped at a later time by anyone, e.g., by the signer or any recipient interested in validating the signature. The time-stamp over the signature from the signer can thus be provided by the signer together with the signed document, and /or obtained by the verifier following receipt of the signed document.
署名は、「オフライン」を生成し、署名または署名を検証することに興味の任意の受信者により、例えば、誰によって後でタイムスタンプされてもよいことに留意することが重要です。署名者から署名オーバータイムスタンプは、このように署名された文書と一緒に署名者によって提供され、及び/又は署名された文書の受領後検証することによって得ることができます。
The business scenarios may thus dictate that one or more of the long-term signature time-stamping methods describe above be used. This will need to be part of a mutually agreed the Signature Validation Policy with is part of the overall signature policy under which digital signature may be used to support the business relationship between the two parties.
ビジネスシナリオは、このようにタイムスタンプ方法を用いることが上述長期署名の1つ以上を決定することができます。これは、デジタル署名が2つの当事者間のビジネス関係をサポートするために使用されることができるの下で、全体的な署名ポリシーの一部であると相互に合意した署名検証ポリシーの一部である必要があります。
B.4.10 TSA Key Compromise
B.4.10 TSA鍵の危殆
TSA servers should be built in such a way that once the private signature key is installed, that there is minimal likelihood of compromise over as long as possible period. Thus the validity period for the TSA's keys should be as long as possible.
TSAサーバはできるだけ長く期間としてにわたる妥協の最小限の可能性があることが、かつて秘密署名鍵がインストールされているような方法で構築する必要があります。したがって、TSAの鍵の有効期間は、できるだけ長くなければなりません。
Both the ES-T and the ES-C contain at least one time stamp over the signer's signature. In order to protect against the compromise of the private signature key used to produce that time-stamp, the Archive validation data can be used when a different Time-Stamping Authority key is involved to produce the additional time-stamp. If it is believed that the TSA key used in providing an earlier time-stamp may ever be compromised (e.g., outside its validity period), then the ES-A should be used. For extremely long periods this may be applied repeatedly using new TSA keys.
ES-TおよびES-Cの両方が署名者の署名の上に少なくとも一つのタイムスタンプを含みます。異なるタイムスタンプ局キーが追加のタイムスタンプを生成するために関与しているときにタイムスタンプを生成するために使用される秘密署名鍵の妥協から保護するためには、アーカイブの検証データを使用することができます。それは（例えば、その有効期間外）以前のタイムスタンプを提供する際に使用されるTSAキーが今まで損なわれる可能性があると考えられる場合には、ES-Aを使用すべきです。非常に長い期間では、これは新しいTSAキーを使用して繰り返し適用することができます。
B.5 Multiple Signatures
B.5複数の署名
Some electronic signatures may only be valid if they bear more than one signature. This is the case generally when a contract is signed between two parties. 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. Several forms of multiple and counter signatures may need to be supported, which fall into two basic categories:
彼らは複数の署名を負担する場合、一部の電子署名のみが有効かもしれません。契約は両当事者間で締結されたとき、これは一般的なケースです。署名の順序は、または、すなわち重要でない場合があり、一方または他方の前に適用する必要はなくてもよいです。複数のカウンタ署名のいくつかの形態は、2つの基本的なカテゴリに分類され、サポートする必要があります。
* independent signatures; * embedded signatures.
*独立した署名。 *埋め込まれた署名。
Independent signatures are parallel signatures where the ordering of the signatures is not important. The capability to have more than one independent signature over the same data must be provided.
独立した署名は、署名の順序は重要ではありません並列署名されています。同じデータに対して複数の独立した署名を持っている能力を提供しなければなりません。
Embedded signatures are applied one after the other and are used where the order the signatures are applied is important. The capability to sign over signed data must be provided.
埋め込まれた署名は、次々に適用され、署名が適用される順序が重要な場合に使用されます。署名されたデータの上に署名する機能が提供されなければなりません。
These forms are described in clause 3.13. 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 occurrence of the above two cases.
これらのフォームは、節3.13で説明されています。他のすべての複数署名方式は、例えば、副署、二重countersignatures又は複数の署名と署名された文書は、上記2例一つ以上の発生を低減することができます。
Annex C (informative): Identifiers and roles
附属書C（参考）：識別子と役割
C.1 Signer Name Forms
C.1署名者の名前フォーム
The name used by the signer, held as the subject in the signer's certificate, must uniquely identify the entity. The name must be allocated and verified on registration with the Certification Authority, either directly or indirectly through a Registration Authority, before being issued with a Certificate.
署名者の証明書のサブジェクトとして保持署名者によって使用される名前は、エンティティを一意に識別しなければなりません。名前は、証明書が発行される前に、登録機関を介して直接または間接的に、割り当てられ、認証局への登録に検証されなければなりません。
This document places no restrictions on the form of the name. The subject's name may be a distinguished name, as defined in [RFC2459], held in the subject field of the certificate, or any other name form held in the X.509 subjectAltName certificate extension field. In the case that the subject has no distinguished name, the subject name can be an empty sequence and the subjectAltName extension must be critical.
この文書は、名前の形式に制限を課すません。対象者の名前は、[RFC2459]で定義された証明書、またはX.509の証明書のsubjectAltName拡張フィールドに保持されている任意の他の名前フォームの件名フィールドに保持されているように、識別名であってもよいです。被写体が全く識別名を持っていない場合には、サブジェクト名が空のシーケンスにすることができ、subjectAltName拡張は、クリティカルでなければなりません。
C.2 TSP Name Forms
C.2 TSP名フォーム
All TSP name forms (Certification Authorities, Attribute Authorities and Time-Stamping Authorities) must be in the form of a distinguished name held in the subject field of the certificate.
すべてのTSPの名前形式（認証局は、当局とタイムスタンプ当局属性）証明書のサブジェクトフィールドで開催された識別名の形式でなければなりません。
The TSP name form must include the legal jurisdiction (i.e., country) under which it operates and an identification for the organization providing the service.
TSP名形式は、それが動作する法的管轄（すなわち、国）とサービスを提供する組織の識別を含まなければなりません。
C.3 Roles and Signer Attributes
C.3役割と署名者の属性
Where a signer signs as an individual but wishes to also identify him/herself as acting on behalf of an organization, it may be necessary to provide two independent forms of identification. The first identity, with is directly associated with the signing key identifies him/her as an individual. The second, which is managed independently, identifies that person acting as part of the organization, possibly with a given role.
どこ署名者の兆候個人としても組織を代表して働くように彼/彼女自身を特定したい、識別の二つの独立した形を提供するために必要な場合があります。直接署名キーに関連付けられているとの最初のアイデンティティは、個人として彼/彼女を識別します。独立して管理されている第二は、おそらく与えられた役割と、組織の一部として機能してその人を識別します。
In this case the first identity is carried in the subject/subjectAltName field of the signer's certificate as described above.
上述したように、この場合、第1識別情報は署名者の証明書のサブジェクト/のsubjectAltNameフィールドで搬送されます。
This document supports the following means of providing a second form of identification:
この文書では、識別の第二の形式を提供する以下の手段をサポートしています。
* by placing a secondary name field containing a claimed role in the CMS signed attributes field;
* CMSでの主張役割を含む二名のフィールドを配置することにより、属性フィールドに署名しました。
* by placing an attribute certificate containing a certified role in the CMS signed attributes field.
* CMSでの認定役割を含む属性証明書を配置することにより、属性フィールドに署名しました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。