[要約] RFC 5126は、CMS Advanced Electronic Signatures（CAdES）の仕様を定義しています。CAdESは、電子署名の高度な機能を提供するために開発されました。このRFCの目的は、CAdESの仕様を明確にし、セキュアな電子署名の実装を促進することです。
Network Working Group D. Pinkas
Request for Comments: 5126 Bull SAS
Obsoletes: 3126 N. Pope
Category: Informational Thales eSecurity
J. Ross
Security and Standards
February 2008
CMS Advanced Electronic Signatures (CAdES)
CMS高度な電子署名（ケード）
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
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 3852 and RFC 2634, where, when appropriate, additional signed and unsigned attributes have been defined.
この形式は、RFC 3852およびRFC 2634の拡張機能と見なすことができ、必要に応じて追加の署名属性と署名されていない属性が定義されています。
The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced Electronic Signatures -- CAdES) and is technically equivalent to it.
この情報RFCの内容は、ETSI技術仕様（TS）101 733 V.1.7.4（CMS Advanced Electronic Signatures -Cades）の転置に相当し、技術的にはそれに相当します。
The technical contents of this specification are maintained by ETSI. The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx
この仕様の技術的内容は、ETSIによって維持されます。ETSI TSおよびその他の更新は、http：//www.etsi.org/website/standards/standardsdownload.aspxで無料でご利用いただけます。
Table of Contents
目次
1. Introduction ....................................................6
2. Scope ...........................................................6
3. Definitions and Abbreviations ...................................8
3.1. Definitions ................................................8
3.2. Abbreviations .............................................11
4. Overview .......................................................12
4.1. Major Parties .............................................13
4.2. Signature Policies ........................................14
4.3. Electronic Signature Formats ..............................15
4.3.1. CAdES Basic Electronic Signature (CAdES-BES) .......15
4.3.2. CAdES Explicit Policy-based Electronic
Signatures (CAdES-EPES) ............................18
4.4. Electronic Signature Formats with Validation Data .........19
4.4.1. Electronic Signature with Time (CAdES-T) ...........20
4.4.2. ES with Complete Validation Data References
(CAdES-C) ..........................................21
4.4.3. Extended Electronic Signature Formats ..............23
4.4.3.1. EXtended Long Electronic Signature
(CAdES-X Long) ............................24
4.4.3.2. EXtended Electronic Signature with
Time Type 1 ...............................25
4.4.3.3. EXtended Electronic Signature with
Time Type 2 ...............................26
4.4.3.4. EXtended Long Electronic Signature
with Time (CAdES-X Long ...................27
4.4.4. Archival Electronic Signature (CAdES-A) ............27
4.5. Arbitration ...............................................28
4.6. Validation Process ........................................29
5. Electronic Signature Attributes ................................30
5.1. General Syntax ............................................30
5.2. Data Content Type .........................................30
5.3. Signed-data Content Type ..................................30
5.4. SignedData Type ...........................................31
5.5. EncapsulatedContentInfo Type ..............................31
5.6. SignerInfo Type ...........................................31
5.6.1. Message Digest Calculation Process .................32
5.6.2. Message Signature Generation Process ...............32
5.6.3. Message Signature Verification Process .............32
5.7. Basic ES Mandatory Present Attributes .....................32
5.7.1. content-type .......................................32
5.7.2. Message Digest .....................................33
5.7.3. Signing Certificate Reference Attributes ...........33
5.7.3.1. ESS signing-certificate Attribute
Definition ................................34
5.7.3.2. ESS signing-certificate-v2
Attribute Definition ......................34
5.7.3.3. Other signing-certificate
Attribute Definition ......................35
5.8. Additional Mandatory Attributes for Explicit
Policy-based Electronic Signatures ........................36
5.8.1. signature-policy-identifier ........................36
5.9. CMS Imported Optional Attributes ..........................38
5.9.1. signing-time .......................................38
5.9.2. countersignature ...................................39
5.10. ESS-Imported Optional Attributes .........................39
5.10.1. content-reference Attribute .......................39
5.10.2. content-identifier Attribute ......................39
5.10.3. content-hints Attribute ...........................40
5.11. Additional Optional Attributes Defined in the
Present Document .........................................40
5.11.1. commitment-type-indication Attribute ..............41
5.11.2. signer-location Attribute .........................43
5.11.3. signer-attributes Attribute .......................43
5.11.4. content-time-stamp Attribute ......................44
5.12. Support for Multiple Signatures ..........................44
5.12.1. Independent Signatures ............................44
5.12.2. Embedded Signatures ...............................45
6. Additional Electronic Signature Validation Attributes ..........45
6.1. signature time-stamp Attribute (CAdES-T) ..................47
6.1.1. signature-time-stamp Attribute Definition ..........47
6.2. Complete Validation Data References (CAdES-C) .............48
6.2.1. complete-certificate-references Attribute
Definition .........................................48
6.2.2. complete-revocation-references Attribute
Definition .........................................49
6.2.3. attribute-certificate-references Attribute
Definition .........................................51
6.2.4. attribute-revocation-references Attribute
Definition .........................................52
6.3. Extended Validation Data (CAdES-X) ........................52
6.3.1. Time-Stamped Validation Data (CAdES-X Type
1 or Type 2) .......................................53
6.3.2. Long Validation Data (CAdES-X Long, CAdES-X
Long Type 1 or 2) ..................................53
6.3.3. certificate-values Attribute Definition ............54
6.3.4. revocation-values Attribute Definition .............54
6.3.5. CAdES-C-time-stamp Attribute Definition ............56
6.3.6. time-stamped-certs-crls-references
Attribute Definition ...............................57
6.4. Archive Validation Data ...................................58
6.4.1. archive-time-stamp Attribute Definition ............58
7. Other Standard Data Structures .................................60
7.1. Public Key Certificate Format .............................60
7.2. Certificate Revocation List Format ........................60
7.3. OCSP Response Format ......................................60
7.4. Time-Stamp Token Format ...................................60
7.5. Name and Attribute Formats ................................60
7.6. AttributeCertificate ......................................61
8. Conformance Requirements .......................................61
8.1. CAdES-Basic Electronic Signature (CAdES-BES) ..............62
8.2. CAdES-Explicit Policy-based Electronic Signature ..........63
8.3. Verification Using Time-Stamping ..........................63
8.4. Verification Using Secure Records .........................63
9. References .....................................................64
9.1. Normative References ......................................64
9.2. Informative References ....................................65
Annex A (normative): ASN.1 Definitions ............................69
A.1. Signature Format Definitions Using
X.208 ASN.1 Syntax ...................................69
A.2. Signature Format Definitions Using
X.680 ASN.1 Syntax ...................................77
Annex B (informative): Extended Forms of Electronic Signatures ....86
B.1. Extended Forms of Validation Data ....................86
B.1.1. CAdES-X Long ..................................87
B.1.2. CAdES-X Type 1 ................................88
B.1.3. CAdES-X Type 2 ................................90
B.1.4. CAdES-X Long Type 1 and CAdES-X Long Type 2 ...91
B.2. Time-Stamp Extensions ................................93
B.3. Archive Validation Data (CAdES-A) ....................94
B.4. Example Validation Sequence ..........................97
B.5. Additional Optional Features ........................102
Annex C (informative): General Description .......................103
C.1. The Signature Policy ................................103
C.2. Signed Information ..................................104
C.3. Components of an Electronic Signature ...............104
C.3.1. Reference to the Signature Policy ............104
C.3.2. Commitment Type Indication ...................105
C.3.3. Certificate Identifier from the Signer .......106
C.3.4. Role Attributes ..............................106
C.3.4.1. Claimed Role .......................107
C.3.4.2. Certified Role .....................107
C.3.5. Signer Location ..............................108
C.3.6. Signing Time .................................108
C.3.7. Content Format ...............................108
C.3.8. content-hints ................................109
C.3.9. Content Cross-Referencing ....................109
C.4. Components of Validation Data .......................109
C.4.1. Revocation Status Information ................109
C.4.1.1. CRL Information .....................110
C.4.1.2. OCSP Information ....................110
C.4.2. Certification Path ...........................111
C.4.3. Time-stamping for Long Life of Signatures ....111
C.4.4. Time-stamping for Long Life of Signature
before CA key Compromises ....................113
C.4.4.1. Time-stamping the ES with
Complete Validation Data ...........113
C.4.4.2. Time-Stamping Certificates and
Revocation Information References ..114
C.4.5. Time-stamping for Archive of Signature .......115
C.4.6. Reference to Additional Data .................116
C.4.7. Time-Stamping for Mutual Recognition .........116
C.4.8. TSA Key Compromise ...........................117
C.5. Multiple Signatures .................................118
Annex D (informative): Data Protocols to Interoperate with TSPs ..118
D.1. Operational Protocols ...............................118
D.1.1. Certificate Retrieval ........................118
D.1.2. CRL Retrieval ................................118
D.1.3. Online Certificate Status ....................119
D.1.4. Time-Stamping ................................119
D.2. Management Protocols ................................119
D.2.1. Request for Certificate Revocation ...........119
Annex E (informative): Security Considerations ...................119
E.1. Protection of Private Key ...........................119
E.2. Choice of Algorithms ................................119
Annex F (informative): Example Structured Contents and MIME ......120
F.1. General Description .................................120
F.1.1. Header Information ...........................120
F.1.2. Content Encoding .............................121
F.1.3. Multi-Part Content ...........................121
F.2. S/MIME ..............................................122
F.2.1. Using application/pkcs7-mime .................123
F.2.2. Using application/pkcs7-signature ............124
Annex G (informative): Relationship to the European Directive
and EESSI .................................125
G.1. Introduction ........................................125
G.2. Electronic Signatures and the Directive .............126
G.3. ETSI Electronic Signature Formats and the Directive .127
G.4. EESSI Standards and Classes of Electronic Signature .127
G.4.1. Structure of EESSI Standardization ...........127
G.4.2. Classes of Electronic Signatures .............128
G.4.3. Electronic Signature Classes and the ETSI
Electronic Signature Format ..................128
Annex H (informative): APIs for the Generation and Verification
of Electronic Signatures Tokens ...........129
H.1. Data Framing ........................................129
H.2. IDUP-GSS-APIs Defined by the IETF ...................131
H.3. CORBA Security Interfaces Defined by the OMG ........132
Annex I (informative): Cryptographic Algorithms ..................133
I.1. Digest Algorithms ...................................133
I.1.1. SHA-1 ........................................133
I.1.2. General ......................................133
I.2. Digital Signature Algorithms ........................134
I.2.1. DSA ..........................................134
I.2.2. RSA ..........................................135
I.2.3. General ......................................135
Annex J (informative): Guidance on Naming ........................137
J.1. Allocation of Names .................................137
J.2. Providing Access to Registration Information ........138
J.3. Naming Schemes ......................................138
J.3.1. Naming Schemes for Individual Citizens .......138
J.3.2. Naming Schemes for Employees of an
Organization .................................139
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 ISO/IEC 10181-5 [ISO10181-5]) the validity of the signature.
このドキュメントは、そのような署名の長期的な有効性が重要な場合、ビジネストランザクション（購入要求、契約、請求書アプリケーションなど）など、さまざまなタイプのトランザクションの電子署名をカバーすることを目的としています。これには、署名者または検証が後で拒否しようとする場合でも（つまり、拒否します。ISO/IEC 10181-5 [ISO10181-5]を参照）、署名の妥当性を検証する場合でも、その有効性に関する証拠が含まれます。
Thus, the present document can be used for any transaction between an individual and a company, between two companies, between an individual and a governmental body, etc. The present document is independent of any environment; it can be applied to any environment, e.g., smart cards, Global System for Mobile Communication Subscriber Identity Module (GSM SIM) cards, special programs for electronic signatures, etc.
したがって、現在の文書は、個人と会社の間の任意の取引、2つの企業間、個人と政府機関などの取引に使用できます。現在の文書は、あらゆる環境とは無関係です。あらゆる環境に適用できます。たとえば、スマートカード、モバイル通信サブスクライバーIDモジュール（GSM SIM）カード用のグローバルシステム、電子署名用の特別なプログラムなど
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 present document, is a form of advanced electronic signature, as defined in the Directive.
現在のドキュメントで使用されている電子署名は、指令で定義されている高度な電子署名の形式です。
The scope of the present document covers electronic signature formats only. The aspects of Electronic Signature Policies are defined in RFC 3125 [RFC3125] and ETSI TR 102 272 [TR102272].
現在のドキュメントの範囲は、電子署名形式のみをカバーしています。電子署名ポリシーの側面は、RFC 3125 [RFC3125]およびETSI TR 102 272 [TR102272]で定義されています。
The present document defines a number of electronic signature formats, including electronic signatures 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 (repudiates) the validity of the electronic signature.
現在のドキュメントでは、長期間にわたって有効であることができる電子署名を含む、多くの電子署名形式を定義しています。これには、署名者または検証が後に電子署名の有効性を否定（拒否）しようとする場合でも、その有効性に関する証拠が含まれます。
The present document specifies use of Trusted Service Providers (e.g., Time-Stamping Authorities) 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, as defined by the present 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.
現在の文書で定義されている電子署名は、署名者と検証者との間の紛争の場合に仲裁に使用できます。
The present document includes the concept of signature policies that can be used to establish technical consistency when validating electronic signatures, but it does not mandate their use.
現在のドキュメントには、電子署名を検証する際に技術的な一貫性を確立するために使用できる署名ポリシーの概念が含まれていますが、それらの使用を義務付けていません。
The present document is based on the use of public key cryptography to produce digital signatures, supported by public key certificates. The present document also specifies the use of time-stamping and time-marking services to prove the validity of a signature long after the normal lifetime of critical elements of an electronic signature. This document also, as an option, defines ways to provide very long-term protection against key compromise or weakened algorithms.
現在の文書は、公開キーの署名を作成するための公開キー暗号化の使用に基づいており、公開キー証明書によってサポートされています。現在のドキュメントでは、電子署名の重要な要素の通常の寿命の後に署名の妥当性を証明するために、タイムスタンプおよびタイムマークサービスの使用も指定しています。また、このドキュメントは、オプションとして、重要な妥協または弱体化したアルゴリズムに対する非常に長期的な保護を提供する方法を定義します。
The present document builds on existing standards that are widely adopted. These include:
現在のドキュメントは、広く採用されている既存の標準に基づいています。これらには以下が含まれます：
- RFC 3852 [4]: "Cryptographic Message Syntax (CMS)";
- RFC 3852 [4]：「暗号化メッセージ構文（CMS）」;
- ISO/IEC 9594-8/ITU-T Recommendation X.509 [1]: "Information technology - Open Systems Interconnection - The Directory: Authentication framework";
- ISO/IEC 9594-8/ITU -T推奨X.509 [1]：「情報技術 - オープンシステムの相互接続 - ディレクトリ：認証フレームワーク」;
- RFC 3280 [2]: "Internet X.509 Public Key Infrastructure (PKIX) Certificate and Certificate Revocation List (CRL) Profile";
- RFC 3280 [2]：「インターネットX.509公開キーインフラストラクチャ（PKIX）証明書および証明書取消リスト（CRL）プロファイル」;
- RFC 3161 [7]: "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)".
- RFC 3161 [7]：「インターネットX.509公開キーインフラストラクチャタイムスタンププロトコル（TSP）」」。
NOTE: See Section 11 for a full set of references.
注：参照の完全なセットについては、セクション11を参照してください。
The present document describes formats for advanced electronic signatures using ASN.1 (Abstract Syntax Notation 1) [14]. ASN.1 is encoded using X.690 [16].
現在のドキュメントでは、ASN.1を使用した高度な電子署名の形式について説明しています（要約構文表記1）[14]。ASN.1はX.690 [16]を使用してエンコードされています。
These formats are based on CMS (Cryptographic Message Syntax) defined in RFC 3852 [4]. These electronic signatures are thus called CAdES, for "CMS Advanced Electronic Signatures".
これらの形式は、RFC 3852 [4]で定義されているCMS（暗号化メッセージ構文）に基づいています。したがって、これらの電子署名は、「CMS Advanced Electronic Signatures」のためにケードと呼ばれます。
Another document, TS 101 903 [TS101903], describes formats for XML advanced electronic signatures (XAdES) built on XMLDSIG as specified in [XMLDSIG].
別のドキュメントTS 101 903 [TS101903]は、[XMLDSIG]で指定されているようにXMLDSIG上に構築されたXML Advanced Electronic Signatures（Xades）の形式について説明しています。
In addition, the present document identifies other documents that define formats for Public Key Certificates, Attribute Certificates, and Certificate Revocation Lists and supporting protocols, including protocols for use by trusted third parties to support the operation of electronic signature creation and validation.
さらに、現在のドキュメントは、公開キー証明書、属性証明書、証明書の取り消しリスト、およびサポートプロトコルの形式を定義する他のドキュメントを特定します。
Informative annexes include:
有益な付録には以下が含まれます。
- illustrations of extended forms of Electronic Signature formats that protect against various vulnerabilities and examples of validation processes (Annex B);
- さまざまな脆弱性と検証プロセスの例から保護する電子署名形式の拡張形式のイラスト（付録B）。
- descriptions and explanations of some of the concepts used in the present document, giving a rationale for normative parts of the present document (Annex C);
- 現在のドキュメントで使用されているいくつかの概念の説明と説明。現在の文書の規範的部分（付録C）の理論的根拠を示しています。
- information on protocols to interoperate with Trusted Service Providers (Annex D);
- 信頼できるサービスプロバイダーと相互運用するプロトコルに関する情報（付録D）。
- guidance on naming (Annex E);
- 命名に関するガイダンス（付録E）;
- an example structured content and MIME (Annex F);
- 構造化されたコンテンツとMIMEの例（付録F）;
- the relationship between the present document and the directive on electronic signature and associated standardization initiatives (Annex G);
- 現在の文書と電子署名および関連する標準化イニシアチブに関する指令（付録G）との関係。
- APIs to support the generation and verification of electronic signatures (Annex H);
- 電子署名の生成と検証をサポートするAPI（付録H）;
- cryptographic algorithms that may be used (Annex I); and
- 使用できる暗号化アルゴリズム（付録I）;と
- naming schemes (see Annex J).
- 命名スキーム（付録Jを参照）。
For the purposes of the present document, the following terms and definitions apply:
現在の文書の目的のために、次の用語と定義が適用されます。
Arbitrator: an arbitrator entity may be used to arbitrate a dispute between a signer and verifier when there is a disagreement on the validity of a digital signature.
仲裁人：仲裁人エンティティは、デジタル署名の有効性について意見の相違がある場合、署名者と検証剤の間の紛争を仲裁するために使用される場合があります。
Attribute Authority (AA): an authority that assigns privileges by issuing attribute certificates.
属性権限（AA）：属性証明書を発行することにより特権を割り当てる権限。
Authority Certificate: a certificate issued to an authority (e.g., either to a certification authority or an attribute authority).
当局証明書：当局に発行された証明書（例：認証当局または属性当局のいずれか）。
Attribute Authority Revocation List (AARL): a revocation list containing a list of references to certificates issued to AAs that are no longer considered valid by the issuing authority.
Attribute Authority Recocation List（AARL）：発行機関によって有効ではなくなったAASに発行された証明書への参照のリストを含む取り消しリスト。
Attribute Certificate Revocation List (ACRL): a revocation list containing a list of references to attribute certificates that are no longer considered valid by the issuing authority.
属性証明書取消リスト（ACRL）：発行機関によって有効ではなくなった属性証明書への参照のリストを含む取り消しリスト。
Certification Authority Revocation List (CARL): a revocation list containing a list of public key certificates issued to certification authorities that are no longer considered valid by the certificate issuer.
認証局の取り消しリスト（CARL）：証明書発行者によって有効ではなくなった認定当局に発行された公開キー証明書のリストを含む取り消しリスト。
Certification Authority (CA): an authority trusted by one or more users to create and assign public key certificates; optionally, the certification authority may create the users' keys.
認定機関（CA）：1人以上のユーザーが公開キーの証明書を作成および割り当てるために信頼できる機関。オプションで、認定機関はユーザーのキーを作成する場合があります。
NOTE: See ITU-T Recommendation X.509 [1].
注：ITU-Tの推奨X.509 [1]を参照してください。
Certificate Revocation List (CRL): a signed list indicating a set of public key certificates that are no longer considered valid by the certificate issuer.
証明書取消リスト（CRL）：証明書発行者によって有効ではなくなった公開キー証明書のセットを示す署名リスト。
Digital Signature: data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery, e.g., by the recipient.
デジタル署名：データユニットの受信者がデータユニットのソースと整合性を証明し、受信者によって偽造から保護できるようにするデータユニットに追加されたデータまたは暗号化された変換。
NOTE: See ISO 7498-2 [ISO7498-2].
注：ISO 7498-2 [ISO7498-2]を参照してください。
Electronic Signature: data in electronic form that is attached to or logically associated with other electronic data and that serves as a method of authentication.
電子署名：他の電子データに添付されている、または論理的に関連付けられており、認証方法として機能する電子形式のデータ。
NOTE: See Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures [EUDirective].
注：1999年12月13日の欧州議会および評議会の1999/93/ECの指令を参照してください。
Extended Electronic Signatures: electronic signatures enhanced by complementing the baseline requirements with additional data, such as time-stamp tokens and certificate revocation data, to address commonly recognized threats.
拡張された電子署名：一般的に認識されている脅威に対処するために、タイムスタンプトークンや証明書の取り消しデータなどの追加データでベースライン要件を補完することにより強化された電子署名。
Explicit Policy-based Electronic Signature (EPES): an electronic signature where the signature policy that shall be used to validate it is explicitly specified.
明示的なポリシーベースの電子署名（EPES）：それを検証するために使用される署名ポリシーが明示的に指定されている電子署名。
Grace Period: a time period that permits the certificate revocation information to propagate through the revocation process to relying parties.
猶予期間：証明書の取り消し情報が取り消しプロセスを通じて依存して当事者に伝播することを許可する期間。
Initial Verification: a process performed by a verifier done after an electronic signature is generated in order to capture additional information that could make it valid for long-term verification.
初期検証：電子署名の後に行われた検証剤によって実行されるプロセスは、長期的な検証に有効にする可能性のある追加情報をキャプチャするために生成されます。
Public Key Certificate (PKC): public keys of a user, together with some other information, rendered unforgeable by encipherment with the private key of the certification authority that issued it.
公開鍵証明書（PKC）：ユーザーのパブリックキーは、他の情報とともに、発行した認定機関の秘密鍵との秘密鍵との容赦なくレンダリングされました。
NOTE: See ITU-T Recommendation X.509 [1].
注：ITU-Tの推奨X.509 [1]を参照してください。
Rivest-Shamir-Adleman (RSA): an asymmetric cryptography algorithm based on the difficulty to factor very large numbers using a key pair: a private key and a public key.
Rivest-Shamir-Adleman（RSA）：キーペアを使用して非常に多くの数値を考慮するのが難しいことに基づく非対称暗号化アルゴリズム：秘密鍵と公開キー。
Signature Policy: a set of rules for the creation and validation of an electronic signature that defines the technical and procedural requirements for electronic signature creation and validation, in order to meet a particular business need, and under which the signature can be determined to be valid.
署名ポリシー：特定のビジネスニーズを満たすために、電子署名の作成と検証の技術的および手続き的要件を定義する電子署名の作成と検証に関する一連のルール、および署名が有効であると判断されることができる。
Signature Policy Issuer: an entity that defines and issues a signature policy.
署名ポリシー発行者：署名ポリシーを定義および発行するエンティティ。
Signature Validation Policy: part of the signature policy that specifies the technical requirements on the signer in creating a signature and verifier when validating a signature.
署名検証ポリシー：署名者の技術要件を指定する署名ポリシーの一部は、署名を検証する際に署名と検証を作成する際に指定します。
Signer: an entity that creates an electronic signature.
署名者：電子署名を作成するエンティティ。
Subsequent Verification: a process performed by a verifier to assess the signature validity.
後続の検証：検証者によって実行されるプロセスが署名の妥当性を評価します。
NOTE: Subsequent verification may be done even years after the electronic signature was produced by the signer and completed by the initial verification, and it might not need to capture more data than those captured at the time of initial verification.
注：後続の検証は、電子署名が署名者によって作成され、最初の検証によって完了してから数年後でも行われ、最初の検証時にキャプチャされたデータよりも多くのデータをキャプチャする必要はない場合があります。
Time-Stamp Token: a data object that binds a representation of a datum to a particular time, thus establishing evidence that the datum existed before that time.
タイムスタンプトークン：データムの表現を特定の時間に結合するデータオブジェクトであり、その時以前にデータムが存在していたという証拠を確立します。
Time-Mark: information in an audit trail from a Trusted Service Provider that binds a representation of a datum to a particular time, thus establishing evidence that the datum existed before that time.
Time-Mark：データムの表現を特定の時間に結合する信頼できるサービスプロバイダーからの監査証跡の情報が、その時以前にデータムが存在していたという証拠を確立します。
Time-Marking Authority: a trusted third party that creates records in an audit trail in order to indicate that a datum existed before a particular point in time.
タイムマーキング当局：特定の時点でデータムが存在したことを示すために監査証跡に記録を作成する信頼できる第三者。
Time-Stamping Authority (TSA): a trusted third party that creates time-stamp tokens in order to indicate that a datum existed at a particular point in time.
タイムスタンピング機関（TSA）：特定の時点でデータムが存在したことを示すために、タイムスタンプトークンを作成する信頼できる第三者。
Time-Stamping Unit (TSU): a set of hardware and software that is managed as a unit and has a single time-stamp token signing key active at a time.
タイムスタンピングユニット（TSU）：ユニットとして管理され、一度にアクティブにアクティブになっている単一のタイムスタンプトークン署名があるハードウェアとソフトウェアのセット。
Trusted Service Provider (TSP): an entity that helps to build trust relationships by making available or providing some information upon request.
Trusted Service Provider（TSP）：リクエストに応じて情報を提供したり、情報を提供したりすることで、信頼関係を構築するのに役立つエンティティ。
Validation Data: additional data that may be used by a verifier of electronic signatures to determine that the signature is valid.
検証データ：電子署名の検証者によって使用される追加データが署名が有効であると判断することができます。
Valid Electronic Signature: an electronic signature that passes validation.
有効な電子署名：検証に合格する電子署名。
Verifier: an entity that verifies evidence.
Verifier：証拠を検証するエンティティ。
NOTE 1: See ISO/IEC 13888-1 [ISO13888-1].
注1：ISO/IEC 13888-1 [ISO13888-1]を参照してください。
NOTE 2: Within the context of the present document, this is an entity that validates an electronic signature.
注2：現在のドキュメントのコンテキスト内で、これは電子署名を検証するエンティティです。
For the purposes of the present document, the following abbreviations apply:
現在の文書の目的のために、次の略語が適用されます。
AA Attribute Authority
AARL Attribute Authority Revocation List
ACRL Attribute Certificate Revocation List
API Application Program Interface
ASCII American Standard Code for Information Interchange
ASN.1 Abstract Syntax Notation 1
CA Certification Authority
CAD Card Accepting Device
CAdES CMS Advanced Electronic Signature
CAdES-A CAdES with Archive validation data
CAdES-BES CAdES Basic Electronic Signature
CAdES-C CAdES with Complete validation data
CAdES-EPES CAdES Explicit Policy Electronic Signature
CAdES-T CAdES with Time
CAdES-X CAdES with eXtended validation data
CAdES-X Long CAdES with EXtended Long validation data
CARL Certification Authority Revocation List
CMS Cryptographic Message Syntax
CRL Certificate Revocation List
CWA CEN (European Committee for Standardization) Workshop
Agreement
DER Distinguished Encoding Rules (for ASN.1)
DSA Digital Signature Algorithm
EDIFACT Electronic Data Interchange For Administration,
Commerce and Transport
EESSI European Electronic Signature Standardization
Initiative
EPES Explicit Policy-based Electronic Signature
ES Electronic Signature
ESS Enhanced Security Services (enhances CMS)
IDL Interface Definition Language
MIME Multipurpose Internet Mail Extensions
OCSP Online Certificate Status Provider
OID Object IDentifier
PKC Public Key Certificate
PKIX Public Key Infrastructure using X.509
(IETF Working Group)
RSA Rivest-Shamir-Adleman
SHA-1 Secure Hash Algorithm 1
TSA Time-Stamping Authority
TSP Trusted Service Provider
TST Time-Stamp Token
TSU Time-Stamping Unit
URI Uniform Resource Identifier
URL Uniform Resource Locator
XML Extensible Markup Language
XMLDSIG XML Digital Signature
The present document defines a number of Electronic Signature (ES) formats that build on CMS (RFC 3852 [4]) by adding signed and unsigned attributes.
現在のドキュメントでは、署名付き属性と符号なし属性を追加することにより、CMS（RFC 3852 [4]）に基づいて構築される多くの電子署名（ES）形式を定義しています。
This section:
このセクション：
- provides an introduction to the major parties involved (Section 4.1),
- 関係する主要政党への紹介を提供します（セクション4.1）、
- introduces the concept of signature policies (Section 4.2),
- 署名ポリシーの概念を紹介します（セクション4.2）、
- provides an overview of the various ES formats (Section 4.3),
- さまざまなES形式の概要（セクション4.3）を提供します。
- introduces the concept of validation data, and provides an overview of formats that incorporate validation data (Section 4.4), and
- 検証データの概念を紹介し、検証データを組み込んだ形式の概要（セクション4.4）を提供します。
- presents relevant considerations on arbitration (Section 4.5) and for the validation process (Section 4.6).
- 仲裁（セクション4.5）および検証プロセス（セクション4.6）に関する関連する考慮事項を提示します。
The formal specifications of the attributes are specified in Sections 5 and 6; Annexes C and D provide rationale for the definitions of the different ES forms.
属性の正式な仕様は、セクション5および6で指定されています。付録CとDは、異なるESフォームの定義の理論的根拠を提供します。
The major parties involved in a business transaction supported by electronic signatures, as defined in the present document, are:
現在の文書で定義されているように、電子署名によってサポートされているビジネストランザクションに関与する主要な当事者は次のとおりです。
- the signer; - the verifier; - Trusted Service Providers (TSP); and - the arbitrator.
- 署名者; - 検証剤; - 信頼できるサービスプロバイダー（TSP）;および - 仲裁人。
The signer is the entity that 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.
署名者は、電子署名を作成するエンティティです。署名者が所定の形式を使用してデータをデジタル的に署名する場合、これは署名されているデータに対する署名エンティティに代わってコミットメントを表します。
The verifier is the entity that validates the electronic signature; it may be a single entity or multiple entities.
検証者は、電子署名を検証するエンティティです。これは、単一のエンティティまたは複数のエンティティである場合があります。
The Trusted Service Providers (TSPs) are one or more entities that help to build trust relationships between the signer and verifier. They support the signer and verifier by means of supporting services including: user certificates, cross-certificates, time-stamp tokens, CRLs, ARLs, and OCSP responses. The following TSPs are used to support the functions defined in the present document:
信頼できるサービスプロバイダー（TSP）は、署名者と検証者の間の信頼関係を構築するのに役立つ1つ以上のエンティティです。ユーザー証明書、クロス認証、タイムスタンプトークン、CRL、ARLS、OCSP応答など、サービスをサポートすることにより、署名者と検証者をサポートします。次のTSPは、現在のドキュメントで定義されている関数をサポートするために使用されます。
- Certification Authorities; - Registration Authorities; - CRL Issuers; - OCSP Responders; - Repository Authorities (e.g., a Directory); - Time-Stamping Authorities; - Time-Marking Authorities; and - Signature Policy Issuers.
- 認定当局。 - 登録当局。-CRL発行者。-OCSP応答者。 - リポジトリ当局（例：ディレクトリ）; - タイムスタンピング当局。 - タイムマーキング当局。および - 署名ポリシー発行者。
Certification Authorities provide users with public key certificates and a revocation service.
認定当局は、ユーザーに公開キー証明書と取り消しサービスを提供します。
Registration Authorities allow the identification and registration of entities before a CA generates certificates.
登録当局は、CAが証明書を生成する前に、エンティティの識別と登録を許可します。
Repository Authorities publish CRLs issued by CAs, signature policies issued by Signature Policy Issuers, and optionally public key certificates.
リポジトリ当局は、CASによって発行されたCRL、署名ポリシー発行者が発行した署名ポリシー、およびオプションで公開キー証明書を公開しています。
Time-Stamping Authorities attest that some data was formed before a given trusted time.
タイムスタンプ当局は、特定の信頼時間の前にいくつかのデータが形成されたことを証明しています。
Time-Marking Authorities record that some data was formed before a given trusted time.
タイムマーク当局は、特定の信頼時間の前にいくつかのデータが形成されたことを記録しています。
Signature Policy Issuers define the signature policies to be used by signers and verifiers.
署名ポリシー発行者は、署名者と検証者が使用する署名ポリシーを定義します。
In some cases, the following additional TSPs are needed:
場合によっては、次の追加のTSPが必要です。
- Attribute Authorities.
- 属性当局。
Attributes Authorities provide users with attributes linked to public key certificates.
属性当局は、公開キー証明書にリンクされた属性をユーザーに提供します。
An Arbitrator is an entity that arbitrates in disputes between a signer and a verifier.
仲裁人は、署名者と検証者の間の紛争で仲裁するエンティティです。
The present document includes the concept of signature policies that can be used to establish technical consistency when validating electronic signatures.
現在のドキュメントには、電子署名を検証する際に技術的な一貫性を確立するために使用できる署名ポリシーの概念が含まれています。
When a comprehensive signature policy used by the verifier is either explicitly indicated by the signer or implied by the data being signed, then a consistent result can be obtained when validating an electronic signature.
検証者が使用する包括的な署名ポリシーが署名者によって明示的に示されるか、署名されているデータによって暗示される場合、電子署名を検証するときに一貫した結果を得ることができます。
When the signature policy being used by the verifier is neither indicated by the signer nor can be derived from other data, or the signature policy is incomplete, then verifiers, including arbitrators, may obtain different results when validating an electronic signature. Therefore, comprehensive signature policies that ensure consistency of signature validation are recommended from both the signer's and verifier's point of view.
検証者が使用する署名ポリシーが署名者によって示されたり、他のデータから導き出されたりすることも、署名ポリシーが不完全である場合、仲裁人を含む検証剤は、電子署名を検証する際に異なる結果を得ることができます。したがって、署名者と検証者の視点の両方から、署名検証の一貫性を確保する包括的な署名ポリシーが推奨されます。
Further information on signature policies is provided in:
署名ポリシーの詳細については、以下を提供しています。
- TR 102 038 [TR102038]; - Sections 5.8.1, C.1, and C.3.1 of the present document; - RFC 3125 [RFC3125]; and - TR 102 272 [TR102272].
- TR 102 038 [TR102038]; - 現在の文書のセクション5.8.1、C.1、およびC.3.1。-RFC 3125 [RFC3125];および-TR 102 272 [TR102272]。
The current section provides an overview for two forms of CMS advanced electronic signature specified in the present document, namely, the CAdES Basic Electronic Signature (CAdES-BES) and the CAdES Explicit Policy-based Electronic Signature (CAdES-EPES). Conformance to the present document mandates that the signer create one of these formats.
現在のセクションでは、現在のドキュメントで指定された2つの形式のCMS高度な電子署名、つまりCades Basic Electronic Signature（Cades-Bes）とCades明示的なポリシーベースの電子署名（Cades-Epes）の概要を説明します。現在の文書への適合は、署名者がこれらの形式のいずれかを作成することを義務付けています。
A CAdES Basic Electronic Signature (CAdES-BES), in accordance with the present document, contains:
Cades Basic Electronic Signature（Cades-Bes）は、現在の文書に従って、以下が含まれています。
- The signed user data (e.g., the signer's document), as defined in CMS (RFC 3852 [4]);
- CMS（RFC 3852 [4]）で定義されている署名されたユーザーデータ（署名者のドキュメントなど）;
- A collection of mandatory signed attributes, as defined in CMS (RFC 3852 [4]) and in ESS (RFC 2634 [5]);
- CMS（RFC 3852 [4]）およびESS（RFC 2634 [5]）で定義されている必須署名属性のコレクション。
- Additional mandatory signed attributes, defined in the present document; and
- 本文書で定義されている追加の必須署名属性。と
- The digital signature value computed on the user data and, when present, on the signed attributes, as defined in CMS (RFC 3852 [4]).
- CMSで定義されているように、ユーザーデータと存在する場合、署名された属性（RFC 3852 [4]）で計算されたデジタル署名値。
A CAdES Basic Electronic Signature (CAdES-BES), in accordance with the present document, may contain:
Cades Basic Electronic Signature（Cades-Bes）は、現在の文書に従って、以下を含めることができます。
- a collection of additional signed attributes; and
- 追加の署名属性のコレクション。と
- a collection of optional unsigned attributes.
- オプションの符号なし属性のコレクション。
The mandatory signed attributes are:
必須の署名属性は次のとおりです。
- Content-type. It is defined in RFC 3852 [4] and specifies the type of the EncapsulatedContentInfo value being signed. Details are provided in Section 5.7.1 of the present document. Rationale for its inclusion is provided in Annex C.3.7;
- コンテンツタイプ。RFC 3852 [4]で定義されており、署名されているカプセル化されたContentInfo値のタイプを指定します。詳細は、現在のドキュメントのセクション5.7.1に記載されています。その包含の理論的根拠は、付録C.3.7で提供されています。
- Message-digest. It is defined in RFC 3852 [4] and specifies the message digest of the eContent OCTET STRING within encapContentInfo being signed. Details are provided in Section 5.7.2;
- メッセージダイジェスト。RFC 3852 [4]で定義されており、署名されているEncapContentInfo内のecontent Octet Stringのメッセージダイジェストを指定します。詳細については、セクション5.7.2に記載されています。
- ESS signing-certificate OR ESS signing-certificate-v2. The ESS signing-certificate attribute is defined in Enhanced Security Services (ESS), RFC 2634 [5], and only allows for the use of SHA-1 as a digest algorithm. The ESS signing-certificate-v2 attribute is defined in "ESS Update: Adding CertID Algorithm Agility", RFC 5035 [15], and allows for the use of any digest algorithm. A CAdES-BES claiming compliance with the present document must include one of them. Section 5.7.3 provides the details of these attributes. Rationale for its inclusion is provided in Annex C.3.3.
- signing signing-certificateまたはsess signing-ectificate-v2。ESSの署名証明属性は、強化されたセキュリティサービス（ESS）、RFC 2634 [5]で定義されており、SHA-1をダイジェストアルゴリズムとしてのみ使用できます。ESS署名の認証-V2属性は、「ESSアップデート：CertIDアルゴリズムAgilityの追加」、RFC 5035 [15]で定義されており、Digestアルゴリズムを使用できます。現在の文書へのコンプライアンスを主張するケードベスには、そのいずれかを含める必要があります。セクション5.7.3は、これらの属性の詳細を示します。その包含の根拠は、付録C.3.3で提供されています。
Optional signed attributes may be added to the CAdES-BES, including optional signed attributes defined in CMS (RFC 3852 [4]), ESS (RFC 2634 [5]), and the present document. Listed below are optional attributes that are defined in Section 5 and have a rationale provided in Annex C:
CMS（RFC 3852 [4]）、ESS（RFC 2634 [5]）、および現在のドキュメントで定義されたオプションの署名された属性を含む、オプションの署名された属性がCades-Besに追加される場合があります。以下にリストされているのは、セクション5で定義されており、付録Cで提供される理論的根拠があるオプションの属性です。
- Signing-time: as defined in CMS (RFC 3852 [4]), indicates the time of the signature, as claimed by the signer. Details and short rationale are provided in Section 5.9.1. Annex C.3.6 provides the rationale.
- 署名時間：CMS（RFC 3852 [4]）で定義されているように、署名者が主張するように、署名の時間を示します。詳細と短い根拠は、セクション5.9.1に記載されています。付録C.3.6は、理論的根拠を提供します。
- content-hints: as defined in ESS (RFC 2634 [5]), provides information that describes the innermost signed content of a multi-layer message where one content is encapsulated in another. Section 5.10.1 provides the specification details. Annex C.3.8 provides the rationale.
- コンテンツヒント：ESS（RFC 2634 [5]）で定義されているように、あるコンテンツが別のコンテンツにカプセル化される多層メッセージの最も内側の署名コンテンツを説明する情報を提供します。セクション5.10.1では、仕様の詳細を示します。付録C.3.8は、理論的根拠を提供します。
- content-reference: as defined in ESS (RFC 2634 [5]), can be incorporated as a way to link request and reply messages in an exchange between two parties. Section 5.10.1 provides the specification details. Annex C.3.9 provides the rationale.
- Content-Reference：ESS（RFC 2634 [5]）で定義されているように、2つの当事者間の交換でリクエストと返信メッセージをリンクする方法として組み込むことができます。セクション5.10.1では、仕様の詳細を示します。付録C.3.9は、理論的根拠を提供します。
- content-identifier: as defined in ESS (RFC 2634 [5]), contains an identifier that may be used later on in the previous content-reference attribute. Section 5.10.2 provides the specification details.
- Content-Identifier：ESS（RFC 2634 [5]）で定義されているように、以前のコンテンツレファレンス属性で後で使用できる識別子が含まれています。セクション5.10.2では、仕様の詳細を示します。
- commitment-type-indication: this attribute is defined by the present document as a way to indicate the commitment endorsed by the signer when producing the signature. Section 5.11.1 provides the specification details. Annex C.3.2 provides the rationale.
- コミットメントタイプの指定：この属性は、署名を作成する際に署名者が承認したコミットメントを示す方法として現在のドキュメントによって定義されます。セクション5.11.1は、仕様の詳細を示します。付録C.3.2は、理論的根拠を提供します。
- signer-location: this attribute is defined by the present document. It allows the signer to indicate the place where the signer purportedly produced the signature. Section 5.11.2 provides the specification details. Annex C.3.5 provides the rationale.
- 署名者ロケーション：この属性は、現在のドキュメントで定義されています。署名者は、署名者が署名を作成したとされる場所を示すことができます。セクション5.11.2では、仕様の詳細を示します。付録C.3.5は、理論的根拠を提供します。
- signer-attributes: this attribute is defined by the present document. It allows a claimed or certified role to be incorporated into the signed information. Section 5.11.3 provides the specification details. Annex C.3.4 provides the rationale.
- Signer-Attributes：この属性は、現在のドキュメントで定義されています。請求または認定された役割を署名された情報に組み込むことができます。セクション5.11.3は、仕様の詳細を示します。付録C.3.4は、理論的根拠を提供します。
- content-time-stamp: this attribute is defined by the present document. It allows a time-stamp token of the data to be signed to be incorporated into the signed information. It provides proof of the existence of the data before the signature was created. Section 5.11.4 provides the specification details. Annex C.3.6 provides the rationale.
- コンテンツタイムスタンプ：この属性は、現在のドキュメントで定義されています。これにより、データのタイムスタンプトークンを署名して、署名された情報に組み込むことができます。署名が作成される前に、データの存在の証拠を提供します。セクション5.11.4では、仕様の詳細を示します。付録C.3.6は、理論的根拠を提供します。
A CAdES-BES form can also incorporate instances of unsigned attributes, as defined in CMS (RFC 3852 [4]) and ESS (RFC 2634 [5]).
CADES-BESフォームには、CMS（RFC 3852 [4]）およびESS（RFC 2634 [5]）で定義されているように、署名されていない属性のインスタンスを組み込むこともできます。
- CounterSignature, as defined in CMS (RFC 3852 [4]); it can be incorporated wherever embedded signatures (i.e., a signature on a previous signature) are needed. Section 5.9.2 provides the specification details. Annex C.5 in Annex C provides the rationale.
- CMSで定義されているbountersignature（RFC 3852 [4]）;埋め込まれた署名（つまり、以前の署名の署名）が必要な場所に組み込むことができます。セクション5.9.2では、仕様の詳細を示します。付録Cの付録C.5は、理論的根拠を提供します。
The structure of the CAdES-BES is illustrated in Figure 1.
Cades-Besの構造を図1に示します。
+------Elect.Signature (CAdES-BES)------+
|+----------------------------------- + |
||+---------+ +----------+ | |
|||Signer's | | Signed | Digital | |
|||Document | |Attributes| Signature | |
||| | | | | |
||+---------+ +----------+ | |
|+------------------------------------+ |
+---------------------------------------+
Figure 1: Illustration of a CAdES-BES
図1：ケードベスのイラスト
The signer's conformance requirements of a CAdES-BES are defined in Section 8.1.
署名者のケードベスの適合要件は、セクション8.1で定義されています。
NOTE: The CAdES-BES is the minimum format for an electronic signature to be generated by the signer. On its own, it does not provide enough information for it to be verified in the longer term. For example, revocation information issued by the relevant certificate status information issuer needs to be available for long-term validation (see Section 4.4.2).
注：Cades-Besは、署名者によって生成される電子署名の最小形式です。それだけでは、長期的に検証するのに十分な情報を提供しません。たとえば、関連する証明書ステータス情報発行者によって発行された失効情報は、長期的な検証に利用できる必要があります（セクション4.4.2を参照）。
The CAdES-BES satisfies the legal requirements for electronic signatures, as defined in the European Directive on Electronic Signatures, (see Annex C for further discussion on the relationship of the present document to the Directive). It provides basic authentication and integrity protection.
Cades-Besは、電子署名に関する欧州指令で定義されているように、電子署名の法的要件を満たしています（現在の文書と指令との関係に関する詳細については、付録Cを参照）。基本的な認証と整合性の保護を提供します。
The semantics of the signed data of a CAdES-BES or its context may implicitly indicate a signature policy to the verifier.
Cades-Besまたはそのコンテキストの署名データのセマンティクスは、Verifierに署名ポリシーを暗黙的に示す場合があります。
Specification of the contents of signature policies is outside the scope of the present document. However, further information on signature policies is provided in TR 102 038 [TR102038], RFC 3125 [RFC3125], and Sections 5.8.1, C.1, and C.3.1 of the present document.
署名ポリシーの内容の指定は、現在の文書の範囲外です。ただし、署名ポリシーに関する詳細情報は、TR 102 038 [TR102038]、RFC 3125 [RFC3125]、および現在の文書のセクション5.8.1、C.1、およびC.3.1で提供されています。
A CAdES Explicit Policy-based Electronic Signature (CAdES-EPES), in accordance with the present document, extends the definition of an electronic signature to conform to the identified signature policy.
現在の文書に従って、明示的なポリシーベースの電子署名（Cades-EPE）は、特定された署名ポリシーに準拠するために電子署名の定義を拡張します。
A CAdES Explicit Policy-based Electronic Signature (CAdES-EPES) incorporates a signed attribute (sigPolicyID attribute) indicating the signature policy that shall be used to validate the electronic signature. This signed attribute is protected by the signature. The signature may also have other signed attributes required to conform to the mandated signature policy.
Cades明示的なポリシーベースの電子署名（Cades-EPE）には、電子署名の検証に使用される署名ポリシーを示す署名属性（Sigpolicyid属性）が組み込まれています。この署名された属性は、署名によって保護されています。署名には、義務付けられた署名ポリシーに準拠するために必要な他の署名属性もあります。
Section 5.7.3 provides the details on the specification of signature-policy-identifier attribute. Annex C.1 provides a short rationale. Specification of the contents of signature policies is outside the scope of the present document.
セクション5.7.3では、署名-Policy-Identifier属性の仕様に関する詳細を示します。付録C.1は、短い理論的根拠を提供します。署名ポリシーの内容の指定は、現在の文書の範囲外です。
Further information on signature policies is provided in TR 102 038 [TR102038] and Sections 5.8.1, C.1, and C.3.1 of the present document.
署名ポリシーの詳細については、現在の文書のTR 102 038 [TR102038]およびセクション5.8.1、C.1、およびC.3.1に記載されています。
The structure of the CAdES-EPES is illustrated in Figure 2.
Cades-EPEの構造を図2に示します。
+------------- Elect.Signature (CAdES-EPES) ---------------+
| |
|+-------------------------------------------------------+ |
|| +-----------+ | |
|| | | +---------------------------+ | |
|| | | | +----------+ | | |
|| | Signer's | | |Signature | Signed | Digital | |
|| | Document | | |Policy ID | Attributes |Signature| |
|| | | | +----------+ | | |
|| | | +---------------------------+ | |
|| +-----------+ | |
|+-------------------------------------------------------+ |
| |
+----------------------------------------------------------+
Figure 2: Illustration of a CAdES-EPES
図2：ケードエペスのイラスト
The signer's conformance requirements of CAdES-EPES are defined in Section 8.2.
Cades-EPEの署名者の適合要件は、セクション8.2で定義されています。
Validation of an electronic signature, in accordance with the present document, requires additional data needed to validate the electronic signature. This additional data is called validation data, and includes:
現在の文書に従って、電子署名の検証には、電子署名を検証するために必要な追加データが必要です。この追加データは検証データと呼ばれ、以下が含まれます。
- Public Key Certificates (PKCs);
- 公開鍵証明書（PKCS）;
- revocation status information for each PKC;
- 各PKCの取り消しステータス情報。
- trusted time-stamps applied to the digital signature, otherwise a time-mark shall be available in an audit log.
- デジタル署名に適用される信頼できるタイムスタンプ、そうでない場合は、監査ログでタイムマークが利用可能でなければなりません。
- when appropriate, the details of a signature policy to be used to verify the electronic signature.
- 必要に応じて、電子署名を検証するために使用される署名ポリシーの詳細。
The validation data may be collected by the signer and/or the verifier. When the signature-policy-identifier signed attribute is present, it shall meet the requirements of the signature policy.
検証データは、署名者および/または検証者によって収集される場合があります。Signature-Policy-Identifier Signed属性が存在する場合、署名ポリシーの要件を満たすものとします。
Validation data includes CA certificates as well as revocation status information in the form of Certificate Revocation Lists (CRLs) or certificate status information (OCSP) provided by an online service. Validation data also includes evidence that the signature was created before a particular point in time; this may be either a time-stamp token or time-mark.
検証データには、CA証明書と、オンラインサービスが提供する証明書の取り消しリスト（CRLS）または証明書ステータス情報（OCSP）の形式での取り消しステータス情報が含まれます。検証データには、特定の時点で署名が作成されたという証拠も含まれています。これは、タイムスタンプトークンまたはタイムマークのいずれかです。
The present document defines unsigned attributes able to contain validation data that can be added to CAdES-BES and CAdES-EPES, leading to electronic signature formats that include validation data. The sections below summarize these formats and their most relevant characteristics.
現在のドキュメントでは、Cades-BesとCades-EPEに追加できる検証データを含めることができる署名されていない属性を定義し、検証データを含む電子署名形式につながります。以下のセクションでは、これらの形式と最も関連性の高い特性を要約しています。
An electronic signature with time (CAdES-T), in accordance with the present document, is when there exits trusted time associated with the ES.
現在の文書に従って、時間のある電子署名（Cades-T）は、ESに関連付けられた信頼時間を終了する場合です。
The trusted time may be provided by:
信頼できる時間は、次のように提供される場合があります。
- a time-stamp attribute as an unsigned attribute added to the ES; and
- ESに追加された署名されていない属性としてのタイムスタンプ属性。と
- a time-mark of the ES provided by a Trusted Service Provider.
- 信頼できるサービスプロバイダーが提供するESのタイムマーク。
The time-stamp attribute contains a time-stamp token of the electronic signature value. Section 6.1.1 provides the specification details. Annex C.4.3 provides the rationale.
タイムスタンプ属性には、電子署名値のタイムスタンプトークンが含まれています。セクション6.1.1は、仕様の詳細を示します。付録C.4.3は、理論的根拠を提供します。
A time-mark provided by a Trusted Service would have a similar effect to the signature-time-stamp attribute, but in this case, no attribute is added to the ES, as it is the responsibility of the TSP to provide evidence of a time-mark when required to do so. The management of time marks is outside the scope of the present document.
信頼できるサービスによって提供されるタイムマークは、署名時間スタンプ属性と同様の効果を持ちますが、この場合、時間の証拠を提供するTSPの責任であるため、ESに属性は追加されません。 - 必要に応じてマークします。タイムマークの管理は、現在の文書の範囲外です。
Trusted time provides the initial steps towards providing long-term validity. Electronic signatures with the time-stamp attribute or a time-marked BES/EPES, forming the CAdES-T are illustrated in Figure 3.
信頼できる時間は、長期的な妥当性を提供するための最初のステップを提供します。タイムスタンプ属性またはタイムマークされたBES/EPESを備えた電子署名、Cades-Tを形成することを図3に示します。
+-------------------------------------------------CAdES-T ---------+
|+------ CAdES-BES or CAdES-EPES -------+ |
||+-----------------------------------+ | +----------------------+ |
|||+---------+ +----------+ | | | | |
||||Signer's | | Signed | Digital | | | Signature-time-stamp | |
||||Document | |Attributes| Signature | | | attribute required | |
|||| | | | | | | when using time | |
|||+---------+ +----------+ | | | stamps. | |
||+-----------------------------------+ | | | |
|+--------------------------------------+ | or the BES/EPES | |
| | shall be time-marked | |
| | | |
| | Management and | |
| | provision of time | |
| | mark is the | |
| | responsibility of | |
| | the TSP. | |
| +----------------------+ |
+------------------------------------------------------------------+
Figure 3: Illustration of CAdES-T formats
図3：Cades-T形式のイラスト
NOTE 1: A time-stamp token is added to the CAdES-BES or CAdES-EPES as an unsigned attribute.
注1：タイムスタンプトークンが、署名されていない属性としてCades-BesまたはCades-Epesに追加されます。
NOTE 2: Time-stamp tokens that may themselves include unsigned attributes required to validate the time-stamp token, such as the complete-certificate-references and complete-revocation-references attributes, as defined by the present document.
注2：現在のドキュメントで定義されているように、完全な認証紹介や完全な拒否再参照属性など、タイムスタンプトークンを検証するために必要な署名されていない属性が含まれる場合があるタイムスタンプトークン。
Electronic Signature with Complete validation data references (CAdES-C), in accordance with the present document, adds to the CAdES-T the complete-certificate-references and complete-revocation-references attributes, as defined by the present document. The complete-certificate-references attribute contains references to all the certificates present in the certification path used for verifying the signature. The complete-revocation-references attribute contains references to the CRLs and/or OCSPs responses used for verifying the signature. Section 6.2 provides the specification details. Storing the references allows the values of the certification path and the CRLs or OCSPs responses to be stored elsewhere, reducing the size of a stored electronic signature format.
現在のドキュメントに従って、完全な検証データ参照（Cades-C）を備えた電子署名（Cades-C）は、現在のドキュメントで定義されているように、Cades-Tに完全な評判と完全な再参照属性を追加します。完全総参照属性には、署名の検証に使用される認証パスに存在するすべての証明書への参照が含まれています。Complete-revocation-References属性には、署名の検証に使用されるCRLSおよび/またはOCSPS応答への参照が含まれています。セクション6.2では、仕様の詳細を示します。参照を保存すると、認証パスの値とCRLSまたはOCSPS応答を他の場所に保存し、保存された電子署名形式のサイズを縮小できます。
Sections C.4.1 to C.4.2 provide rationale on the usage of validation data and when it is suitable to generate the CAdES-C form. Electronic signatures, with the additional validation data forming the CAdES-C, are illustrated in Figure 4.
セクションC.4.1からC.4.2は、検証データの使用法と、Cades-Cフォームを生成するのに適した場合の理論的根拠を提供します。Cades-Cを形成する追加の検証データを備えた電子署名を図4に示します。
+------------------------- CAdES-C --------------------------------+
|+----------------------------- CAdES-T ---------+ |
|| +----------+ | +-------------+ |
|| |Timestamp | | | | |
|| |attribute | | | | |
||+- CAdES-BES or CAdES-EPES ------+|over | | | | |
||| ||digital | | | Complete | |
|||+---------++----------+ ||signature | | | certificate | |
||||Signer's || Signed | Digital ||is | | | and | |
||||Document ||Attributes|Signature||mandatory | | | revocation | |
|||| || | ||if is not | | | references | |
|||+---------++----------+ ||timemarked| | | | |
||+--------------------------------++----------+ | | | |
|+-----------------------------------------------+ +-------------+ |
+------------------------------------------------------------------+
Figure 4: Illustration of CAdES-C format
図4：Cades-C形式のイラスト
NOTE 1: The complete certificate and revocation references are added to the CAdES-T as an unsigned attribute.
注1：完全な証明書と取り消しの参照が、署名されていない属性としてCades-Tに追加されます。
NOTE 2: As a minimum, the signer will provide the CAdES-BES or, when indicating that the signature conforms to an explicit signing policy, the CAdES-EPES.
注2：少なくとも、署名者はケードベスを提供するか、署名が明示的な署名ポリシーに準拠していることを示す場合、ケードエペスを提供します。
NOTE 3: To reduce the risk of repudiating signature creation, the trusted time indication needs to be as close as possible to the time the signature was created. The signer or a TSP could provide the CAdES-T; if not, the verifier should create the CAdES-T on first receipt of an electronic signature because the CAdES-T provides independent evidence of the existence of the signature prior to the trusted time indication.
注3：署名の作成を拒否するリスクを減らすには、信頼できる時間兆候は、署名が作成された時間にできるだけ近くである必要があります。署名者またはTSPはCades-Tを提供できます。そうでない場合、Cades-Tは信頼できる時間指示の前に署名の存在の独立した証拠を提供するため、電子署名の最初の受信時に検証者はCades-Tを作成する必要があります。
NOTE 4: A CAdES-T trusted time indication must be created before a certificate has been revoked or expired.
注4：証明書が取り消されるか、期限切れになる前に、Cades-T信頼できる時間の表示を作成する必要があります。
NOTE 5: The signer and TSP could provide the CAdES-C to minimize this risk, and when the signer does not provide the CAdES-C, the verifier should create the CAdES-C when the required component of revocation and validation data become available; this may require a grace period.
注5：署名者とTSPは、このリスクを最小限に抑えるためにCades-Cを提供することができ、署名者がCades-Cを提供しない場合、Verifierは失効と検証データの必要なコンポーネントが利用可能になったときにCades-Cを作成する必要があります。これには恵み期間が必要になる場合があります。
NOTE 6: A grace period permits certificate revocation information to propagate through the revocation processes. This period could extend from the time an authorized entity requests certificate revocation to when the information is available for the relying party to use. In order to make sure that the certificate was not revoked at the time the signature was time-marked or time-stamped, verifiers should wait until the end of the grace period. A signature policy may define specific values for grace periods.
注6：猶予期間は、証明書の取り消し情報を失効プロセスを通じて伝播することを許可します。この期間は、承認されたエンティティが証明書の取り消しを要求してから、頼っている当事者が使用する情報がいつ利用できるかまで延長する可能性があります。証明書が取り消されていないことを確認するために、署名が時間マークまたはタイムスタンプされていたときに、検証者は恵み期間の終了まで待つ必要があります。署名ポリシーは、恵み期間の特定の値を定義する場合があります。
An illustration of a grace period is provided in Figure 5.
猶予期間の図を図5に示します。
+<--------------Grace Period --------->+
----+-------+-------+--------+---------------------+----------+
^ ^ ^ ^ ^ ^
| | | | | |
| | | | | |
Signature | First | Second |
creation | revocation | revocation |
time | status | status |
| checking | checking |
| | |
Time-stamp Certification Build
or path CAdES-C
time-mark construction
over & verification
signature
Figure 5: Illustration of a grace period
図5：恵み期間の図
NOTE 7: CWA 14171 [CWA14171] specifies a signature validation process using CAdES-T, CAdES-C, and a grace period. Annex B provides example validation processes. Annex C.4 provides additional information about applying grace periods during the validation process.
注7：CWA 14171 [CWA14171]は、Cades-T、Cades-C、およびGrace期間を使用した署名検証プロセスを指定します。付録Bは、検証プロセスの例を提供します。Annex C.4は、検証プロセス中の恵み期間の適用に関する追加情報を提供します。
The verifier's conformance requirements are defined in Section 8.3 for time-stamped CAdES-C, and Section 8.4 for time-marked CAdES-C. The present document only defines conformance requirements for the verifier up to an ES with Complete validation data (CAdES-C). This means that none of the extended and archive forms of electronic signatures, as defined in Sections 4.4.3 to 4.4.4, need to be implemented to achieve conformance to the present document.
検証剤の適合要件は、時間刻印されたケードCのセクション8.3で定義されており、タイムマークされたケードCのセクション8.4で定義されています。現在のドキュメントは、完全な検証データ（Cades-C）を持つESまでの検証者の適合要件のみを定義しています。これは、セクション4.4.3〜4.4.4で定義されているように、電子署名の拡張フォームとアーカイブフォームのいずれも、現在のドキュメントへの適合を達成するために実装する必要がないことを意味します。
CAdES-C can be extended by adding unsigned attributes to the electronic signature. The present document defines various unsigned attributes that are applicable for very long-term verification, and for preventing some disaster situations that are discussed in Annex C. Annex B provides the details of the various extended formats, all the required unsigned attributes for each type, and how they can be used within the electronic signature validation process. The sections below give an overview of the various forms of extended signature formats in the present document.
Cades-Cは、電子署名に署名されていない属性を追加することで拡張できます。現在のドキュメントでは、非常に長期的な検証に適用されるさまざまな署名の属性を定義し、付録C. Annex Bで議論されているいくつかの災害状況を防ぐために、各タイプに必要なすべての符号なし属性の詳細を提供します。電子署名検証プロセス内でどのように使用できるか。以下のセクションでは、現在のドキュメントの拡張署名形式のさまざまな形式の概要を示しています。
Extended Long format (CAdES-X Long), in accordance with the present document, adds the certificate-values and revocation-values attributes to the CAdES-C format. The first one contains the whole certificate path required for verifying the signature; the second one contains the CRLs and/OCSP responses required for the validation of the signature. This provides a known repository of certificate and revocation information required to validate a CAdES-C and prevents such information from getting lost. Sections 6.3.3 and 6.3.4 give specification details. Annex B.1.1 gives details on the production of the format. Annexes C4.1 to C.4.2 provide the rationale.
現在のドキュメントに従って、拡張ロングフォーマット（Cades-X Long）は、Cades-C形式に証明書の値と取消値の属性を追加します。最初のものには、署名を確認するために必要な証明書パス全体が含まれています。2つ目には、署名の検証に必要なCRLSおよび/OCSP応答が含まれています。これにより、Cades-Cを検証するために必要な証明書および取り消し情報の既知のリポジトリが提供され、そのような情報が迷子になるのを防ぎます。セクション6.3.3および6.3.4は、仕様の詳細を示します。付録B.1.1は、フォーマットの作成に関する詳細を示しています。付録C4.1からC.4.2は、理論的根拠を提供します。
The structure of the CAdES-X Long format is illustrated in Figure 6.
Cades-X Long形式の構造を図6に示します。
+----------------------- CAdES-X-Long -----------------------------+
|+------------------------------------ CadES-C --+ |
|| +----------+ | +-------------+ |
||+------ CAdES -------------------+|Timestamp | | | | |
||| || over | | | Complete | |
|||+---------++----------+ ||digital | | | certificate | |
||||Signer's || Signed | Digital ||signature | | | and | |
||||Document ||Attributes|Signature|| | | | revocation | |
|||| || | ||Optional | | | data | |
|||+---------++----------+ ||when | | | | |
||+--------------------------------+|timemarked| | | | |
|| +----------+ | | | |
|| +-------------+ | +-------------+ |
|| | Complete | | |
|| | certificate | | |
|| | and | | |
|| | revocation | | |
|| | references | | |
|| +-------------+ | |
|+-----------------------------------------------+ |
| |
+------------------------------------------------------------------+
Figure 6: Illustration of CAdES-X-Long
図6：Cades-X-Longのイラスト
4.4.3.2. EXtended Electronic Signature with Time Type 1 (CAdES-X Type 1)
4.4.3.2. タイムタイプ1の拡張電子署名（ケード-Xタイプ1）
Extended format with time type 1 (CAdES-X Type 1), in accordance with the present document, adds the CAdES-C-time-stamp attribute, whose content is a time-stamp token on the CAdES-C itself, to the CAdES-C format.
Time Type 1（Cades-X Type 1）を使用した拡張形式は、現在のドキュメントに従って、Cades-C-Time-Stamp属性を追加します。-c形式。
This provides an integrity and trusted time protection over all the elements and references. It may protect the certificates, CRLs, and OCSP responses in case of a later compromise of a CA key, CRL key, or OCSP issuer key. Section 6.3.5 provides the specification details.
これは、すべての要素と参照にわたって完全性と信頼できる時間保護を提供します。CAキー、CRLキー、またはOCSP発行者キーの後の妥協の場合、証明書、CRL、およびOCSP応答を保護する場合があります。セクション6.3.5では、仕様の詳細を示します。
Annex B.1.2 gives details on the production of the time-stamping process. Annex C.4.4.1 provides the rationale.
付録B.1.2は、タイムスタンププロセスの生産に関する詳細を示しています。付録C.4.4.1は、理論的根拠を提供します。
The structure of the CAdES-X Type 1 format is illustrated in Figure 7.
Cades-X Type 1形式の構造を図7に示します。
+----------------------- CAdES-X-Type 1 ------------------------------+
|+-------------------------------------- CAdES-C -----+ |
|| +-------------+ | +-----------+ |
||+--------- CAdES ------------------+| Timestamp | | | | |
||| || over | | | | |
|||+---------++----------+ || digital | | | | |
||||Signer's || Signed | Digital || signature | | | Timestamp | |
||||Document ||Attributes| Signature || | | | over | |
|||| || | || Optional | | | CAdES-C | |
|||+---------++----------+ || when | | | | |
||+----------------------------------+| time-marked | | | | |
|| +-------------+ | | | |
|| +-------------+ | +-----------+ |
|| | Complete | | |
|| | certificate | | |
|| | and | | |
|| | revocation | | |
|| | references | | |
|| +-------------+ | |
|+----------------------------------------------------+ |
+---------------------------------------------------------------------+
Figure 7: Illustration of CAdES-X Type 1
図7：Cades-X Type 1のイラスト
4.4.3.3. EXtended Electronic Signature with Time Type 2 (CAdES-X Type 2)
4.4.3.3. タイムタイプ2の拡張電子署名（ケード-Xタイプ2）
Extended format with time type 2 (CAdES-X Type 2), in accordance with the present document, adds to the CAdES-C format the CAdES-C-time-stamped-certs-crls-references attribute, whose content is a time-stamp token on the certification path and revocation information references. This provides an integrity and trusted time protection over all the references.
Time Type 2（Cades-X Type 2）を使用した拡張形式は、現在のドキュメントに従って、Cades-C-Time-Stamped-Certs-CRLS-References属性をCades-C形式に追加します。認証パスおよび取り消し情報の参照にトークンをスタンプします。これは、すべての参照に対して完全性と信頼できる時間保護を提供します。
It may protect the certificates, CRLs and OCSP responses in case of a later compromise of a CA key, CRL key or OCSP issuer key.
CAキー、CRLキー、またはOCSP発行者キーの後の妥協の場合、証明書、CRLS、およびOCSP応答を保護する場合があります。
Both CAdES-X Type 1 and CAdES-X Type 2 counter the same threats, and the usage of one or the other depends on the environment. Section 6.3.5 provides the specification details. Annex B.1.3 gives details on the production of the time-stamping process. Annex C.4.4.2 provides the rationale.
Cades-X Type 1とCades-X Type 2の両方が同じ脅威に対抗し、どちらか一方の使用は環境に依存します。セクション6.3.5では、仕様の詳細を示します。付録B.1.3は、タイムスタンププロセスの生産に関する詳細を示しています。付録C.4.4.2は、理論的根拠を提供します。
The structure of the CAdES-X Type 2 format is illustrated in Figure 8.
Cades-X Type 2形式の構造を図8に示します。
+------------------------- CAdES-X-Type 2 ----------------------------+
|+----------------------------------------CAdES-C ---+ |
|| +------------+| |
||+----- CAdES -----------------------+| Timestamp || |
||| || over || |
|||+---------+ +----------+ || digital || +-------------+|
||||Signer's | | Signed | Digital || signature || | Time-stamp ||
||||Document | |Attributes| signature || || | only over ||
|||| | | | || optional || | complete ||
|||+---------+ +----------+ || when || | certificate ||
||+-----------------------------------+| timemarked || | and ||
|| +------------+| | revocation ||
|| +-------------+ | | references ||
|| | Complete | | +-------------+|
|| | certificate | | |
|| | and | | |
|| | revocation | | |
|| | references | | |
|| +-------------+ | |
|+---------------------------------------------------+ |
+---------------------------------------------------------------------+
Figure 8: Illustration of CAdES-X Type 2
図8：Cades-Xタイプ2のイラスト
Extended Long with Time (CAdES-X Long Type 1 or 2), in accordance with the present document, is a combination of CAdES-X Long and one of the two former types (CAdES-X Type 1 and CAdES-X Type 2). Annex B.1.4 gives details on the production of the time-stamping process. Annex C.4.8 in Annex C provides the rationale.
現在のドキュメントに従って、時間とともに長い時間を長く延長します（Cades-X Long Type 1または2）は、Cades-X Longと2つの以前のタイプの1つ（Cades-X Type 1とCades-X Type 2の1つ）の組み合わせです。。付録B.1.4は、タイムスタンププロセスの生産に関する詳細を示しています。付録Cの付録C.4.8は、理論的根拠を提供します。
The structure of the CAdES-X Long Type 1 and CAdES-X Long Type 2 format is illustrated in Figure 9.
Cades-X Long Type 1およびCades-X Long Type 2形式の構造を図9に示します。
+------------------ CAdES-X Long Type 1 or 2 -----------------------+
| +--------------+|
|+-------------------------------------- CAdES-C --+|+------------+||
|| ||| Timestamp |||
||+------- CAdES --------------------++----------+ ||| over |||
||| ||Timestamp | ||| CAdES-C |||
||| ||over | ||+------------+||
|||+---------++----------+ ||digital | || OR ||
||||Signer's || Signed | Digital ||signature | ||+------------+||
||||Document ||Attributes| signature || | ||| Timestamp |||
|||| || | ||Optional | ||| only over |||
|||+---------++----------+ ||when | ||| complete |||
||+----------------------------------+|timemarked| ||| certificate|||
|| +----------+ ||| and |||
|| ||| Revocation |||
|| +-------------+ ||| References |||
|| | Complete | ||+------------+||
|| | certificate | |+--------------+|
|| | and | | +------------+ |
|| | revocation | | | Complete | |
|| | references | | |certificate | |
|| +-------------+ | | and | |
|+-------------------------------------------------+ |revocation | |
| | value | |
| +------------+ |
+-------------------------------------------------------------------+
Figure 9: Illustration of CAdES-X Long Type 1 and CAdES Long Type 2
図9：ケードXロングタイプ1とケードロングタイプ2のイラスト
Archival Form (CAdES-A), in accordance with the present document, builds on a CAdES-X Long or a CAdES-X Long Type 1 or 2 by adding one or more archive-time-stamp attributes. This form is used for archival of long-term signatures. Successive time-stamps protect the whole material against vulnerable hashing algorithms or the breaking of the cryptographic material or algorithms. Section 6.4 contains the specification details. Sections C.4.5 and C.4.8 provide the rationale.
アーカイブフォーム（Cades-A）は、現在のドキュメントに従って、1つ以上のアーカイブタイムスタンプ属性を追加することにより、Cades-X LongまたはCades-X Long Type 1または2の上に構築されます。このフォームは、長期署名のアーカイブに使用されます。連続したタイムスタンプは、脆弱なハッシュアルゴリズムまたは暗号化材料またはアルゴリズムの破壊から材料全体を保護します。セクション6.4には、仕様の詳細が含まれています。セクションC.4.5およびC.4.8は、理論的根拠を提供します。
The structure of the CAdES-A form is illustrated in Figure 10.
Cades-Aフォームの構造を図10に示します。
+---------------------------CAdES-A ---------------------------------+
|+----------------------------------------------------+ |
|| +--------------+| +----------+ |
||+----------------------CAdES-C ----+|+------------+|| | | |
||| +----------+ ||| Timestamp ||| | | |
|||+---- CAdES-BES ----+|Timestamp | ||| over ||| | | |
|||| or CAdeS-EPES || over | ||| CAdES-C ||| | Archive | |
|||| ||digital | ||+------------+|| | | |
|||| ||signature | || or || |Timestamp | |
|||| || | ||+------------+|| | | |
|||| ||Optional | ||| Timestamp ||| | | |
|||| ||when | ||| only over ||| | | |
|||| ||Timemarked| ||| complete ||| | | |
|||+-------------------+| | ||| certificate||| +----------+ |
||| +----------+ ||| and ||| |
||| +-------------+ ||| revocation ||| |
||| | Complete | ||| references ||| |
||| | certificate | ||+------------+|| |
||| | and | |+--------------+| |
||| | revocation | | +------------+ | |
||| | references | | | Complete | | |
||| +-------------+ | |certificate | | |
||| | | and | | |
||+----------------------------------+ |revocation | | |
|| | values | | |
|| +------------+ | |
|+----------------------------------------------------+ |
+--------------------------------------------------------------------+
Figure 10: Illustration of CAdES-A
図10：Cades-Aのイラスト
The CAdES-C may be used for arbitration should there be a dispute between the signer and verifier, provided that:
Cades-Cは、署名者と検証者の間に紛争がある場合、仲裁に使用される場合があります。
- the arbitrator knows where to retrieve the signer's certificate (if not already present), all the cross-certificates and the required CRLs, ACRLs, or OCSP responses referenced in the CAdES-C;
- 仲裁人は、署名者の証明書（まだ存在していない場合）、すべてのクロス認証、および必要なCRL、ACRL、またはCades-Cで参照されるOCSP応答をどこで取得するかを知っています。
- when time-stamping in the CAdES-T is being used, the certificate from the TSU that has issued the time-stamp token in the CAdES-T format is still within its validity period;
- Cades-Tのタイムスタンプが使用されている場合、Cades-T形式でタイムスタンプトークンを発行したTSUの証明書は、その有効期間内にあります。
- when time-stamping in the CAdES-T is being used, the certificate from the TSU that has issued the time-stamp token in the CAdES-T format is not revoked at the time of arbitration;
- Cades-Tのタイムスタンプが使用されている場合、Cades-T形式でタイムスタンプトークンを発行したTSUの証明書は、仲裁時には取り消されません。
- when time-marking in the CAdES-T is being used, a reliable audit trail from the Time-Marking Authority is available for examination regarding the time;
- Cades-Tでのタイムマークが使用されている場合、タイムマーク当局からの信頼できる監査証跡が、時間に関する試験に利用できます。
- none of the private keys corresponding to the certificates used to verify the signature chain have ever been compromised;
- 署名チェーンの検証に使用される証明書に対応するプライベートキーは、これまでに侵害されていません。
- the cryptography used at the time the CAdES-C was built has not been broken at the time the arbitration is performed; and
- Cades-Cが構築されたときに使用された暗号化は、仲裁が行われた時点で壊れていません。と
- if the signature policy can be explicitly or implicitly identified, then an arbitrator is able to determine the rules required to validate the electronic signature.
- 署名ポリシーを明示的または暗黙的に識別できる場合、仲裁人は電子署名を検証するために必要な規則を決定できます。
The validation process validates an electronic signature; the output status of the validation process can be:
検証プロセスは、電子署名を検証します。検証プロセスの出力ステータスは次のとおりです。
- invalid;
- 無効;
- incomplete validation; or
- 不完全な検証。また
- valid.
- 有効。
An invalid response indicates that either the signature format is incorrect or that the digital signature value fails verification (e.g., the integrity check 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 signature validation status is currently unknown. In the case of incomplete validation, additional information may be made available to the application or user, thus allowing them to decide what to do with the electronic signature. In the case of incomplete validation, the electronic signature may be checked again at some later time when additional information becomes available.
不完全な検証応答は、署名検証ステータスが現在不明であることを示しています。不完全な検証の場合、アプリケーションまたはユーザーが追加情報を利用できるようにすることができるため、電子署名をどうするかを決定できるようになります。不完全な検証の場合、追加情報が利用可能になった後の時期に、電子署名が再度チェックされる場合があります。
NOTE: For example, an incomplete validation may be because all the required certificates are not available or the grace period is not completed.
注：たとえば、不完全な検証は、必要なすべての証明書が利用できないか、猶予期間が完了していないためである可能性があります。
A valid response indicates that the signature has passed verification, and it complies with the signature validation policy.
有効な応答は、署名が検証に合格しており、署名検証ポリシーに準拠していることを示しています。
Example validation sequences are illustrated in Annex B.
検証シーケンスの例は、付録Bに示されています。
This section builds upon the existing Cryptographic Message Syntax (CMS), as defined in RFC 3852 [4], and Enhanced Security Services (ESS), as defined in RFC 2634 [5]. The overall structure of an Electronic Signature is as defined in CMS. The Electronic Signature (ES) uses attributes defined in CMS, ESS, and the present document. The present document defines ES attributes that it uses and that are not defined elsewhere.
このセクションでは、RFC 3852 [4]で定義されているように、既存の暗号化メッセージ構文（CMS）と、RFC 2634 [5]で定義されているセキュリティサービス（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 the present document. A signature policy may mandate that other signed attributes be present.
義務付けられた属性とデジタル署名値は、現在のドキュメントで必要な最小電子署名（ES）として定義されます。署名ポリシーは、他の署名された属性が存在することを義務付ける場合があります。
The general syntax of the ES is as defined in CMS (RFC 3852 [4]).
ESの一般的な構文は、CMSで定義されています（RFC 3852 [4]）。
NOTE: CMS defines content types for id-data, id-signedData, id-envelopedData, id-digestedData, id-encryptedData, and id-authenticatedData. Although CMS permits other documents to define other content types, the ASN.1 type defined should not be a CHOICE type. The present document does not define other content types.
注：CMSは、ID-Data、ID-SignedData、ID-EnvelopedData、ID-DigestedData、ID-RyptedData、およびID-AuthenticedDataのコンテンツタイプを定義します。CMSは他のドキュメントで他のコンテンツタイプを定義することを許可していますが、定義されたASN.1タイプは選択タイプであってはなりません。現在のドキュメントでは、他のコンテンツタイプを定義していません。
The data content type of the ES is as defined in CMS (RFC 3852 [4]).
ESのデータコンテンツタイプは、CMSで定義されています（RFC 3852 [4]）。
NOTE: If the content type is id-data, it is recommended that the content be encoded using MIME, and that the MIME type is used to identify the presentation format of the data. See Annex F.1 for an example of using MIME to identify the encoding type.
注：コンテンツタイプがID-DATAの場合、MIMEを使用してコンテンツをエンコードし、MIMEタイプを使用してデータのプレゼンテーション形式を識別することをお勧めします。MIMEを使用してエンコーディングタイプを識別する例については、付録F.1を参照してください。
The Signed-data content type of the ES is as defined in CMS (RFC 3852 [4]).
ESの署名されたDATAコンテンツタイプは、CMSで定義されています（RFC 3852 [4]）。
The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 [4]).
ESのSignedDataの構文は、CMSで定義されているとおりです（RFC 3852 [4]）。
The fields of type SignedData are as defined in CMS (RFC 3852 [4]).
タイプSignedDataのフィールドは、CMSで定義されているとおりです（RFC 3852 [4]）。
The identification of a signer's certificate used to create the signature is always signed (see Section 5.7.3). The validation policy may specify requirements for the presence of certain certificates. The degenerate case, where there are no signers, is not valid in the present document.
署名の作成に使用される署名者の証明書の識別は、常に署名されています（セクション5.7.3を参照）。検証ポリシーは、特定の証明書の存在に関する要件を指定する場合があります。署名者がいない退化したケースは、現在の文書では無効です。
The syntax of the EncapsulatedContentInfo type ES is as defined in CMS (RFC 3852 [4]).
CMSの構文は、CMS（RFC 3852 [4]）で定義されているとおりです。
For the purpose of long-term validation, as defined by the present document, it is advisable that either the eContent is present, or the data that is signed is archived in such as way as to preserve 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が署名を生成するために使用することが重要です。
NOTE: The eContent is optional in CMS :
注：econtentはCMSでオプションです：
- When it is present, this allows the signed data to be encapsulated in the SignedData structure, which then contains both the signed data and the signature. However, the signed data may only be accessed by a verifier able to decode the ASN.1 encoded SignedData structure.
- それが存在する場合、これにより、署名されたデータを署名されたデータ構造にカプセル化することができます。これには、署名されたデータと署名の両方が含まれます。ただし、署名されたデータには、ASN.1エンコードされたSignedData構造をデコードできる検証者によってのみアクセスできます。
- When it is missing, this allows the signed data to be sent or stored separately from the signature, and the SignedData structure only contains the signature. It is, in the case of the signature, only the data that is signed that needs to be stored and distributed in such as way as to preserve any data encoding.
- 欠落している場合、これにより、署名されたデータを署名から個別に送信または保存することができ、署名data構造には署名のみが含まれます。署名の場合、署名されたデータのみが、エンコードを保存する方法などで保存および配布する必要があります。
The degenerate case where there are no signers is not valid in the present document.
署名者がいない退化したケースは、現在の文書では無効です。
The syntax of the SignerInfo type ES is as defined in CMS (RFC 3852 [4]).
SignerINFOタイプESの構文は、CMSで定義されているとおりです（RFC 3852 [4]）。
Per-signer information is represented in the type SignerInfo. In the case of multiple independent signatures (see Annex B.5), there is an instance of this field for each signer.
署名者ごとの情報は、Type Signerinfoで表されます。複数の独立した署名の場合（付録B.5を参照）、各署名者にこのフィールドのインスタンスがあります。
The fields of type SignerInfo have the meanings defined in CMS (RFC 3852 [4]), but the signedAttrs field shall contain the following attributes:
タイプSignerinfoのフィールドには、CMS（RFC 3852 [4]）で定義されている意味がありますが、SigneDattrsフィールドには次の属性が含まれます。
- content-type, as defined in Section 5.7.1; and
- セクション5.7.1で定義されているコンテンツタイプ。と
- message-digest, as defined in Section 5.7.2;
- セクション5.7.2で定義されているメッセージダイジスト。
- signing-certificate, as defined in Section 5.7.3.
- セクション5.7.3で定義されているように、署名証明。
The message digest calculation process is as defined in CMS (RFC 3852 [4]).
メッセージダイジェスト計算プロセスは、CMSで定義されているとおりです（RFC 3852 [4]）。
The input to the message signature generation process is as defined in CMS (RFC 3852 [4]).
メッセージ署名生成プロセスへの入力は、CMSで定義されています（RFC 3852 [4]）。
The procedures for message signature verification are defined in CMS (RFC 3852 [4]) and enhanced in the present document: the input to the signature verification process must be the signer's public key, which shall be verified as correct using the signing certificate reference attribute containing a reference to the signing certificate, i.e., when SigningCertificateV2 from RFC 5035 [16] or SigningCertificate from ESS [5] is used, the public key from the first certificate identified in the sequence of certificate identifiers from SigningCertificate must be the key used to verify the digital signature.
メッセージ署名検証の手順はCMS（RFC 3852 [4]）で定義され、現在のドキュメントで強化されています。署名検証プロセスへの入力は、署名者の公開鍵でなければなりません。署名証明書への参照を含む、つまり、RFC 5035 [16]からの署名certificatev2またはess [5]からの署名certificate [5]を含む場合、signiblecertificateの証明書識別子のシーケンスで識別された最初の証明書の公開キーは、使用されるキーでなければなりませんデジタル署名を確認します。
The following attributes shall be present with the signed-data defined by the present document. The attributes are defined in CMS (RFC 3852 [4]).
以下の属性は、現在の文書で定義された署名されたデータとともに存在するものとします。属性はCMS（RFC 3852 [4]）で定義されています。
The content-type attribute indicates the type of the signed content. The syntax of the content-type attribute type is as defined in CMS (RFC 3852 [4]) Section 11.1.
コンテンツタイプの属性は、署名されたコンテンツのタイプを示します。コンテンツタイプの属性タイプの構文は、CMS（RFC 3852 [4]）セクション11.1で定義されています。
NOTE 1: As stated in RFC 3852 [4] , the content-type attribute must have its value (i.e., ContentType) equal to the eContentType of the EncapsulatedContentInfo value being signed.
注1：RFC 3852 [4]に記載されているように、コンテンツタイプの属性は、その値（つまり、コンテンツタイプ）が署名されているcapsulatedContentInfo値のecontentTypeに等しくなければなりません。
NOTE 2: For implementations supporting signature generation, if the content-type attribute is id-data, then it is recommended that the eContent be encoded using MIME. For implementations supporting signature verification, if the signed data (i.e., eContent) is MIME-encoded, then the OID of the content-type attribute must be id-data. In both cases, the MIME content-type(s) must be used to identify the presentation format of the data. See Annex F for further details about the use of MIME.
注2：署名生成をサポートする実装の場合、コンテンツタイプの属性がID-DATAの場合、EcontentをMIMEを使用してエンコードすることをお勧めします。署名検証をサポートする実装の場合、署名されたデータ（つまり、econtent）がMIMEエンコードされている場合、コンテンツタイプの属性のOIDはid-dataでなければなりません。どちらの場合も、MIMEコンテンツタイプを使用して、データのプレゼンテーション形式を識別する必要があります。MIMEの使用に関する詳細については、付録Fを参照してください。
The syntax of the message-digest attribute type of the ES is as defined in CMS (RFC 3852 [4]).
ESのメッセージダイジェスト属性タイプの構文は、CMSで定義されているとおりです（RFC 3852 [4]）。
The Signing certificate reference attributes are supported by using either the ESS signing-certificate attribute or the ESS-signing-certificate-v2 attribute.
署名証明書リファレンス属性は、ESS署名の認証属性またはESS-SINGIBE-Certificate-V2属性のいずれかを使用してサポートされます。
These attributes shall contain a reference to the signer's certificate; they are designed to prevent simple substitution and reissue attacks and to allow for a restricted set of certificates to be used in verifying a signature. They have a compact form (much shorter than the full certificate) that allows for a certificate to be unambiguously identified.
これらの属性には、署名者の証明書への参照が含まれます。それらは、単純な置換および再発行攻撃を防ぎ、署名の検証に制限された証明書を使用できるように設計されています。それらは、証明書を明確に識別できるようにするコンパクトなフォーム（完全な証明書よりもはるかに短い）を持っています。
One, and only one, of the following alternative attributes shall be present with the signedData, defined by the present document:
次の代替属性のうち、1つ、および1つだけが、現在のドキュメントで定義されたSignedDataに存在するものとします。
- The ESS signing-certificate attribute, defined in ESS [5], must be used if the SHA-1 hashing algorithm is used.
- ESS [5]で定義されているESS署名証明の属性は、SHA-1ハッシュアルゴリズムを使用する場合は使用する必要があります。
- The ESS signing-certificate-v2 attribute, defined in "ESS Update: Adding CertID Algorithm Agility", RFC 5035 [15], which shall be used when other hashing algorithms are to be used.
- 「ESSアップデート：CertIDアルゴリズムのagilityの追加」、RFC 5035 [15]で定義されているESS署名の認証-V2属性。これは、他のハッシュアルゴリズムを使用する場合に使用されるものとします。
The certificate to be used to verify the signature shall be identified in the sequence (i.e., the certificate from the signer), and the sequence shall not be empty. The signature validation policy may mandate other certificates be present that may include all the certificates up to the trust anchor.
The syntax of the signing-certificate attribute type of the ES is as defined in Enhanced Security Services (ESS), RFC 2634 [5], and further qualified in the present document.
ESの署名認証属性タイプの構文は、強化されたセキュリティサービス（ESS）、RFC 2634 [5]で定義されており、現在のドキュメントでさらに資格があります。
The sequence of the policy information field is not used in the present document.
ポリシー情報フィールドのシーケンスは、現在のドキュメントでは使用されていません。
The ESS signing-certificate attribute shall be a signed attribute. The encoding of the ESSCertID for this certificate shall include the issuerSerial field.
ESS Signing-Certificate属性は、署名された属性でなければなりません。この証明書のEsscertidのエンコーディングには、発行担当フィールドが含まれます。
If present, the issuerAndSerialNumber in SignerIdentifier field of the SignerInfo shall match the issuerSerial field present in ESSCertID. In addition, the certHash from ESSCertID shall match the SHA-1 hash of the certificate. The certificate identified shall 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 shall be considered invalid.
存在する場合、SignerInfoのSigneridentifierフィールドにある発行者の登録担当者は、Esscertidに存在する発行担当フィールドと一致するものとします。さらに、EsscertidのCerthashは、証明書のSHA-1ハッシュと一致するものとします。特定された証明書は、署名検証プロセス中に使用されるものとします。証明書のハッシュが署名の検証に使用される証明書と一致しない場合、署名は無効と見なされます。
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-attributes attribute as defined in Section 5.8.3.
The ESS signing-certificate-v2 attribute is similar to the ESS signing-certificate defined above, except that this attribute can be used with hashing algorithms other than SHA-1.
この属性は、SHA-1以外のハッシュアルゴリズムで使用できることを除いて、ESS署名の認証-V2属性は、上記で定義されたESS署名認証の属性と類似しています。
The syntax of the signing-certificate-v2 attribute type of the ES is as defined in "ESS Update: Adding CertID Algorithm Agility", RFC 5035 [15], and further qualified in the present document.
ESの署名認証-V2属性タイプの構文は、「ESSアップデート：CertIDアルゴリズムのagilityの追加」、RFC 5035 [15]で定義されており、現在のドキュメントでさらに資格があります。
The sequence of the policy information field is not used in the present document.
ポリシー情報フィールドのシーケンスは、現在のドキュメントでは使用されていません。
This attribute shall be used in the same manner as defined above for the ESS signing-certificate attribute.
この属性は、上記のESS署名承認属性の場合と同じ方法で使用するものとします。
The object identifier for this attribute is:
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 47 }
If present, the issuerAndSerialNumber in SignerIdentifier field of the SignerInfo shall match the issuerSerial field present in ESSCertIDv2. In addition, the certHash from ESSCertIDv2 shall match the hash of the certificate computed using the hash function specified in the hashAlgorithm field. The certificate identified shall 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 shall be considered invalid.
存在する場合、SignerInfoのSigneridentifierフィールドの発行者と登場者は、esscertidv2に存在する発行担当フィールドと一致するものとします。さらに、esscertidv2のcerthashは、ハッシュハルゴリズムフィールドで指定されたハッシュ関数を使用して計算された証明書のハッシュと一致するものとします。特定された証明書は、署名検証プロセス中に使用されるものとします。証明書のハッシュが署名の検証に使用される証明書と一致しない場合、署名は無効と見なされます。
NOTE 1: 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-attributes attribute as defined in Section 5.8.3.
注1：署名者が属性証明書を使用して、署名者のその他の属性を電子署名に関連付けるために使用されます。これは、セクション5.8.3で定義されているように、署名者とアトリビュートの属性に配置されます。
NOTE 2: RFC 3126 was using the other signing-certificate attribute (see Section 5.7.3.3) for the same purpose. Its use is now deprecated, since this structure is simpler.
注2：RFC 3126は、同じ目的で他の署名承認属性（セクション5.7.3.3を参照）を使用していました。この構造はより単純であるため、その使用は現在廃止されています。
RFC 3126 was using the other signing-certificate attribute as an alternative to the ESS signing-certificate when hashing algorithms other than SHA-1 were being used. Its use is now deprecated, since the structure of the signing-certificate-v2 attribute is simpler. Its description is however still present in this version for backwards compatibility.
RFC 3126は、SHA-1以外のハッシュアルゴリズムが使用されている場合、ESSの署名証明書に代わるものとして、他の署名認証属性を使用していました。署名の認証-V2属性の構造がより単純であるため、その使用は現在廃止されています。ただし、このバージョンには、後方互換性のためにまだ説明が存在します。
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 other-signing-certificate attribute value has the ASN.1 syntax OtherSigningCertificate:
他の署名承認属性値には、asn.1 syntax othersIngingCertificateがあります。
OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THE PRESENT 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 }
The present document mandates that for CAdES-EPES, a reference to the signature policy is included in the signedData. This reference is explicitly identified. A signature policy defines the rules for creation and validation of an electronic signature, and is included as a signed attribute with every Explicit Policy-based Electronic Signature. The signature-policy-identifier shall be a signed attribute.
現在の文書は、Cades-EPEの場合、署名ポリシーへの参照がSignedDataに含まれていることを義務付けています。この参照は明示的に識別されます。署名ポリシーは、電子署名の作成と検証のルールを定義し、すべての明示的なポリシーベースの電子署名と署名された属性として含まれています。Signature-Policy-Identifierは、署名された属性でなければなりません。
The following object identifier identifies the signature-policy-identifier attribute:
次のオブジェクト識別子は、署名-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 }
signature-policy-identifier attribute values have ASN.1 type SignaturePolicyIdentifier:
Signature-Policy-Identifierの属性値にはasn.1タイプSignaturePolicyIdentifier：
SignaturePolicyIdentifier ::= CHOICE {
signaturePolicyId SignaturePolicyId,
signaturePolicyImplied SignaturePolicyImplied
-- not used in this version
}
SignaturePolicyId ::= SEQUENCE {
sigPolicyId SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL}
SignaturePolicyImplied ::= NULL
The sigPolicyId field contains an object-identifier that uniquely identifies a specific version of the signature policy. The syntax of this field is as follows:
Sigpolicyidフィールドには、署名ポリシーの特定のバージョンを一意に識別するオブジェクト識別子が含まれています。このフィールドの構文は次のとおりです。
SigPolicyId ::= OBJECT IDENTIFIER
The sigPolicyHash field optionally contains the identifier of the hash algorithm and the hash of the value of the signature policy. The hashValue within the sigPolicyHash may be set to zero to indicate that the policy hash value is not known.
Sigpolicyhashフィールドには、オプションで、ハッシュアルゴリズムの識別子と署名ポリシーの値のハッシュが含まれています。Sigpolicyhash内のハッシュバルーは、ポリシーハッシュ値が不明であることを示すためにゼロに設定される場合があります。
NOTE: The use of a zero sigPolicyHash value is to ensure backwards compatibility with earlier versions of the current document. If sigPolicyHash is zero, then the hash value should not be checked against the calculated hash value of the signature policy.
注：ゼロSigpolicyhash値の使用は、現在のドキュメントの以前のバージョンとの逆方向の互換性を確保することです。Sigpolicyhashがゼロの場合、ハッシュ値を署名ポリシーの計算されたハッシュ値に対してチェックしないでください。
If the signature policy is defined using ASN.1, then the hash is calculated on the value without the outer type and length fields, and the hashing algorithm shall be as specified in the field sigPolicyHash.
署名ポリシーがASN.1を使用して定義されている場合、ハッシュは外部タイプと長さのフィールドなしで値で計算され、ハッシュアルゴリズムはフィールドSigpolicyhashで指定されているとおりです。
If the signature policy is defined using another structure, the type of structure and the hashing algorithm shall be either specified as part of the signature policy, or indicated using a signature policy qualifier.
署名ポリシーが別の構造を使用して定義されている場合、構造のタイプとハッシュアルゴリズムは、署名ポリシーの一部として指定されるか、署名ポリシー修飾子を使用して示されます。
SigPolicyHash ::= OtherHashAlgAndValue
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue }
OtherHashValue ::= OCTET STRING
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 }
The present document specifies the following qualifiers:
現在のドキュメントでは、次の予選を指定します。
- spuri: this contains the web URI or URL reference to the signature policy, and
- Spuri：これには、署名ポリシーへのWeb URIまたはURL参照が含まれています。
- sp-user-notice: this contains a user notice that should be displayed whenever the signature is validated.
- SP-USER-NOTICE：これには、署名が検証されたときに表示されるユーザー通知が含まれています。
sigpolicyQualifierIds defined in the present document:
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、Noticenumbersシーケンスの整数}
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; the attributes are defined in CMS (RFC 3852 [4]) and are imported into the present document. Where appropriate, the attributes are qualified and profiled by the present document.
次の属性は、署名されたデータに存在する場合があります。属性はCMS（RFC 3852 [4]）で定義され、現在のドキュメントにインポートされます。必要に応じて、属性は現在のドキュメントによって資格があり、プロファイルされます。
The signing-time attribute specifies the time at which the signer claims to have performed the signing process.
署名時の属性は、署名者が署名プロセスを実行したと主張する時間を指定します。
Signing-time attribute values for ES have the ASN.1 type SigningTime as defined in CMS (RFC 3852 [4]).
ESの署名時間属性値には、CMS（RFC 3852 [4]）で定義されているASN.1タイプの署名時間があります。
NOTE: RFC 3852 [4] states that dates between January 1, 1950 and December 31, 2049 (inclusive) must be encoded as UTCTime. Any dates with year values before 1950 or after 2049 must be encoded as GeneralizedTime.
注：RFC 3852 [4]は、1950年1月1日から2049年12月31日（包括的）の間にUTCTIMEとしてエンコードする必要があると述べています。1950年以前または2049年以降の年価値のある日付は、一般化された時間としてエンコードする必要があります。
The countersignature attribute values for ES have ASN.1 type CounterSignature, as defined in CMS (RFC 3852 [4]). A countersignature attribute shall be an unsigned attribute.
cmsで定義されているように、ESのcountersignature属性値には、asn.1型countersignatureがあります（RFC 3852 [4]）。counterSignature属性は、署名されていない属性でなければなりません。
The following attributes may be present with the signed-data defined by the present document. The attributes are defined in ESS and are imported into the present document and are appropriately qualified and profiled by the present document.
以下の属性は、現在のドキュメントで定義された署名されたデータに存在する場合があります。属性はESSで定義されており、現在のドキュメントにインポートされており、現在のドキュメントで適切に資格があり、プロファイルされています。
The content-reference attribute is a link from one SignedData to another. It may be used to link a reply to the original message to which it refers, or to incorporate by reference one SignedData into another. The content-reference attribute shall be a signed attribute.
コンテンツリファレンス属性は、あるsignedDataから別の署名型へのリンクです。これは、それが言及する元のメッセージへの返信をリンクするために使用するか、参照1つのsignedDataに組み込むために使用される場合があります。コンテンツリファレンス属性は、署名された属性でなければなりません。
content-reference attribute values for ES have ASN.1 type ContentReference, as defined in ESS (RFC 2634 [5]).
ES（RFC 2634 [5]）で定義されているように、ESのコンテンツリファレンス属性値には、asn.1タイプのコンテンツがあります。
The content-reference attribute shall be used as defined in ESS (RFC 2634 [5]).
コンテンツリファレンス属性は、ESS（RFC 2634 [5]）で定義されているように使用するものとします。
The content-identifier attribute provides an identifier for the signed content, for use when a reference may be later required to that content; for example, in the content-reference attribute in other signed data sent later. The content-identifier shall be a signed attribute.
Content-Identifier属性は、そのコンテンツに後で参照が必要になる場合に使用するために、署名されたコンテンツの識別子を提供します。たとえば、後で送信された他の署名データのコンテンツリファレンス属性。Content-Identifierは、署名された属性でなければなりません。
content-identifier attribute type values for the ES have an ASN.1 type ContentIdentifier, as defined in ESS (RFC 2634 [5]).
ES（RFC 2634 [5]）で定義されているように、ESのContent-Identifier属性タイプの値は、asn.1型Contentidentifierを持っています。
The minimal content-identifier attribute 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 Content-Identifier属性には、ユーザー固有の識別情報（ユーザー名やパブリックキーイングマテリアル識別情報など）の連結、一般化された時間文字列、および乱数を含める必要があります。
The content-hints attribute provides information on the innermost signed content of a multi-layer message where one content is encapsulated in another.
コンテンツヒント属性は、あるコンテンツが別のコンテンツにカプセル化されているマルチレイヤーメッセージの最も内側の符号付きコンテンツに関する情報を提供します。
The syntax of the content-hints attribute type of the ES is as defined in ESS (RFC 2634 [5]).
ESのコンテンツヒント属性タイプの構文は、ESS（RFC 2634 [5]）で定義されているとおりです。
When used to indicate the precise format of the data to be presented to the user, the following rules apply:
ユーザーに提示されるデータの正確な形式を示すために使用される場合、次のルールが適用されます。
- the contentType 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; and
- ContentTypeは、関連するコンテンツのタイプを示します。これは、コンテンツタイプを定義する当局によって割り当てられたオブジェクト識別子（つまり、一意の整数の文字列）です。と
- when the contentType is id-data, the contentDescription shall define the presentation format; the format may be defined by MIME types.
- ContentTypeがID-DATAの場合、ContentDescriptionはプレゼンテーション形式を定義します。この形式は、MIMEタイプで定義できます。
When the format of the content is defined by MIME types, the following rules apply:
コンテンツの形式がMIMEタイプで定義される場合、次のルールが適用されます。
- the contentType shall be id-data, as defined in CMS (RFC 3852 [4]);
- CMS（RFC 3852 [4]）で定義されているように、contentTypeはid-dataでなければなりません。
- the contentDescription shall be used to indicate the encoding of the data, in accordance with the rules defined RFC 2045 [6]; see Annex F for an example of structured contents and MIME.
- コンテンツデスクリプリは、RFC 2045 [6]と定義されたルールに従って、データのエンコードを示すために使用するものとします。構造化された内容とmimeの例については、付録Fを参照してください。
NOTE 1: id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
NOTE 2: contentDescription is optional in ESS (RFC 2634 [5]). It may be used to complement contentTypes defined elsewhere; such definitions are outside the scope of the present document.
注2：ContentDescriptionはESS（RFC 2634 [5]）でオプションです。他の場所で定義されているコンテンツタイプを補完するために使用できます。このような定義は、現在のドキュメントの範囲外です。
This section defines a number of attributes that may be used to indicate additional information to a verifier:
このセクションでは、検証者に追加情報を示すために使用できる多くの属性を定義します。
a) the type of commitment from the signer, and/or
a) 署名者からのコミットメントの種類、および/または
b) the claimed location where the signature is performed, and/or c) claimed attributes or certified attributes of the signer, and/or
b) 署名が実行される請求場所、および/またはc）署名者の属性または認定属性、および/または
d) a content time-stamp applied before the content was signed.
d) コンテンツが署名される前に適用されるコンテンツタイムスタンプ。
There may be situations where 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 commitment-type-indication attribute conveys such information.
署名者が、データに署名することにより、署名者に代わって一種のコミットメントを示していることを検証者に明示的に示したい状況があるかもしれません。コミットメントタイプの指標属性は、そのような情報を伝えます。
The commitment-type-indication attribute shall be a signed attribute. The commitment type may be:
コミットメントタイプの指標属性は、署名された属性でなければなりません。コミットメントタイプは次のとおりです。
- defined as part of the signature policy, in which case, the commitment type has precise semantics that are defined as part of the signature policy; and
- 署名ポリシーの一部として定義されています。その場合、コミットメントタイプには、署名ポリシーの一部として定義される正確なセマンティクスがあります。と
- 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 the present document.
コミットメントタイプへの予選者の使用は、現在のドキュメントの範囲外です。
The following generic commitment types are defined in the present 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 meanings:
これらの一般的なコミットメントタイプには、次の意味があります。
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 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 [11]).
署名者ロケーション属性は、特定の地理的（都市）の場所で署名者に関連付けられたアドレスのニーモニックを指定します。ニーモニックは、署名者が位置する国に登録されており、公共電報サービスの提供に使用されています（ITU-Tの推奨F.1 [11]に従って）。
The signer-location attribute shall 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 shall 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 specifies additional attributes of the signer (e.g., role). It may be either:
Signer-Attributes属性は、署名者の追加属性（例：役割）を指定します。どちらかです：
- claimed attributes of the signer; or
- 署名者の主張された属性。また
- certified attributes of the signer.
- 署名者の認定属性。
The signer-attributes attribute shall be a signed attribute. The following object identifier identifies the signer-attribute attribute:
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}
signer-attributes values have ASN.1 type SignerAttribute:
Signer-Attributesの値にはasn.1タイプSignerAttribute：
SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes }
ClaimedAttributes ::= SEQUENCE OF Attribute
CertifiedAttributes ::= AttributeCertificate
-- as defined in RFC 3281: see Section 4.1.
NOTE 1: Only a single signer-attributes can be used.
注1：単一の署名者とアトリビュートのみを使用できます。
NOTE 2: Attribute and AttributeCertificate are as defined respectively in ITU-T Recommendations X.501 [9] and X.509 [1].
注2：属性と属性の属性は、ITU-Tの推奨X.501 [9]およびX.509 [1]でそれぞれ定義されています。
The content-time-stamp attribute is an attribute that is the time-stamp token of the signed data content before it is signed. The content-time-stamp attribute shall be a signed attribute.
コンテンツタイムスタンプ属性は、署名される前に署名されたデータコンテンツのタイムスタンプトークンである属性です。コンテンツタイムスタンプ属性は、署名された属性でなければなりません。
The following object identifier identifies the content-time-stamp 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 of TimeStampToken (as described in RFC 3161 [7]) shall be a hash of the value of the eContent field within encapContentInfo in the signedData.
（RFC 3161 [7]で説明されている）TimestamptokenのMessageImprintの値は、SignedDataのEncapContentinfo内のecontentフィールドの値のハッシュとなります。
For further information and definition of TimeStampToken, see Section 7.4.
Timestamptokenの詳細と定義については、セクション7.4を参照してください。
NOTE: content-time-stamp indicates that the signed information was formed before the date included in the content-time-stamp.
注：コンテンツタイムスタンプは、コンテンツタイムスタンプに含まれる日付の前に署名された情報が形成されたことを示します。
Multiple independent signatures (see Annex B.5) are supported by independent SignerInfo from each signer.
複数の独立した署名（付録B.5を参照）は、各署名者の独立した署名者によってサポートされています。
Each SignerInfo shall include all the attributes required under the present document and shall be processed independently by the verifier.
各Signerinfoは、本文書に必要なすべての属性を含めるものとし、検証剤によって独立して処理されるものとします。
NOTE: Independent signatures may be used to provide independent signatures from different parties with different signed attributes, or to provide multiple signatures from the same party using alternative signature algorithms, in which case the other attributes, excluding time values and signature policy information, will generally be the same.
注：独立した署名を使用して、さまざまな署名属性を持つさまざまな関係者から独立した署名を提供するか、代替署名アルゴリズムを使用して同じ当事者から複数の署名を提供することができます。同じである。
Multiple embedded signatures (see Annex C.5) are supported using the countersignature unsigned attribute (see Section 5.9.2). Each counter signature is carried in countersignature held as an unsigned attribute to the SignerInfo to which the counter-signature is applied.
複数の埋め込み署名（付録C.5を参照）は、counterignature unsigned属性（セクション5.9.2を参照）を使用してサポートされています。各カウンター署名は、カウンターシグネチャが適用されるSignerInfoへの符号なしの属性として保持されているcountersignatureで運ばれます。
NOTE: Counter signatures may be used to provide signatures from different parties with different signed attributes, or to provide multiple signatures from the same party using alternative signature algorithms, in which case the other attributes, excluding time values and signature policy information, will generally be the same.
注：カウンターシグネチャは、さまざまな署名属性を持つさまざまな関係者の署名を提供するために使用できます。また、代替署名アルゴリズムを使用して同じ当事者から複数の署名を提供します。同じ。
This section specifies attributes that contain different types of validation data. These attributes build on the electronic signature specified in Section 5. This includes:
このセクションでは、さまざまなタイプの検証データを含む属性を指定します。これらの属性は、セクション5で指定された電子署名に基づいて構築されます。これには以下が含まれます。
- Signature-time-stamp applied to the electronic signature value or a Time-Mark in an audit trail. This is defined as the Electronic Signature with Time (CAdES-T); and
- 電子署名値または監査証跡のタイムマークに適用される署名時間スタンプ。これは、時間のある電子署名（Cades-T）として定義されます。と
- Complete validation data references that comprise the time-stamp of the signature value, plus references to all the certificates (complete-certificate-references) and revocation (complete-revocation-references) information used for full validation of the electronic signature. This is defined as the Electronic Signature with Complete data references (CAdES-C).
- 署名値のタイムスタンプを構成する完全な検証データ参照に加えて、すべての証明書（完全な認証参照）および撤退（完全繰り返し参照）情報への参照は、電子署名の完全な検証に使用されます。これは、完全なデータ参照（Cades-C）を備えた電子署名として定義されます。
NOTE 1: Formats for CAdES-T are illustrated in Section 4.4, and the attributes are defined in Section 6.1.1.
注1：Cades-Tの形式はセクション4.4に示されており、属性はセクション6.1.1で定義されています。
NOTE 2: Formats for CAdES-C are illustrated in Section 4.4. The required attributes for the CAdES-C signature format are defined in Sections 6.2.1 to 6.2.2; optional attributes are defined in Sections 6.2.3 and 6.2.4.
注2：Cades-Cのフォーマットは、セクション4.4に示されています。Cades-C署名形式に必要な属性は、セクション6.2.1〜6.2.2で定義されています。オプションの属性は、セクション6.2.3および6.2.4で定義されています。
In addition, the following optional extended forms of validation data are also defined; see Annex B for an overview of the extended forms of validation data:
さらに、次のオプションの拡張フォームの検証データも定義されています。検証データの拡張形式の概要については、付録Bを参照してください。
- CAdES-X with time-stamp: there are two types of time-stamps used in extended validation data defined by the present document;
- タイムスタンプ付きのCades-X：現在のドキュメントで定義された拡張検証データに使用されるタイムスタンプには2つのタイプがあります。
- Type 1(CAdES-X Type 1): comprises a time-stamp over the ES with Complete validation data (CAdES-C); and
- タイプ1（Cades-X Type 1）：完全な検証データ（Cades-C）を備えたES上のタイムスタンプを含む。と
- Type 2 (CAdES-X Type2): comprises a time-stamp over the certification path references and the revocation information references used to support the CAdES-C.
- タイプ2（Cades-X Type2）：認定パス参照のタイムスタンプと、Cades-Cをサポートするために使用される取り消し情報リファレンスを含む。
NOTE 3: Formats for CAdES-X Type 1 and CAdES-X Type 2 are illustrated in Sections B.1.2 and B.1.3, respectively.
注3：Cades-X Type 1およびCades-X Type 2のフォーマットは、それぞれセクションB.1.2およびB.1.3に示されています。
- CAdES-X Long: comprises the Complete validation data references (CAdES-C), plus the actual values of all the certificates and revocation information used in the CAdES-C.
- Cades-X Long：完全な検証データ参照（Cades-C）に加えて、Cades-Cで使用されるすべての証明書と取り消し情報の実際の値を含む。
NOTE 4: Formats for CAdES-X Long are illustrated in Annex B.1.1.
注4：Cades-X Longのフォーマットは、付録B.1.1に示されています。
- CAdES-X Long Type 1 or CAdES-X Long Type 2: comprises an X-Time-Stamp (Type 1 or Type 2), plus the actual values of all the certificates and revocation information used in the CAdES-C as per CAdES-X Long.
- Cades-X Long Type 1またはCades-X Long Type 2：X-Time-Stamp（タイプ1またはタイプ2）に加えて、Cades-Cで使用されるすべての証明書と取り消し情報の実際の値を含む - x長い。
This section also specifies the data structures used in Archive validation data format (CAdES-A)of extended forms:
このセクションでは、拡張フォームのアーカイブ検証データ形式（Cades-A）で使用されるデータ構造も指定しています。
- Archive form of electronic signature (CAdES-A) comprises:
- 電子署名のアーカイブ形式（Cades-A）は次のとおりです。
- the Complete validation data references (CAdES-C),
- 完全な検証データ参照（Cades-C）、
- the certificate and revocation values (as in a CAdES-X Long ),
- 証明書と失効値（ケードXの長さのように）、
- any existing extended electronic signature time-stamps (CAdES-X Type 1 or CAdES-X Type 2), if present, and
- 既存の電子署名タイムスタンプ（Cades-Xタイプ1またはCades-Xタイプ2）、存在する場合、
- the signed user data and an additional archive time-stamp applied over all that data.
- 署名されたユーザーデータと追加のアーカイブタイムスタンプが、そのすべてのデータに適用されました。
An archive time-stamp may be repeatedly applied after long periods to maintain validity when electronic signature and time-stamping algorithms weaken.
アーカイブタイムスタンプは、電子署名およびタイムスタンプアルゴリズムが弱体化する場合に有効性を維持するために、長期にわたって繰り返し適用できます。
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 Section 6 are unsigned attributes.
上記の電子署名の形式を作成するために必要な追加データは、SignerInfoのunsignedattrsフィールドに配置されることにより、個々の署名に関連付けられた署名のない属性として運ばれます。したがって、セクション6で定義されているすべての属性は、署名されていない属性です。
NOTE 5: Where multiple signatures are to be supported, as described in Section 5.12, each signature has a separate SignerInfo. Thus, each signature requires its own unsigned attribute values to create CAdES-T, CAdES-C, etc.
注5：セクション5.12で説明されているように、複数の署名がサポートされる場合、各署名には別のSignerinfoがあります。したがって、各署名には、Cades-T、Cades-Cなどを作成するために、独自の署名されていない属性値が必要です。
NOTE 6: The optional attributes of the extended validation data are defined in Sections 6.3 and 6.4.
注6：拡張検証データのオプションの属性は、セクション6.3および6.4で定義されています。
An electronic signature with time-stamp is an electronic signature for which part, but not all, of the additional data required for validation is available (i.e., some certificates and revocation information are available, but not all).
タイムスタンプを備えた電子署名は、検証に必要な追加データのすべてではなく、すべてではありませんが、すべてではありませんが、すべてではありませんが、すべてではありませんが、すべてではありません）。
The minimum structure time-stamp validation data is:
最小構造のタイムスタンプ検証データは次のとおりです。
- the signature time-stamp attribute, as defined in Section 6.1.1, over the ES signature value.
- セクション6.1.1で定義されているSignature Time-Stamp属性は、ES署名値を超えています。
The signature-time-stamp attribute is a TimeStampToken computed on the signature value for a specific signer; it is an unsigned attribute. Several instances of this attribute may occur with an electronic signature, from different TSAs.
署名時間スタンプ属性は、特定の署名者の署名値に計算されたタイムスタンプトンです。それは署名されていない属性です。この属性のいくつかのインスタンスは、異なるTSAから電子署名で発生する場合があります。
The following object identifier identifies the signature-time-stamp 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-time-stamp attribute value has ASN.1 type SignatureTimeStampToken:
Signature-Time-Stamp属性値には、asn.1タイプSignAtureTimestAmptoken：
SignatureTimeStampToken ::= TimeStampToken
The value of the messageImprint field within TimeStampToken shall be
a hash of the value of the signature field within SignerInfo for the
signedData being time-stamped.
For further information and definition of TimeStampToken, see Section 7.4.
Timestamptokenの詳細と定義については、セクション7.4を参照してください。
NOTE 1: In the case of multiple signatures, it is possible to have a:
注1：複数の署名の場合、：
- TimeStampToken computed for each and all signers; or
- すべての署名者のために計算されたTimestamptoken;また
- TimeStampToken computed on one signer's signature; and no
- 1つの署名者の署名で計算されたTimestamptoken。といいえ
- TimeStampToken on another signer's signature.
- 別の署名者の署名でTimestamptoken。
NOTE 2: In the case of multiple signatures, several TSTs, issued by different TSAs, may be present within the same signerInfo (see RFC 3852 [4]).
注2：複数の署名の場合、異なるTSAによって発行されたいくつかのTSTが同じSignerinfo内に存在する場合があります（RFC 3852 [4]を参照）。
An electronic signature with Complete validation data references (CAdES-C) is an electronic signature for which all the additional data required for validation (i.e., all certificates and revocation information) is available. This form is built on the CAdES-T form defined above.
完全な検証データ参照（CADES-C）を備えた電子署名は、検証に必要なすべての追加データ（つまり、すべての証明書と取り消し情報）が利用可能な電子署名です。このフォームは、上記のCades-Tフォームの上に構築されています。
As a minimum, the Complete validation data shall include the following:
少なくとも、完全な検証データには以下が含まれます。
- a time, which shall either be a signature-timestamp attribute, as defined in Section 6.1.1, or a time-mark operated by a Time-Marking Authority;
- セクション6.1.1で定義されているように、これは署名のティメスタンプ属性であるか、タイムマーク当局によって操作されるタイムマークのいずれかです。
- complete-certificate-references, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、完全な認証参照。
- complete-revocation-references, as defined in Section 6.2.2.
- セクション6.2.2で定義されているように、完全な改訂版参照。
The complete-certificate-references attribute is an unsigned attribute. It references the full set of CA certificates that have been used to validate an ES with Complete validation data up to (but not including) the signer's certificate. Only a single instance of this attribute shall occur with an electronic signature.
完全な認証再参照属性は、署名されていない属性です。これは、署名者の証明書まで完全な検証データを使用してESを検証するために使用されたCA証明書の完全なセットを参照します。この属性の単一のインスタンスのみが、電子署名で発生するものとします。
NOTE 1: The signer's certificate is referenced in the signing certificate attribute (see Section 5.7.3).
注1：署名者の証明書は、署名証明書属性に参照されます（セクション5.7.3を参照）。
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-references attribute value has the ASN.1 syntax CompleteCertificateRefs.
完全な資格 - 参照属性値には、ASN.1構文CompleteCertificAterefがあります。
CompleteCertificateRefs ::= SEQUENCE OF OtherCertID
OtherCertID is defined in Section 5.7.3.3.
othercertidは、セクション5.7.3.3で定義されています。
The IssuerSerial that shall be present in OtherCertID. The certHash shall match the hash of the certificate referenced.
他のcertidに存在する発行担当者。Certhashは、参照されている証明書のハッシュと一致するものとします。
NOTE 2: Copies of the certificate values may be held using the certificate-values attribute, defined in Section 6.3.3.
This attribute may include references to the certification chain for any TSUs that provides time-stamp tokens. In this case, the unsigned attribute shall be added to the signedData of the relevant time-stamp token as an unsignedAttrs in the signerInfos field.
この属性には、タイムスタンプトークンを提供するTSUの認証チェーンへの参照が含まれます。この場合、署名されたタイムスタンプトークンのSignerinfosフィールドの符号なしの属性に署名されていない属性を追加するものとします。
The complete-revocation-references attribute is an unsigned attribute. Only a single instance of this attribute shall occur with an electronic signature. It references the full set of the CRL, ACRL, or OCSP responses that have been used in the validation of the signer, and CA certificates used in ES with Complete validation data.
完全な反省再参照属性は、署名されていない属性です。この属性の単一のインスタンスのみが、電子署名で発生するものとします。署名者の検証で使用されているCRL、ACRL、またはOCSP応答の完全なセットと、完全な検証データを持つESで使用されるCA証明書を参照します。
This attribute indicates that the verifier has taken due diligence to gather the available revocation information. The references stored in this attribute can be used to retrieve the referenced information, if not stored in the CMS structure, but somewhere else.
この属性は、検証者が利用可能な取り消し情報を収集するためにデューデリジェンスを取ったことを示しています。この属性に保存されている参照は、CMS構造に保存されていない場合、他のどこかに参照される情報を取得するために使用できます。
The following object identifier identifies the complete-revocation-references attribute:
次のオブジェクト識別子は、完全な反映再参照属性を識別します。
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-references attribute value has the ASN.1 syntax CompleteRevocationRefs:
完全な再参照属性の値には、ASN.1構文CompleerEvocationRefsがあります。
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL
}
CompleteRevocationRefs shall contain one CrlOcspRef for the signing-certificate, followed by one for each OtherCertID in the CompleteCertificateRefs attribute. The second and subsequent CrlOcspRef fields shall be in the same order as the OtherCertID to which they relate. At least one of CRLListID or OcspListID or OtherRevRefs should be present for all but the "trusted" CA of the certificate path.
CompleteRevocationRefsには、署名承認のために1つのcrlocsprefを含める必要があり、その後、CompleteCertificaterefs属性のbothercertidに続きます。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 a 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 shall correspond to the time thisUpdate contained in the issued CRL, and if present, the crlNumber. 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 shall be included.
CRLIDENTIFIERは、発行者名と発行された時間を使用してCRLを識別することであり、これは発行されたCRLに含まれる時間に対応し、存在する場合はCRLNumberに対応するものとします。crllistid属性は、署名されていない属性です。特定されたCRLがDelta CRLである場合、完全な取り消しリストを提供するためにCRLのセットへの参照を含めます。
The OcspIdentifier is to identify the OCSP response using the issuer name and the time of issue of the OCSP response, which shall correspond to the time produced as contained in the issued OCSP response. Since it may be needed to make the difference between two OCSP responses received within the same second, the hash of the response contained in the OcspResponsesID may be needed to solve the ambiguity.
OCSpidentifierは、発行者名とOCSP応答の発行時間を使用してOCSP応答を識別することです。これは、発行されたOCSP応答に含まれる時間に対応するものとします。同じ秒以内に受信された2つのOCSP応答の違いを作成する必要がある可能性があるため、曖昧さを解決するためにOCSPRESPONSESIDに含まれる応答のハッシュが必要になる場合があります。
NOTE 1: Copies of the CRL and OCSP responses values may be held using the revocation-values attribute defined in Section 6.3.4.
注1：CRLおよびOCSP応答値のコピーは、セクション6.3.4で定義されている取り消し値属性を使用して保持できます。
NOTE 2: It is recommended that this attribute be used in preference to the OtherRevocationInfoFormat specified in RFC 3852 to maintain backwards compatibility with the earlier version of this specification.
注2：この仕様の以前のバージョンとの逆方向の互換性を維持するために、RFC 3852で指定された他のrevocationInfoformatを優先してこの属性を使用することをお勧めします。
The syntax and semantics of other revocation references are outside the scope of the present document. The definition of the syntax of the other form of revocation information is as identified by OtherRevRefType.
他の取り消し参照の構文とセマンティクスは、現在のドキュメントの範囲外です。取り消し情報の他の形式の構文の定義は、otherRevreftypeによって識別されているとおりです。
This attribute may include the references to the full set of the CRL, ACRL, or OCSP responses that have been used to verify the certification chain for any TSUs that provide time-stamp tokens. In this case, the unsigned attribute shall be added to the signedData of the relevant time-stamp token as an unsignedAttrs in the signerInfos field.
この属性には、タイムスタンプトークンを提供するTSUの認証チェーンを検証するために使用されたCRL、ACRL、またはOCSP応答の完全なセットへの参照を含めることができます。この場合、署名されたタイムスタンプトークンのSignerinfosフィールドの符号なしの属性に署名されていない属性を追加するものとします。
This attribute is only used when a user attribute certificate is present in the electronic signature.
この属性は、ユーザー属性証明書が電子署名に存在する場合にのみ使用されます。
The attribute-certificate-references attribute is an unsigned attribute. It references the full set of AA certificates that have been used to validate the attribute certificate. Only a single instance of this attribute shall occur with an electronic signature.
属性 - 認証 - 参照属性は、署名されていない属性です。属性証明書の検証に使用されたAA証明書の完全なセットを参照します。この属性の単一のインスタンスのみが、電子署名で発生するものとします。
id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 44}
The attribute-certificate-references attribute value has the ASN.1 syntax AttributeCertificateRefs:
Attribute-Certificate-References属性値には、asn.1構文属性certificaterefsがあります。
AttributeCertificateRefs ::= SEQUENCE OF OtherCertID
OtherCertID is defined in Section 5.7.3.3.
othercertidは、セクション5.7.3.3で定義されています。
NOTE: Copies of the certificate values may be held using the certificate-values attribute defined in Section 6.3.3.
注：証明書のコピーは、セクション6.3.3で定義されている証明書値属性を使用して保持できます。
This attribute is only used when a user attribute certificate is present in the electronic signature and when that attribute certificate can be revoked.
この属性は、ユーザー属性証明書が電子署名に存在する場合、およびその属性証明書を取り消すことができる場合にのみ使用されます。
The attribute-revocation-references attribute is an unsigned attribute. Only a single instance of this attribute shall occur with an electronic signature. It references the full set of the ACRL or OCSP responses that have been used in the validation of the attribute certificate. This attribute can be used to illustrate that the verifier has taken due diligence of the available revocation information.
属性 - 反復再参照属性は、署名されていない属性です。この属性の単一のインスタンスのみが、電子署名で発生するものとします。属性証明書の検証で使用されているACRLまたはOCSP応答の完全なセットを参照します。この属性を使用して、検証者が利用可能な取り消し情報のデューデリジェンスを取得したことを説明できます。
The following object identifier identifies the attribute-revocation-references attribute:
次のオブジェクト識別子は、属性 - 再参照属性を識別します。
id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
id-aa(2) 45}
The attribute-revocation-references attribute value has the ASN.1 syntax AttributeRevocationRefs:
属性 - 再参照属性値には、asn.1構文属性revocationRefsがあります。
AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef
This section specifies a number of optional attributes that are used by extended forms of electronic signatures (see Annex B for an overview of these forms of validation data).
このセクションでは、電子署名の拡張フォームで使用される多くのオプションの属性を指定します（これらの形式の検証データの概要については、付録Bを参照）。
The extended validation data may include one of the following additional attributes, forming a CAdES-X Time-Stamp validation data (CAdES-X Type 1 or CAdES-X Type 2), to provide additional protection against later CA compromise and provide integrity of the validation data used:
拡張検証データには、以下の追加属性のいずれかが含まれる場合があります。Cades-Xタイムスタンプ検証データ（Cades-X Type 1またはCades-X Type 2）を形成し、後のCA妥協に対する追加の保護を提供し、使用される検証データ：
- CAdES-C Time-stamp, as defined in Section 6.3.5 (CAdES-X Type 1); or
- セクション6.3.5で定義されているCades-Cタイムスタンプ（Cades-X Type 1）;また
- Time-Stamped Certificates and CRLs references, as defined in Section 6.3.6 (CAdES-X Type 2).
- セクション6.3.6（Cades-Xタイプ2）で定義されているタイムスタンプの証明書とCRLS参照。
The extended validation data may also include the following additional information, forming a CAdES-X Long, for use if later validation processes may not have access to this information:
拡張された検証データには、以下の追加情報が含まれる場合があります。これは、後の検証プロセスがこの情報にアクセスできない場合に使用するために、Cades-X Longを形成します。
- certificate-values, as defined in Section 6.3.3; and
- セクション6.3.3で定義されている証明書の価値。と
- revocation-values, as defined in Section 6.3.4.
- セクション6.3.4で定義されているように、取り消し値。
The extended validation data may, in addition to certificate-values and revocation-values as defined in Sections 6.3.3 and 6.3.4, include one of the following additional attributes, forming a CAdES-X Long Type 1 or CAdES-X Long Type 2.
拡張検証データは、セクション6.3.3および6.3.4で定義されている証明書の価値と取り消し値に加えて、以下の追加属性のいずれかを含めて、Cades-X Long Type 1またはCades-X Longタイプを形成することができます。2。
- CAdES-C Time-stamp, as defined in Section 6.3.3 (CAdES-X long Type 1); or
- セクション6.3.3で定義されているCades-Cタイムスタンプ（Cades-X Long Type 1）;また
- Time-Stamped Certificates and CRLs references, as defined in Section 6.3.4 (CAdES-X Long Type 2).
- セクション6.3.4（Cades-X Long Type 2）で定義されているタイムスタンプの証明書とCRLS参照。
The CAdES-X Long Type 1 or CAdES-X Long Type 2 provides additional protection against later CA compromise and provides integrity of the validation data used.
Cades-X Long Type 1またはCades-X Long Type 2は、後のCA妥協に対する追加の保護を提供し、使用される検証データの整合性を提供します。
NOTE 1: The CAdES-X-Long signature provides long-term proof of the validity of the signature for as long as the CA keys, CRL Issuers keys, and OCSP responder keys are not compromised and are resistant to cryptographic attacks.
注1：CADES-X-LONGの署名は、CAキー、CRL発行者キー、およびOCSPレスポンダーキーが侵害されず、暗号攻撃に耐性がある限り、署名の有効性の長期的な証拠を提供します。
NOTE 2: As long as the time-stamp data remains valid, the CAdES-X Long Type 1 and the CAdES-X Long Type 2 provide the following important property for long-standing signatures; that having been found once to be valid, it shall continue to be so months or years later, long after the validity period of the certificates has expired, or after the user key has been compromised.
注2：タイムスタンプデータが有効である限り、Cades-X Long Type 1とCades-X Long Type 2は、長年の署名に次の重要な特性を提供します。それは一度有効であることが判明したため、証明書の有効期間が失効した後、またはユーザーキーが侵害された後、それは数か月または数年後も続きます。
This attribute may be used to contain the certificate information required for the following forms of extended electronic signature: CAdES-X Long, ES X-Long Type 1, and CAdES-X Long Type 2; see Annex B.1.1 for an illustration of this form of electronic signature.
この属性は、拡張された電子署名の次の形式に必要な証明書情報を含めることができます。この形式の電子署名のイラストについては、付録B.1.1を参照してください。
The certificate-values attribute is an unsigned attribute. Only a single instance of this attribute shall occur with an electronic signature. It holds the values of certificates referenced in the complete-certificate-references attribute.
証明書価値属性は、署名されていない属性です。この属性の単一のインスタンスのみが、電子署名で発生するものとします。完全な資格再参照属性で参照される証明書の値を保持します。
NOTE: If an attribute certificate is used, it is not provided in this structure but shall be provided by the signer as a signer-attributes attribute (see Section 5.11.3).
注：属性証明書が使用されている場合、この構造では提供されませんが、署名者から署名者とアトリビュートの属性として提供されるものとします（セクション5.11.3を参照）。
The following object identifier identifies the certificate-values 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 Section 7.1. (which is as defined in ITU-T Recommendation X.509 [1]).
証明書はセクション7.1で定義されています。（これは、ITU-T推奨x.509 [1]で定義されています）。
This attribute may include the certification information for any TSUs that have provided the time-stamp tokens, if these certificates are not already included in the TSTs as part of the TSUs signatures. In this case, the unsigned attribute shall be added to the signedData of the relevant time-stamp token.
この属性には、TSUS署名の一部としてこれらの証明書がまだTSTに含まれていない場合、タイムスタンプトークンを提供したTSUの認証情報を含めることができます。この場合、署名されていない属性を、関連するタイムスタンプトークンのSignedDataに追加するものとします。
This attribute is used to contain the revocation information required for the following forms of extended electronic signature: CAdES-X Long, ES X-Long Type 1, and CAdES-X Long Type 2; see Annex B.1.1 for an illustration of this form of electronic signature.
この属性は、拡張された電子署名の次の形式に必要な取り消し情報を含むために使用されます。Cades-X Long、ES X-Long Type 1、およびCades-X Long Type 2。この形式の電子署名のイラストについては、付録B.1.1を参照してください。
The revocation-values attribute is an unsigned attribute. Only a single instance of this attribute shall occur with an electronic signature. It holds the values of CRLs and OCSP referenced in the complete-revocation-references attribute.
ragocation-values属性は、署名されていない属性です。この属性の単一のインスタンスのみが、電子署名で発生するものとします。CRLSとOCSPの値を完全な再展開再参照属性で参照しています。
NOTE: It is recommended that this attribute be used in preference to the OtherRevocationInfoFormat specified in RFC 3852 to maintain backwards compatibility with the earlier version of this specification.
The following object identifier identifies the revocation-values attribute:
次のオブジェクト識別子は、regocation-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}
The revocation-values attribute value has the ASN.1 syntax RevocationValues
raucocation-values属性値には、asn.1構文gococationvaluesがあります
RevocationValues ::= SEQUENCE {
crlVals [0] SEQUENCE OF CertificateList OPTIONAL,
ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
otherRevVals [2] OtherRevVals OPTIONAL }
OtherRevVals ::= SEQUENCE {
OtherRevValType OtherRevValType,
OtherRevVals ANY DEFINED BY OtherRevValType }
OtherRevValType ::= OBJECT IDENTIFIER
The syntax and semantics of the other revocation values (OtherRevVals) are outside the scope of the present document.
他の取り消し値（その他のREVVALS）の構文とセマンティクスは、現在のドキュメントの範囲外です。
The definition of the syntax of the other form of revocation information is as identified by OtherRevRefType.
取り消し情報の他の形式の構文の定義は、otherRevreftypeによって識別されているとおりです。
CertificateList is defined in Section 7.2. (which is as defined in ITU-T Recommendation X.509 [1]).
証明書リストは、セクション7.2で定義されています。（これは、ITU-T推奨x.509 [1]で定義されています）。
BasicOCSPResponse is defined in Section 7.3. (which is as defined in RFC 2560 [3]).
Basicocspresponseはセクション7.3で定義されています。（これはRFC 2560 [3]で定義されています）。
This attribute may include the values of revocation data including CRLs and OCSPs for any TSUs that have provided the time-stamp tokens, if these certificates are not already included in the TSTs as part of the TSUs signatures. In this case, the unsigned attribute shall be added to the signedData of the relevant time-stamp token.
この属性には、TSUS署名の一部としてこれらの証明書がTSTにまだ含まれていない場合、タイムスタンプトークンを提供したTSUのCRLとOCSPを含む取消データの値が含まれます。この場合、署名されていない属性を、関連するタイムスタンプトークンのSignedDataに追加するものとします。
This attribute is used to protect against CA key compromise.
この属性は、CAの重要な妥協から保護するために使用されます。
This attribute is used for the time-stamping of the complete electronic signature (CAdES-C). It is used in the following forms of extended electronic signature; CAdES-X Type 1 and CAdES-X Long Type 1; see Annex B.1.2 for an illustration of this form of electronic signature.
この属性は、完全な電子署名（Cades-C）のタイムスタンプに使用されます。拡張された電子署名の次の形式で使用されます。Cades-X Type 1およびCades-X Long Type 1;この形式の電子署名のイラストについては、付録B.1.2を参照してください。
The CAdES-C-time-stamp attribute is an unsigned attribute. It is a time-stamp token of the hash of the electronic signature and the complete validation data (CAdES-C). It is a special-purpose TimeStampToken Attribute that time-stamps the CAdES-C. Several instances of this attribute may occur with an electronic signature from different TSAs.
Cades-C-Time-Stamp属性は、署名されていない属性です。これは、電子署名のハッシュのタイムスタンプトークンと完全な検証データ（Cades-C）です。これは、Cades-Cをタイムスタンプする特別な目的のTimestamptoken属性です。この属性のいくつかのインスタンスは、異なるTSAからの電子署名で発生する場合があります。
NOTE 1: It is recommended that the attributes being time-stamped be encoded in DER. If DER is not employed, then the binary encoding of the ASN.1 structures being time-stamped should be preserved to ensure that the recalculation of the data hash is consistent.
注1：タイムスタンプされている属性をDERでエンコードすることをお勧めします。derが使用されていない場合、データハッシュの再計算が一貫していることを確認するために、asn.1構造のバイナリエンコードを保存する必要があります。
NOTE 2: Each attribute is included in the hash with the attrType and attrValues (including type and length) but without the type and length of the outer SEQUENCE.
注2：各属性は、attrypeと属性（タイプと長さを含む）を備えたハッシュに含まれますが、外側シーケンスのタイプと長さはありません。
The following object identifier identifies the CAdES-C-Timestamp attribute:
次のオブジェクト識別子は、Cades-C-Timestamp属性を識別します。
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 CAdES-C-timestamp attribute value has the ASN.1 syntax ESCTimeStampToken :
Cades-C-Timestamp属性値には、ASN.1構文ESCTIMESTAMPTOKEN：
ESCTimeStampToken ::= TimeStampToken
The value of the messageImprint field within TimeStampToken shall be a hash of the concatenated values (without the type or length encoding for that value) of the following data objects:
TimeStamptoken内のmessageImprintフィールドの値は、次のデータオブジェクトの連結値（その値のタイプまたは長さのエンコードなし）のハッシュでなければなりません。
- OCTETSTRING of the SignatureValue field within SignerInfo;
- SignerInfo内の署名バリューフィールドのオクテットストリング。
- signature-time-stamp, or a time-mark operated by a Time-Marking Authority;
- シグネチャータイムスタンプ、またはタイムマーク当局が運営するタイムマーク。
- complete-certificate-references attribute; and
- 完全総参照属性。と
- complete-revocation-references attribute.
- 完全な反省再参照属性。
For further information and definition of the TimeStampToken, see Section 7.4.
Timestamptokenの詳細と定義については、セクション7.4を参照してください。
This attribute is used to protect against CA key compromise. This attribute is used for the time-stamping certificate and revocation references. It is used in the following forms of extended electronic signature: CAdES-X Type 2 and CAdES-X Long Type 2; see Annex B.1.3 for an illustration of this form of electronic signature.
この属性は、CAの重要な妥協から保護するために使用されます。この属性は、タイムスタンプ証明書および取り消し参照に使用されます。拡張された電子署名の次の形式で使用されています。Cades-X Type 2およびCades-X Long Type 2。この形式の電子署名のイラストについては、付録B.1.3を参照してください。
A time-stamped-certs-crls-references attribute is an unsigned attribute. It is a time-stamp token issued for a list of referenced certificates and OCSP responses and/or CRLs to protect against certain CA compromises. Its syntax is as follows:
タイムスタンプ付きcerts-crls-references属性は、署名されていない属性です。これは、特定のCAの妥協から保護するために、参照されている証明書とOCSP応答および/またはCRLのリストに対して発行されたタイムスタンプトークンです。その構文は次のとおりです。
NOTE 1: It is recommended that the attributes being time-stamped be encoded in DER. If DER is not employed, then the binary encoding of the ASN.1 structures being time-stamped should be preserved to ensure that the recalculation of the data hash is consistent.
注1：タイムスタンプされている属性をDERでエンコードすることをお勧めします。derが使用されていない場合、データハッシュの再計算が一貫していることを確認するために、asn.1構造のバイナリエンコードを保存する必要があります。
NOTE 2: Each attribute is included in the hash with the attrType and attrValues (including type and length) but without the type and length of the outer SEQUENCE.
注2：各属性は、attrypeと属性（タイプと長さを含む）を備えたハッシュに含まれますが、外側シーケンスのタイプと長さはありません。
The following object identifier identifies the time-stamped-certs-crls-references attribute:
次のオブジェクト識別子は、タイムスタンプされたCERTS-CRLS-REFERENCES属性を識別します。
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 the messageImprint field within the TimeStampToken shall 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 (CAdES-C):
TimeStamptoken内のmessageImprintフィールドの値は、完全な検証データ（Cades-C）のESに存在するように、次のデータオブジェクトの連結値（その値のタイプまたは長さのエンコードなし）のハッシュでなければなりません。
- complete-certificate-references attribute; and
- 完全総参照属性。と
- complete-revocation-references attribute.
- 完全な反省再参照属性。
Where an electronic signature is required to last for a very long time, and the time-stamp token on an electronic signature is in danger of being invalidated due to algorithm weakness or limits in the validity period of the TSA certificate, it may be required to time-stamp the electronic signature several times. When this is required, an archive time-stamp attribute may be required for the archive form of the electronic signature (CAdES-A). This archive time-stamp attribute may be repeatedly applied over a period of time.
非常に長い間持続するために電子署名が必要であり、電子署名のタイムスタンプトークンがアルゴリズムの弱点またはTSA証明書の有効期間の制限により無効になる危険にさらされている場合、それは必要になる場合があります電子署名を数回タイムスタンプします。これが必要な場合、電子署名のアーカイブフォーム（Cades-A）にはアーカイブタイムスタンプ属性が必要になる場合があります。このアーカイブタイムスタンプ属性は、一定期間にわたって繰り返し適用される場合があります。
The archive-time-stamp attribute is a time-stamp token of many of the elements of the signedData in the electronic signature. If the certificate-values and revocation-values attributes are not present in the CAdES-BES or CAdES-EPES, then they shall be added to the electronic signature prior to computing the archive time-stamp token.
アーカイブタイムスタンプ属性は、電子署名の署名されたdataの多くの要素のタイムスタンプトークンです。Cades-BesまたはCades-Epesに証明書の値と取消値の属性が存在しない場合、アーカイブタイムスタンプトークンを計算する前に、電子署名に追加されます。
The archive-time-stamp attribute is an unsigned attribute. Several instances of this attribute may occur with an electronic signature both over time and from different TSUs.
The following object identifier identifies the nested archive-time-stamp attribute:
次のオブジェクト識別子は、ネストされたアーカイブ時間スタンプ属性を識別します。
id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 48}
Archive-time-stamp attribute values have the ASN.1 syntax ArchiveTimeStampToken
Archive-Time-Stamp属性の値には、ASN.1構文ArchiveTimestamptokenがあります
ArchiveTimeStampToken ::= TimeStampToken
The value of the messageImprint field within TimeStampToken shall be a hash of the concatenation of:
TimeStamptoken内のmessageImprintフィールドの値は、次のように連結するハッシュでなければなりません。
- the encapContentInfo element of the SignedData sequence;
- SignedDataシーケンスのcapContentInfo要素。
- any external content being protected by the signature, if the eContent element of the encapContentInfo is omitted;
- EncapContentInfoのecontent要素が省略されている場合、署名によって保護されている外部コンテンツはいずれかです。
- the Certificates and crls elements of the SignedData sequence, when present, and;
- SignedDataシーケンスの証明書とCRLS要素、存在する場合、
- all data elements in the SignerInfo sequence including all signed and unsigned attributes.
- SignerINFOシーケンスのすべてのデータ要素は、すべての署名属性と符号なし属性を含む。
NOTE 1: An alternative archiveTimestamp attribute, identified by an object identifier { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27, is defined in prior versions of TS 101 733 [TS101733] and in RFC 3126.
注1：オブジェクト識別子によって識別される代替Archivetimestamp属性{ISO（1）メンバーボディ（2）US（840）Rsadsi（113549）PKCS（1）PKCS-9（16）ID-AA（2）27は、TS 101 733 [TS101733]の以前のバージョンとRFC 3126で定義されています。
The archiveTimestamp attribute, defined in versions of TS 101 733 prior to 1.5.1 and in RFC 3126, is not compatible with the attribute defined in the current document. The archiveTimestamp attribute, defined in versions 1.5.1 to 1.6.3 of TS 101 733, is compatible with the current document if the content is internal to encapContentInfo. Unless the version of TS 101 733 employed by the signing party is known by all recipients, use of the archiveTimestamp attribute defined in prior versions of TS 101 733 is deprecated.
1.5.1より前のTS 101 733およびRFC 3126のバージョンで定義されているArchivetimestamp属性は、現在のドキュメントで定義されている属性と互換性がありません。TS 101 733のバージョン1.5.1〜1.6.3で定義されているArchiveTimestamp属性は、コンテンツが内部である場合、現在のドキュメントと互換性があります。署名当事者が採用しているTS 101 733のバージョンがすべての受信者に知られている場合を除き、TS 101 733の以前のバージョンで定義されたArchivetimestamp属性の使用は非推奨です。
NOTE 2: Counter signatures held as countersignature attributes do not require independent archive time-stamps, as they are protected by the archive time-stamp against the containing SignedData structure.
注2：countersignature属性として保持されているカウンターシグネチャは、署名data構造を含むアーカイブタイムスタンプによって保護されているため、独立したアーカイブタイムスタンプを必要としません。
NOTE 3: Unless DER is used throughout, it is recommended that the binary encoding of the ASN.1 structures being time-stamped be preserved when being archived to ensure that the recalculation of the data hash is consistent.
注3：derが全体を通して使用されない限り、データハッシュの再計算が一貫していることを確認するためにアーカイブされるときに、asn.1構造のバイナリエンコードをアーカイブする場合、保存することをお勧めします。
NOTE 4: The hash is calculated over the concatenated data elements as received/stored, including the Type and Length encoding.
注4：ハッシュは、タイプと長さのエンコーディングを含む、受信/保存された連結データ要素に対して計算されます。
NOTE 5: Whilst it is recommended that unsigned attributes be DER encoded, it cannot generally be so guaranteed except by prior arrangement. For further information and definition of TimeStampToken, see Section 7.4. The timestamp should be created using stronger algorithms (or longer key lengths) than in the original electronic signatures and weak algorithm (key length) timestamps.
注5：符号なしの属性をderエンコードすることをお勧めしますが、通常、事前の取り決めを除いてそれほど保証することはできません。Timestamptokenの詳細と定義については、セクション7.4を参照してください。タイムスタンプは、元の電子署名と弱いアルゴリズム（キー長）タイムスタンプよりも強力なアルゴリズム（または長いキーの長さ）を使用して作成する必要があります。
NOTE 6: This form of ES also provides protection against a TSP key compromise.
注6：この形式のESは、TSPキーの妥協に対する保護も提供します。
The ArchiveTimeStamp will be added as an unsigned attribute in the SignerInfo sequence. For the validation of one ArchiveTimeStamp, the data elements of the SignerInfo must be concatenated, excluding all later ArchivTimeStampToken attributes.
Archivetimestampは、SignerInfoシーケンスの符号なし属性として追加されます。1つのArchiveTimestampの検証のために、SignerInfoのデータ要素を連結する必要があり、すべてのArchivtimestamptoken属性を除外します。
Certificates and revocation information required to validate the ArchiveTimeStamp shall be provided by one of the following methods:
Archivetimestampを検証するために必要な証明書と取り消し情報は、次の方法のいずれかによって提供されるものとします。
- The TSU provides the information in the SignedData of the timestamp token;
- TSUは、タイムスタンプトークンのSignedDataに情報を提供します。
- Adding the complete-certificate-references attribute and the complete-revocation-references attribute of the TSP as an unsigned attribute within TimeStampToken, when the required information is stored elsewhere; or
- 必要な情報が他の場所に保存されている場合、TSPの完全な参照属性とTSPの完全な再展開属性属性を追加しない属性として追加します。また
- Adding the certificate-values attribute and the revocation-values attribute of the TSP as an unsigned attribute within TimeStampToken, when the required information is stored elsewhere.
- 必要な情報が他の場所に保存されている場合、TSPのTSPのRogocation-Values属性を、Timestamptoken内の符号なし属性として追加します。
The X.509 v3 certificate basis syntax is defined in ITU-T Recommendation X.509 [1]. A profile of the X.509 v3 certificate is defined in RFC 3280 [2].
X.509 V3証明書ベースの構文は、ITU-T推奨X.509 [1]で定義されています。X.509 V3証明書のプロファイルは、RFC 3280 [2]で定義されています。
The X.509 v2 CRL syntax is defined in ITU-T Recommendation X.509 [1]. A profile of the X.509 v2 CRL is defined in RFC 3280 [2].
X.509 V2 CRL構文は、ITU-T推奨X.509 [1]で定義されています。X.509 V2 CRLのプロファイルは、RFC 3280で定義されています[2]。
The format of an OCSP token is defined in RFC 2560 [3].
OCSPトークンの形式は、RFC 2560 [3]で定義されています。
The format of a TimeStampToken type is defined in RFC 3161 [7] and profiled in ETSI TS 101 861 [TS101861].
Timestamptokenタイプの形式は、RFC 3161 [7]で定義され、ETSI TS 101 861 [TS101861]でプロファイルされます。
The syntax of the naming and other attributes is defined in ITU-T Recommendation X.509 [1].
命名およびその他の属性の構文は、ITU-T推奨x.509 [1]で定義されています。
NOTE: The name used by the signer, held as the subject in the signer's certificate, is allocated and verified on registration with the Certification Authority, either directly or indirectly through a Registration Authority, before being issued with a Certificate.
注：署名者の証明書の主題として保持されている署名者が使用する名前は、証明書が発行される前に、登録機関を通じて直接的または間接的に認定当局への登録時に割り当てられ、検証されます。
The present document places no restrictions on the form of the name. The subject's name may be a distinguished name, as defined in ITU-T Recommendation X.500 [12], held in the subject field of the certificate, or any other name form held in the subjectAltName certificate extension field, as defined in ITU-T Recommendation X.509 [1]. In the case that the subject has no distinguished name, the subject name can be an empty sequence and the subjectAltName extension shall be critical.
現在のドキュメントは、名前の形式に制限を設けません。被験者の名前は、ITU-Tの推奨x.500 [12]で定義されているように、証明書の件名フィールド、またはITU-で定義されているsubjectName証明書拡張フィールドに保持されているその他の名前フォームに保持されている著名な名前である場合があります。T勧告X.509 [1]。被験者が著名な名前を持っていない場合、サブジェクト名は空のシーケンスであり、subjectaltname拡張機能が重要でなければなりません。
All Certification Authorities, Attribute Authorities, and Time-Stamping Authorities shall use distinguished names in the subject field of their certificate.
すべての認証当局、属性当局、およびタイムスタンプ当局は、証明書の主題分野で著名な名前を使用するものとします。
The distinguished name shall include identifiers for the organization providing the service and the legal jurisdiction (e.g., country) under which it operates.
著名な名前には、サービスを提供する組織の識別子と、それが運営されている法的管轄（例：国）を含めるものとします。
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, which is directly associated with the signing key, identifies him/her as an individual. The second, which is managed independently, identifies that person acting as part of the organization, possibly with a given role. In this case, one of the two identities is carried in the subject/subjectAltName field of the signer's certificate as described above.
署名者が個人として署名しているが、組織に代わって行動していると自分自身を特定したい場合、2つの独立した形式の識別を提供する必要があるかもしれません。署名キーに直接関連付けられている最初のアイデンティティは、彼/彼女を個人として識別します。独立して管理されている2番目は、おそらく特定の役割を持つ組織の一部として行動する人を特定します。この場合、2つのIDのうちの1つが、上記のように署名者の証明書の件名/subjectaltnameフィールドに掲載されます。
The present document does not specify the format of the signer's attribute that may be included in public key certificates.
現在のドキュメントでは、公開キー証明書に含まれる可能性のある署名者の属性の形式を指定していません。
NOTE: The signer's attribute may be supported by using a claimed role in the CMS signed attributes field or by placing an attribute certificate containing a certified role in the CMS signed attributes field; see Section 7.6.
注：署名者の属性は、CMS署名属性フィールドで請求された役割を使用するか、CMS署名属性フィールドに認定された役割を含む属性証明書を配置することにより、サポートされる場合があります。セクション7.6を参照してください。
The syntax of the AttributeCertificate type is defined in RFC 3281 [13].
属性セクチファートタイプの構文は、RFC 3281 [13]で定義されています。
For implementations supporting signature generation, the present document defines conformance requirements for the generation of two forms of basic electronic signature, one of the two forms must be implemented.
署名生成をサポートする実装のために、現在のドキュメントでは、2つの形式の基本的な電子署名の生成の適合要件を定義します。2つのフォームの1つを実装する必要があります。
For implementations supporting signature verification, the present document defines conformance requirements for the verification of two forms of basic electronic signature, one of the two forms must be implemented.
署名検証をサポートする実装のために、本文書は、2つの形式の基本的な電子署名の検証の適合要件を定義しています。2つのフォームの1つを実装する必要があります。
The present document only defines conformance requirements up to an ES with Complete validation data (CAdES-C). This means that none of the extended and archive forms of the electronic signature (CAdES-X, CAdES-A) need to be implemented to get conformance to the present document.
現在のドキュメントは、完全な検証データ（Cades-C）を持つESまでの適合要件のみを定義しています。これは、現在のドキュメントに順応するために、電子署名の拡張フォームとアーカイブフォーム（Cades-X、Cades-A）を実装する必要がないことを意味します。
On verification the inclusion of optional signed and unsigned attributes must be supported only to the extent that the signature is verifiable. The semantics of optional attributes may be unsupported, unless specified otherwise by a signature policy.
検証では、署名が検証可能である範囲でのみ、オプションの署名付き属性と符号なしの属性を含める必要があります。オプションの属性のセマンティクスは、署名ポリシーによって特に指定されていない限り、サポートされていない場合があります。
A system supporting CAdES-BES signers, according to the present document, shall, at a minimum, support generation of an electronic signature consisting of the following components:
現在の文書によると、Cades-Besの署名者をサポートするシステムは、少なくとも、次のコンポーネントで構成される電子署名の生成をサポートするものとします。
- The general CMS syntax and content type, as defined in RFC 3852 [4] (see Sections 5.1 and 5.2);
- RFC 3852 [4]で定義されている一般的なCMS構文とコンテンツタイプ（セクション5.1および5.2を参照）。
- CMS SignedData, as defined in RFC 3852 [4], with the version set to 3 and at least one SignerInfo present (see Sections 5.3 to 5.6);
- RFC 3852 [4]で定義されているCMS SignedData、バージョンは3に設定され、少なくとも1つのSignerinfoの存在（セクション5.3〜5.6を参照）。
- The following CMS attributes, as defined in RFC 3852 [4]:
- RFC 3852 [4]で定義されている次のCMS属性：
- content-type; this shall always be present (see Section 5.7.1); and
- コンテンツタイプ;これは常に存在するものとします（セクション5.7.1を参照）。と
- message-digest; this shall always be present (see Section 5.7.2).
- メッセージダイジェスト;これは常に存在するものとします（セクション5.7.2を参照）。
- One of the following attributes, as defined in the present document:
- 現在のドキュメントで定義されているように、次の属性のいずれかが次のとおりです。
- signing-certificate: as defined in Section 5.7.3.1; or - signing-certificate v2 : as defined in Section 5.7.3.2.
- 署名証明書：セクション5.7.3.1で定義されています。または - 署名承認V2：セクション5.7.3.2で定義されています。
NOTE: RFC 3126 was using the other signing-certificate attribute (see Section 5.7.3.3). Its use is now deprecated, since the structure of the signing-certificate v2 attribute is simpler than the other signing-certificate attribute.
注：RFC 3126は、他の署名認証属性を使用していました（セクション5.7.3.3を参照）。署名証明のV2属性の構造は、他の署名認証属性よりも単純であるため、その使用は現在廃止されています。
A system supporting Policy-based signers, according to the present document, shall, at a minimum, support the generation of an electronic signature consisting of the previous components defined for the basic signer, plus:
現在の文書によると、政策ベースの署名者をサポートするシステムは、少なくとも、基本的な署名者向けに定義された以前のコンポーネントで構成される電子署名の生成をサポートするものとします。
- The following attributes, as defined in Section 5.9:
- セクション5.9で定義されているように、次の属性：
- signature-policy-identifier; this shall always be present (see Section 5.8.1).
- Signature-Policy-Identifier;これは常に存在するものとします（セクション5.8.1を参照）。
A system supporting verifiers, according to the present document, with time-stamping facilities shall, at a minimum, support:
現在の文書によると、タイムスタンピング施設を備えた検証剤をサポートするシステムは、少なくともサポートするものとします。
- verification of the mandated components of an electronic signature, as defined in Section 8.1;
- セクション8.1で定義されているように、電子署名の義務付けられたコンポーネントの検証。
- signature-time-stamp attribute, as defined in Section 6.1.1;
- セクション6.1.1で定義されている署名時刻スタンプ属性。
- complete-certificate-references attribute, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、完全総参照属性。
- complete-revocation-references attribute, as defined in Section 6.2.2;
- セクション6.2.2で定義されているように、完全な再展開再参照属性。
- Public Key Certificates, as defined in ITU-T Recommendation X.509 [1] (see Section 8.1); and
- ITU-Tの推奨X.509 [1]で定義されている公開鍵証明書（セクション8.1を参照）;と
- either of:
- のどちらか：
- Certificate Revocation Lists, as defined in ITU-T Recommendation X.509 [1] (see Section 8.2); or
- ITU-Tの推奨X.509 [1]で定義されている証明書の取り消しリスト（セクション8.2を参照）。また
- Online Certificate Status Protocol, as defined in RFC 2560 [3] (see Section 8.3).
- RFC 2560 [3]で定義されているオンライン証明書ステータスプロトコル（セクション8.3を参照）。
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 Section 8.1;
- セクション8.1で定義されているように、電子署名の義務付けられたコンポーネントの検証。
- complete-certificate-references attribute, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、完全総参照属性。
- complete-revocation-references attribute, as defined in Section 6.2.2;
- セクション6.2.2で定義されているように、完全な再展開再参照属性。
- a record of the electronic signature and the time when the signature was first validated, using the referenced certificates and revocation information, must be maintained, such that records cannot be undetectably modified;
- 電子署名の記録と、参照されている証明書と取り消し情報を使用して、署名が最初に検証された時間を維持する必要があります。
- Public Key Certificates, as defined in ITU-T Recommendation X.509 [1] (see Section 8.1); and
- ITU-Tの推奨X.509 [1]で定義されている公開鍵証明書（セクション8.1を参照）;と
- either of:
- のどちらか：
- Certificate Revocation Lists, as defined in ITU-T Recommendation X.509 [1] (see Section 8.2); or
- ITU-Tの推奨X.509 [1]で定義されている証明書の取り消しリスト（セクション8.2を参照）。また
- online Certificate Status Protocol, as defined in RFC 2560 [3] (see Section 8.3).
- RFC 2560 [3]で定義されているオンライン証明書ステータスプロトコル（セクション8.3を参照）。
[1] ITU-T Recommendation X.509 (2000)/ISO/IEC 9594-8 (2001): "Information technology - Open Systems Interconnection - The Directory: Public key and Attribute Certificate framework".
[1] ITU -Tの推奨X.509（2000）/ISO/IEC 9594-8（2001）：「情報技術 - オープンシステムの相互接続 - ディレクトリ：公開キーと属性証明書フレームワーク」。
[2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[2] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[3] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[3] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S。、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、RFC 2560、1999年6月。
[4] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[4] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[5] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[5] Hoffman、P.、ed。、「S/MIMEの強化されたセキュリティサービス」、RFC 2634、1999年6月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[6] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[7] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[7] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「Internet X.509公開キーインフラストラクチャタイムスタンププロトコル（TSP）」、RFC 3161、2001年8月。
[8] ITU-T Recommendation X.680 (1997): "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation".
[8] ITU -Tの推奨X.680（1997）：「情報技術 - 要約構文表記1（ASN.1）：基本表記の仕様」。
[9] ITU-T Recommendation X.501 (2000)/ISO/IEC 9594-1 (2001): "Information technology - Open Systems Interconnection - Directory models".
[9] ITU -Tの推奨X.501（2000）/ISO/IEC 9594-1（2001）：「情報技術 - オープンシステムの相互接続 - ディレクトリモデル」。
[10] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[10] Housley、R。、「暗号化メッセージ構文（CMS）アルゴリズム」、RFC 3370、2002年8月。
[11] ITU-T Recommendation F.1: "Operational provisions for the international public telegram service".
[11] ITU-Tの推奨F.1：「国際公共電報サービスの運用規定」。
[12] ITU-T Recommendation X.500: "Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services".
[12] ITU -Tの推奨X.500：「情報技術 - オープンシステムの相互接続 - ディレクトリ：概念、モデル、サービスの概要」。
[13] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[13] Farrell、S。およびR. Housley、「認証のためのインターネット属性証明書プロファイル」、RFC 3281、2002年4月。
[14] ITU-T Recommendation X.208 (1988): "Specification of Abstract Syntax Notation One (ASN.1)".
[14] ITU-T推奨X.208（1988）：「抽象的構文表記の仕様（ASN.1）」。
[15] Schaad, J., "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", RFC 5035, August 2007.
[15] Schaad、J。、「強化されたセキュリティサービス（ESS）アップデート：CertIDアルゴリズムのagilityの追加」、RFC 5035、2007年8月。
[16] ITU-T Recommendation X.690 (2002): "Information technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)".
[16] ITU-Tの推奨X.690（2002）：「情報技術ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコードルール（CER）、および区別されたエンコードルール（DER）の仕様」。
[EUDirective] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a community framework for Electronic Signatures.
[eudirective]指令1999/93/EC欧州議会および1999年12月13日の評議会の電子署名に関するコミュニティフレームワークに関する評議会。
[TS101733] ETSI Standard TS 101 733 V.1.7.3 (2005-06) Electronic Signature Formats.
[TS101733] ETSI標準TS 101 733 V.1.7.3（2005-06）電子署名形式。
[TS101861] ETSI TS 101 861: "Time stamping profile".
[TS101861] ETSI TS 101 861：「タイムスタンピングプロファイル」。
[TS101903] ETSI TS 101 903: "XML Advanced Electronic Signatures (XAdES)".
[TS101903] ETSI TS 101 903：「XML Advanced Electronic Signatures（Xades）」。
[TR102038] ETSI TR 102 038: "Electronic Signatures and Infrastructures (ESI); XML format for signature policies".
[TR102038] ETSI TR 102 038：「電子署名とインフラストラクチャ（ESI）;署名ポリシーのXML形式」。
[TR102272] ETSI TR 102 272 V1.1.1 (2003-12). "Electronic Signatures and Infrastructures (ESI); ASN.1 format for signature policies".
[TR102272] ETSI TR 102 272 V1.1.1（2003-12）。「電子署名とインフラストラクチャ（ESI）; ASN.1署名ポリシーの形式」。
[RFC2479] Adams, C., "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)", RFC 2479, December 1998.
[RFC2479] Adams、C。、「独立データユニット保護ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（IDUP-GSS-API）」、RFC 2479、1998年12月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interfaceバージョン2、Update 1」、RFC 2743、2000年1月。
[RFC3125] Ross, J., Pinkas, D., and N. Pope, "Electronic Signature Policies", RFC 3125, September 2001.
[RFC3125] Ross、J.、Pinkas、D。、およびN. Pope、「電子署名ポリシー」、RFC 3125、2001年9月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status", RFC 3494, March 2003.
[RFC3494] Zeilenga、K。、「Lightweight Directory Access Protocolバージョン2（LDAPV2）への歴史的ステータス」、RFC 3494、2003年3月。
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4210] Adams、C.、Farrell、S.、Kause、T。、およびT. Mononen、「Internet X.509公開キーインフラストラクチャ証明書管理プロトコル（CMP）」、RFC 4210、2005年9月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006.
[RFC4523] Zeilenga、K。、「X.509証明書のLightweight Directory Access Protocol（LDAP）スキーマ定義」、RFC 4523、2006年6月。
[ISO7498-2] ISO 7498-2 (1989): "Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture".
[ISO7498-2] ISO 7498-2（1989）：「情報処理システム - オープンシステムの相互接続 - 基本的な参照モデル - パート2：セキュリティアーキテクチャ」。
[ISO9796-2] ISO/IEC 9796-2 (2002): "Information technology - Security techniques - Digital signature schemes giving message recovery - Part 2: Integer factorization based mechanisms".
[ISO9796-2] ISO/IEC 9796-2（2002）：「情報技術 - セキュリティテクニック - メッセージ回復を与えるデジタル署名スキーム - パート2：整数因数分解ベースのメカニズム」。
[ISO9796-4] ISO/IEC 9796-4 (1998): "Digital signature schemes giving message recovery - Part 4: Discrete logarithm based mechanisms".
[ISO9796-4] ISO/IEC 9796-4（1998）：「メッセージの回復を与えるデジタル署名スキーム - パート4：離散対数ベースのメカニズム」。
[ISO10118-1] ISO/IEC 10118-1 (2000): "Information technology - Security techniques - Hash-functions - Part 1: General".
[ISO10118-1] ISO/IEC 10118-1（2000）：「情報技術 - セキュリティ技術 - ハッシュファンクション - パート1：一般」。
[ISO10118-2] ISO/IEC 10118-2 (2000): "Information technology - Security techniques - Hash-functions - Part 2: Hash-functions using an n-bit block cipher algorithm".
[ISO118-2] ISO/IEC 10118-2（2000）：「情報技術 - セキュリティ技術 - ハッシュファンクション - パート2：Nビットブロック暗号アルゴリズムを使用したハッシュファンクション」。
[ISO10118-3] ISO/IEC 10118-3 (2004): "Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions".
[ISO10118-3] ISO/IEC 10118-3（2004）：「情報技術 - セキュリティテクニック - ハッシュファンクション - パート3：専用ハッシュファンクション」。
[ISO10118-4] ISO/IEC 10118-4 (1998): "Information technology - Security techniques - Hash-functions - Part 4: Hash-functions using modular arithmetic".
[ISO10118-4] ISO/IEC 10118-4（1998）：「情報技術 - セキュリティテクニック - ハッシュファンクション - パート4：モジュラー算術を使用したハッシュファクション」。
[ISO10181-5] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997.
[ISO10181-5] ISO/IEC 10181-5：オープンシステムのセキュリティフレームワーク。非繰り返しフレームワーク。1997年4月。
[ISO13888-1] ISO/IEC 13888-1 (2004): "IT security techniques - Non-repudiation - Part 1: General".
[ISO13888-1] ISO/IEC 13888-1（2004）：「ITセキュリティテクニック - 非和解 - パート1：一般」。
[ISO14888-1] ISO/IEC 14888-1 (1998): "Information technology - Security techniques - Digital signatures with appendix - Part 1: General".
[ISO14888-1] ISO/IEC 14888-1（1998）：「情報技術 - セキュリティテクニック - 付録付きデジタル署名 - パート1：一般」。
[ISO14888-2] ISO/IEC 14888-2 (1999): "Information technology - Security techniques - Digital signatures with appendix - Part 2: Identity-based mechanisms".
[ISO14888-2] ISO/IEC 14888-2（1999）：「情報技術 - セキュリティ技術 - 付録付きデジタル署名 - パート2：アイデンティティベースのメカニズム」。
[ISO14888-3] ISO/IEC 14888-3 (1998): "Information technology - Security techniques - Digital signatures with appendix - Part 3: Certificate-based mechanisms".
[ISO14888-3] ISO/IEC 14888-3（1998）：「情報技術 - セキュリティ技術 - 付録付きデジタル署名 - パート3：証明書ベースのメカニズム」。
[ISO15946-2] ISO/IEC 15946-2 (2002): "Information technology - Security techniques - Cryptographic techniques based on elliptic curves - Part 2: Digital signatures".
[ISO15946-2] ISO/IEC 15946-2（2002）：「情報技術 - セキュリティ技術 - 楕円曲線に基づく暗号化技術 - パート2：デジタル署名」。
[CWA14171] CWA 14171 CEN Workshop Agreement: "General Guidelines for Electronic Signature Verification".
[CWA14171] CWA 14171 CENワークショップ契約：「電子署名の一般的なガイドライン」。
[XMLDSIG] XMLDSIG: W3C/IETF Recommendation (February 2002): "XML-Signature Syntax and Processing".
[xmldsig] xmldsig：w3c/ietf推奨（2002年2月）：「xml-signature構文と処理」。
[X9.30-1] ANSI X9.30-1 (1997): "Public Key Cryptography for the Financial Services Industry - Part 1: The Digital Signature Algorithm (DSA)".
[X9.30-1] ANSI X9.30-1（1997）：「金融サービス業界向けの公開キー暗号化 - パート1：デジタル署名アルゴリズム（DSA）」。
[X9.30-2] ANSI X9.30-2 (1997): "Public Key Cryptography for the Financial Services Industry - Part 2: The Secure Hash Algorithm (SHA-1)".
[X9.30-2] ANSI X9.30-2（1997）：「金融サービス業界向けの公開鍵暗号 - パート2：安全なハッシュアルゴリズム（SHA-1）」。
[X9.31-1] ANSI X9.31-1 (1997): "Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry - Part 1: The RSA Signature Algorithm".
[X9.31-1] ANSI X9.31-1（1997）：「金融サービス業界に可逆アルゴリズムを使用した公開キー暗号化 - パート1：RSA署名アルゴリズム」。
[X9.31-2] ANSI X9.31-2 (1996): "Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry - Part 2: Hash Algorithms".
[X9.31-2] ANSI X9.31-2（1996）：「金融サービス業界に可逆アルゴリズムを使用した公開キー暗号 - パート2：ハッシュアルゴリズム」。
[X9.62] ANSI X9.62 (1998): "Public Key Cryptography for the Financial Services Industry - The Elliptic Curve Digital Signature Algorithm (ECDSA)".
[X9.62] ANSI X9.62（1998）：「金融サービス業界向けの公開キー暗号化 - 楕円曲線デジタル署名アルゴリズム（ECDSA）」。
[P1363] IEEE P1363 (2000): "Standard Specifications for Public-Key Cryptography".
[P1363] IEEE P1363（2000）：「パブリックキー暗号化の標準仕様」。
ETSI technical specifications can be downloaded free of charge via the Services and Products Download Area at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx
ETSI技術仕様は、サービスおよび製品を介して無料でダウンロードできます。
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 the present document.
この付録は、本文書で定義されている新しい構文のすべてのASN.1構文定義の要約を提供します。
NOTE: The ASN.1 module defined in Annex A.1 using syntax defined in ITU-T Recommendation X.208 [14] has precedence over that defined in Annex A.2 in the case of any conflict.
注：Annex A.1で定義されているASN.1モジュールは、ITU-T推奨X.208 [14]で定義された構文を使用して、競合の場合にAnnex A.2で定義されていることよりも優先されます。
ETS-ElectronicSignatureFormats-ExplicitSyntax88 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0)
eSignature-explicit88(28)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS All
- すべてエクスポートします
IMPORTS
-- Cryptographic Message Syntax (CMS): RFC 3852
- 暗号化メッセージ構文（CMS）：RFC 3852
ContentInfo, ContentType, id-data, id-signedData, SignedData,
EncapsulatedContentInfo, SignerInfo, id-contentType,
id-messageDigest, MessageDigest, id-signingTime, SigningTime,
id-countersignature, Countersignature
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }
-- ESS Defined attributes: ESS Update
-- RFC 5035 (Adding CertID Algorithm Agility)
id-aa-signingCertificate, SigningCertificate, IssuerSerial,
id-aa-contentReference, ContentReference, id-aa-contentIdentifier,
ContentIdentifier, id-aa-signingCertificateV2
FROM ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) }
-- Internet X.509 Public Key Infrastructure - Certificate and CRL
-- Profile: RFC 3280
Certificate, AlgorithmIdentifier, CertificateList, Name, DirectoryString, Attribute, 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(18)}
GeneralNames, GeneralName, PolicyInformation
FROM PKIX1Implicit88
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit (19)}
-- Internet Attribute Certificate Profile for Authorization - RFC 3281
- 承認のためのインターネット属性証明書プロファイル-RFC3281
AttributeCertificate
FROM PKIXAttributeCertificate {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-attribute-cert(12)}
-- OCSP - RFC 2560
-OCSP -RFC 2560
BasicOCSPResponse, ResponderID
FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)}
-- Time Stamp Protocol RFC 3161
- タイムスタンププロトコルRFC 3161
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)}
;
;
-- Definitions of Object Identifier arcs used in the present document
-- ==================================================================
-- OID used referencing electronic signature mechanisms based on
-- the present document for use with the Independent Data Unit
-- Protection (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) }
-- Basic ES CMS Attributes Defined in the present document
-- =======================================================
-- OtherSigningCertificate - deprecated
-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 THE PRESENT DOCUMENT
}
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL }
OtherHash ::= CHOICE {
sha1Hash OtherHashValue,
-- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue}
-- Policy ES Attributes Defined in the present document
-- ====================================================
-- Mandatory Basic Electronic Signature Attributes as above,
-- plus in addition.
-- Signature-policy-identifier attribute
-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
-- not used in this version
}
SignaturePolicyId ::= SEQUENCE {
sigPolicyId SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL
}
SignaturePolicyImplied ::= NULL
SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyHash ::= OtherHashAlgAndValue
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue }
OtherHashValue ::= OCTET STRING
SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId }
SigPolicyQualifierId ::= OBJECT IDENTIFIER
id-spq-ets-uri OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 1 }
SPuri ::= IA5String
id-spq-ets-unotice OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-spq(5) 2 }
SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
UTF8STRING UTF8STRING（サイズ（1..200））}
-- Optional Electronic Signature Attributes
- オプションの電子署名属性
-- Commitment-type 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}
CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier, commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF CommitmentTypeQualifier OPTIONAL}
CombutmentTypeid CombutmentTypeIdentifier、CommitmentTypequalifierオプションのCommitmentTypequalifierシーケンスサイズ（1..max）}}
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 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}
SignerLocation ::= SEQUENCE {
-- at least one of the following shall 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 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}
SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes }
ClaimedAttributes ::= SEQUENCE OF Attribute
CertifiedAttributes ::= AttributeCertificate
-- as defined in RFC 3281: see Section 4.1
-- Content-time-stamp 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}
ContentTimestamp ::= TimeStampToken
-- Signature-time-stamp 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}
SignatureTimeStampToken ::= TimeStampToken
-- Complete-certificate-references attribute
-Complete-Certificate-References属性
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-references attribute
- 完全な反省再参照属性
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 OtherRevRefType,
otherRevRefs ANY DEFINED BY otherRevRefType
}
OtherRevRefType ::= OBJECT IDENTIFIER
-- Certificate-values 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}
CertificateValues ::= SEQUENCE OF Certificate
-- Certificate-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}
RevocationValues ::= SEQUENCE {
crlVals [0] SEQUENCE OF CertificateList OPTIONAL, ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, otherRevVals [2] OtherRevVals OPTIONAL}
CRLVALS [0] SERTATICATELISTオプションのシーケンス、OCSPVALS [1] BASICOCSPRESPONSEオプションのシーケンス、otherRevVals [2] Opental}
OtherRevVals ::= SEQUENCE {
otherRevValType OtherRevValType,
otherRevVals ANY DEFINED BY otherRevValType
}
OtherRevValType ::= OBJECT IDENTIFIER
-- CAdES-C time-stamp attribute
-Cades-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 attribute
id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 48}
ArchiveTimeStampToken ::= TimeStampToken
-- Attribute-certificate-references attribute
- 属性認証 - 参照属性
id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 44}
AttributeCertificateRefs ::= SEQUENCE OF OtherCertID
-- Attribute-revocation-references attribute
- 属性 - 反論再参照属性
id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 45}
AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef
END
NOTE: The ASN.1 module defined in Annex A.1 has precedence over that defined in Annex A.2 using syntax defined in ITU-T Recommendation X.680 (1997) [8] in the case of any conflict.
注：付録A.1で定義されているASN.1モジュールは、競合の場合にITU-T推奨X.680（1997）[8]で定義された構文を使用して、付録A.2で定義されているものよりも優先されます。
ETS-ElectronicSignatureFormats-ExplicitSyntax97 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0)
eSignature-explicit97(29)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS All -
- すべてエクスポート -
IMPORTS
輸入
-- Cryptographic Message Syntax (CMS): RFC 3852
- 暗号化メッセージ構文（CMS）：RFC 3852
ContentInfo, ContentType, id-data, id-signedData, SignedData,
EncapsulatedContentInfo, SignerInfo,
id-contentType, id-messageDigest, MessageDigest, id-signingTime,
SigningTime, id-countersignature, Countersignature
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }
-- ESS Defined attributes: ESS Update
-- RFC 5035 (Adding CertID Algorithm Agility)
id-aa-signingCertificate, SigningCertificate, IssuerSerial,
id-aa-contentReference, ContentReference, id-aa-contentIdentifier,
ContentIdentifier, id-aa-signingCertificateV2
FROM ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) }
-- Internet X.509 Public Key Infrastructure
-- Certificate and CRL Profile: RFC 3280
Certificate, AlgorithmIdentifier, CertificateList, Name, Attribute
証明書、AlgorithMidentifier、証明書作成者、名前、属性
FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)}
GeneralNames, GeneralName, PolicyInformation
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)}
-- Internet Attribute Certificate Profile for Authorization - RFC 3281
- 承認のためのインターネット属性証明書プロファイル-RFC3281
AttributeCertificate
FROM PKIXAttributeCertificate {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert(12)}
-- OCSP RFC 2560
-OCSP RFC 2560
BasicOCSPResponse, ResponderID
FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)}
-- RFC 3161 Internet X.509 Public Key Infrastructure
-- Time-Stamp Protocol
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)}
-- X.520
-X.520
DirectoryString {}
FROM SelectedAttributeTypes
{joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4}
;
;
-- Definitions of Object Identifier arcs used in the present document
-- ==================================================================
-- OID used referencing electronic signature mechanisms based
-- on the present document 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) }
-- Basic ES Attributes Defined in the present document
-- ===================================================
-- CMS Attributes defined in the present document
- 現在のドキュメントで定義されているCMS属性
-- OtherSigningCertificate - deprecated
-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 THE PRESENT DOCUMENT
}
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL }
OtherHash ::= CHOICE {
sha1Hash OtherHashValue,
-- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue}
-- Policy ES Attributes Defined in the present document
-- ====================================================
-- Mandatory Basic Electronic Signature Attributes, plus in addition.
-- 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
-- not used in this version
}
SignaturePolicyId ::= SEQUENCE {
sigPolicyId SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL
}
}
SignaturePolicyImplied ::= NULL
SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyHash ::= OtherHashAlgAndValue
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue
}
OtherHashValue ::= OCTET STRING
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-spq-ets-unotice SIG-QUALIFIER-TYPE
SPUserNotice }
pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= {
SIG-POLICY-QUALIFIER-ID id-spq-ets-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 shall be present
countryName [0] DirectoryString{maxSize} OPTIONAL,
-- as used to name a Country in X.520
localityName [1] DirectoryString{maxSize} OPTIONAL,
-- as used to name a locality in X.520
postalAdddress [2] PostalAddress OPTIONAL }
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString{maxSize}
-- maxSize parametrization as specified in X.683
-- 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 RFC 3281: see Section 4.1
-- Content Timestamp
- コンテンツタイムスタンプ
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
-- Signature Timestamp
- 署名タイムスタンプ
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 SEQUENCE OF OTHER-REVOCATION-REF.&Type
}
OTHER-REVOCATION-REF ::= CLASS {
&Type,
&id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX {
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 OPTIONAL }
otherRevvals [2] otherRevvalsオプション}
OtherRevVals ::= SEQUENCE {
otherRevValType OTHER-REVOCATION-VAL.&id,
otherRevVals SEQUENCE OF OTHER-REVOCATION-REF.&Type
}
OTHER-REVOCATION-VAL ::= CLASS {
&Type,
&id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX {
WITH SYNTAX &Type ID &id }
-- CAdES-C Timestamp
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 Timestamp
- アーカイブタイムスタンプ
id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 48}
ArchiveTimeStampToken ::= TimeStampToken
-- Attribute certificate references
- 属性証明書の参照
id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 44}
AttributeCertificateRefs ::= SEQUENCE OF OtherCertID
-- Attribute revocation references
- 属性「取り消し」参照
id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 45}
AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef
ENDAnnex B (Informative): Extended Forms of Electronic Signatures
エンドアネックスB（情報）：電子署名の拡張フォーム
Section 4 provides an overview of the various formats of electronic signatures included in the present document. This annex lists the attributes that need to be present in the various extended electronic signature formats and provides example validation sequences using the extended formats.
セクション4では、現在のドキュメントに含まれるさまざまな形式の電子署名の概要を説明します。この付録は、さまざまな拡張された電子署名形式に存在する必要がある属性をリストし、拡張形式を使用して例の検証シーケンスを提供します。
The Complete validation data (CAdES-C) described in Section 4.3 and illustrated in Figure 3 may be extended to create electronic signatures with extended validation data. Some electronic signature forms that include extended validation are explained below.
セクション4.3で説明し、図3に示す完全な検証データ（CADES-C）を拡張して、拡張検証データを備えた電子署名を作成することができます。拡張検証を含むいくつかの電子署名フォームを以下に説明します。
An X-Long electronic signature (CAdES-X Long) is the CAdES-C with the values of the certificates and revocation information.
X-Long Electronic Signature（Cades-X Long）は、証明書と取り消し情報の値を持つCades-Cです。
This form of electronic signature can be useful when the verifier does not have direct access to the following information:
この形式の電子署名は、検証者が次の情報に直接アクセスできない場合に役立ちます。
- the signer's certificate;
- 署名者の証明書。
- all the CA certificates that make up the full certification path;
- 完全な認定パスを構成するすべてのCA証明書。
- all the associated revocation status information, as referenced in the CAdES-C.
- Cades-Cで参照されているすべての関連する取り消しステータス情報。
In some situations, additional time-stamps may be created and added to the Electronic Signatures as additional attributes. For example:
状況によっては、追加の属性として追加のタイムスタンプが作成され、電子署名に追加される場合があります。例えば：
- time-stamping all the validation data as held with the ES (CAdES-C), this eXtended validation data is called a CAdES-X Type 1; or
- ES（Cades-C）に保持されているすべての検証データをタイムスタンピングするこの拡張検証データは、Cades-X Type 1と呼ばれます。また
- time-stamping individual reference data as used for complete validation. This form of eXtended validation data is called an CAdES-X Type 2.
- 完全な検証に使用される個々の参照データのタイムスタンプ。この形式の拡張検証データは、Cades-X Type 2と呼ばれます。
NOTE 1: The advantages/drawbacks for CAdES-X Type 1 and CAdES-X Type 2 are discussed in Annex C.4.4.
The above time-stamp forms can be useful when it is required to counter the risk that any CA keys used in the certificate chain may be compromised.
上記のタイムスタンプフォームは、証明書チェーンで使用されているCAキーが損なわれる可能性があるリスクに対抗するために必要な場合に役立ちます。
A combination of the two formats above may be used. This form of eXtended validation data is called an ES X-Long Type 1 or CAdES-X Long Type 2. This form of electronic signature can be useful when the verifier needs both the values and proof of when the validation data existed.
上記の2つの形式の組み合わせを使用できます。この形式の拡張検証データは、ES X-Long Type 1またはCades-X Long Type 2と呼ばれます。この形式の電子署名は、検証者が検証データが存在するときの値と証明の両方を必要とする場合に役立ちます。
NOTE 2: The advantages/drawbacks for CAdES-X long Type 1 and CAdES-X long Type 2 are discussed in Annex C.4.6.
注2：Cades-X Long Type 1およびCades-X Long Type 2の利点/欠点については、付録C.4.6で説明します。
An electronic signature with the additional validation data forming the CAdES-X Long form (CAdES-X-Long) is illustrated in Figure B.1 and comprises the following:
Cades-X Longフォーム（Cades-X-Long）を形成する追加の検証データを備えた電子署名を図B.1に示し、以下を含みます。
- CAdES-BES or CAdES-EPES, as defined in Sections 4.3 , 5.7, or 5.8;
- セクション4.3、5.7、または5.8で定義されているように、Cades-BesまたはCades-Epes。
- complete-certificate-references attribute, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、完全総参照属性。
- complete-revocation-references attribute, as defined in Section 6.2.2.
- セクション6.2.2で定義されているように、完全な再展開再参照属性。
The following attributes are required if a TSP is not providing a time-mark of the ES:
TSPがESのタイムマークを提供していない場合、次の属性が必要です。
- signature-time-stamp attribute, as defined in Section 6.1.1.
- セクション6.1.1で定義されている署名時刻スタンプ属性。
The following attributes are required if the full certificate values and revocation values are not already included in the CAdES-BES or CAdES-EPES:
完全な証明書値と取り消し値がまだCades-BesまたはCades-Epesに含まれていない場合、次の属性が必要です。
- certificate-values attribute, as defined in Section 6.3.3;
- セクション6.3.3で定義されている証明書値属性。
- revocation-values attribute, as defined in Section 6.3.4.
- セクション6.3.4で定義されているように、取消値属性。
If attributes certificates are used, then the following attributes may be present:
属性証明書が使用される場合、次の属性が存在する場合があります。
- attribute-certificate-references attribute, defined in Section 6.2.3;
-
- attribute-revocation-references attribute, as defined in Section 6.2.4.
- セクション6.2.4で定義されているように、属性 - revocation-References属性。
Other unsigned attributes may be present, but are not required.
他の署名されていない属性が存在する場合がありますが、必要ありません。
NOTE: Attribute certificate and revocation references are only present if a user attribute certificate is present in the electronic signature; see Sections 6.2.2 and 6.2.3.
注：属性証明書と取り消しの参照は、電子署名にユーザー属性証明書が存在する場合にのみ存在します。セクション6.2.2および6.2.3を参照してください。
+---------------------- CAdES-X-Long --------------------------------+
|+-------------------------------------- CAdES-C ---+ |
|| +----------+ | +-------------+|
||+----- CAdES-BES or CAdES-EPES ----+ |Timestamp | | | ||
||| | |over | | | Complete ||
|||+---------++----------++---------+| |digital | | | certificate ||
|||| || || || |signature | | | and ||
||||Signer's || Signed ||Digital || | | | | revocation ||
||||Document ||Attributes||signature|| |Optional | | | data ||
|||| || || || |when | | | ||
|||+---------++----------++---------+| |timemarked| | | ||
||+----------------------------------+ +----------+ | | ||
|| +-----------+| +-------------+|
|| |Complete || |
|| |certificate|| |
|| |and || |
|| |revocation || |
|| |references || |
|| +-----------+| |
|+--------------------------------------------------+ |
| |
+--------------------------------------------------------------------+
Figure B.1: Illustration of CAdES-X-Long
An electronic signature with the additional validation data forming the eXtended validation data - Type 1 X is illustrated in Figure B.2 and comprises the following:
拡張検証データを形成する追加の検証データを備えた電子署名-1 xを図B.2に示し、以下を含みます。
- the CAdES-BES or CAdES-EPES, as defined in Sections 4.2, 5.7, or 5.8;
- セクション4.2、5.7、または5.8で定義されているように、Cades-BesまたはCades-Epes。
- complete-certificate-references attribute, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、完全総参照属性。
- complete-revocation-references attribute, as defined in Section 6.2.2;
- セクション6.2.2で定義されているように、完全な再展開再参照属性。
- CAdES-C-Timestamp attribute, as defined in Section 6.3.5.
- セクション6.3.5で定義されているように、Cades-C-Timestamp属性。
The following attributes are required if a TSP is not providing a time-mark of the ES:
TSPがESのタイムマークを提供していない場合、次の属性が必要です。
- signature-time-stamp attribute, as defined in Section 6.1.1.
- セクション6.1.1で定義されている署名時刻スタンプ属性。
If attributes certificates are used, then the following attributes may be present:
属性証明書が使用される場合、次の属性が存在する場合があります。
- attribute-certificate-references attribute, defined in Section 6.2.3;
- セクション6.2.3で定義されている属性 - 認証 - 参照属性。
- attribute-revocation-references attribute, as defined in Section 6.2.4.
- セクション6.2.4で定義されているように、属性 - revocation-References属性。
Other unsigned attributes may be present, but are not required.
他の署名されていない属性が存在する場合がありますが、必要ありません。
+------------------------ CAdES-X-Type 1 ----------------------------+
|+---------------------------------- CAdES-C ------+ |
|| +----------+ | +-------------+ |
||+--- CAdES-BES or CAdES-EPES ------+|Timestamp | | | | |
||| ||over | | | | |
|||+---------++----------++---------+||digital | | | | |
||||Signer's || Signed || Digital |||signature | | | Timestamp | |
||||Document ||Attributes||signature||| | | | over | |
|||| || || |||Optional | | | CAdES-C | |
|||+---------++----------++---------+||when | | | | |
||+----------------------------------+|timemarked| | | | |
|| +----------+ | | | |
|| +-----------+| +-------------+ |
|| |Complete || |
|| |certificate|| |
|| | and || |
|| |revocation || |
|| |references || |
|| +-----------+| |
|+-------------------------------------------------+ |
| |
+--------------------------------------------------------------------+
Figure B.2: Illustration of CAdES-X Type 1
図B.2：Cades-Xタイプ1のイラスト
An electronic signature with the additional validation data forming the eXtended Validation Data - Type 2 X is illustrated in Figure B.3 and comprises the following:
拡張検証データを形成する追加の検証データを備えた電子署名-2 xタイプ2を図B.3に示し、以下を含みます。
- CAdES-BES or CAdES-EPES, as defined in Sections 4.2, 5.7, or 5.8;
- セクション4.2、5.7、または5.8で定義されているように、Cades-BesまたはCades-Epes。
- complete-certificate-references attribute, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、完全総参照属性。
- complete-revocation-references attribute, as defined in Section 6.2.2;
- セクション6.2.2で定義されているように、完全な再展開再参照属性。
- time-stamped-certs-crls-references attribute, as defined in Section 6.3.6.
- セクション6.3.6で定義されているように、タイムスタンプCERTS-CRLS-References属性属性。
The following attributes are required if a TSP is not providing a time-mark of the ES:
TSPがESのタイムマークを提供していない場合、次の属性が必要です。
- signature-time-stamp attribute, as defined in Section 6.1.1.
- セクション6.1.1で定義されている署名時刻スタンプ属性。
If attributes certificates are used, then the following attributes may be present:
属性証明書が使用される場合、次の属性が存在する場合があります。
- attribute-certificate-references attribute, defined in Section 6.2.3;
- セクション6.2.3で定義されている属性 - 認証 - 参照属性。
- attribute-revocation-references attribute, as defined in Section 6.2.4.
- セクション6.2.4で定義されているように、属性 - revocation-References属性。
Other unsigned attributes may be present, but are not required.
他の署名されていない属性が存在する場合がありますが、必要ありません。
+----------------------- CAdES-X-Type 2 -----------------------------+
|+-------------------------------------- CAdES-C --+ |
|| +----------+ | |
||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | | |
||| ||over | | |
|||+---------++----------++---------+||digital | | +-------------+ |
|||| || || |||Signature | | | Timestamp | |
||||Signer's || Signed || Digital ||| | | | only over | |
||||Document ||Attributes||signature|||Optional | | | Complete | |
|||| || || |||when | | | certificate | |
|||+---------++----------++---------+||Timemarked| | | and | |
||+----------------------------------++----------+ | | revocation | |
|| +-----------+| | references | |
|| |Complete || +-------------+ |
|| |certificate|| |
|| |and || |
|| |revocation || |
|| |references || |
|| +-----------+| |
|+-------------------------------------------------+ |
| |
+--------------------------------------------------------------------+
Figure B.3: Illustration of CAdES-X Type 2
図B.3：Cades-Xタイプ2のイラスト
An electronic signature with the additional validation data forming the CAdES-X Long Type 1 and CAdES-X Long Type 2 is illustrated in Figure B.4 and comprises the following:
Cades-X Long Type 1とCades-X Long Type 2を形成する追加の検証データを備えた電子署名を図B.4に示し、以下を含みます。
- CAdES-BES or CAdES-EPES, as defined in Sections 4.3, 5.7, or 5.8;
- セクション4.3、5.7、または5.8で定義されているように、Cades-BesまたはCades-Epes。
- complete-certificate-references attribute, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、完全総参照属性。
- complete-revocation-references attribute, as defined in Section 6.2.2;
- セクション6.2.2で定義されているように、完全な再展開再参照属性。
The following attributes are required if a TSP is not providing a time-mark of the ES:
TSPがESのタイムマークを提供していない場合、次の属性が必要です。
- signature-time-stamp attribute, as defined in Section 6.1.1.
- セクション6.1.1で定義されている署名時刻スタンプ属性。
The following attributes are required if the full certificate values and revocation values are not already included in the CAdES-BES or CAdES-EPES:
完全な証明書値と取り消し値がまだCades-BesまたはCades-Epesに含まれていない場合、次の属性が必要です。
- certificate-values attribute, as defined in Section 6.3.3;
- セクション6.3.3で定義されている証明書値属性。
- revocation-values attribute, as defined in Section 6.3.4.
- セクション6.3.4で定義されているように、取消値属性。
If attributes certificates are used, then the following attributes may be present:
属性証明書が使用される場合、次の属性が存在する場合があります。
- attribute-certificate-references attribute, defined in Section 6.2.3;
- セクション6.2.3で定義されている属性 - 認証 - 参照属性。
- attribute-revocation-references attribute, as defined in Section 6.2.4.
- セクション6.2.4で定義されているように、属性 - revocation-References属性。
Plus one of the following attributes is required:
さらに、次の属性のいずれかが必要です。
- CAdES-C-Timestamp attribute, as defined in Section 6.3.5;
- セクション6.3.5で定義されているCades-C-Timestamp属性。
- time-stamped-certs-crls-references attribute, as defined in Section 6.3.6.
- セクション6.3.6で定義されているように、タイムスタンプCERTS-CRLS-References属性属性。
Other unsigned attributes may be present, but are not required.
他の署名されていない属性が存在する場合がありますが、必要ありません。
+---------------------- CAdES-X-Type 1 or 2 ------------------------+
| +--------------+|
|+-------------------------------------- CAdES-C --+|+------------+||
|| +----------+ ||| Timestamp |||
||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | ||| over |||
||| ||over | ||| CAdES-C |||
|||+---------++----------++---------+||digital | | +------------+ |
|||| || || |||signature | || or ||
||||Signer's || Signed || Digital ||| | ||+------------+||
||||Document ||Attributes||Signature|||Optional | ||| Timestamp |||
|||| || || |||when | ||| only over |||
|||+---------++----------++---------+||timemarked| ||| complete |||
||+----------------------------------++----------+ ||| certificate|||
|| ||| and |||
|| +-----------+||| revocation |||
|| |Complete |||| references |||
|| |certificate|||+------------+||
|| |and ||+--------------+|
|| |revocation || +------------+ |
|| |references || |Complete | |
|| +-----------+| |certificate | |
|+-------------------------------------------------+ | and | |
| |revocation | |
| | values | |
| +------------+ |
+-------------------------------------------------------------------+
Figure B.4: Illustration of CAdES-X Long Type 1 and CAdES-X Long Type 2
図B.4：Cades-X Long Type1とCades-X Long Type2のイラスト
Each instance of the time-stamp attribute may include, as unsigned attributes in the signedData of the time-stamp, the following attributes related to the TSU:
タイムスタンプ属性の各インスタンスには、TSUに関連する次の属性が、タイムスタンプの署名された属性に署名されていない属性として含まれる場合があります。
- complete-certificate-references attribute of the TSU, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、TSUの完全な資格再参照属性。
- complete-revocation-references attribute of the TSU, as defined in Section 6.2.2;
- セクション6.2.2で定義されているように、TSUの完全な再展開属性属性。
- certificate-values attribute of the TSU, as defined in Section 6.3.3;
- セクション6.3.3で定義されているTSUの証明書値属性。
- revocation-values attribute of the TSU, as defined in Section 6.3.4.
- セクション6.3.4で定義されているように、TSUの取消値属性属性。
Other unsigned attributes may be present, but are not required.
他の署名されていない属性が存在する場合がありますが、必要ありません。
Before the algorithms, keys, and other cryptographic data used at the time the CAdES-C was built become weak and the cryptographic functions become vulnerable, or the certificates supporting previous time-stamps expire, the signed data, the CAdES-C, and any additional information (i.e., any CAdES-X) should be time-stamped. If possible, this should use stronger algorithms (or longer key lengths) than in the original time-stamp. This additional data and time-stamp is called Archive validation data required for the ES Archive format (CAdES-A). The Time-stamping process may be repeated every time the protection used to time-stamp a previous CAdES-A becomes weak. A CAdES-A may thus bear multiple embedded time-stamps.
アルゴリズム、キー、およびCades-Cの構築時に使用されたキー、およびその他の暗号化データが弱くなり、暗号化機能が脆弱になるか、以前のタイムスタンプが期限切れになる証明書、署名されたデータ、Cades-C、および追加情報（すなわち、任意のCades-X）は時間刻印する必要があります。可能であれば、これは元のタイムスタンプよりも強いアルゴリズム（または長いキーの長さ）を使用する必要があります。この追加データとタイムスタンプは、ESアーカイブ形式（Cades-A）に必要なアーカイブ検証データと呼ばれます。タイムスタンピングプロセスは、以前のケードAのタイムスタンプに保護が弱くなるたびに繰り返される場合があります。したがって、ケードAは複数の埋め込まれたタイムスタンプを負担する可能性があります。
An example of an electronic signature (ES), with the additional validation data for the CAdES-C and CAdES-X forming the CAdES-A is illustrated in Figure B.5.
Cades-CとCades-Xの追加の検証データを使用した電子署名（ES）の例を図B.5に示します。
+--------------------------- CAdES-A---------------------------------+
|+----------------------------------------------------+ |
|| +--------------+| +----------+ |
||+--------------------- CAdES-C ----+|+------------+|| | | |
||| +----------+ ||| Timestamp ||| | | |
|||+-- CAdES-BES ------+|Timestamp | ||| over ||| | | |
|||| or CAdES-EPES ||over | ||| CAdES-C ||| | Archive | |
|||| ||digital | ||+------------+|| | | |
|||| ||signature | || or || |Timestamp | |
|||| || | ||+------------+|| | | |
|||| ||optional | ||| Timestamp ||| | | |
|||| ||when | ||| only over ||| | | |
|||| ||timemarked| ||| complete ||| | | |
|||+-------------------++----------+ ||| certificate||| +----------+ |
||| ||| and ||| |
||| +-------------+||| revocation ||| |
||| | Complete |||| references ||| |
||| | certificate |||+------------+|| |
||| | and ||+--------------+| |
||| | revocation || +------------+ | |
||| | references || |Complete | | |
||| +-------------+| |certificate | | |
||+----------------------------------+ | and | | |
|| |revocation | | |
|| | values | | |
|| +------------+ | |
|+----------------------------------------------------+ |
+--------------------------------------------------------------------+
Figure B.5: Illustration of CAdES-A
図B.5：Cades-Aのイラスト
The CAdES-A comprises the following elements:
Cades-Aは次の要素で構成されています。
- the CAdES-BES or CAdES-EPES, including their signed and unsigned attributes;
- 署名された属性と署名されていない属性を含む、ケードベスまたはケードエペス。
- complete-certificate-references attribute, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、完全総参照属性。
- complete-revocation-references attribute, as defined in Section 6.2.2.
- セクション6.2.2で定義されているように、完全な再展開再参照属性。
The following attributes are required if a TSP is not providing a time-mark of the ES:
TSPがESのタイムマークを提供していない場合、次の属性が必要です。
- signature-time-stamp attribute, as defined in Section 6.1.1.
- セクション6.1.1で定義されている署名時刻スタンプ属性。
If attributes certificates are used, then the following attributes may be present:
属性証明書が使用される場合、次の属性が存在する場合があります。
- attribute-certificate-references attribute, defined in Section 6.2.3;
- セクション6.2.3で定義されている属性 - 認証 - 参照属性。
- attribute-revocation-references attribute, as defined in Section 6.2.4.
- セクション6.2.4で定義されているように、属性 - revocation-References属性。
The following attributes are required if the full certificate values and revocation values are not already included in the CAdES-BES or CAdES-EPES:
完全な証明書値と取り消し値がまだCades-BesまたはCades-Epesに含まれていない場合、次の属性が必要です。
- certificate-values attribute, as defined in Section 6.3.3;
- セクション6.3.3で定義されている証明書値属性。
- revocation-values attribute, as defined in Section 6.3.4.
- セクション6.3.4で定義されているように、取消値属性。
At least one of the following two attributes is required:
次の2つの属性のうち少なくとも1つが必要です。
- CAdES-C-Timestamp attribute, as defined in Section 6.3.5;
- セクション6.3.5で定義されているCades-C-Timestamp属性。
- time-stamped-certs-crls-references attribute, as defined in Section 6.3.6.
- セクション6.3.6で定義されているように、タイムスタンプCERTS-CRLS-References属性属性。
The following attribute is required:
次の属性が必要です。
- archive-time-stamp attributes, defined in Section 6.4.1.
- セクション6.4.1で定義されているアーカイブタイムスタンプ属性。
Several instances of the archive-time-stamp attribute may occur with an electronic signature, both over time and from different TSUs. The time-stamp should be created using stronger algorithms (or longer key lengths) than in the original electronic signatures or time-stamps.
アーカイブ時間スタンプ属性のいくつかのインスタンスは、時間の経過とともに異なるTSUからの電子署名で発生する場合があります。タイムスタンプは、元の電子署名またはタイムスタンプよりも強力なアルゴリズム（または長いキーの長さ）を使用して作成する必要があります。
Other unsigned attributes of the ES may be present, but are not required.
ESの他の署名されていない属性が存在する場合がありますが、必要ありません。
The archive-time-stamp will itself contain the certificate and revocation information required to validate the archive-time-stamp; this may include the following unsigned attributes:
アーカイブタイムスタンプ自体には、アーカイブタイムスタンプを検証するために必要な証明書と取り消し情報が含まれます。これには、次の符号なしの属性が含まれる場合があります。
- complete-certificate-references attribute of the TSU, as defined in Section 6.2.1;
- セクション6.2.1で定義されているように、TSUの完全な資格再参照属性。
- complete-revocation-references attribute of the TSU, as defined in Section 6.2.2;
- セクション6.2.2で定義されているように、TSUの完全な再展開属性属性。
- certificate-values attribute of the TSU, as defined in Section 6.3.3;
- セクション6.3.3で定義されているTSUの証明書値属性。
- revocation-values attribute of the TSU, as defined in Section 6.3.4.
- セクション6.3.4で定義されているように、TSUの取消値属性属性。
Other unsigned attributes may be present, but are not required.
他の署名されていない属性が存在する場合がありますが、必要ありません。
As described earlier, the signer or initial verifier may collect all the additional data that forms the electronic signature. Figure B.6 and the subsequent description describe how the validation process may build up a complete electronic signature over time.
前述のように、署名者または初期検証者は、電子署名を形成するすべての追加データを収集する場合があります。図B.6およびその後の説明では、検証プロセスが時間の経過とともに完全な電子署名を構築する方法を説明します。
+------------------------------------------ CAdES-C -------------+
|+------------------------------- CAdES-T ------+ |
||+-------------- CAdES ------------+ | |
|||+--------------------++---------+|+---------+| +-----------+ |
|||| ________ || |||Timestamp|| |Complete | |
|||||Sign.Pol| ||Digital |||over || |certificate| |
||||| Id. | Signed ||signature|||digital || | and | |
||||| option.|attributes|| |||signature|| |revocation | |
|||||________| |+---------+|+---------+| |references | |
|||+--------------------+ | ^ | +-----------+ |
||+---------------------------------+ | | ^ |
|| 1 | / | | |
|+---------------------- | ------------/--------+ | |
+----------------------- | ---------- / --------------- / -------+
| /2 ----3--------
+----------+ | / /
| | v / |
| Signer's | +---------------------+ +-------------+
| document |----->| Validation Process |---->|- Valid |
| | +---------------------+ 4 |- Invalid |
+----------+ | ^ | ^ |- Validation |
v | v | | Incomplete |
+---------+ +--------+ +-------------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure B.6: Illustration of a CAdES validation sequence
図B.6：ケード検証シーケンスの図
Soon after receiving the electronic signature (CAdES) from the signer (1), the digital signature value may be checked; the validation process shall 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 using additional data (e.g., certificates, CRL, etc.) provided by Trusted Service Providers. When applicable, the validation process will also need to conform to the requirements specified in a signature policy. If the validation process is validation incomplete, then the output from this stage is the CAdES-T.
署名者（1）から電子署名（ケード）を受け取った直後に、デジタル署名値がチェックされる場合があります。検証プロセスは、署名者が検証者によって信頼されているものを提供していない場合を除き、少なくともタイムスタンプ（2）を追加するものとします。検証プロセスは、信頼できるサービスプロバイダーが提供する追加データ（証明書、CRLなど）を使用して電子署名を検証することもできます。該当する場合、検証プロセスは、署名ポリシーで指定された要件にも準拠する必要があります。検証プロセスが検証が不完全である場合、この段階からの出力はCades-Tです。
To ascertain the validity status as Valid or Invalid and communicate that to the user (4), all the additional data required to validate the CAdES-C must be available (e.g., the complete certificate and revocation information).
有効性を有効または無効として確認し、ユーザー（4）に伝えるために、Cades-Cを検証するために必要なすべての追加データが利用可能でなければなりません（たとえば、完全な証明書と取り消し情報）。
Once the data needed to complete validation data references (CAdES-C) is available, then the validation process should:
検証データ参照（Cades-C）を完了するために必要なデータが利用可能になったら、検証プロセスは次のとおりです。
- obtain all the necessary additional certificates and revocation status information;
- 必要なすべての追加の証明書と取り消しステータス情報を取得します。
- complete all the validation checks on the ES using the complete certificate and revocation information (if a time-stamp is not already present, this may be added at the same stage, combining the CAdES-T and CAdES-C processes);
- 完全な証明書と取り消し情報を使用してESのすべての検証チェックを完了します（タイムスタンプがまだ存在していない場合、これは同じ段階で追加され、Cades-TとCades-Cプロセスを組み合わせて追加できます）。
- record the complete certificate and revocation references (3);
- 完全な証明書と取消しの参照（3）を記録します。
- indicate the validity status to the user (4).
- ユーザーに妥当性のステータスを示します（4）。
At the same time as the validation process creates the CAdES-C, the validation process may provide and/or record the values of certificates and revocation status information used in CAdES-C (5). The end result is called CAdES-X Long.
検証プロセスがCades-Cを作成すると同時に、検証プロセスは、Cades-Cで使用される証明書と取り消しステータス情報の値を提供および/または記録する場合があります（5）。最終結果は、Cades-X Longと呼ばれます。
This is illustrated in Figure B.7.
これを図B.7に示します。
+----------------------------------------------------- CAdES-X Long -+
|+------------------------------- CAdES-C -------------+ |
||+-------------- CAdES ------------+ | |
|||+--------------------++---------+|+---------+ |+-----------+|
|||| ________ || |||Timestamp| ||Complete ||
|||||Sign.Pol| ||Digital |||over | ||certificate||
||||| Id. | Signed ||signature|||digital | || and ||
||||| option.|attributes|| |||signature| ||revocation ||
|||||________| || ||+---------+ || values ||
|||+--------------------++---------+| ^ +-----------+|+-----------+|
||+---------------------------------+ | |Complete || ^ |
|| | | |certificate|| | |
|| | 2 | | and || | |
|| | | |revocation || | |
|| | | |references || | |
|| 1 | / +-----------+| | |
|+------------------------ | ------- / --------- ^-----+ / |
+------------------------- | ------ / ---------- |--------- / -------+
| / ----- / ------- /
+----------+ | / / 3 / 5
| | v | | |
| Signer's | +--------------------+ +-----------+
| document |----->| Validation Process |----->| - Valid |
| | +--------------------+ 4 | - Invalid |
+----------+ | ^ | ^ +-----------+
v | v |
+---------+ +--------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure B.7: Illustration of a CAdES validation sequence with CAdES-X Long
図B.7：ケードXの長さのケード検証シーケンスのイラスト
When the validation process creates the CAdES-C, it may also create extended forms of validation data.
検証プロセスがCades-Cを作成すると、検証データの拡張形式も作成される場合があります。
A first alternative is to time-stamp all data forming the CAdES-X Type 1.
最初の選択肢は、Cades-X Type 1を形成するすべてのデータをタイムスタンプすることです。
This is illustrated in Figure B.8.
これを図B.8に示します。
+------------------------------------------------ CAdES-X Type 1 -----+
|+------------------------------- CAdES-C ------------------+ |
||+-------------- CAdES ------------+ | |
|||+--------------------++---------+|+---------++----------+|+-------+|
|||| ________ || |||Timestamp|| Complete ||| ||
|||||Sign.Pol| ||Digital |||over || cert. |||Time- ||
||||| Id. | Signed ||signature|||digital || and |||stamp ||
||||| option.|attributes|| |||signature|| revoc. ||| over ||
|||||________| |+---------+|+---------+|references|||CAdES-C||
|||+--------------------+ | ^ | ||| ||
||+---------------------------------+ | +----------+|+-------+|
|| | | ^ | ^ |
|| 1 | / | | | |
|+------------------------ | --------- / ----------- / -----+ | |
+------------------------- | -------- / ----------- / --------- / ----+
| 2 / ---3---- /
+----------+ | / / -----------5------
| | v | | /
| Signer's | +--------------------+ +-----------+
| document |----->| Validation Process |-----> | - Valid |
| | +--------------------+ 4 | - Invalid |
+----------+ | ^ | ^ +-----------+
v | v |
+---------+ +--------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure B.8: Illustration of CAdES with eXtended validation data CAdES-X Type 1
図B.8：検証データを拡張したケードのイラストCades-X Type1
Another alternative is to time-stamp the certificate and revocation information references used to validate the electronic signature (but not the signature) (6). The end result is called CAdES-X Type 2.
もう1つの選択肢は、電子署名を検証するために使用される証明書と取り消し情報の参照をタイムスタンプすることです（署名ではありません）（6）。最終結果は、Cades-X Type 2と呼ばれます。
This is illustrated in Figure B.9.
これを図B.9に示します。
+-------------------------------------------- CAdES-X Type 2 --------+
|+------------------------------- CAdES-C -------------+ |
||+-------------- CAdES ------------+ | |
|||+--------------------++---------+|+---------+ |+-----------+|
|||| ________ || |||Timestamp| ||Timestamp ||
|||||Sign.Pol| || |||over | || over ||
||||| Id. | Signed ||Digital |||digital | ||complete ||
||||| option.|attributes||signature|||signature| ||certificate||
|||||________| || ||| | || ||
|||+--------------------++---------+|+---------+ || and ||
||+---------------------------------+ ^ +-----------+||revocation ||
|| | | |Complete |||references ||
|| | | |certificate||+-----------+|
|| | | | and || ^ |
|| 1 | 2 | |revocation || | |
|| | | |references || | |
|| | | +-----------+| | |
|+------------------------ | --------- | --- ^ --------+ | |
| | | 3 | / |
| | | / ---------- |
| | / / / 6 |
| | / / / |
| | / / / |
+------------------------- | ----- | -- | -- / ----------------------+
| | | |
v | | |
+--------------------+ +-----------+
| Validation Process |----->| - Valid |
+--------------------+ 4 | - Invalid |
| ^ | ^ +-----------+
v | v |
+---------+ +--------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure B.9: Illustration of CAdES with eXtended validation data CAdES-X Type 2
図B.9：検証データを拡張したケードのイラストCades-Xタイプ2
Before the algorithms used in any of the electronic signatures become or are likely to be compromised or rendered vulnerable in the future, it may be necessary to time-stamp the entire electronic signature, including all the values of the validation and user data as an ES with Archive validation data (CAdES-A) (7).
電子署名のいずれかで使用されるアルゴリズムは、将来的に脆弱になったり、脆弱になったりする可能性が高い場合、検証のすべての値とユーザーデータをESとしてのすべての値を含む電子署名全体をタイムスタンプする必要がある場合があります。アーカイブ検証データ（Cades-A）（7）。
A CAdES-A is illustrated in Figure B.10.
Cades-Aを図B.10に示します。
+----------------------------- CAdES-A ---------------------------+
| |
| +-- CAdES-X Long Type 1 or 2 ----------+ |
| | | +------------+ |
| | | | | |
| | | | Archive | |
| | | | Time-stamp | |
| | | | | |
| | | +------------+ |
| +---------------------------------------+ ^ |
| +----------+ ^ ^ ^ ^ | |
| | | | | | | / |
| | Signers' | | | | | / |
| | Document |\ | | | | / |
| | | \ 1 2 | 3 | 5 | 6 | 7 / |
| +----------+ \ | | | | / |
| \ | | | | / |
+----------------- \ --- | - | - | - | ------ / ------------------+
\ | | | | |
| | | | | |
| | | | | |
v v | | | |
+-----------------------------+ +-----------+
| Validation Process |----->| - Valid |
+-----------------------------+ 4 | - Invalid |
| ^ | ^ +-----------+
v | v |
+---------+ +--------+
|Signature| |Trusted |
| Policy | |Service |
| Issuer | |Provider|
+---------+ +--------+
Figure B.10: Illustration of CAdES-A
図B.10：Cades-Aのイラスト
The present document also defines additional optional features to:
現在のドキュメントでは、以下の追加のオプション機能も定義しています。
- indicate a commitment type being made by the signer;
- 署名者によって行われているコミットメントタイプを示します。
- indicate the claimed time when the signature was done;
- 署名が行われたときの主張された時間を示します。
- indicate the claimed location of the signer;
- 署名者の主張された場所を示します。
- indicate the claimed or certified role under which a signature was created;
- 署名が作成された請求または認定された役割を示します。
- support counter signatures;
- カウンターシグネチャをサポートします。
- support multiple signatures.
- 複数の署名をサポートします。
Annex C (Informative): General Description
付録C（情報）：一般的な説明
This annex explains some of the concepts and provides the rationale for normative parts of the present document.
この付録は、いくつかの概念を説明し、現在の文書の規範的部分の理論的根拠を提供します。
The specification below includes a description of why and when each component of an electronic signature is useful, with a brief description of the vulnerabilities and threats and the manner by which they are countered.
以下の仕様には、電子署名の各コンポーネントが有用である理由と時期の説明が含まれており、脆弱性と脅威、およびそれらが対抗する方法の簡単な説明があります。
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 need to be comprehensively defined and in a computer-processable form.
署名ポリシーは、適用されている法的および契約上のコンテキストの要件を満たすために評価できるように、人間の読み取り可能な形式で利用できる必要があります。電子署名の自動処理を容易にするために、電子署名の作成と検証のための電子ルールを指定する署名ポリシーの部分も、包括的に定義され、コンピューター制御可能な形式で定義される必要があります。
The signature policy thus includes the following:
したがって、署名ポリシーには以下が含まれます。
- rules that apply to technical validation of a particular signature;
-
- rules that may be implied through adoption of Certificate Policies that apply to the electronic signature (e.g., rules for ensuring the secrecy of the private signing key);
- 電子署名に適用される証明書ポリシーの採用を通じて暗示される可能性のある規則（たとえば、プライベート署名キーの秘密を確保するための規則）;
- rules that relate to the environment used by the signer, e.g., the use of an agreed CAD (Card Accepting Device) used in conjunction with a smart card.
- 署名者が使用する環境に関連するルール、たとえば、スマートカードと組み合わせて使用される合意されたCAD（カードを受け入れるデバイス）の使用。
For example, the major rules required for technical validation can include:
たとえば、技術的検証に必要な主要なルールには、以下を含めることができます。
- recognized root keys or "top-level certification authorities";
- 認識されたルートキーまたは「トップレベル認証当局」。
- acceptable certificate policies (if any);
- 許容可能な証明書ポリシー（ある場合）;
- necessary certificate extensions and values (if any);
- 必要な証明書の拡張と値（ある場合）;
- the need for the revocation status for each component of the certification tree;
- 認証ツリーの各コンポーネントの取り消しステータスの必要性。
- acceptable TSAs (if time-stamp tokens are being used);
- 許容可能なTSA（タイムスタンプトークンが使用されている場合）;
- acceptable organizations for keeping the audit trails with time-marks (if time-marking is being used);
- 監査証跡をタイムマークで保持するための許容可能な組織（タイムマークが使用されている場合）。
- acceptable AAs (if any are being used),and;
- 許容可能なAAS（使用中の場合）、および;
- rules defining the components of the electronic signature that shall be provided by the signer with data required by the verifier when required to provide long-term proof.
- 長期的な証拠を提供するために必要な場合に検証者が必要とするデータを署名者から提供する電子署名のコンポーネントを定義するルール。
The information being signed may be defined as a MIME-encapsulated message that can be used to signal the format of the content in order to select the right display or application. It can be composed of formatted data, free text, or fields from an electronic form (e-form). For example, the Adobe(tm) format "pdf" or the eXtensible Mark up Language (XML) may be used. Annex D defines how the content may be structured to indicate the type of signed data using MIME.
署名されている情報は、適切なディスプレイまたはアプリケーションを選択するためにコンテンツの形式を信号するために使用できるMIMEでカプセル化されたメッセージとして定義できます。フォーマットされたデータ、無料テキスト、または電子フォーム（e-form）のフィールドで構成できます。たとえば、Adobe（TM）形式「PDF」または拡張可能なマークアップ言語（XML）を使用できます。付録Dは、MIMEを使用して署名されたデータのタイプを示すようにコンテンツを構造化する方法を定義します。
When two independent parties want to evaluate an electronic signature, it is fundamental that they get the same result. This requirement can be met using comprehensive signature policies that ensure consistency of signature validation. Signature policies can be identified implicitly by the data being signed, or they can be explicitly identified using the CAdES-EPES form of electronic signature; the CAdES-EPES mandates a consistent signature policy must be used by both the signer and verifier.
2つの独立した当事者が電子署名を評価したい場合、同じ結果を得ることが基本です。この要件は、署名検証の一貫性を確保する包括的な署名ポリシーを使用して満たすことができます。署名ポリシーは、署名されているデータによって暗黙的に識別されるか、電子署名のCades-EPES形式を使用して明示的に識別することができます。Cades-Epesは、署名者とVerifierの両方が使用する必要がある一貫した署名ポリシーを義務付けています。
By signing over the Signature Policy Identifier in the CAdES-EPES, the signer explicitly indicates that he or she has applied the signature policy in creating the signature.
Cades-Epesの署名ポリシー識別子に署名することにより、署名者は、署名の作成に署名ポリシーを適用したことを明示的に示します。
In order to unambiguously identify the details of an explicit signature policy that is to be used to verify a CAdES-EPES, the signature, an identifier, and hash of the "Signature policy" 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リファレンス）は、署名ポリシー識別子に「予選」として伝えることができます。
In order to unambiguously identify the authority responsible for defining an explicit signature policy, the "Signature policy" can be signed.
明示的な署名ポリシーを定義する責任のある当局を明確に特定するために、「署名ポリシー」に署名することができます。
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 type indications may be subject to signer and verifier agreement, specified as part of the signature policy or registered for generic use across multiple policies.
指定されたコミットメントタイプが電子署名の「コミットメントタイプの表示」を使用して明示的である場合、検証された署名の受け入れは、そのコミットメントタイプのセマンティクスの受け入れを意味します。明示的なコミットメントタイプの適応症のセマンティクスは、署名ポリシーの一部として指定されている署名者および検証者契約の対象である場合があります。
If a CAdES-EPES electronic signature format is used and the electronic signature includes a commitment type indication other than one of those recognized under the signature policy, the signature shall be treated as invalid.
Cades-EPES電子署名形式が使用され、電子署名に署名ポリシーに基づいて認識されているものの1つ以外のコミットメントタイプの表示が含まれている場合、署名は無効として扱われます。
How commitment is indicated using the semantics of the data being signed is outside the scope of the present 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 that is a commitment made by the signer because the data being signed over has specific semantics (meaning), which is only interpretable by humans, (i.e., free text).
- 署名されているデータには特定のセマンティクス（意味）があるため、署名者が行ったコミットメントである暗黙のコミットメントは、人間（つまり、無料のテキスト）によってのみ解釈可能です。
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 citizen of a nation 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 that multiple private keys are used, it is necessary for the signer to indicate to the verifier the precise certificate to be used.
多くの実際の環境では、ユーザーは異なるCAまたは同じCAから、同じ公開キーを含む異なる名前を含む異なる証明書からでも取得できます。主な利点は、ユーザーが異なる目的で同じ秘密鍵を使用できることです。スマートカードの保管は常に制限されているため、秘密鍵を複数使用すると、スマートカードが秘密鍵を保護するために使用される場合に利点があります。複数のCAが関与している場合、それぞれの異なる証明書には、国の市民として、または会社の従業員として、異なるアイデンティティが含まれている場合があります。したがって、さまざまな目的で秘密鍵を使用する場合、署名を生成するときに秘密鍵が使用されたコンテキストを明確にするために証明書が必要です。複数のプライベートキーが使用される可能性がある場合、署名者が使用する正確な証明書を検証器に示す必要があります。
Many current schemes simply add the certificate after the signed data and thus are vulnerable to substitution attacks. If the certificate from the signer was simply appended to the signature and thus not protected by the signature, anyone could substitute one certificate for another, and the message would appear to be signed by someone else. In order to counter this kind of attack, the identifier of the signer has to be protected by the digital signature from the signer.
多くの現在のスキームは、署名されたデータの後に証明書を単に追加するため、代替攻撃に対して脆弱です。署名者からの証明書が署名に単に追加され、署名によって保護されていない場合、誰でも1つの証明書を別の証明書に置き換えることができ、メッセージは他の誰かによって署名されているように見えます。この種の攻撃に対抗するために、署名者の識別子は、署名者からのデジタル署名によって保護されなければなりません。
In order to unambiguously identify the certificate to be used for the verification of the signature, an identifier of the certificate from the signer shall be part of the signed data.
署名の検証に使用される証明書を明確に特定するために、署名者からの証明書の識別子は、署名されたデータの一部でなければなりません。
While the name of the signer is important, the position of the signer within a company or an organization is of paramount importance as well. Some information (i.e., a contract) may only be valid if signed by a user in a particular role, e.g., a Sales Director. In many cases, who the sales Director really is, is not that important, but being sure that the signer is empowered by his company to be the Sales Director is fundamental.
署名者の名前は重要ですが、会社または組織内の署名者の立場も最も重要です。一部の情報（つまり、契約）は、特定の役割でユーザーが署名した場合にのみ有効です。たとえば、セールスディレクター。多くの場合、セールスディレクターが実際に誰であるかはそれほど重要ではありませんが、署名者が彼の会社からセールスディレクターになることが基本的であることを確認することです。
The present 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 an 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 identity certificate. However, it was decided not to follow this approach as it significantly complicates the management of certificates. For example, by using separate certificates for the signer's identity and roles means new identity keys need not be issued if a user's role changes.
注：別の可能なアプローチは、署名者の身元証明書にロール名名を含む追加の属性を使用することでした。ただし、証明書の管理を大幅に複雑にするため、このアプローチに従わないことが決定されました。たとえば、署名者の身元と役割に個別の証明書を使用することにより、ユーザーの役割が変更された場合、新しいIDキーを発行する必要がないことを意味します。
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, in most cases, might be under the control of an organization or a company that is best placed to know which attributes are relevant for which individual. 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 be 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, 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によって発行されるのではなく、属性権限（AA）によって発行されます。属性当局は、ほとんどの場合、どの属性がどの属性に関連しているかを知るのに最適な組織または会社の管理下にある可能性があります。属性当局は、CAに適切な信頼が置かれる場合がある場合、CAが発行した公開キー証明書を使用または指している場合があります。属性証明書には、さまざまな期間の有効性がある場合があります。その期間は非常に短いかもしれません。たとえば、いつか。これには、その日に有効な新しい属性証明書を毎日取得する必要がありますが、そのような証明書の取り消しは必要ない場合があるため、これは有利です。署名時に、署名者は選択する属性証明書を指定する必要があります。そのためには、署名者からのデジタル署名によって保護されるために、属性証明書を署名されたデータに含める必要があります。
In order to unambiguously identify the attribute certificate(s) to be used for the verification of the signature, an identifier of the attribute certificate(s) from the signer shall 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 shall 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 present document provides the capability to include a claimed signing time as an attribute of an electronic signature.
現在のドキュメントは、電子署名の属性として請求された署名時間を含める機能を提供します。
Using this attribute, a signer may sign over a time that is the claimed signing time. When an ES with Time is created (CAdES-T), then either a trusted time-stamp is obtained and added to the ES or a trusted time-mark exists in an audit trail. When a verifier accepts a signature, the two times shall be within acceptable limits.
この属性を使用して、署名者は、署名された時間である時間にわたって署名することができます。時間のあるESが作成されると（Cades-T）、信頼できるタイムスタンプが取得され、ESに追加されるか、監査証跡に信頼できるタイムマークが存在します。検証者が署名を受け入れる場合、2回は許容できる制限内になります。
A further optional attribute is defined in the present document to time-stamp the content and to provide proof of the existence of the content, at the time indicated by the time-stamp token.
現在のドキュメントでは、コンテンツをタイムスタンプし、タイムスタンプトークンで示されたコンテンツの存在の証拠を提供するために、さらにオプションの属性が定義されています。
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 online connection to a trusted time-stamping service before generating the signature and may not represent the precise signing time, since it can be obtained in advance. 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 Section 5.11.4).
このオプションの属性を使用して、ドキュメントが署名され、デジタル署名の下に含まれる前に、信頼できる安全時間を取得することができます。このソリューションには、署名を生成する前に信頼できるタイムスタンプサービスへのオンライン接続が必要であり、事前に取得できるため、正確な署名時間を表すことはできません。ただし、このオプションの属性は、署名者がタイムスタンプに含まれる日付の前に署名されたオブジェクトが存在することを証明するために使用できます（セクション5.11.4を参照）。
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 when data (as opposed to data that has been further signed or encrypted) is encapsulated in the SignedData (indicated by the eContentType within EncapsulatedContentInfo being set to id-data), further typing information should be used to identify the type of document being signed. This is generally achieved using the MIME content typing and encoding mechanism defined in RFC 2045 [6]). Further information on the use of MIME is given in Annex F.
署名入りデータを人間のユーザーに提示する場合、依存者に署名された情報の提示に関して曖昧さがないことが重要かもしれません。適切な表現（テキスト、サウンド、またはビデオ）が依存パーティによって選択されるために、データ（さらに署名または暗号化されたデータとは対照的に）がsignedDataにカプセル化されている場合（contulatedContentInfo内のecontentTypeによって示されます。id-dataに）、さらに入力する情報を使用して、署名されているドキュメントのタイプを識別する必要があります。これは一般に、RFC 2045 [6]で定義されたMIMEコンテンツのタイピングとエンコードメカニズムを使用して達成されます。MIMEの使用に関する詳細については、付録Fに記載されています。
The contents-hints attribute provides information on the innermost signed content of a multi-layer message where one content is encapsulated in another. This may be useful if the signed data is itself encrypted.
コンテンツヒント属性は、あるコンテンツが別のコンテンツにカプセル化されているマルチレイヤーメッセージの最も内側の符号付きコンテンツに関する情報を提供します。これは、署名されたデータ自体が暗号化されている場合に役立つ場合があります。
When presenting a signed data is in relation to another signed data, it may be important to identify the signed data to which it relates. The content-reference and content-identifier attributes, as defined in ESS (RFC 2634 [5]), provide the ability to link a request and reply messages in an exchange between two parties.
署名されたデータを提示する場合、別の署名されたデータに関連している場合、それが関連する署名されたデータを識別することが重要かもしれません。ESS（RFC 2634 [5]）で定義されているように、コンテンツリファレンスおよびコンテンツ識別子の属性は、2つの当事者間の交換でリクエストメッセージと返信メッセージをリンクする機能を提供します。
A verifier will have to ascertain 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 online certificate status server (for example, obtained through the OCSP protocol).
- オンライン証明書ステータスサーバーからの回答（たとえば、OCSPプロトコルを介して取得）を使用します。
NOTE 1: The time of the signature may not be known, so time-stamping or time-marking may be used to provide the time indication of when it was known that the signature existed.
注1：署名の時間がわからない可能性があるため、署名が存在したことがわかった時期を示すために、タイムスタンプまたはタイムマークを使用することができます。
NOTE 2: When validating an electronic signature and checking revocation status information, if a "grace period" is required, it needs to be suitably long enough to allow the involved authority to process a "last-minute" revocation request and for the request to propagate through the revocation system. This grace period is to be added to the time included with the time-stamp token or the time-mark, and thus the revocation status information should be captured after the end of the grace period.
注2：電子署名を検証して失効ステータス情報をチェックする場合、「恵み期間」が必要な場合は、関係する権限が「土壇場」の失効リクエストを処理し、リクエストを処理できるようにする必要があります。取り消しシステムを通じて伝播します。この猶予期間は、タイムスタンプトークンまたはタイムマークに含まれる時間に追加されるため、猶予期間の終了後に取り消しステータス情報をキャプチャする必要があります。
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. However, a "grace period" is required to allow CAs time to process revocation requests.
CRLSを使用して取り消し情報を取得する場合、検証者は、最初の検証の時点で、署名者のCAから適切な証明書の取り消し情報を取得することを確認する必要があります。これは、署名の生成と検証の間の時間遅延を最小限に抑えるためにできるだけ早く行う必要があります。ただし、CASの時間が取り消しリクエストを処理できるようにするには、「猶予期間」が必要です。
For example, a revocation request may arrive at a CA just before issuing the next CRL, and there may not enough time to include the revised revocation status information. This involves checking that the signer certificate serial number is not included in the CRL. Either the signer, the initial verifier, or a subsequent verifier may obtain this CRL. If obtained by the signer, then it shall be conveyed to the verifier. It may be convenient to archive the CRL for ease of subsequent verification or arbitration. Alternatively, provided the CRL is archived elsewhere, which is accessible for the purpose of arbitration, then the serial number of the CRL used may be archived together with the verified electronic signature as a CAdES-C form.
たとえば、取り消し要求は、次のCRLを発行する直前にCAに到着する場合があり、改訂された取り消しステータス情報を含めるのに十分な時間がない場合があります。これには、署名者証明書のシリアル番号がCRLに含まれていないことを確認することが含まれます。署名者、初期検証剤、または後続の検証者のいずれかがこのCRLを取得できます。署名者によって取得された場合、それは検証者に伝えられます。その後の検証または仲裁を容易にするために、CRLをアーカイブするのが便利かもしれません。あるいは、仲裁の目的でアクセス可能なCRLが他の場所にアーカイブされている場合、使用されるCRLのシリアル番号は、Cades-Cフォームとして検証された電子署名とともにアーカイブできます。
Even if the certificate serial number appears in the CRL with the status "suspended" (i.e., on hold), the signature is not to be deemed as valid since a suspended certificate is not supposed to be used even by its rightful owner.
ステータス「停止」（つまり、保留中）があるCRLに証明書のシリアル番号が表示されたとしても、署名は正当な所有者でさえも使用されていないため、中断された証明書は使用されないため、有効とはみなされません。
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, still providing a "grace period" suitable enough to allow the involved authority to process a "last-minute" revocation request. The signer, the verifier, or any other third party may fetch this OCSP response. Since OCSP responses are transient and thus are not archived by any TSP, including CA, it is the responsibility of every verifier to make sure that it is stored in a safe place. The simplest way is to store them associated with the electronic signature. An alternative would be to store them so that they can then be easily retrieved and incorporate references to them in the electronic signature itself as a CAdES-C form.
OCSPを使用して取り消し情報を取得する場合、検証剤は、最初の検証の時点で、ステータス「有効」を含むOCSP応答を取得する必要があります。これは、署名の生成後もできるだけ早く行う必要がありますが、関連する権限が「土壇場」の取り消しリクエストを処理できるように十分な「恵み期間」を提供します。署名者、検証者、または他の第三者は、このOCSP応答を取得できます。OCSP応答は一時的であるため、CAを含むTSPによってアーカイブされないため、安全な場所に保管されることを確認することは、すべての検証者の責任です。最も簡単な方法は、電子署名に関連付けられているものを保存することです。別の方法は、それらを保存することで、それらを簡単に取得し、Cades-Cフォームとして電子署名自体にそれらへの参照を組み込むことができます。
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". In such a case, the same comment as for the CRL applies.
CRLの場合と同じように、証明書は無効であると宣言されているが、二次的なステータスが「中断」されていると宣言される可能性があります。そのような場合、CRLと同じコメントが適用されます。
A verifier may have to ascertain that the certification path was valid, at the time of the signature, up to a trust point, according to the:
検証器は、署名時に、信託ポイントまでの認定パスが有効であることを確認する必要がある場合があります。
- naming constraints; - certificate policy constraints; - signature policy, when applicable.
- 命名制約; - 証明書のポリシーの制約。 - 該当する場合、署名ポリシー。
Since the time of the signature cannot be known with certainty, an upper limit of it should be used as indicated by either the time-stamp or time-mark.
署名の時間は確実に知らないため、その上限は、タイムスタンプまたはタイムマークのいずれかで示されるように使用する必要があります。
In this case, it will be necessary to capture all the certificates from the certification path, starting with those from the signer and ending up with those of the self-signed certificate from one trusted root; when applicable, this may be specified as part of the Signature Policy. In addition, it will be necessary to capture the Certificate Authority Revocation Lists (CARLs) to prove that none of the CAs from the chain were revoked at the time of the signature. Again, all this material may be incorporated in the electronic signature (ES X forms). An alternative would be to store this information so that it can be easily retrieved and incorporate references to it in the electronic signature itself as a CAdES-C form.
この場合、署名者からのものから始めて、1つの信頼できるルートからの自己署名証明書の証明書から始めて、認定パスからすべての証明書をキャプチャする必要があります。該当する場合、これは署名ポリシーの一部として指定される場合があります。さらに、Certifical Authority Authority Rococation List（CARLS）をキャプチャして、署名時にチェーンのCASが取り消されなかったことを証明する必要があります。繰り返しますが、この資料はすべて、電子署名（ES Xフォーム）に組み込まれる場合があります。別の方法は、この情報を簡単に取得し、Cades-Cフォームとして電子署名自体に参照を組み込むことができるように保存することです。
An important property for long-standing signatures is that a signature, having been found once to be valid, shall 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 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 the signer's certificate and all the CA certificates used to form a valid certification path were not revoked when the signature was created or verified.
署名者、検証者、またはその両方が、リクエストに応じて、証明書パスを構成するすべての証明書の有効期間中にデジタル署名が作成または検証されたことを証明する必要がある場合があります。この場合、署名者の証明書と有効な認証パスを形成するために使用されるすべての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 were valid at 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 shall 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 had been created before the certificate 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. Any time-stamp or time-mark that is taken after the expiration date of any certificate in the certification path has no value in proving the validity of a signature.
受信者が有効な電子署名を保持したい場合、そのキー（および検証に関与するキー）が取り消される前に、彼が有効なタイムスタンプを取得したことを確認する必要があります。署名時間の後にタイムスタンプが早く取得されるほど、より良くなります。認定パスの証明書の有効期限後に撮影されるタイムスタンプまたはタイムマークは、署名の有効性を証明することに価値がありません。
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 Basic Electronic Signature, but it is the essential component of the ES with Time.
タイムスタンプは、基本的な電子署名のコンポーネントではありませんが、ESの重要なコンポーネントです。
It is required, in the present document, that if a signer's digital signature value is to be time-stamped, the time-stamp token is issued by a trusted source, known as a Time-Stamping Authority.
現在の文書では、署名者のデジタル署名値がタイムスタンプである場合、タイムスタンプトークンは、タイムスタンプ機関として知られる信頼できるソースによって発行されることが必要です。
The present document requires that the signer's digital signature value be time-stamped by a trusted source before the electronic signature can become an ES with Complete validation data. Acceptable TSAs may be specified in a Signature Validation Policy.
現在のドキュメントでは、電子署名が完全な検証データを持つESになる前に、署名者のデジタル署名値が信頼できるソースによって時間刻み付けられることを要求しています。許容可能なTSAは、署名検証ポリシーで指定される場合があります。
This technique is referred to as CAdES-C in the present document.
この手法は、現在の文書ではCades-Cと呼ばれています。
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 at 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 present 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 (CAdES-X Type 1). This format is suitable to be used with an OCSP response, and it offers the additional advantage of providing an integrity protection over the whole data;
- signer（Cades-x Type 1）から証明書のステータスを取得するためにOCSP応答を使用した場合、完全な検証データを使用してESをタイムスタンプします。この形式は、OCSP応答で使用するのに適しており、データ全体にわたって整合性保護を提供するという追加の利点を提供します。
- 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 (CAdES-X Type2). This format is suitable to be used with CRLs, since the time-stamped information may be used for more than one signature (when signers have their certificates issued by the same CA and when signatures can be checked using the same CRLs).
- CRLを使用して署名者（Cades-X Type2）から証明書のステータスを取得するためにCRLを使用した場合の認定パスと取り消し情報の参照のみがタイムスタンプします。この形式は、タイムスタンプの情報が複数の署名に使用される場合があるため、CRLで使用するのに適しています（署名者が同じCAによって発行された証明書を持っている場合、および同じ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 revocation information references, which include the OCSP response, the time-stamp is placed on the CAdES-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. 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.
OCSP応答が使用される場合、特に、レスポンダーからのキーが侵害される場合の応答をタイムスタンプする必要があります。OCSP応答に含まれる情報はユーザー固有で時間固有のものであるため、受信したすべての署名に個別のタイムスタンプが必要です。OCSP応答を含む認定パス参照と取り消し情報参照の上にタイムスタンプを配置する代わりに、タイムスタンプはケードCに配置されます。認証パスおよび取り消し情報の参照は、完全な検証データを備えたESに含まれているため、保護されています。同じ暗号化価格で、これは完全な検証データを備えたES上の整合性メカニズムを提供します。変更はすぐに検出できます。完全な検証データを使用してESの整合性を保護/検出する他の手段が存在し、使用できることに注意する必要があります。この手法には、すべての署名に対してタイムスタンプが必要ですが、受け取ったすべての検証された署名の整合性保護されたコピーを持ちたい個々のユーザーに適しています。
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 CAdES-X Type 1 in the present document.
この手法は、現在のドキュメントではCades-X Type 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 CAdES-X Long Type 1, as defined by the present document.
A CAdES-X Long Type 1 is simply the concatenation of a CAdES-X Type 1, with a copy of the additional data being referenced.
Cades-X Long Type 1は、単にCades-X Type 1の連結であり、追加データのコピーが参照されています。
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 exist 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 that could be claimed to exist before the CA key was compromised.
タイムスタンピングCA証明書は、CAキーが侵害される前に存在すると主張される可能性のある偽のCA証明書を発行する攻撃者を妨げます。偽のタイムスタンプCA証明書は、正当なCAキーが侵害された後に証明書が作成されたことを示します。同様に、タイムスタンプCA CRLSは、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 be reduced to just one time-stamp per day (i.e., in the case where 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への明確な参照です。
This technique is referred to as CAdES-X Type 2 in the present document and requires the following:
この手法は、現在のドキュメントではCades-X Type 2と呼ばれ、以下が必要です。
- all the CA certificates references and revocation information references (i.e., CRLs) used in validating the CAdES-C are covered by one or more time-stamps.
- すべてのCA証明書の参照および取り消し情報参照（つまり、CRL）は、Cades-Cの検証に使用されます。
Thus, a CAdES-C with a time-stamp signature value at time T1 can be proved valid if all the CA and CRL references are time-stamped at time T1+.
したがって、すべてのCAおよびCRL参照が時間T1でタイムスタンプされている場合、時間T1にタイムスタンプの署名値を持つCades-Cを有効にすることができます。
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 possibility.
コンピューティングの進歩により、アルゴリズムを破り、キーを妥協できる可能性が高まります。したがって、この可能性から電子署名を保護できる要件があります。
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 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 matters, a single technique called Archive validation data, covering all the cases, is being used in the present document.
しばらくの間、電子署名の作成に使用される暗号化アルゴリズムでは、弱点が発生する可能性があります（たとえば、暗号分析に利用できる時間、または暗号分析技術の改善など）。このような弱点が可能になる前に、検証者は電子署名の妥当性を維持するために追加の措置を講じる必要があります。弱体化した暗号化の性質に応じて、この目標を達成するためにいくつかの手法を使用できます。問題を簡素化するために、すべてのケースをカバーするアーカイブ検証データと呼ばれる単一の手法が現在のドキュメントで使用されています。
Archive validation data consists of the 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 the Archived Electronic Signature are required.
アーカイブ検証データは、検証データと完全な証明書および取り消しデータで構成されており、電子署名とともにタイムスタンプされています。ハッシュ関数と署名の作成に使用された暗号アルゴリズムがもはや安全ではない場合、アーカイブ検証データが必要です。また、タイムスタンプ機関が使用するハッシュ関数が安全であると想定できない場合は、アーカイブされた電子署名のネストされたタイムスタンプが必要です。
The potential for a 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 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 the present document was at least 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.
プロセスは、以前のタイムスタンプを生成するために使用される暗号化アルゴリズムが安全ではなくなる前に、実行および繰り返す必要があります。したがって、アーカイブ検証データには、複数の埋め込まれたタイムスタンプが付いている場合があります。
This technique is referred to as CAdES-A in the present document.
この手法は、現在の文書ではCades-Aと呼ばれています。
Using CAdES-X Type 1 or CAdES-X Type 2 extended validation data, verifiers still need 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 (CAdES-C) is adequate. The actual certificates and CRL information reference in the CAdES-C can be gathered when needed for arbitration.
Cades-X Type 1またはCades-X Type 2拡張検証データを使用して、Verifiersは、後で再び取得できるように、署名を検証するために使用されたすべてのコンポーネントを追跡する必要があります。これらのコンポーネントは、信頼できるサービスプロバイダーのような外部ソースによってアーカイブされる場合があります。その場合、完全な検証データ（Cades-C）を持つESの一部として提供される参照情報（Cades-C）は適切です。Cades-Cの実際の証明書とCRL情報リファレンスは、仲裁に必要なときに収集できます。
If references to additional data are not adequate, then the actual values of all the certificates and revocation information required may be part of the electronic signature. This technique is referred to as CAdES-X Long Type 1 or CAdES-X Long Type 2 in the present document.
追加データへの参照が適切でない場合、必要なすべての証明書と取り消し情報の実際の値は、電子署名の一部である可能性があります。この手法は、現在のドキュメントでは、Cades-X Long Type 1またはCades-X Long Type 2と呼ばれます。
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つの当事者によって署名されます。署名者と検証者のデータをタイムスタンプするには、2つのアプローチが可能です。
- under the terms of the contract, a predefined 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.
- 両方の組織が独自のタイムスタンピングサービスを実行している場合、AとBは、これら2つのタイムスタンプサービスによってトランザクションをタイムスタンプすることができます。
In the latter case, the electronic signature will only be considered 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. Therefore, A and B do not need to agree on a common "trusted" TSA to get a valid transaction.
後者の場合、電子署名は、両方のタイムスタンプが期限内に取得された場合にのみ有効と見なされます（つまり、2つのタイムスタンプを取得するまでに長い遅延はありません）。したがって、AもBも、自分の時間刻みサービスによって示される署名時間を拒否することはできません。したがって、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 be 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 described above be used. This may be part of a mutually agreed Signature Validation Policy that is part of an agreed signature policy under which digital signatures 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, there is minimal likelihood of compromise over as long as a possible period. Thus, the validity period for the TSA's keys should be as long as possible.
TSAサーバーは、プライベート署名キーがインストールされると、可能な期間で妥協の可能性が最小限に抑えられるように構築する必要があります。したがって、TSAのキーの妥当性期間はできるだけ長くなければなりません。
Both the CAdES-T and the CAdES-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 CAdES-A should be used. For extremely long periods, this may be applied repeatedly using new TSA keys.
Cades-TとCades-Cの両方に、署名者の署名の上に少なくとも1つのタイムスタンプが含まれています。そのタイムスタンプを作成するために使用されるプライベート署名キーの妥協から保護するために、別のタイムスタンプ機関キーが追加されて追加のタイムスタンプを生成する場合、アーカイブ検証データを使用できます。以前のタイムスタンプの提供に使用されるTSAキーがこれまでに妥協される可能性があると考えられている場合（例：その有効期間以外）、Cades-Aを使用する必要があります。非常に長い間、これは新しいTSAキーを使用して繰り返し適用できます。
This technique is referred to as a nested CAdES-A in the present document.
この手法は、本文書のネストされたケードAと呼ばれています。
Some electronic signatures may only be valid if they bear more than one signature. This is generally the case 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.
一部の電子署名は、複数の署名を負担した場合にのみ有効です。これは通常、2つの当事者間で契約が署名された場合です。署名の順序は重要である場合とそうでない場合があります。つまり、一方を他方より前に適用する必要がある場合とそうでない場合があります。
Several forms of multiple and counter signatures need to be supported, which fall into two basic categories:
複数の署名のいくつかの形式をサポートする必要があります。これは、2つの基本的なカテゴリに分類されます。
- independent signatures; - embedded signatures.
- 独立した署名; - 組み込み署名。
Independent signatures are parallel signatures where the ordering of the signatures is not important. The capability to have more than one independent signature over the same data shall be provided.
独立した署名は、署名の順序付けが重要ではない並列署名です。同じデータ上に複数の独立した署名を持つ機能が提供されます。
Embedded signatures are applied one after the other and are used where the order in which the signatures are applied is important. The capability to sign over signed data shall be provided.
埋め込まれた署名は次々と適用され、署名が適用される順序が重要な場合に使用されます。署名されたデータに署名する機能が提供されます。
These forms are described in Section 5.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 occurrences of the above two cases.
これらのフォームは、セクション5.13で説明されています。他のすべての複数の署名スキーム、例えば、countersignature、二重のcountersignatures、または複数の署名を備えた署名ドキュメントは、上記の2つのケースの1つ以上の発生に削減できます。
Annex D (Informative): Data Protocols to Interoperate with TSPs
付録D（情報）：TSPと相互操作するデータプロトコル
The following protocols can be used by signers and verifiers to interoperate with Trusted Service Providers during the electronic signature creation and validation.
次のプロトコルは、電子署名の作成と検証中に信頼できるサービスプロバイダーと相互操作するために、署名者と検証者によって使用できます。
User certificates, CA certificates, and cross-certificates can be retrieved from a repository using the Lightweight Directory Access Protocol as defined in RFC 3494 [RFC3494], with the schema defined in RFC 4523 [RFC4523].
ユーザー証明書、CA証明書、およびクロス認証は、RFC 3494 [RFC3494]で定義されているLightWeight Directory Access Protocolを使用してリポジトリから取得できます。RFC4523[RFC4523]でスキーマが定義されています。
Certificate revocation lists, including authority revocation lists and partial CRL variants, can be retrieved from a repository using the Lightweight Directory Access Protocol, as defined in RFC 3494 [RFC3494], with the schema defined in RFC 4523 [RFC4523].
RFC 3494 [RFC3494]で定義されているように、権限の取り消しリストや部分的なCRLバリアントを含む証明書の取り消しリストは、RFC 3494 [RFC3494]で定義されているように、軽量ディレクトリアクセスプロトコルを使用してリポジトリから取得できます。
As an alternative to the use of certificate revocation lists, the status of a certificate can be checked using the Online Certificate Status Protocol (OCSP), as defined in RFC 2560 [3].
証明書の取り消しリストの使用に代わるものとして、RFC 2560 [3]で定義されているように、証明書のステータスをオンライン証明書ステータスプロトコル（OCSP）を使用して確認できます。
The time-stamping service can be accessed using the Time-Stamping Protocol defined in RFC 3161 [7].
タイムスタンプサービスは、RFC 3161 [7]で定義されたタイムスタンププロトコルを使用してアクセスできます。
Signers and verifiers can use the following management protocols to manage the use of certificates.
署名者と検証者は、次の管理プロトコルを使用して、証明書の使用を管理できます。
Request for a certificate to be revoked can be made using the revocation request and response messages defined in RFC 4210 [RFC4210].
RFC 4210 [RFC4210]で定義されている取り消しリクエストと応答メッセージを使用して、証明書のリクエストを取り消すことができます。
Annex E (Informative): Security Considerations
付録E（情報）：セキュリティ上の考慮事項
The security of the electronic signature mechanism defined in the present document depends on the privacy of the signer's private key.
本文書で定義されている電子署名メカニズムのセキュリティは、署名者の秘密鍵のプライバシーに依存します。
Implementations should 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.
実装者は、暗号化アルゴリズムが時間とともに弱くなることに注意する必要があります。新しい暗号分析技術が開発され、コンピューティングのパフォーマンスが向上するにつれて、特定の暗号化アルゴリズムを破る作業要因が減少します。したがって、暗号化アルゴリズムの実装はモジュール式であり、新しいアルゴリズムを容易に挿入できるようにする必要があります。つまり、実装者は、時間の経過とともに変更するために、義務的なアルゴリズムのセットに備える必要があります。
Annex F (Informative): Example Structured Contents and MIME
付属書F（情報）：構造化された内容とmimeの例
The signed content may be structured using MIME (Multipurpose Internet Mail Extensions -- RFC 2045 [6]). Whilst the MIME structure was initially developed for Internet email, it has a number of features that make it useful to provide a common structure for encoding a range of electronic documents and other multi-media data (e.g., photographs, video). These features include:
署名されたコンテンツは、MIME（多目的インターネットメールエクステンション-RFC 2045 [6]）を使用して構成できます。MIME構造は最初はインターネットメール用に開発されましたが、さまざまな電子ドキュメントやその他のマルチメディアデータ（写真、ビデオなど）をエンコードするための共通の構造を提供するのに役立つ多くの機能があります。これらの機能には以下が含まれます。
- providing a means of signalling the type of "object" being carried (e.g., text, image, ZIP file, application data);
- 運ばれる「オブジェクト」のタイプを通知する手段（例：テキスト、画像、zipファイル、アプリケーションデータ）を提供します。
- providing a means of associating a file name with an object;
- ファイル名をオブジェクトに関連付ける手段を提供します。
- associating several independent objects (e.g., a document and image) to form a multi-part object;
- 複数の独立したオブジェクト（ドキュメントと画像など）を関連付けて、マルチパートオブジェクトを形成します。
- handling data encoded in text or binary and, if necessary, re-encoding the binary as text.
- テキストまたはバイナリでエンコードされたデータの処理、および必要に応じて、バイナリをテキストとして再エンコードします。
When encoding a single object, MIME consists of:
単一のオブジェクトをエンコードする場合、MIMEは以下で構成されます。
- header information, followed by;
- ヘッダー情報、続いて。
- encoded content.
- エンコードされたコンテンツ。
This structure can be extended to support multi-part content.
この構造は、マルチパートコンテンツをサポートするために拡張できます。
A MIME header includes:
MIMEヘッダーには以下が含まれます。
MIME Version information: e.g., MIME-Version: 1.0
MIMEバージョン情報：例えば、MIME-version：1.0
Content type information, which includes information describing the content sufficient for it to be presented to a user or application process, as required. This includes information on the "media type" (e.g., text, image, audio) or whether the data is for passing to a particular type of application. In the case of text, the content type includes information on the character set used, e.g., Content-Type: text/plain; charset="us-ascii".
コンテンツタイプ情報。これには、必要に応じて、ユーザーまたは申請プロセスに適切なコンテンツを説明する情報が含まれます。これには、「メディアタイプ」（テキスト、画像、オーディオなど）に関する情報、または特定のタイプのアプリケーションに渡すためのデータが含まれます。テキストの場合、コンテンツタイプには、使用される文字セットに関する情報、たとえばコンテンツタイプ：テキスト/プレーン。charset = "us-ascii"。
Content-encoding information, which defines how the content is encoded (see below about encoding supported by MIME).
コンテンツをエンコードする情報。コンテンツのエンコード方法を定義します（MIMEでサポートされているエンコードについては以下を参照）。
Other information about the content, such as a description or an associated file name.
説明や関連するファイル名など、コンテンツに関するその他の情報。
An example MIME header for text object is:
テキストオブジェクトのMIMEヘッダーの例は次のとおりです。
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
An example MIME header for a binary file containing a pdf document is:
PDFドキュメントを含むバイナリファイルのMIMEヘッダーの例は次のとおりです。
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Description: JCFV201.pdf
Content-Disposition: filename="JCFV201.pdf"
MIME supports a range of mechanisms for encoding both text and binary data.
MIMEは、テキストデータとバイナリデータの両方をエンコードするためのさまざまなメカニズムをサポートしています。
Text data can be carried transparently as lines of text data encoded in 7- or 8-bit ASCII characters. MIME also includes a "quoted-printable" encoding that converts characters other than the basic ASCII into an ASCII sequence.
テキストデータは、7ビットまたは8ビットASCII文字でエンコードされたテキストデータの行として透過的に伝達できます。MIMEには、基本的なASCII以外の文字をASCIIシーケンスに変換する「引用された印刷可能な」エンコードも含まれています。
Binary can either be carried:
バイナリは運ぶことができます：
- transparently as 8-bit octets; or
- 8ビットオクテットとして透過的に。また
- converted to a basic set of characters using a system called Base64.
- Base64と呼ばれるシステムを使用して、基本的な文字セットに変換されました。
NOTE: As there are some mail relays that can only handle 7-bit ASCII, Base64 encoding is usually used on the Internet.
注：7ビットASCIIのみを処理できるメールリレーがあるため、通常はインターネットでBase64エンコードが使用されます。
Several objects (e.g., text and a file attachment) can be associated together using a special "multi-part" content type. This is indicated by the content type "multipart" with an indication of the string to be used indicating a separation between each part.
いくつかのオブジェクト（テキストやファイルの添付ファイルなど）は、特別な「マルチパート」コンテンツタイプを使用して一緒に関連付けることができます。これは、各部品間の分離を示す文字列を示す文字列を示すコンテンツタイプ「マルチパート」で示されます。
In addition to a header for the overall multipart content, each part includes its own header information indicating the inner content type and encoding.
全体的なマルチパートコンテンツのヘッダーに加えて、各部品には、内部コンテンツの種類とエンコードを示す独自のヘッダー情報が含まれています。
An example of a multipart content is:
マルチパートコンテンツの例は次のとおりです。
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----
=_NextPart_000_01BC4599.98004A80"
Content-Transfer-Encoding: 7bit
------=_NextPart_000_01BC4599.98004A80
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Per your request, I've attached our proposal for the Java Card Version 2.0 API and the Java Card FAQ.
あなたのリクエストに従って、私はJavaカードバージョン2.0 APIとJavaカードFAQの提案を添付しました。
------=_NextPart_000_01BC4599.98004A80
Content-Type: application/pdf; name="JCFV201.pdf"
Content-Transfer-Encoding: base64
Content-Description: JCFV201.pdf
Content-Disposition: attachment; filename="JCFV201.pdf"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA////////////////////////////// //////////AANhAAQAYg==
==
------=_NextPart_000_01BC4599.98004A80--
Multipart content can be nested. So a set of associated objects (e.g., HTML text and images) can be handled as a single attachment to another object (e.g., text).
マルチパートコンテンツはネストできます。そのため、関連するオブジェクトのセット（HTMLテキストや画像など）は、別のオブジェクト（テキストなど）への単一の添付ファイルとして処理できます。
The Content-Type from each part of the S/MIME message indicates the type of content.
S/MIMEメッセージの各部分からのコンテンツタイプは、コンテンツのタイプを示します。
The specific use of MIME to carry CMS (extended as defined in the present document) secured data is called S/MIME (see [RFC3851]).
CMSを運ぶためのMIMEの特定の使用（現在のドキュメントで定義されているように拡張された）保護されたデータは、S/MIMEと呼ばれます（[RFC3851]を参照）。
S/MIME carries electronic signatures as either:
s/mimeは、次のように電子署名を運びます
- an "application/pkcs7-mime" object with the CMS carried as a binary attachment (PKCS7 is the name of the early version of CMS).
- CMSを備えた「アプリケーション/PKCS7-MIME」オブジェクトは、バイナリアタッチメントとして運ばれます（PKCS7はCMSの初期バージョンの名前です）。
The signed data may be included in the SignedData, which itself may be included in a single S/MIME object. See [RFC3851], Section 3.4.2: "Signing Using application/pkcs7-mime with SignedData" and Figure F.1 hereafter.
署名されたデータは、SignedDataに含まれる場合があります。これは、単一のS/MIMEオブジェクトに含まれる場合があります。[RFC3851]、セクション3.4.2：「SignedDataを使用したアプリケーション/PKCS7-MIMEを使用した署名」および図F.1を参照してください。
or
また
- a "multipart/signed" object with the signed data and the signature encoded as separate MIME objects.
- 署名されたデータと個別のMIMEオブジェクトとしてエンコードされた署名を使用した「MultiPart/署名された」オブジェクト。
The signed data is not included in the SignedData, and the CMS structure only includes the signature. See [RFC3851], Section 3.4.3: "Signing Using the multipart/signed Format" and Figure F.2 hereafter.
署名されたデータはSignedDataには含まれておらず、CMS構造には署名のみが含まれます。[RFC3851]、セクション3.4.3：「マルチパート/署名形式を使用した署名」および図F.2以下を参照してください。
+-------------++----------++-------------++------------+
| || || || |
| S/MIME || CAdES || MIME || pdf file |
| || || || |
|Content-Type=||SignedData||Content-Type=||Dear MrSmith|
|application/ || eContent ||application/ ||Received |
|pkcs7-mime || ||pdf || 100 tins |
| || || || |
|smime-type= || /| || /| || Mr.Jones |
|signed-data || / -----+ / ------+ |
| || \ -----+ \ ------+ |
| || \| || \| |+------------+
| || |+-------------+
| |+----------+
+-------------+
Figure F.1: Signing Using application/pkcs7-mime
図F.1：アプリケーション/PKCS7-MIMEを使用した署名
This approach is similar to handling signed data as any other binary file attachment.
このアプローチは、他のバイナリファイル添付ファイルと同様に、署名データの処理に似ています。
An example of signed data encoded using this approach is:
このアプローチを使用してエンコードされた署名されたデータの例は次のとおりです。
Content-Type: application/pkcs7-mime; smime-type=signed-data;
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75
CMS also supports an alternative structure where the signature and data being protected are separate MIME objects carried within a single message. In this case, the signed data is not included in the SignedData, and the CMS structure only includes the signature. See [RFC3851], Section 3.4.3: "Signing Using the multipart/signed Format" and Figure F.2 hereafter.
CMSは、保護されている署名とデータが単一のメッセージ内で運ばれる個別のMIMEオブジェクトである代替構造もサポートしています。この場合、署名されたデータはSignedDataに含まれておらず、CMS構造には署名のみが含まれます。[RFC3851]、セクション3.4.3：「マルチパート/署名形式を使用した署名」および図F.2以下を参照してください。
An example of signed data encoded using this approach is:
このアプローチを使用してエンコードされた署名されたデータの例は次のとおりです。
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
--boundary42
Content-Type: text/plain
This is a clear-signed message.
これは明確なメッセージです。
--boundary42
-boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
--boundary42--
-boundary42---
With this second approach, the signed data passes through the CMS process and is carried as part of a multiple-parts signed MIME structure, as illustrated in Figure F.2. The CMS structure just holds the electronic signature.
この2番目のアプローチにより、署名されたデータはCMSプロセスを通過し、図F.2に示すように、複数部の署名されたMIME構造の一部として運ばれます。CMS構造は、電子署名を保持するだけです。
+---------------++----------++-------------++------------+
| || || || |
| MIME || CAdES || MIME || pdf file |
| || || || |
|Content-Type= ||SignedData||Content-Type=||Dear MrSmith|
|multipart/ || ||application/ ||Received |
|signed || ||pdf || 100 tins |
| /| || || || |
| / -------------------+ /| || Mr.Jones |
| \ -------------------+ / -----+ |
| \| || || \ -----+ |
|Content-Type= || || \| |+------------+
|application/ || |+-------------+
|pdf || |
| || |
|Content-Type= || |
|application/ || |
|pkcs7-signature|| |
| || |
| /| || |
| / -------+ |
| \ -------+ |
| \| ||----------+
| |
+---------------+
Figure F.2: Signing Using application/pkcs7-signature
図F.2：Application/PKCS7-Signatureを使用した署名
This second approach (multipart/signed) has the advantage that the signed data can be decoded by any MIME-compatible system even if it does not recognize CMS-encoded electronic signatures.
この2番目のアプローチ（MultiPart/署名）には、CMSエンコードされた電子署名を認識していなくても、MIME互換システムによって署名されたデータをデコードできるという利点があります。
Annex G (Informative): Relationship to the European Directive and EESSI
付録G（情報）：欧州指令とEessiとの関係
This annex provides an indication of the relationship between electronic signatures created under the present document and requirements under the European Parliament and Council Directive on a Community framework for electronic signatures.
この付属書は、現在の文書の下で作成された電子署名と、欧州議会の下で要件と、電子署名に関するコミュニティフレームワークに関する評議会指令の間の関係を示しています。
NOTE: Legal advice should be sought on the specific national legislation regarding use of electronic signatures.
注：電子署名の使用に関する特定の国家法については、法的助言を求める必要があります。
The present document is one of a set of standards that has been defined under the "European Electronic Signature Standardization Initiative" (EESSI) for electronic signature products and solutions compliant with the European Directive for Electronic Signatures.
現在の文書は、電子署名製品と電子署名の欧州指令に準拠したソリューションのための「欧州電子署名標準化イニシアチブ」（EESSI）の下で定義されている一連の基準の1つです。
This directive defines electronic signatures as:
この指令は、電子署名を次のように定義しています。
- "data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication".
- 「他の電子データに添付されている、または論理的に関連付けられており、認証方法として機能する電子形式のデータ」。
The directive states that an electronic signature should not be denied "legal effectiveness and admissibility as evidence in legal proceedings" solely on the grounds that it is in electronic form.
この指令は、電子署名は、「法的手続きの証拠としての法的有効性と容認性」を電子形式であるという理由だけで拒否されるべきではないと述べています。
The directive identifies an electronic signature as having equivalence to a hand-written signature if it meets specific criteria:
指令は、特定の基準を満たしている場合、手書きの署名と同等の電子署名を識別します。
- it is an "advanced electronic signature" with the following properties:
- これは、次のプロパティを備えた「高度な電子署名」です。
a) it is uniquely linked to the signatory;
a) それは署名者と一意にリンクしています。
b) it is capable of identifying the signatory;
b) 署名者を特定することができます。
c) it is created using means that the signatory can maintain under his sole control; and
c) これは、署名者が唯一のコントロールの下で維持できることを意味します。と
d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable.
d) これは、データのその後の変更が検出可能であるような方法で関連するデータにリンクされています。
- it is based on a certificate that meets detailed criteria given in Annex I of the directive and is issued by a "certification-service-provider" that meets requirements given in Annex II of the directive. Such a certificate is referred to as a "qualified certificate";
- これは、指令の付属書Iに記載されている詳細な基準を満たす証明書に基づいており、指令の付録IIで与えられた要件を満たす「認定サービスプロバイダー」によって発行されます。このような証明書は、「資格のある証明書」と呼ばれます。
- it is created by a "device", for which detailed criteria are given in Annex III of the directive. Such a device is referred to a "secure-signature-creation device".
- これは、「デバイス」によって作成されており、ディレクティブの付録IIIに詳細な基準が提供されています。このようなデバイスは、「安全な署名 - 作成デバイス」と呼ばれます。
This form of electronic signature is referred to as a "qualified electronic signature" in EESSI (see below).
この形式の電子署名は、Eessiの「資格のある電子署名」と呼ばれます（以下を参照）。
An electronic signature created in accordance with the present document is:
現在の文書に従って作成された電子署名は次のとおりです。
a) considered to be an "electronic signature" under the terms of the Directive;
a) 指令の条件に基づく「電子署名」と見なされる。
b) considered to be an "advanced electronic signature" under the terms of the Directive;
b) 指令の条件に基づく「高度な電子署名」と見なされる。
c) considered to be a "Qualified Electronic Signature", provided the additional requirements in Annex I, II, and III of the Directive are met. The requirements in Annex I, II, and III of the Directive are outside the scope of the present document, and are subject to standardization elsewhere.
c) 指令の付録I、II、およびIIIの追加要件が満たされている場合、「適格な電子署名」と見なされます。指令の付録I、II、およびIIIの要件は、現在の文書の範囲外であり、他の場所で標準化の対象となります。
EESSI looks at standards in several areas. See the ETSI and CEN web sites for the latest list of standards and their versions:
Eessiは、いくつかの分野で標準を調べています。標準の最新リストとそのバージョンについては、ETSIおよびCEN Webサイトを参照してください。
- use of X.509 public key certificates as qualified certificates;
- 資格のある証明書としてのX.509公開証明書の使用。
- security Management and Certificate Policy for CSPs Issuing Qualified Certificates;
- 資格のある証明書を発行するCSPのセキュリティ管理と証明書ポリシー。
- security requirements for trustworthy systems used by CSPs Issuing Qualified Certificates;
- 資格のある証明書を発行するCSPが使用する信頼できるシステムのセキュリティ要件。
- security requirements for Secure Signature Creation Devices;
- 安全な署名作成デバイスのセキュリティ要件。
- security requirements for Signature Creation Systems;
- 署名作成システムのセキュリティ要件。
- procedures for Electronic Signature Verification;
- 電子署名検証の手順。
- electronic signature syntax and encoding formats;
- 電子署名の構文とエンコード形式。
- protocol to interoperate with a Time-Stamping Authority;
- タイムスタンプ機関と相互運用するプロトコル。
- Policy requirements for Time-Stamping Authorities; and
- タイムスタンピング当局のポリシー要件。と
- XML electronic signature formats.
- XML電子署名形式。
Each of these standards addresses a range of requirements, including the requirements of Qualified Electronic Signatures, as specified in Article 5.1 of the Directive. However, some of them also address general requirements of electronic signatures for business and electronic commerce, which all fall into the category of Article 5.2 of the Directive. Such variation in the requirements may be identified either as different levels or different options.
これらの各標準は、指令の第5.1条に指定されているように、適格な電子署名の要件を含む、さまざまな要件に対処しています。ただし、それらのいくつかはまた、ビジネスおよび電子商取引のための電子署名の一般的な要件にも対処しています。これらはすべて、指令5.2のカテゴリに分類されます。要件のこのような変動は、異なるレベルまたは異なるオプションとして識別される場合があります。
Since some of these standards address a range of requirements, it may be useful to identify a set of standards to address a specific business need. Such a set of standards and their uses define a class of electronic signature. The first class already identified is the qualified electronic signature, fulfilling the requirements of Article 5.1 of the Directive.
これらの標準の一部はさまざまな要件に対処しているため、特定のビジネスニーズに対処するための一連の基準を特定することが有用かもしれません。このような標準のセットとその使用は、電子署名のクラスを定義します。すでに特定されている最初のクラスは、指令5.1の要件を満たしている資格のある電子署名です。
A limited number of "classes of electronic signatures" and corresponding profiles could be defined in close cooperation with actors on the market (business, users, suppliers). The need for such standards is envisaged, in addition to those for qualified electronic signatures, in areas such as:
限られた数の「電子署名のクラス」と対応するプロファイルは、市場の俳優（ビジネス、ユーザー、サプライヤー）と緊密に協力して定義できます。そのような標準の必要性は、次のような分野で、資格のある電子署名の必要性に加えて想定されています。
- different classes of electronic signatures with long-term validity;
- 長期的な妥当性を持つ電子署名のさまざまなクラス。
- electronic signatures for business transactions with limited value.
- 限られた価値のあるビジネストランザクションの電子署名。
The electronic signature format defined in the present document is applicable to the EESSI area "electronic signature and encoding formats".
現在のドキュメントで定義されている電子署名形式は、Eessiエリア「電子署名およびエンコード形式」に適用されます。
An electronic signature produced by a signer (see Section 5 and conformance Section 10.1) is applicable to the proposed class of electronic signature: "qualified electronic signatures fulfilling article 5.1".
署名者によって作成された電子署名（セクション5および適合セクション10.1を参照）は、提案された電子署名のクラス「記事5.1を満たす資格のある電子署名」に適用できます。
With the addition of attributes by the verifier (see Section 6 and conformance Section 10.2) the qualified electronic signature supports long-term validity.
検証者による属性の追加（セクション6および適合セクション10.2を参照）を使用すると、適格な電子署名は長期的な妥当性をサポートします。
Annex H (Informative): APIs for the Generation and Verification of Electronic Signatures Tokens
付録H（情報）：電子署名の生成と検証のためのAPIトークン
While the present document describes the data format of an electronic signature, the question is whether there exist APIs (Application Programming Interfaces) able to manipulate these structures. At least two such APIs have been defined; one set by the IETF and another set by the OMG (Object Management Group).
現在のドキュメントでは、電子署名のデータ形式について説明していますが、問題は、これらの構造を操作できるAPI（アプリケーションプログラミングインターフェイス）が存在するかどうかです。少なくとも2つのそのようなAPIが定義されています。1つはIETFによってセットされ、もう1つはOMG（オブジェクト管理グループ）によってセットされました。
In order to be able to use either of these APIs, it will be necessary to frame the previously defined electronic signature data structures using a mechanism-independent token format. Section 3.1 of RFC 2743 [RFC2743] specifies a mechanism-independent level of encapsulating representation for the initial token of a GSS-API context establishment sequence, incorporating an identifier of the mechanism type to be used on that context and enabling tokens to be interpreted unabmiguously.
これらのAPIのいずれかを使用できるようにするには、メカニズムに依存しないトークン形式を使用して、以前に定義された電子署名データ構造をフレーム化する必要があります。RFC 2743 [RFC2743]のセクション3.1 [RFC2743]は、GSS-APIコンテキスト確立シーケンスの初期トークンのメカニズムに依存しないレベルのカプセル化レベルを指定し、そのコンテキストで使用されるメカニズムタイプの識別子を組み込み、分解されないトークンを可能にすることを可能にします。。
In order to be processable by these APIs, all electronic signature data formats that are defined in the present document shall be framed following that description.
これらのAPIで処理可能であるために、本文書で定義されているすべての電子署名データ形式は、その説明に従ってフレーム化するものとします。
The encoding format for the token tag is derived from ASN.1 and DER, but its concrete representation is defined directly in terms of octets rather than at the ASN.1 level, in order to facilitate interoperable implementation without use of general ASN.1 processing code. The token tag consists of the following elements, in order:
トークンタグのエンコーディング形式はASN.1およびDerから派生していますが、その具体的な表現は、一般的なASN.1処理を使用せずに相互運用可能な実装を促進するために、ASN.1レベルではなくオクテットの観点から直接定義されます。コード。トークンタグは、次の要素で構成されています。
1) 0x60 -- Tag for RFC 2743 SEQUENCE; indicates that constructed form, definite length encoding follows.
1) 0x60 -RFC 2743シーケンスのタグ。構築されたフォーム、明確な長さエンコーディングが続くことを示します。
2) Token-length octets, specifying length of subsequent data (i.e., the summed lengths of elements 3 to 5 in this list, and of the mechanism-defined token object following the tag). This element comprises a variable number of octets:
2) トークンの長さのオクテット、後続のデータの長さを指定します（つまり、このリストの要素3〜5の合計長さ、およびタグに続くメカニズム定義のトークンオブジェクトの長さ）。この要素は、さまざまな数のオクテットで構成されています。
a) If the indicated value is less than 128, it shall be represented in a single octet with bit 8 (high order) set to "0" and the remaining bits representing the value.
a) 指定された値が128未満の場合、それはビット8（高次）が「0」に設定され、残りのビットが値を表す単一のオクテットで表されるものとします。
b) If the indicated value is 128 or more, it shall be represented in two or more octets, with bit 8 of the first octet set to "1" and the remaining bits of the first octet specifying the number of additional octets. The subsequent octets carry the value, 8 bits per octet, with the most significant digit first. The minimum number of octets shall be used to encode the length (i.e., no octets representing leading zeros shall be included within the length encoding).
b) 指定された値が128以上の場合、最初のオクテットのビット8を「1」に設定し、最初のオクテットの残りのビットが追加のオクテットの数を指定し、2つ以上のオクテットで表されます。後続のオクテットは、最初に最も重要な数字で、オクテットあたり8ビットの値を持ちます。オクテットの最小数は、長さをエンコードするために使用するものとします（つまり、主要なゼロを表すオクテットは長さエンコーディングに含まれないものとします）。
3) 0x06 -- Tag for OBJECT IDENTIFIER.
3) 0x06-オブジェクト識別子のタグ。
4) Object identifier length -- length (number of octets) of the encoded object identifier contained in element 5, encoded per rules as described in 2a) and 2b) above.
4) オブジェクト識別子の長さ - エンコードされたオブジェクト5に含まれるエンコードされたオブジェクト識別子の長さ（オクテット数）、上記の2a）および2b）で説明されている規則ごとにエンコードされています。
5) object identifier octets -- variable number of octets, encoded per ASN.1 BER rules:
5) オブジェクト識別子オクテット - ASN.1 BERルールごとにエンコードされたオクテットの可変数：
- The first octet contains the sum of two values:
- 最初のオクテットには、2つの値の合計が含まれています。
(1) the top-level object identifier component, multiplied by 40 (decimal); and
(1) トップレベルのオブジェクト識別子コンポーネントに40（小数）を掛けたもの。と
(2) the second-level object identifier component.
(2) セカンドレベルのオブジェクト識別子コンポーネント。
This special case is the only point within an object identifier encoding where a single octet represents contents of more than one component.
この特別なケースは、単一のオクテットが複数のコンポーネントの内容を表す場合、オブジェクト識別子エンコード内の唯一のポイントです。
- Subsequent octets, if required, encode successively lower components in the represented object identifier. A component's encoding may span multiple octets, encoding 7 bits per octet (most significant bits first) and with bit 8 set to "1" on all but the final octet in the component's encoding. The minimum number of octets shall be used to encode each component (i.e., no octets representing leading zeros shall be included within a component's encoding).
- 後続のオクテットは、必要に応じて、表現されたオブジェクト識別子のコンポーネントを連続的にエンコードします。コンポーネントのエンコーディングは、オクテットあたり7ビット（最初に最も重要なビット）をエンコードし、ビット8がコンポーネントのエンコードの最後のオクテットを除くすべてで「1」に設定されている複数のオクテットにまたがる場合があります。オクテットの最小数は、各コンポーネントをエンコードするために使用されます（つまり、主要なゼロを表すオクテットはコンポーネントのエンコードに含まれてはなりません）。
NOTE: In many implementations, elements 3 to 5 may be stored and referenced as a contiguous string constant.
注：多くの実装では、要素3〜5が保存され、隣接する文字列定数として参照される場合があります。
The token tag is immediately followed by a mechanism-defined token object. Note that no independent size specifier intervenes following the object identifier value to indicate the size of the mechanism-defined token object.
トークンタグのすぐ後に、メカニズム定義のトークンオブジェクトが続きます。メカニズム定義のトークンオブジェクトのサイズを示すために、オブジェクト識別子値に従って独立したサイズの仕様が介入しないことに注意してください。
Tokens conforming to the present document shall have the following OID in order to be processable by IDUP-APIs:
現在のドキュメントに準拠しているトークンは、IDUP-APIによって加工可能であるために、次のOIDを持つものとします。
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) }
The IETF CAT WG produced, in December 1998, an RFC (RFC 2479 [RFC2479]) under the name of IDUP-GSS-API (Independent Data Unit Protection) able to handle the electronic signature data format defined in the present document.
IETF CAT WGは、1998年12月に、現在のドキュメントで定義されている電子署名データ形式を処理できるIDUP-GSS-API（独立データユニット保護）の名前で、RFC（RFC 2479 [RFC2479]）を生産しました。
The IDUP-GSS-API includes support for non-repudiation services.
IDUP-GSS-APIには、非repudiationサービスのサポートが含まれています。
It supports evidence generation, where "evidence" is information that either by itself, or when used in conjunction with other information, is used to establish proof about an event or action, as well as evidence verification.
「証拠」は、それ自体によって、または他の情報と併用した場合の情報と、イベントまたは行動に関する証拠、および証拠の検証を確立するために使用される証拠生成をサポートします。
IDUP supports various types of evidences. All the types defined in IDUP are supported in the present document through the commitment-type parameter.
idupはさまざまなタイプの証拠をサポートしています。IDUPで定義されているすべてのタイプは、コミットメントタイプのパラメーターを通じて現在のドキュメントでサポートされています。
Section 2.3.3 of IDUP describes the specific calls needed to handle evidence ("EV" calls). The "EV" group of calls provides a simple, high-level interface to underlying IDUP mechanisms when application developers need to deal with only evidence: not with encryption or integrity services.
IDUPのセクション2.3.3では、証拠を処理するために必要な特定の呼び出し（「EV」コール）について説明します。コールの「EV」グループは、アプリケーション開発者が暗号化や整合性サービスではなく、証拠のみに対処する必要がある場合、基礎となるIDUPメカニズムにシンプルで高レベルのインターフェイスを提供します。
All generations and verification are performed according to the content of a NR policy that is referenced in the context.
すべての世代と検証は、コンテキストで参照されるNRポリシーの内容に従って実行されます。
Get_token_details is used to return the attributes that correspond to a given input token to an application. Since IDUP-GSS-API tokens are meant to be opaque to the calling application, this function allows the application to determine information about the token without having to violate the opaqueness intention of IDUP. Of primary importance is the mechanism type, which the application can then use as input to the IDUP_Establish_Env() call in order to establish the correct environment in which to have the token processed.
get_token_detailsは、特定の入力トークンに対応する属性をアプリケーションに返すために使用されます。IDUP-GSS-APIトークンは呼び出しアプリケーションに不透明であることを意図しているため、この関数により、IDUPの不透明度の意図に違反することなく、アプリケーションがトークンに関する情報を決定できます。主に重要なのはメカニズムタイプです。その後、アプリケーションは、トークンを処理する正しい環境を確立するために、IDUP_ESTABLISH_ENV（）呼び出しに入力として使用できます。
Generate_token generates a non-repudiation token using the current environment.
Generate_tokenは、現在の環境を使用して非繰り返しトークンを生成します。
Verify_evidence verifies the evidence token using the current environment. This operation returns a major_status code that can be used to determine whether the evidence contained in a token is complete (i.e., can be successfully verified (perhaps years) later). If a token's evidence is not complete, the token can be passed to another API, form_complete_pidu, to complete it. This happens when a status "conditionally valid" is returned. That status corresponds to the status "validation incomplete" of the present document.
Verify_Evidenceの現在の環境を使用して、証拠トークンを検証します。この操作は、トークンに含まれる証拠が完全であるかどうかを判断するために使用できるMajor_Statusコードを返します（つまり、後で（おそらく数年）検証することができます）。トークンの証拠が完了していない場合、トークンを別のAPI form_complete_piduに渡すことができます。これは、ステータス「条件付きで有効」が返されたときに発生します。そのステータスは、現在のドキュメントのステータス「検証不完全」に対応しています。
Form_complete_PIDU is used primarily when the evidence token itself does not contain all the data required for its verification, and it is anticipated that some of the data not stored in the token may become unavailable during the interval between generation of the evidence token and verification unless it is stored in the token. The Form_Complete_PIDU operation gathers the missing information and includes it in the token so that verification can be guaranteed to be possible at any future time.
form_complete_piduは、主に証拠トークン自体にその検証に必要なすべてのデータが含まれていない場合に使用され、トークンに保存されていないデータの一部は、証拠トークンと検証の間にある間に入手できなくなる可能性があると予想されます。トークンに保存されます。form_complete_pidu操作は、欠落している情報を収集し、トークンにそれを含めて、将来の時期に検証が可能になることを保証できるようにします。
Non-repudiation interfaces have been defined in "CORBA Security", a document produced by the OMG (Object Management Group). These interfaces are described in IDL (Interface Definition Language) and are optional.
非和解インターフェイスは、OMG（オブジェクト管理グループ）が作成したドキュメントである「Corba Security」で定義されています。これらのインターフェイスはIDL（インターフェイス定義言語）で説明されており、オプションです。
The handling of "tokens" supporting non-repudiation is done through the following interfaces:
非repudiationをサポートする「トークン」の処理は、次のインターフェイスを通じて行われます。
- set_NR_features specifies the features to apply to future evidence generation and verification operations;
- set_nr_features将来の証拠生成および検証操作に適用する機能を指定します。
- get_NR_features returns the features that will be applied to future evidence generation and verification operations;
- get_nr_features将来の証拠生成および検証操作に適用される機能を返します。
- generate_token generates a non-repudiation token using the current non-repudiation features;
- Generate_tokenは、現在の非repudiation機能を使用して非repudiationトークンを生成します。
- verify_evidence verifies the evidence token using the current non-repudiation features;
- verify_evidenceの現在の非repudiation機能を使用して、証拠トークンを検証します。
- get_tokens_details returns information about an input non-repudiation token. The information returned depends upon the type of token;
- get_tokens_details入力非repudiationトークンに関する情報を返します。返される情報は、トークンの種類によって異なります。
- form_complete_evidence is used when the evidence token itself does not contain all the data required for its verification, and it is anticipated that some of the data not stored in the token may become unavailable during the interval between generation of the evidence token and verification unless it is stored in the token. The form_complete_evidence operation gathers the missing information and includes it in the token so that verification can be guaranteed to be possible at any future time.
- form_complete_evidenceは、証拠トークン自体にその検証に必要なすべてのデータが含まれていない場合に使用され、トークンに保存されていないデータの一部は、証拠トークンと検証の間に入力できなくなる可能性があると予想されます。トークンに保存されます。form_complete_evidence操作は、欠落している情報を収集し、将来の時期に検証が可能になることが保証できるように、トークンにそれを含めます。
NOTE: The similarity between the two sets of APIs is noticeable.
注：APIの2つのセット間の類似性は顕著です。
Annex I (Informative): Cryptographic Algorithms
付録I（情報）：暗号化アルゴリズム
RFC 3370 [10] describes the conventions for using several cryptographic algorithms with the Crytographic Message Syntax (CMS). Only the hashing and signing algorithms are appropriate for use with the present document.
RFC 3370 [10]は、Crytographic Message Syntax（CMS）でいくつかの暗号化アルゴリズムを使用するための規則について説明しています。ハッシュおよび署名アルゴリズムのみが、現在のドキュメントで使用するのに適しています。
Since the publication of RFC 3370 [10], MD5 has been broken. This algorithm is no longer considered appropriate and has been deleted from the list of algorithms.
RFC 3370 [10]の公開以来、MD5は壊れています。このアルゴリズムはもはや適切とは見なされず、アルゴリズムのリストから削除されています。
The SHA-1 digest algorithm is defined in FIPS Pub 180-1. The algorithm identifier for SHA-1 is:
SHA-1ダイジェストアルゴリズムは、FIPS Pub 180-1で定義されています。SHA-1のアルゴリズム識別子は次のとおりです。
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14)
secsig(3) algorithm(2) 26 }
The AlgorithmIdentifier parameters field is optional. If present, the parameters field shall contain an ASN.1 NULL. Implementations should accept SHA-1 AlgorithmIdentifiers with absent parameters as well as NULL parameters. Implementations should generate SHA-1 AlgorithmIdentifiers with NULL parameters.
Algorithmidentifierパラメーターフィールドはオプションです。存在する場合、パラメーターフィールドにはasn.1 nullが含まれます。実装は、パラメーターがないだけでなく、ヌルパラメーターを備えたSHA-1アルゴリズムのdidentifiersを受け入れる必要があります。実装では、ヌルパラメーターを備えたSHA-1アルゴリズムのIdentifiersを生成する必要があります。
The following is a selection of work that has been done in the area of digest algorithms or, as they are often called, hash functions:
以下は、ダイジェストアルゴリズムの領域で行われた作業の選択、またはしばしばハッシュ関数と呼ばれるように、次のように行われています。
- ISO/IEC 10118-1 (1994) [ISO10118-1]: "Information technology - Security techniques - Hash-functions - Part 1: General". ISO/IEC 10118-1 contains definitions and describes basic concepts.
- ISO/IEC 10118-1（1994）[ISO10118-1]：「情報技術 - セキュリティテクニック - ハッシュファンクション - パート1：一般」。ISO/IEC 10118-1には定義が含まれており、基本概念を説明しています。
- ISO/IEC 10118-2 (1994) [ISO10118-2]: "Information technology - Security techniques - Hash-functions - Part 2: Hash-functions using an n-bit block cipher algorithm". ISO/IEC 10118-2 specifies two ways to construct a hash-function from a block cipher.
- ISO/IEC 10118-2（1994）[ISO10118-2]：「情報技術 - セキュリティ技術 - ハッシュファンクション - パート2：Nビットブロック暗号アルゴリズムを使用したハッシュファンクション」。ISO/IEC 10118-2は、ブロック暗号からハッシュ機能を構築する2つの方法を指定しています。
- ISO/IEC 10118-3 (1997) [ISO10118-3]: "Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions". ISO/IEC 10118-3 specifies the following dedicated hash-functions:
- ISO/IEC 10118-3（1997）[ISO10118-3]：「情報技術 - セキュリティテクニック - ハッシュファンクション - パート3：専用ハッシュファンクション」。ISO/IEC 10118-3次の専用ハッシュファンクションを指定します。
- SHA-1 (FIPS 180-1); - RIPEMD-128; - RIPEMD-160.
- SHA-1（FIPS 180-1）;-RIPEMD-128;-RIPEMD-160。
- ISO/IEC 10118-4 (1998) [ISO10118-4]: "Information technology - Security techniques - Hash-functions - Part 4: Hash-functions using modular arithmetic".
- ISO/IEC 10118-4（1998）[ISO10118-4]：「情報技術 - セキュリティテクニック - ハッシュファンクション - パート4：モジュラー算術を使用したハッシュファクション」。
- RFC 1320 (PS 1992): "The MD4 Message-Digest Algorithm". RFC 1320 specifies the hash-function MD4. Today, MD4 is considered outdated.
- RFC 1320（PS 1992）：「MD4 Message-Digest Algorithm」。RFC 1320ハッシュ機能MD4を指定します。今日、MD4は時代遅れと見なされています。
- RFC 1321 (I 1992): "The MD5 Message-Digest Algorithm". RFC 1321 (informational) specifies the hash-function MD5. Today, MD5 is not recommended for new implementations.
- RFC 1321（I 1992）：「MD5メッセージダイジストアルゴリズム」。RFC 1321（情報）ハッシュ機能MD5を指定します。今日、MD5は新しい実装には推奨されません。
- FIPS Publication 180-1 (1995): "Secure Hash Standard". FIPS 180-1 specifies the Secure Hash Algorithm (SHA), dedicated hash-function developed for use with the DSA. The original SHA, published in 1993, was slightly revised in 1995 and renamed SHA-1.
- FIPS Publication 180-1（1995）：「Secure Hash Standard」。FIPS 180-1 DSAで使用するために開発された専用のハッシュ機能が開発された安全なハッシュアルゴリズム（SHA）を指定します。1993年に公開された元のSHAは、1995年にわずかに改訂され、SHA-1と改名されました。
- ANSI X9.30-2 (1997) [X9.30-2]: "Public Key Cryptography for the Financial Services Industry - Part 2: The Secure Hash Algorithm (SHA-1)". X9.30-2 specifies the ANSI-Version of SHA-1.
- ANSI X9.30-2（1997）[X9.30-2]：「金融サービス業界向けの公開キー暗号化 - パート2：安全なハッシュアルゴリズム（SHA-1）」。X9.30-2 SHA-1のAnsi-versionを指定します。
- ANSI X9.31-2 (1996) [X9.31-2]: "Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry - Part 2: Hash Algorithms". X9.31-2 specifies hash algorithms.
- ANSI X9.31-2（1996）[X9.31-2]：「金融サービス業界に可逆アルゴリズムを使用した公開キー暗号化 - パート2：ハッシュアルゴリズム」。X9.31-2ハッシュアルゴリズムを指定します。
The DSA signature algorithm is defined in FIPS Pub 186. DSA is always used with the SHA-1 message digest algorithm. The algorithm identifier for DSA is:
DSA署名アルゴリズムは、FIPS Pub 186で定義されています。DSAは常にSHA-1メッセージダイジェストアルゴリズムで使用されます。DSAのアルゴリズム識別子は次のとおりです。
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57 (10040) x9cm(4) 3 }
The AlgorithmIdentifier parameters field shall not be present.
Algorithmidentifierパラメーターフィールドは存在しないものとします。
The RSA signature algorithm is defined in RFC 3447 [RFC3447]. RFC 3370 [10] specifies the use of the RSA signature algorithm with the SHA-1 algorithm. The algorithm identifier for RSA with SHA-1 is:
RSA署名アルゴリズムは、RFC 3447 [RFC3447]で定義されています。RFC 3370 [10]は、SHA-1アルゴリズムでRSA署名アルゴリズムの使用を指定します。SHA-1を備えたRSAのアルゴリズム識別子は次のとおりです。
Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
NOTE: RFC 3370 [10] recommends that MD5 not be used for new implementations.
注：RFC 3370 [10]は、MD5を新しい実装に使用しないことを推奨しています。
The following is a selection of work that has been done in the area of digital signature mechanisms:
以下は、デジタル署名メカニズムの分野で行われた作業の選択です。
- FIPS Publication 186 (1994): "Digital Signature Standard". NIST's Digital Signature Algorithm (DSA) is a variant of ElGamal's Discrete Logarithm-based digital signature mechanism. The DSA requires a 160-bit hash-function and mandates SHA-1.
- FIPS Publication 186（1994）：「デジタル署名標準」。NISTのデジタル署名アルゴリズム（DSA）は、Elgamalの個別の対数ベースのデジタル署名メカニズムのバリアントです。DSAには160ビットのハッシュ機能が必要であり、SHA-1を義務付けています。
- IEEE P1363 (2000) [P1363]: "Standard Specifications for Public-Key Cryptography". IEEE P1363 contains mechanisms for digital signatures, key establishment, and encipherment based on three families of public key schemes:
- IEEE P1363（2000）[P1363]：「パブリックキー暗号化の標準仕様」。IEEE P1363には、公開キースキームの3つのファミリーに基づいたデジタル署名、主要な設立、およびエンシファメントのメカニズムが含まれています。
- "Conventional" Discrete Logarithm (DL)-based techniques, i.e., Diffie-Hellman (DH) key agreement, Menezes-Qu-Vanstone (MQV) key agreement, the Digital Signature Algorithm (DSA), and Nyberg-Rueppel (NR) digital signatures;
- 「従来の」離散対数（DL）ベースの手法、すなわち、Diffie-Hellman（DH）Key Agreement、Menezes-QU-Vanstone（MQV）キー契約、デジタル署名アルゴリズム（DSA）、およびNyberg-Rueppel（NR）Digital署名;
- Elliptic Curve (EC)-based variants of the DL-mechanisms specified above, i.e., EC-DH, EC-MQV, EC-DSA, and EC-NR. For elliptic curves, implementation options include mod p and characteristic 2 with polynomial or normal basis representation;
- 上記で指定されたDLメカニズムの楕円曲線（EC）ベースのバリアント、つまりEC-DH、EC-MQV、EC-DSA、およびEC-NR。楕円曲線の場合、実装オプションには、多項式または正常な表現を備えたMOD Pおよび特性2が含まれます。
- Integer Factoring (IF)-based techniques, including RSA encryption, RSA digital signatures, and RSA-based key transport.
- RSA暗号化、RSAデジタル署名、RSAベースのキートランスポートを含む整数ファクタリング（IF）ベースの手法。
- ISO/IEC 9796-2 (1997) [ISO9796-2]: "Information technology - Security techniques - Digital signature schemes giving message recovery - Part 2: Mechanisms using a hash-function". ISO/IEC 9796-2 specifies digital signature mechanisms with partial message recovery that are also based on the RSA technique but make use of a hash-function.
- ISO/IEC 9796-2（1997）[ISO9796-2]：「情報技術 - セキュリティ技術 - メッセージ回復を与えるデジタル署名スキーム - パート2：ハッシュ機能を使用したメカニズム」。ISO/IEC 9796-2は、RSA手法にも基づいているがハッシュ機能を使用する部分的なメッセージ回復を備えたデジタル署名メカニズムを指定します。
- ISO/IEC 9796-4 (1998) [ISO9796-4]: "Digital signature schemes giving message recovery - Part 4: Discrete logarithm based mechanisms". ISO/IEC 9796-4 specifies digital signature mechanisms with partial message recovery that are based on Discrete Logarithm techniques. The document includes the Nyberg-Rueppel scheme.
- ISO/IEC 9796-4（1998）[ISO9796-4]：「メッセージの回復を与えるデジタル署名スキーム - パート4：離散対数ベースのメカニズム」。ISO/IEC 9796-4離散対数手法に基づいた部分的なメッセージ回復を備えたデジタル署名メカニズムを指定します。このドキュメントには、Nyberg-Rueppelスキームが含まれています。
- ISO/IEC 14888-1 [ISO14888-1]: "Digital signatures with appendix - Part 1: General". ISO/IEC 14888-1 contains definitions and describes the basic concepts of digital signatures with appendix.
- ISO/IEC 14888-1 [ISO14888-1]：「付録を備えたデジタル署名 - パート1：一般」。ISO/IEC 14888-1には定義が含まれており、付録を使用したデジタル署名の基本概念を説明しています。
- ISO/IEC 14888-2 [ISO14888-2]: "Digital signatures with appendix - Part 2: Identity-based mechanisms". ISO/IEC 14888-2 specifies digital signature schemes with appendix that make use of identity-based keying material. The document includes the zero-knowledge techniques of Fiat-Shamir and Guillou-Quisquater.
- ISO/IEC 14888-2 [ISO14888-2]：「付録を備えたデジタル署名 - パート2：アイデンティティベースのメカニズム」。ISO/IEC 14888-2は、アイデンティティベースのキーイング素材を使用する付録を備えたデジタル署名スキームを指定します。この文書には、フィアット・シャミールとギルー・カスカイターのゼロ知識技術が含まれています。
- ISO/IEC 14888-3 [ISO14888-3]: "Digital signatures with appendix - Part 3: Certificate-based mechanisms". ISO/IEC 14888-3 specifies digital signature schemes with appendix that make use of certificate-based keying material. The document includes five schemes:
- ISO/IEC 14888-3 [ISO14888-3]：「付録を備えたデジタル署名 - パート3：証明書ベースのメカニズム」。ISO/IEC 14888-3証明書ベースのキーイング素材を使用する付録を備えたデジタル署名スキームを指定します。ドキュメントには5つのスキームが含まれています。
- DSA; - EC-DSA, an elliptic curve-based analog of NIST's Digital Signature Algorithm; - Pointcheval-Vaudeney signatures; - RSA signatures; - ESIGN.
- DSA;-EC-DSA、NISTのデジタル署名アルゴリズムの楕円曲線ベースのアナログ。-pointcheval-vaudeney Signatures;-RSA署名; - esign。
- ISO/IEC 15946-2 (2002) [ISO15946-2]: "Cryptographic techniques based on elliptic curves - Part 2: Digital signatures", specifies digital signature schemes with appendix using elliptic curves.
- ISO/IEC 15946-2（2002）[ISO15946-2]：「楕円曲線に基づく暗号化技術 - パート2：デジタル署名」は、楕円曲線を使用した付録を備えたデジタル署名スキームを指定します。
- The document includes two schemes:
- ドキュメントには2つのスキームが含まれています。
- EC-DSA, an elliptic curve-based analog of NIST's Digital Signature Algorithm;
- EC-DSA、NISTのデジタル署名アルゴリズムの楕円曲線ベースのアナログ。
- EC-AMV, an elliptic curve-based analog of the Agnew-Muller-Vanstone signature algorithm.
- EC-AMV、Agnew-Muller-Vanstone Signature Algorithmの楕円曲線ベースのアナログ。
- ANSI X9.31-1 (1997) [X9.31-1]: "Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry - Part 1: The RSA Signature Algorithm". ANSI X9.31-1 specifies a digital signature mechanism with appendix using the RSA public key technique.
- ANSI X9.31-1（1997）[X9.31-1]：「金融サービス業界に可逆アルゴリズムを使用した公開キー暗号化 - パート1：RSA署名アルゴリズム」。ANSI X9.31-1 RSA公開キーテクニックを使用した付録を備えたデジタル署名メカニズムを指定します。
- ANSI X9.30-1 (1997) [X9.30-1]: "Public Key Cryptography Using Irreversible Algorithms for the Financial Services Industry - Part 1: The Digital Signature Algorithm (DSA)". ANSI X9.30-1 specifies the DSA, NIST's Digital Signature Algorithm.
- ANSI X9.30-1（1997）[X9.30-1]：「金融サービス業界に不可逆アルゴリズムを使用した公開キー暗号化 - パート1：デジタル署名アルゴリズム（DSA）」。ANSI X9.30-1 NISTのデジタル署名アルゴリズムであるDSAを指定します。
- ANSI X9.62 (1998) [X9.62]: "Public Key Cryptography for the Financial Services Industry - The Elliptic Curve Digital Signature Algorithm (ECDSA)". ANSI X9.62 specifies the Elliptic Curve Digital Signature Algorithm, an analog of NIST's Digital Signature Algorithm (DSA) using elliptic curves. The appendices provide tutorial information on the underlying mathematics for elliptic curve cryptography and give many examples.
- ANSI X9.62（1998）[X9.62]：「金融サービス業界向けの公開キー暗号化 - 楕円曲線デジタル署名アルゴリズム（ECDSA）」。ANSI X9.62は、楕円曲線を使用してNISTのデジタル署名アルゴリズム（DSA）のアナログであるElliptic Curve Digital Signature Algorithmを指定します。付録は、楕円曲線暗号化の基礎となる数学に関するチュートリアル情報を提供し、多くの例を示します。
Annex J (Informative): Guidance on Naming
Annex J（Informative）：命名に関するガイダンス
The subject name shall be allocated through a registration scheme administered through a Registration Authority (RA) to ensure uniqueness. This RA may be an independent body or a function carried out by the Certification Authority.
件名は、一意性を確保するために、登録機関（RA）を通じて管理された登録スキームを通じて割り当てられるものとします。このRAは、認定機関によって実行される独立した機関または機能である可能性があります。
In addition to ensuring uniqueness, the RA shall verify that the name allocated properly identifies the applicant and that authentication checks are carried out to protect against masquerade.
一意性を確保することに加えて、RAは、割り当てられた名前が申請者を適切に識別し、マスカレードから保護するために認証チェックが実行されることを確認するものとします。
The name allocated by an RA is based on registration information provided by, or relating to, the applicant (e.g., his personal name, date of birth, residence address) and information allocated by the RA. Three variations commonly exist:
RAによって割り当てられた名前は、申請者（たとえば、彼の個人名、生年月日、居住住所など）によって提供される、または関連する登録情報とRAによって割り当てられた情報に基づいています。通常、3つのバリエーションが存在します。
- the name is based entirely on registration information, which uniquely identifies the applicant (e.g., "Pierre Durand (born on) July 6, 1956");
- 名前は完全に登録情報に基づいており、申請者を一意に識別します（たとえば、「1956年7月6日にピエールデュランド（生まれ）」）。
- the name is based on registration information, with the addition of qualifiers added by the registration authority to ensure uniqueness (e.g., "Pierre Durand 12");
-
- the registration information is kept private by the registration authority and the registration authority allocates a "pseudonym".
- 登録情報は登録機関によって非公開になり、登録機関は「仮名」を割り当てます。
Under certain circumstances, it may be necessary for information used during registration, but not published in the certificate, to be made available to third parties (e.g., to an arbitrator to resolve a dispute or for law enforcement). This registration information is likely to include personal and sensitive information.
特定の状況下では、登録中に使用される情報が必要になる場合がありますが、証明書には公開されていないため、第三者（例：紛争を解決するための仲裁人が）に利用できるようにします。この登録情報には、個人的および機密情報が含まれる可能性があります。
Thus, the RA needs to establish a policy for:
したがって、RAは以下のポリシーを確立する必要があります。
- whether the registration information should be disclosed; - to whom such information should be disclosed; - under what circumstances such information should be disclosed.
- 登録情報を開示する必要があるかどうか。 - そのような情報を公開すべきか。 - そのような情報をどのような状況で開示すべきか。
This policy may be different whether the RA is being used only within a company or for public use. The policy will have to take into account national legislation and in particular any data protection and privacy legislation.
このポリシーは、RAが会社内でのみ使用されているか公共のために使用されているかどうかに異なる場合があります。このポリシーは、国家法、特にデータ保護とプライバシー法を考慮する必要があります。
Currently, the provision of access to registration is a local matter for the RA. However, if open access is required, standard protocols, such as HTTP -- RFC 2068 (Internet Web Access Protocol), may be employed with the addition of security mechanisms necessary to meet the data protection requirements (e.g., Transport Layer Security -- RFC 4346 [RFC4346]) with client authentication.
現在、登録へのアクセスの提供は、RAのローカルな問題です。ただし、オープンアクセスが必要な場合、HTTP -RFC 2068（インターネットWebアクセスプロトコル）などの標準プロトコルは、データ保護要件を満たすために必要なセキュリティメカニズムを追加して使用できます（たとえば、輸送層のセキュリティ-RFC4346 [RFC4346]）クライアント認証を使用。
In some cases, the subject name that is contained in a public key certificate may not be meaningful enough. This may happen because of the existence of homonyms or because of the use of pseudonyms. A distinction could be made if more attributes were present. However, adding more attributes to a public key certificate placed in a public repository would be going against the privacy protection requirements.
場合によっては、公開キー証明書に含まれる件名は、十分に意味がない場合があります。これは、同音異義語の存在や仮名の使用のために起こる可能性があります。より多くの属性が存在する場合、区別ができます。ただし、公開リポジトリに配置された公開鍵証明書にさらに属性を追加すると、プライバシー保護要件に反します。
In any case, the Registration Authority will get information at the time of registration, but not all that information will be placed in the certificate. In order to achieve a balance between these two opposite requirements, the hash values of some additional attributes can be placed in a public key certificate. When the certificate owner provides these additional attributes, then they can be verified. Using biometrics attributes may unambiguously identify a person. Examples of biometrics attributes that can be used include: a picture or a manual signature from the certificate owner.
いずれにせよ、登録機関は登録時に情報を取得しますが、そのすべての情報が証明書に配置されるわけではありません。これら2つの反対の要件のバランスをとるために、いくつかの追加属性のハッシュ値を公開鍵証明書に配置できます。証明書所有者がこれらの追加属性を提供する場合、それらを検証することができます。生体認証属性を使用すると、人を明確に識別する場合があります。使用できる生体認証属性の例は次のとおりです。
NOTE: Using hash values protects privacy only if the possible inputs are large enough. For example, using the hash of a person's social security number is generally not sufficient since it can easily be reversed.
注：ハッシュ値を使用すると、可能な入力が十分に大きい場合にのみ、プライバシーを保護します。たとえば、人の社会保障番号のハッシュを使用するだけでは、簡単に逆転できるため十分ではありません。
A picture can be used if the verifier once met the person and later on wants to verify that the certificate that he or she got relates to the person whom was met. In such a case, at the first exchange, the picture is sent, and the hash contained in the certificate may be used by the verifier to verify that it is the right person. At the next exchange, the picture does not need to be sent again.
検証者がかつて人に会った場合、後で彼または彼女が得た証明書が出会った人に関連していることを確認したい場合、写真を使用できます。そのような場合、最初の交換で写真が送信され、証明書に含まれるハッシュは、適切な人物であることを確認するために検証者によって使用されます。次の交換では、写真を再び送信する必要はありません。
A manual signature may be used if a signed document has been received beforehand. In such a case, at the first exchange, the drawing of the manual signature is sent, and the hash contained in the certificate may be used by the verifier to verify that it is the right manual signature. At the next exchange, the manual signature does not need to be sent again.
事前に署名されたドキュメントを受け取った場合、手動署名を使用できます。そのような場合、最初の交換では、マニュアル署名の図面が送信され、証明書に含まれるハッシュを検証者が使用して、それが正しい手動署名であることを確認できます。次の交換では、手動の署名を再度送信する必要はありません。
The name of an employee within an organization is likely to be some combination of the name of the organization and the identifier of the employee within that organization.
組織内の従業員の名前は、組織の名前とその組織内の従業員の識別子の組み合わせである可能性があります。
An organization name is usually a registered name, i.e., business or trading name used in day-to-day business. This name is registered by a Naming Authority, which guarantees that the organization's registered name is unambiguous and cannot be confused with another organization.
組織名は通常、登録名、つまり日常業務で使用されるビジネス名または取引名です。この名前は命名当局によって登録されています。これは、組織の登録名が明確であり、別の組織と混同することができないことを保証します。
In order to get more information about a given registered organization name, it is necessary to go back to a publicly available directory maintained by the Naming Authority.
特定の登録された組織名に関する詳細情報を取得するには、命名当局が管理する公開されているディレクトリに戻る必要があります。
The identifier may be a name or a pseudonym (e.g., a nickname or an employee number). When it is a name, it is supposed to be descriptive enough to unambiguously identify the person. When it is a pseudonym, the certificate does not disclose the identity of the person. However, it ensures that the person has been correctly authenticated at the time of registration and therefore may be eligible to some advantages implicitly or explicitly obtained through the possession of the certificate. In either case, however, this can be insufficient because of the existence of homonyms.
識別子は、名前または仮名（例：ニックネームまたは従業員番号）である場合があります。それが名前である場合、それはその人を明確に識別するのに十分な記述であると想定されています。それが仮名である場合、証明書はその人の身元を開示しません。ただし、登録時にその人が正しく認証されていることを保証し、したがって、証明書の所有を通じて暗黙的または明示的に取得されるいくつかの利点の対象となる可能性があります。ただし、どちらの場合でも、同音異義語が存在するため、これは不十分な場合があります。
Placing more attributes in the certificate may be one solution, for example, by giving the organization unit of the person or the name of a city where the office is located. However, the more information is placed in the certificate, the more problems arise if there is a change in the organization structure or the place of work. So this may not be the best solution. An alternative is to provide more attributes (like the organization unit and the place of work) through access to a directory maintained by the company. It is likely that, at the time of registration, the Registration Authority got more information than what was placed in the certificate, if such additional information is placed in a repository accessible only to the organization.
証明書にもっと多くの属性を配置することは、たとえば、組織ユニットの個人またはオフィスがある都市の名前を提供することにより、1つの解決策です。ただし、より多くの情報が証明書に配置されるほど、組織構造または職場の場所に変更がある場合、より多くの問題が発生します。したがって、これは最良の解決策ではないかもしれません。別の方法は、会社が管理するディレクトリへのアクセスを通じて、より多くの属性（組織ユニットや職場の場所など）を提供することです。登録時に、登録機関は、組織がのみアクセスできるリポジトリにそのような追加情報が配置されている場合、証明書に配置されたものよりも多くの情報を得た可能性があります。
Acknowledgments
謝辞
Special thanks to Russ Housley for reviewing the document.
ドキュメントをレビューしてくれたRuss Housleyに感謝します。
Authors' Addresses
著者のアドレス
Denis Pinkas Bull SAS Rue Jean-Jaures 78340 Les Clayes sous Bois CEDEX FRANCE EMail: Denis.Pinkas@bull.net
デニス・ピンカス・ブル・サス・rue jean-jaures 78340 les clayes sous bois cedex franceメール：denis.pinkas@bull.net
Nick Pope Thales eSecurity Meadow View House Long Crendon Aylesbury Buck HP18 9EQ United Kingdom EMail: nick.pope@thales-esecurity.com
John Ross Security & Standards Consultancy Ltd The Waterhouse Business Centre 2 Cromer Way Chelmsford Essex CM1 2QE United Kingdom EMail: ross@secstan.com
John Ross Security＆Standards Consultancy Ltd The Waterhouse Business Center 2 Cromer Way Chelmsford Essex CM1 2QE United Kingdom Email：Ross@secstan.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。