[要約] RFC 3126は、長期的な電子署名のための電子署名形式に関する要件を定義しています。このRFCの目的は、長期的な電子署名の信頼性と持続性を確保するための標準化を促進することです。
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.
Copyright（c）The Internet Society（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).
このドキュメントでは、長期間にわたって有効であることができる電子署名の形式を定義します。これには、署名者または検証する当事者が後で拒否しようとする場合でも（つまり、署名の妥当性を否認しようとする場合でも、その有効性に関する証拠が含まれます。
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 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 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
1. はじめに概要5 2.1 AIM 5 2.2現在のドキュメントの基礎5 2.3主要な関係者6 2.4電子署名と検証データ7 2.5検証データの形式8 2.6検証データの拡張フォーム2 2.7アーカイブ検証データ13 2.8仲裁15 2.9検証プロセス152。メッセージダイジェスト計算プロセス23 3.6.2メッセージ署名生成プロセス24 3.6.3メッセージ署名検証プロセス24 3.7 cmsインポート必須現在の属性24 3.7.1コンテンツタイプ24 3.7.2メッセージダイジェスト24 3.7.3署名時間3.8代替署名証明書属性24 3.8.1 ESS SING SINGILE CERTITINCE属性定義25 3.8.2その他の署名証明書属性定義25 3.9追加の必須属性26 3.9.1署名ポリシー識別子26 3.10 cm.1コンテンツリファレンス属性29 3.11.2コンテンツ識別子属性29 3.11.3コンテンツヒント属性29 3.12追加オプション属性30 3.12.1コミットメントタイプ表示属性30 3.12.2署名者ロケーション属性32 3.12.3署名者属性33 3.12.444コンテンツタイムスタンプ属性34 3.13複数の署名のサポート34 3.13.1独立署名34 3.13.2埋め込み署名34 4.検証データ35 4.1電子署名タイムスタンプ36 4.1.1署名タイムスタンプ属性定義36 4.2完全な検証データデータ37 4.2.1完全な証明書REFS属性定義38 4.2.2完全な取り消しREFS属性定義38 4.3拡張検証データ40 4.3.1証明書値属性定義40 4.3.2失効値属性定義41 4.3.3 ES-Cタイムスタンプ属性定義42 4.3.4タイムスタンプ証明書とCRLS属性定義42 4.4アーカイブ検証データ43 4.4.1アーカイブタイムスタンプ属性定義43 5.セキュリティ考慮事項44 5.1秘密キー44 5.2アルゴリズムの選択44 6.適合要件456.1署名者45 6.2タイムスタンピングを使用した検証46 6.3セキュアレコードを使用した検証剤46 7.参考文献47 8.著者のアドレス48付録A（規範）：ASN.1定義49 A.1 X.208（1988）ASNを使用した定義。1構文49 A.2 X.680 1997を使用した定義ASN.1構文57付録B（情報）：一般的な説明66 B.1署名ポリシー66 B.2署名情報67 B.3電子署名68 B. B.3.1署名ポリシーへの参照68 B.3.2コミットメントタイプ表示69 B.3.3署名者からの証明書識別子69 B.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検証データのコンポーネント73 B.4.1取り消しステータス情報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時間 - 完全な検証データを使用してESをスタンピングする77 B.4.6.2タイムスタンピング証明書と取り消し情報78 B.4.7署名の長寿命のためのタイムスタンピング79 B.4.8追加データへの参照80 B.4.10 TSAキー妥協点81 B.5複数の署名81付録C（情報）：識別子と役割82 C.1署名者名フォーム82 C.2 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).
このドキュメントは、そのような署名の長期的な有効性が重要な場合、ビジネストランザクション（たとえば、購入要求、契約、請求書アプリケーションなど）など、さまざまなタイプのトランザクションの電子署名をカバーすることを目的としています。これには、署名者または検証が後に署名の妥当性を拒否しようとする（つまり、拒否、[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.
電子署名は、個人と会社の間の任意の取引、2つの企業間、個人と政府機関などの取引に使用できます。この文書は、あらゆる環境とは無関係です。あらゆる環境に適用できます。たとえば、スマートカード、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].
「必須」、「必要」、「必須」、「必要」、「必要はない」、「推奨」、「5月」、および「オプション」（図のように大文字で）は次のとおりです。[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）を定義することです。これには、署名者または検証が後で署名の妥当性を否定（拒否）しようとする場合でも、その有効性に関する証拠が含まれます。
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.
また、このドキュメントは、電子署名の重要な要素の通常の寿命の長い寿命の長い間署名の妥当性を証明し、非repudiationをサポートするために、タイムスタンプサービスの使用を指定しています。また、オプションとして、追加のタイムスタンプの使用を定義して、重要な妥協または弱体化したアルゴリズムに対する非常に長期的な保護を提供します。
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).
* RFC 2459 [RFC2459]インターネットX.509公開キーインフラストラクチャ証明書およびCRLプロファイル（PKIX）;
* RFC 2630 [CMS] Crytographic Message Syntax（CMS）;
* RFC 2634 [ESS]強化されたセキュリティサービス（ESS）;
* RFC 2439 [OCSP]ワンライン証明書ステータスプロトコル（OCSP）;
* ITU-T推奨X.509 [1]認証フレームワーク。
* RFC（公開）[TSP] PKIXタイムスタンピングプロトコル（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).
*署名者。
*検証剤;
*仲裁人。
*信頼できるサービスプロバイダー（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）は、署名者と検証者の間の信頼関係を構築するのに役立つ1つ以上のエンティティです。いくつかの特定のTSPサービスの使用は、署名ポリシーによって義務付けられる場合があります。TSPサポートサービスは、ユーザー証明書、クロス認証、タイムスタンプトークン、CRLS、ARLS、OCSP応答の情報を提供する場合があります。
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.
*認定当局。
*登録当局。
*リポジトリ当局（例：ディレクトリ）;
*タイムスタンピング当局。
* 1行証明書ステータスプロトコルレスポンダー。
*属性当局。
*署名ポリシー発行者。
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.
リポジトリ当局は、CASによって発行されたCRL、CASが発行したCRLS（すなわち、CA証明書）、署名ポリシー発行者によって発行された署名ポリシー、およびオプションではCASが発行した公開キー証明書（つまり、LEAF証明書）が発行します。
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.
1行の証明書ステータスプロトコルレスポンズ（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).
- 証明書の参照。 - 証明書; - 取り消しステータス情報参照。 - 取り消しステータス情報。 - タイムスタンプ時間スタンプ当局（TSA）。
* 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のような正式な表記法または非公式の無料テキストフォームで記述される場合があります。ただし、特定の署名ポリシーには、一意のバイナリエンコード値を持つ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-C）を備えたESは、電子署名の有効性（つまり、取り消しステータス情報）をサポートする完全なデータセットにES-T参照に追加されます。
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).
デジタル署名をタイムスタンプすることなく長期的な署名の要件がある場合、電子署名に関連した検証の時間には安全なレコードが必要です（つまり、両方とも安全に記録する必要があります）。さらに、検証時に使用される証明書と取り消し情報は、図3にES-C（BIS）として示すように記録する必要があります。
+-------------------------------------------------------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（BIS）のイラスト
The verifiers conformance requirements of an ES-C(bis) is defined in subclause 6.3.
ES-C（BIS）の検証者の適合要件は、サブクロース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-X）を備えたESを形成して、追加の要件を満たすことができます。
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.
*署名者の証明書、
*完全な認定パスを構成するすべてのCA証明書、
* ES-Cで参照されているすべての関連する取り消しステータス情報。
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-Longと呼ばれます。
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.
上記のすべての条件が発生する場合、上記の2つの形式の組み合わせを使用できます。この形式の拡張検証データは、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 Longを形成する追加の検証データを含む電子署名（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-Xの追加の検証データをES-Aを形成する電子署名（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で参照されているすべてのクロス認証、および/または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.
3番目の条件が満たされていないことを意味するものがある場合、原告は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つの以前の条件が満たされていない場合、原告は上記の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.
検証者は、2つの異なる時間の瞬間に2つのタイムスタンプを取得する必要がある場合があることに注意する必要があります。1つはESの生成後すぐに、もう1つは、認定チェーンのエンティティが重要な妥協を宣言することを許可する猶予期間のすぐ後です。
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）を受信した直後に、デジタル署名値をチェックすることができます。検証剤。検証プロセスは、信頼できるサービスプロバイダーが提供する追加データ（証明書、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のすべての検証チェックを完了します（タイムスタンプがまだ存在していない場合、これはES-TとES-Cプロセスを組み合わせた同じ段階で追加できます）。
* 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) 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:
図8：検証プロセスがES-Cを作成すると同時に、完全な検証データ（ES-C）を持つESの図は、検証プロセスがESで使用されている証明書の値と取り消しステータス情報の値を提供および/または記録する場合があります-C、Es-X Long（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（LONG）
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-Time-Stamp（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-Time-Stamp
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:
もう1つの選択肢は、電子署名を検証するために使用される証明書と取り消し情報の参照をタイムスタンプすることです（署名ではありません）（6 '）。これは、タイプ2 X-Timeスタンプと呼ばれます。これを図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-Time-Stamp
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) An ES-A is illustrated in figure 12:
電子署名のいずれかで使用されるアルゴリズムが侵害または脆弱になる可能性が高くなる前に、将来的には脆弱にされるようになる前に、検証のすべての値とユーザーデータを含む電子署名全体をタイムスタンプする必要があります。アーカイブ検証データ（ES-A）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 2630 [CMS]で定義されているように、暗号化メッセージの構文（CMS）を使用および構築し、RFC 2634 [ESS]で定義されているように、セキュリティサービス（ESS）の強化（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].
ESの一般的な構文は、[CMS]で定義されています。
The data content type of the ES is as defined in [CMS].
ESのデータコンテンツタイプは、[CMS]で定義されています。
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].
ESの署名されたデータコンテンツタイプは、[CMS]で定義されています。
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.
署名されたDATAコンテンツタイプは、あらゆるタイプのコンテンツとゼロ以上の署名値で構成されています。並行して任意の数の署名者は、あらゆる種類のコンテンツに署名できます。署名されたDATAコンテンツタイプの典型的なアプリケーションは、データコンテンツタイプのコンテンツに関する1つの署名者のデジタル署名を表します。
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.
Verifierが適切な証明書を使用することを確認するために、このドキュメントは、署名者証明書のハッシュが常に署名証明書署名属性に含まれていることを義務付けています。
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].
ESのタイプのcantulatedContentInfoの構文は、[CMS]で定義されているとおりです。
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.
このドキュメントで定義されている長期検証を目的として、econtentが存在するか、署名されたデータがデータエンコーディングを保持するような方法などでアーカイブされることをお勧めします。検証剤または仲裁人が署名を検証するたびに、署名を生成するために使用されるoctet stringが署名を生成するために使用することが重要です。
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].
SignerInfoのsのタイプの構文は、[CMS]で定義されているとおりです。
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.
署名者ごとの情報は、Type Signerinfoで表されます。複数の独立した署名の場合、各署名者にこのフィールドのインスタンスがあります。
The fields of type SignerInfo have the meanings defined in [CMS] except that signedAttributes must, as a minimum, contain the following attributes:
Signerinfoのタイプのフィールドには、[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。
* 3.7.2項で定義されているMESSAGEDGEST。
*条項3.7.3で定義されている署名時間。
*条項3.8.1で定義されているsigningcertificate。
* 3.9.1項で定義されているSignaturePolicyID。
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].
ESのコンテンツタイプ属性タイプの構文は、[CMS]で定義されているとおりです。
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.
ESのメッセージダイジェスト属性タイプの構文は、[CMS]で定義されているとおり、このドキュメントでさらに資格があります。
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.
この現在の文書は、一般化された時間の使用を推奨しています。
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.
次の2つの代替属性のうち、1つ、および1つだけが、署名証明書を特定するためにこのドキュメントで定義された署名されたデータに存在する必要があります。両方の属性には、識別子と署名証明書のハッシュが含まれます。既存の標準で採用されている最初のものは、SHA-1ハッシュアルゴリズムでのみ使用できます。もう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.
ESの署名証明書属性タイプの構文は、[ess]で定義されているとおりであり、このドキュメントでさらに資格とプロファイルがあります。
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のエンコードには、発行担当フィールドを含める必要があります。
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に存在する発行者の登場人物は、発行型フィールドと一致している必要があります。特定された証明書は、署名検証プロセス中に使用する必要があります。証明書のハッシュが署名を確認するために使用される証明書と一致しない場合、署名は無効と見なされなければなりません。
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以外のハッシュアルゴリズムで使用できることを除いて、上記で定義されたsigningcertificateと同一です。
This attribute must be used in the same manner as defined above for the ESS SigningCertificate attribute.
この属性は、ESS signiveCertificate属性に対して上記と同じ方法で使用する必要があります。
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構文がありますothersingcertificate
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.
Signature-Policy-Identifier属性の値には、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.
ヌルタイプの存在は、署名ポリシーが署名されたデータおよびその他の外部データのセマンティクスによって暗示されていることを示しています。
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フィールドには、署名ポリシーの特定のバージョンを一意に識別するオブジェクトIDENTIFIERが含まれています。このフィールドの構文は次のとおりです。
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：これには、署名ポリシーへのWeb URIまたはURL参照が含まれています
* spUserNotice: This contains a user notice which should be displayed whenever the signature is validated.
* Spusernotice：これには、署名が検証されたときに表示されるユーザー通知が含まれています。
-- sigpolicyQualifierIds defined in this document
- この文書で定義されている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 ::= 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.
次の属性は、このドキュメントで定義された署名されたデータに存在する場合があります。属性はREF [CMS]で定義され、この仕様にインポートされ、このドキュメントによって適切な資格とプロファイリングでした。
The syntax of the countersignature attribute type of the ES is as defined in [CMS]. The countersignature attribute must be an unsigned attribute.
ESのcounterSignature属性タイプの構文は、[CMS]で定義されているとおりです。counterSignature属性は、符号なし属性でなければなりません。
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.
次の属性は、このドキュメントで定義された署名されたデータに存在する場合があります。属性はref [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から別の署名型へのリンクです。これは、それが言及する元のメッセージへの返信をリンクするために使用するか、参照1つの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].
ESのコンテンツ識別子属性タイプの構文は、[ess]で定義されているとおりです。
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.
Minimal SignedContentidentidifierには、ユーザー固有の識別情報（ユーザー名やパブリックキーイングマテリアル識別情報など）の連結、一般化されたタイム文字列、および乱数を含める必要があります。
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のコンテンツの構文は、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：コンテンツタイプは、CMS（RFC 2630 [8]）で定義されるID-DATAにすることができます。UTF8STRINGを使用して、MIMEタイプなどのデータのエンコードを示すことができます。RFC 2045 [25]は、さまざまな電子ドキュメントやその他のマルチメディアタイプをエンコードするための共通構造を提供します。詳細については、Annex 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 ::= 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が、表示の受信者がアクセスできる地元の店でメッセージを送信したことを提供する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.
署名者ロケーション属性は、署名属性でなければなりません。
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.
署名者ロケーション属性値にはasn.1タイプの署名者があります。
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).
Signer-Attributes属性は、署名者の追加属性（役割など）を指定する属性です。
It may be either:
どちらかです：
* claimed attributes of the signer; or * certified attributes of the signer;
* 署名者の主張された属性。または *署名者の認定属性。
The signer-attributes attribute must be a signed attribute.
Signer-Attributes属性は、署名付き属性でなければなりません。
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.
Signer-Attributeの属性値には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からインポートされます。
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内のcapContentInfo内のecontentフィールドの値のハッシュでなければなりません。
For further information and definition of TimeStampToken see [TSP].
Timestamptokenの詳細と定義については、[TSP]を参照してください。
Multiple independent signatures are supported by independent SignerInfo from each signer.
複数の独立した署名は、各署名者の独立した署名者によってサポートされています。
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への符号なしの属性として保持されているcountersignatureで運ばれます。
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-Timestamp：このドキュメントで定義された拡張検証データで使用されるタイムスタンプには2つのタイプがあります。
- Type 1 -Time-Stamp which comprises a time-stamp over the ES with Complete validation data (ES-C).
- 完全な検証データ（ES-C）を使用して、ES上のタイムスタンプを含むタイプ1 -Time-Stamp。
- 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-Long：これは、完全な検証データに加えて、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-Long-Time-Stamp：これは、タイプ1またはタイプ2のX-Timestampと、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-Long検証データのように）、その他の既存のX-Timestamp、さらに署名されたユーザーデータ、およびそのすべてのデータにわたって追加のアーカイブタイムスタンプで構成されています。アーカイブタイムスタンプは、電子署名とタイムスタンプのアルゴリズムが弱体化する場合に有効性を維持するために、長期にわたって繰り返し適用できます。
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の署名型 -ティメスタムデレイフィールドで、署名時間属性に示されている時間と署名タイムスタンプ属性によって示される時間との間に許可される最大許容時間差を指定します。この遅延を超えた場合、電子署名は無効と見なされる必要があります。
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フィールドの値は、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.
*条項4.1.1で定義されている署名タイムスタンプ属性。
*条項4.2.1で定義されているように、完全な証明書Refs。
*条項4.2.2で定義されているように、完全な取り消しREF。
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:
完全な検証データには、X-Time-Stamp検証データを形成する以下の追加属性のいずれかが含まれる場合があります。
* 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.
* 4.2.5項で定義されているES-Cタイムスタンプ。または *条項4.2.6で定義されているように、 *タイムスタンプ証明書とCRLS参照。
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.
完全な証明書Refs属性は、署名されていない属性です。完全な検証データ（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.
完全な証明書Refs属性値には、asn.1構文CompleceCertificaterefsがあります。
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に存在しなければならない発行担当者。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.
完全なrefocation Refs属性は、署名されていない属性です。この属性の単一のインスタンスのみが、電子署名で発生する必要があります。完全な検証データを使用して、ESで使用されている署名者およびCA証明書の検証で使用されているCRLまたはOCSP応答の完全なセットを参照します。
The following object identifier identifies the CompleteRevocationRefs attribute:
次のオブジェクト識別子は、completeervocationRefs属性を識別します。
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.
完全なrefocation Refs属性値には、asn.1構文CompleerevocationRefsがあります。
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.
completeervocationRefsには、署名証明書に1つのcrlocsprefを含める必要があり、その後、CompleteCertificaterefs属性のbothercertidが1つ含まれている必要があります。2番目と後続のCrlocsprefフィールドは、それらが関係する他のCertidと同じ順序でなければなりません。証明書パスの「信頼できる」CAを除くすべてに、CrllistIDまたはOCSPLISTIDまたはその他のREVREFSの少なくとも1つが存在する必要があります。
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がDelta 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応答に含まれる「生成」に対応する必要がある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:
次のオブジェクト識別子は、証明書数の属性を識別します。
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 ::= 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.
ravesocation値属性は、署名されていない属性です。この属性の単一のインスタンスのみが、電子署名で発生する必要があります。CRLSとOCSPの値を保持し、CompleerVocationRefs属性で参照されます。
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.
ravesocation値属性値には、asn.1構文gococationvaluesがあります。
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]).
証明書は、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）です。これは、ES-Cをタイムスタンプする特別な目的Timestamptoken属性です。この属性のいくつかのインスタンスインスタンスは、異なる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.
* completeervocationRefs属性。
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-Time-Stamp検証データに使用されます。TimestamedCertScrlSref属性は、署名されていない属性です。これは、特定のCAの妥協から保護するためにタイムスタンプされた参照されている証明書とOCSP応答/CRLのリストです。その構文は次のとおりです。
The following object identifier identifies the TimestampedCertsCRLsRef attribute:
次のオブジェクト識別子は、TimestameDcertScrlsref属性を識別します。
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構文タイムスタンプ型certscrlsがあります。
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属性。* completeervocationrefs属性。
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:
* 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.
* encapcontentinfo econtentオクテット弦;* signedattributes;* Signerinfo内の署名フィールド。* SignatureTimestamptoken属性。* CompleceCertificAterefs属性。* completervocationdata属性。* certerminceValues属性（まだ提示されていない場合は、この情報をES-Aに含める必要があります）;* regocationValues属性（まだ提示されていない場合は、この情報をES-Aに含める必要があります）。*存在する場合はesctimestamptoken属性。*存在する場合は、TimestameDcertScrls属性。*以前のArchiveTimestamptoken属性。
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).
* RFC 2630で定義されている一般的なCMS構文とコンテンツタイプ（句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).
* RFC 2630で定義されているCMS SignedDataは、バージョンが3に設定され、少なくとも1つのSignerinfoが存在する必要があります（条項4.3、4.4、4.5、4.6を参照）。
* The following CMS Attributes as defined in RFC 2630:
* RFC 2630で定義されている次のCMS属性：
- 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).
- 署名時間;これは常に存在する必要があります（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で定義されているように、完全な証明書Refs属性。
* Complete Revocation Refs Attribute, as defined in clause 4.2.2.
* 条項4.2.2で定義されているように、完全な取り消しREFS属性。
* 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
- ITU-Tの推奨X.509 [1]で定義され、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サブクロースで定義されているように、完全な証明書Refs属性。
* Complete Revocation Refs Attribute, as defined in subclause 9.2.2.
* サブクロース9.2.2で定義されているように、完全な取り消しREFS属性。
* 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).
* ITU-Tの推奨X.509 [1]で定義され、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS] Hoffman、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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S。、およびC. Adams、「オンラインステータス証明書プロトコル」、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] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「Internet 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.、Ford、W.、Polk、W。and D. Solo、「Internet 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、「The Public-Key Cryptography Standards（PKCS）」、RSA Data Security Inc.、Redwood City、California、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 Webサイト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
Contact Point
コンタクトポイント
Harri Rasilainen ETSI 650 Route des Lucioles F-06921 Sophia Antipolis, Cedex FRANCE
Harri Rasilainen Etsi 650ルートDes Lucioles F-06921 Sophia Antipolis、Cedex France
EMail: harri.rasilainen@etsi.fr
Denis Pinkas Integris 68, Route de Versailles 78434 Louveciennes CEDEX FRANCE
Denis Pinkas Integris 68、Route De Versailles 78434 Louveciennes Cedex France
EMail: Denis.Pinkas@bull.net
John Ross Security & Standards 192 Moulsham Street Chelmsford, Essex CM2 0LG United Kingdom
ジョンロスセキュリティ＆標準192ムルシャムストリートチェルムスフォード、エセックスCM2 0LGイギリス
EMail: ross@secstan.com
Nick Pope Security & Standards 192 Moulsham Street Chelmsford, Essex CM2 0LG United Kingdom
ニック・ポープセキュリティ＆標準192ムルシャムストリートチェルムスフォード、エセックスCM2 0LGイギリス
EMail: 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構文定義の要約を提供します。
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.
注：ASN.1モジュールは、条項A.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}
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-data、id-signeddata、signeddata、capsulatedcontentinfo、signerinfo、id-contenttype、id-sesagedigest、messagedigest、id-singimetime、signingtime、id-countersignature、countersignatureation
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) }
-- ESS Defined attributes: RFC 2634
-- (Enhanced Security Services for S/MIME)
id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-contentReference, ContentReference, id-aa-contentIdentifier, ContentIdentifier
id-aa-signingcertificate、signingcertificate、発行担当者、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) }
-- Internet X.509 Public Key Infrastructure
-- Certificate and CRL Profile: RFC 2459
Certificate, AlgorithmIdentifier, CertificateList, Name, GeneralNames, GeneralName, DirectoryString,Attribute, AttributeTypeAndValue, AttributeType, AttributeValue, PolicyInformation, BMPString, UTF8String
証明書、AlgorithMidentifier、証明書リスト、名前、一般名、一般名、directoryString、属性、属性、属性、属性、属性、属性、政策情報、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)}
-- X.509 '97 Authentication Framework
-X.509 '97認証フレームワーク
AttributeCertificate
属性証明書
FROM AuthenticationFramework
{joint-iso-ccitt ds(5) module(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.
-- OCSP 2560
-OCSP 2560
BasicOCSPResponse, ResponderID
Basicocspresponse、responderid
FROM OCSP {-- OID not assigned -- }
-- 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)}
-- 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
-- OID used referencing electronic signature mechanisms based on this
-- standard for use with the IDUP API (see annex 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
-othineingcertificate
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
}
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 }
NoticeRef NoticeReferenceオプション、Explicittext DisplayTextオプション}}
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.
- 完全な証明書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
- 完全な取り消し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のOCSPRESPONSESシーケンス}
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-electronicsignatureformats-88syntax-
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-data、id-signeddata、signeddata、capsulatedcontentinfo、signerinfo、id-contenttype、id-sesagedigest、messagedigest、id-singimetime、signingtime、id-countersignature、countersignatureation
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) }
-- ESS Defined attributes: RFC 2634 (Enhanced Security Services
-- for S/MIME)
id-aa-signingCertificate, SigningCertificate, IssuerSerial, id-aa-contentReference, ContentReference, id-aa-contentIdentifier, ContentIdentifier
id-aa-signingcertificate、signingcertificate、発行担当者、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) }
-- 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、証明書リスト、名前、一般名、一般名、directoryString、属性、属性、属性、属性、属性、ポリシー情報。
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)}
-- X.509 '97 Authentication Framework
-X.509 '97認証フレームワーク
AttributeCertificate
属性証明書
FROM AuthenticationFramework
{joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}
-- OCSP 2560
-OCSP 2560
BasicOCSPResponse, ResponderID
Basicocspresponse、responderid
FROM OCSP
OCSPから
-- { OID not assigned }
- {oidが割り当てられない}
-- Time Stamp Protocol Work in Progress 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)}
-- 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
-- OID used referencing electronic signature mechanisms based on this
-- standard for use with the IDUP API (see annex 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
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
}
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] }
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.
- 完全な証明書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
- 完全な取り消し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.
以下の仕様には、脆弱性と脅威の簡単な説明、およびそれらがカウンターされる方法の簡単な説明がある説明が含まれています。
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.
明示的な署名検証ポリシーを構成して、コンピューター処理可能にすることができます。このドキュメントでは、署名検証ポリシーの任意の形式が許可されています。ただし、特定の明示的な署名ポリシーには、一意のバイナリエンコード値を持つ1つの決定的なフォームが必要です。
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、属性当局、タイムスタンプ当局）の使用に関する規則と、長期的な証拠を提供するために検証者が必要とするデータを署名者が提供する必要がある電子署名のコンポーネントを定義する規則が含まれます。
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など）、無料のテキスト、または電子形式（e-form）のフィールドで構成できます。たとえば、Adobe（TM）形式「PDF」を使用するか、拡張可能なマークアップ言語（XML）を使用できます。
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.
2つの独立した当事者が電子署名を評価したい場合、同じ結果を得ることが基本です。この要件を満たすには、署名者と検証者が同じ署名ポリシーを使用する必要があります。
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.
「署名ポリシー」の識別子とハッシュが署名されたデータの一部となる署名を検証するために使用される明示的な署名ポリシーを明確に識別するために。明示的なポリシーに関する追加情報（例：ドキュメントへのWebリファレンス）は、署名ポリシー識別子に「予選」として伝えることができます。
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.
署名を検証するために使用する「署名検証ポリシー」を明確に識別するために、「署名ポリシー」の識別子とハッシュが署名されたデータの一部でなければなりません。ポリシーに関する追加情報（たとえば、ドキュメントへのWebリファレンス）は、署名ポリシー識別子に「修飾子」として伝えることができます。
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).
* 署名されているデータには、人間が解釈できる特定のセマンティクス（意味）があるため、署名者によって行われたコミットメントである暗黙のコミットメントがあります（つまり、無料のテキスト）。
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." 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.
ETSI Electronic Signatureの定義には、「コミットメントは、特定の時間に、識別子の下の署名者、例えば、名前または仮名、およびオプションの役割によって明示的に承認されています。」多くの実際の環境では、ユーザーは異なる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.
以前の手法と同じ利点を提供しませんが、その脅威に対抗する別の手法が特定されています。すべてのCASが登録時に秘密鍵の所持の証明を実行する必要があります。その手法の問題は、検証時に保証を提供しないことであり、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.
署名の検証に使用する証明書を明確に識別するために、署名者からの証明書の識別子は署名データの一部でなければなりません。
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つの主要な目的で発行されている証明書の基本哲学を破るため、このアプローチに従わないことが決定されました。また、署名者の身元証明書の管理のために個別の証明書を使用することにより、追加の役割の管理を簡素化することができます。
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.
署名者は、この主張を裏付ける証明書なしで彼自身の役割を述べると信頼されるかもしれません。その場合、請求された役割を署名属性として署名に追加できます。
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が発行した公開キー証明書を使用または指している場合があります。属性証明書には、さまざまな期間の有効性がある場合があります。その期間は非常に短いかもしれません。たとえば、いつか。これには、その日に有効な新しい属性証明書が毎日取得される必要がありますが、このような証明書の取り消しは必要ない場合があるため、これは有利です。署名時に、署名者は選択する属性証明書を指定する必要があります。そのためには、署名者からのデジタル署名によって保護されるために、属性証明書への参照を署名データに含める必要があります。
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.
署名の検証に使用する属性証明書を明確に識別するために、署名者からの属性証明書の識別子は署名データの一部でなければなりません。
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.
署名者の署名を適用したときに署名者の位置を示すことを提供するために、場所の属性を署名に含めることができます。
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タイムスタンプで示される時間の間である必要があります。
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.
人間のユーザーに署名されたデータを提示する場合、依存している当事者への署名情報の提示に関して曖昧さがないことが重要かもしれません。適切な表現（テキスト、サウンド、またはビデオ）が頼りのパーティーによって選択されるためには、署名者がコンテンツのヒントを示すことができます。依存関係者システムがコンテンツのヒントで指定された形式を使用してデータを依存関係者に提示しない場合、電子署名が有効でない場合があります。
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);
* 証明書の取り消しリスト（CRLS）を使用しています。
* using responses from an on-line certificate status server (for example; obtained through the OCSP protocol).
* オンライン証明書ステータスサーバーからの応答を使用します（たとえば、OCSPプロトコルを介して取得）。
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.
CRLSを使用して取り消し情報を取得する場合、検証者は、署名者の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応答を使用することです。
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の場合のように、この時点で、検証者は、彼または彼女が有効な署名を取得したと確信するかもしれませんが、署名が有効であると確認されたことを後で証明する立場にまだありません。
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.
検証者は、認定パスが署名時に、命名の制約と「署名検証ポリシー」からの証明書ポリシーの制約に従って信託ポイントまで有効であることを証明する必要があります。署名者からのものから始めて、認定パスからすべての証明書をキャプチャし、「署名検証ポリシー」の信頼できるルートからの自己署名証明書の証明書を作成する必要があります。さらに、署名時にチェーンのCASが取り消されなかったことを証明するために、当局の失効リスト（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の場合のように、この時点で、検証者は、彼または彼女が有効な署名を取得したと確信するかもしれませんが、署名が有効であると確認されたことを後で証明する立場にはまだありません。
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つのタイムスタンプ間の許可された時間遅延を指定する場合があります。
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:
現在のドキュメントでは、この妥協から保護するためにタイムスタンプを使用する2つの方法を定義します。
* Time-Stamp the ES with Complete validation data, when an OCSP response is used to get the status of the certificate from the signer.
* 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.
注：署名者、検証者、またはその両方がタイムスタンプを取得する場合があります。
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-X）を備えたESと呼ばれ、このドキュメントにタイムスタンプされたタイプ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の時間スタンプを連結することです。
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.
参考文献上記の完全な検証データで各ESをタイムスタンプすることは、特に同じセットのCA証明書とCRL情報が多くの署名を検証するために使用される場合、効率的ではない場合があります。
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のタイムスタンピングは、たとえば、会社内またはサービスプロバイダーによって中央に行うことができます。この方法は、検証者がタイムスタンプするデータの量を減らします。たとえば、1日に1回のタイムスタンプに減らすことができます（つまり、すべての署名者が同じCAを使用し、CRLが1日に適用される場合があります）。タイムスタンプを必要とする情報は、実際の証明書や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）は、1つ以上のタイムスタンプでカバーされます。
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+.
したがって、時間T1でタイムスタンプの署名値を持つES-Cは、すべてのCAおよびCRL参照が時間T1でタイムスタンプされている場合に有効であることが証明できます。
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.
一定期間にわたって、電子署名を作成するために使用される暗号化アルゴリズムで弱点が発生する可能性があります（たとえば、暗号分析に利用できる時間、または暗号分析技術の改善など）。このような弱点が可能になる前に、検証者は電子署名の妥当性を維持するために追加の措置を講じる必要があります。弱体化した暗号化の性質に応じて、この目標を達成するためにいくつかの手法を使用できます。簡素化するために、すべてのケースをカバーするアーカイブ検証データと呼ばれる単一の手法がこのドキュメントで使用されています。
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（S）はより強力な暗号化とより良いキー保護を使用すると予想されるため、信頼できるサービスプロバイダー（TSP）の重要な妥協の可能性はユーザーキーよりも大幅に低くなるはずです。新しいアルゴリズム（またはキーの長さが大きい古いアルゴリズム）が使用されることが予想されます。そのような場合、一連のタイムスタンプは偽造から保護されます。各タイムスタンプは、署名キーの妥協、またはTSAが使用するアルゴリズムの亀裂のいずれかの前に貼り付ける必要があります。TSAS（タイムスタンピング当局）には、長いキー（例えば、このドキュメントの起草時には、署名RSAアルゴリズムの2048ビット）および/または「良い」または異なるアルゴリズムが必要です。
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.
プロセスは、以前のタイムスタンプを生成するために使用される暗号化アルゴリズムが安全ではなくなる前に、実行および繰り返す必要があります。したがって、アーカイブ検証データには、複数の埋め込みタイムスタンプが付いている場合があります。
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を使用して、Verifiersは、後で再びそれらを取得できるように、署名を検証するために使用されたすべてのコンポーネントを追跡する必要があります。これらのコンポーネントは、信頼できるサービスプロバイダーのような外部ソースによってアーカイブされる場合があります。この場合、完全な検証データ（ES-C）を持つESの一部として提供される情報が適切です。ES-Cの実際の証明書とCRL情報リファレンスは、仲裁に必要なときに収集できます。
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によって署名され、署名者と検証者のデータをタイムスタンプするために2つのアプローチが可能です。
* 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つのタイムスタンプサービスによってトランザクションをタイムスタンプすることができます。後者の場合、電子署名は、両方のタイムスタンプが期限内に取得された場合にのみ有効であると見なされます（つまり、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つの当事者間のビジネス関係をサポートするためにデジタル署名を使用できる全体的な署名ポリシーの一部である署名検証ポリシーの一部です。
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の両方に、署名者の署名に少なくとも1つのタイムスタンプが含まれています。そのタイムスタンプを作成するために使用されるプライベート署名キーの妥協から保護するために、別のタイムスタンプ機関キーが追加されて追加のタイムスタンプを生成する場合、アーカイブ検証データを使用できます。以前のタイムスタンプを提供する際に使用されるTSAキーが（例えば、その有効期間以外）妥協する可能性があると考えられている場合、ES-Aを使用する必要があります。非常に長い間、これは新しいTSAキーを使用して繰り返し適用できます。
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つの当事者間で契約が署名されている場合です。署名の順序は重要である場合とそうでない場合があります。つまり、一方を他方より前に適用する必要がある場合とそうでない場合があります。複数の署名のいくつかの形式をサポートする必要がある場合があります。これは、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項で説明されています。他のすべての複数の署名スキーム、例えば、委員会、二重委員会、または複数の署名を備えた署名ドキュメントは、上記の2つのケースの1つ以上の発生に減らすことができます。
Annex C (informative): Identifiers and roles
付録C（情報）：識別子と役割
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 subjectname証明書拡張フィールドに保持されているその他の名前フォームに保持されている著名な名前である場合があります。被験者が著名な名前を持っていない場合、サブジェクト名は空のシーケンスであり、subjectaltname拡張機能が重要でなければなりません。
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名フォームには、法的管轄区域（すなわち、国）を含む必要があります。
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.
署名者が個人として署名したが、彼/自分自身を組織に代わって行動しているとも特定したい場合、2つの独立した形式の識別を提供する必要があるかもしれません。最初のアイデンティティは、署名キーに直接関連付けられています。独立して管理されている2番目は、おそらく特定の役割を持つ組織の一部として行動する人を特定します。
In this case the first identity is carried in the subject/subjectAltName field of the signer's certificate as described above.
この場合、最初の身元は、上記のように署名者の証明書の件名/subjectaltnameフィールドで運ばれます。
This document supports the following means of providing a second form of identification:
このドキュメントは、2番目の形式の識別を提供する次の手段をサポートしています。
* 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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。