RFC5126 日本語訳
5126 CMS Advanced Electronic Signatures (CAdES). D. Pinkas, N. Pope,J. Ross. March 2008. (Format: TXT=309173 bytes) (Obsoletes RFC3126) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループD.ピンカスの要求をネットワークでつないでください: 5126年の雄牛SASは以下を時代遅れにします。 3126年のN.法王カテゴリ: 情報のThales eSecurity J.ロスセキュリティと規格2008年2月
CMS Advanced Electronic Signatures (CAdES)
cmは電子署名を進めました。(ビャクシン属の木)
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.
RFC3852とRFC2634への拡大であると形式をみなすことができます。(適切であるときに、そこでは、追加署名していて未署名の属性が定義されました)。
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.
このInformational RFCの内容は、ETSI仕様書(TS)101 733V.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
Pinkas, et al. Informational [Page 1] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[1ページ]情報のRFC5126cm
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
1. 序論…6 2. 範囲…6 3. 定義と略語…8 3.1. 定義…8 3.2. 略語…11 4. 概要…12 4.1. メージャーはパーティーへ行きます…13 4.2. 署名方針…14 4.3. 電子署名形式…15 4.3.1. ビャクシン属の木基本的な電子署名(ビャクシン属の木-BES)…15 4.3.2. ビャクシン属の木明白な方針ベースの電子署名(ビャクシン属の木-EPES)…18 4.4. 電子署名は合法化でデータをフォーマットします…19 4.4.1. 時間(ビャクシン属の木T)との電子署名…20 4.4.2. 完全な合法化データ参照(ビャクシン属の木C)があるES…21 4.4.3. 電子署名形式を広げています…23 4.4.3.1. 長い電子署名(ビャクシン属の木X長さ)を広げています…24 4.4.3.2. 時間タイプ1との電子署名を広げています…25 4.4.3.3. 時間タイプ2との電子署名を広げています…26 4.4.3.4. ビャクシン属の木Xは.4.4に.4の記録保管所の電子署名を切望します。時間との拡張長い電子署名、((ビャクシン属の木a).274.5仲裁.4.6合法化は処理されます…; …、.29、5. 電子署名属性................................30 5.1の一般構文............................................30 5.2データcontent type.........................................30 5.3署名しているデータcontent type; …、.30、5.4. SignedData Type...........................................31 5.5EncapsulatedContentInfo Type..............................31 5.6SignerInfo Type、.5.6、.1. メッセージDigest Calculation Process、.5.6、.2. メッセージSignature Generation Process、.325.6、.3. メッセージSignature Verification Process.............32 5.7の基本的なES Mandatory Present Attributes、.325.7、.1. content type。…… .32 5.7.2メッセージDigest、.5.7、.3. 署名Certificate Reference Attributes、.5.7、.3、.1. ESS署名証明書Attribute Definition、.5.7、.3、.2. ESS署名証明書v2 Attribute Definition………………….34
Pinkas, et al. Informational [Page 2] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[2ページ]情報のRFC5126cm
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
5.7.3.3. 他の署名証明書Attribute Definition…35 5.8. 明白な方針ベースの電子署名のための追加義務的な属性…36 5.8 .1署名方針識別子…36 5.9. cmは任意の属性をインポートしました…38 5.9 .1署名時間…38 5.9.2副署…39 5.10. 任意の属性をESSインポートします…39 5.10.1. 内容照会Attribute…39 5.10.2. 満足している識別子Attribute…39 5.10.3. 満足しているヒントAttribute…40 5.11. 現在のドキュメントで定義された追加任意の属性…40 5.11.1. 委任タイプ指示Attribute…41 5.11.2. 署名者位置のAttribute…43 5.11.3. 署名者属性Attribute…43 5.11.4. 満足しているタイムスタンプAttribute…44 5.12. 複数の署名のために、サポートします。44 5.12.1. 独立している署名…44 5.12.2. 署名を埋め込みます…45 6. 追加電子署名合法化属性…45 6.1署名タイムスタンプAttribute(CAdES-T)…47 6.1 .1署名タイムスタンプAttribute Definition…47 6.2. 合法化データ参照(ビャクシン属の木C)を終了してください…48 6.2 .1完全な証明書参照Attribute Definition…48 6.2 .2完全な取消し参照Attribute Definition…49 6.2 .3属性証明書参照Attribute Definition…51 6.2 .4属性取消し参照Attribute Definition…52 6.3. 合法化データ(ビャクシン属の木X)を広げています…52 6.3.1. 時間で押し込まれた合法化データ(ビャクシン属の木Xタイプ1かタイプ2)…53 6.3.2. 合法化データ(ビャクシン属の木X長さビャクシン属の木X長いタイプ1か2)を切望してください…53 6.3 .3証明書値のAttribute Definition…54 6.3 .4取消し値のAttribute Definition…54 6.3.5. ビャクシン属の木Cタイムスタンプは定義を結果と考えます…56 6.3 .6時間の押し込まれた本命crls参照Attribute Definition…57 6.4. 合法化データを格納してください…58 6.4 タイムスタンプを格納している.1Attribute Definition…58 7. 他の標準のデータ構造…60 7.1. 公開鍵証明書形式…60 7.2. 取消しリスト書式を証明してください…60
Pinkas, et al. Informational [Page 3] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[3ページ]情報のRFC5126cm
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
7.3. OCSP応答形式…60 7.4. タイムスタンプトークン形式…60 7.5. 形式を命名して、結果と考えてください…60 7.6. AttributeCertificate…61 8. 順応要件…61 8.1. ビャクシン属の木基本的な電子署名(ビャクシン属の木-BES)…62 8.2. ビャクシン属の木明白な方針ベースの電子署名…63 8.3. …を時押し込む検証使用…63 8.4. 検証の使用の安全な記録…63 9. 参照…64 9.1. 標準の参照…64 9.2. 有益な参照…65 別館A(標準の): ASN.1定義…69 A.1。 X.208 ASN.1構文を使用する署名形式定義…69 A.2。 X.680 ASN.1構文を使用する署名形式定義…77 別館B(有益な): 拡張型の電子署名…86 B.1。 拡張型に関する合法化データ…86 B.1.1。 ビャクシン属の木X長さ…87 B.1.2。 ビャクシン属の木Xタイプ1…88 B.1.3。 ビャクシン属の木Xタイプ2…90 B.1.4。 ビャクシン属の木X長いタイプ1とビャクシン属の木Xは長い間、2をタイプします…91 B.2。 タイムスタンプ拡大…93 B.3。 合法化データを格納してください、(ビャクシン属の木a)…94 B.4。 例の合法化系列…97 B.5。 追加オプション機能…102 別館C(有益な): 一般記述…103 C.1。 署名方針…103 C.2。 情報であると署名されます…104 C.3。 電子署名のコンポーネント…104 C.3.1。 署名方針の参照…104 C.3.2。 委任タイプ指示…105 C.3.3。 署名者から識別子を証明してください…106 C.3.4。 役割の属性…106 C.3.4.1。 役割であると主張されます…107 C.3.4.2。 役割であることが公認されます…107 C.3.5。 署名者位置…108 C.3.6。 署名時間…108 C.3.7。 満足している形式…108 C.3.8満足しているヒント…109 C.3.9。 …に十字で参照をつける内容…109 C.4。 合法化データの成分…109 C.4.1。 取消し状態情報…109 C.4.1.1。 CRL情報…110 C.4.1.2。 OCSP情報…110 C.4.2。 証明経路…111 C.4.3。 署名の長寿のために時押し込みます…111
Pinkas, et al. Informational [Page 4] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[4ページ]情報のRFC5126cm
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
C.4.4。 カリフォルニアの主要なCompromisesの前のSignatureのLong Lifeのために時押し込みます…113 C.4.4.1。 完全な合法化データがあるESを時押し込みます…113 C.4.4.2。 時間の刻印証明書と取消し情報参照。114 C.4.5。 署名のアーカイブのために時押し込みます…115 C.4.6。 追加データの参照…116 C.4.7。 相互承認のために時押し込みます…116 C.4.8。 TSAの主要な感染…117 C.5。 複数の署名…118 別館D(有益な): ティースプーンフルで共同利用するデータプロトコル。118 D.1。 操作上のプロトコル…118 D.1.1。 検索を証明してください…118 D.1.2。 CRL検索…118 D.1.3。 オンライン証明書状態…119 D.1.4。 時間を押し込みます…119 D.2。 管理プロトコル…119 D.2.1。 証明書には、取消しを要求してください…119 別館E(有益な): セキュリティ問題…119 E.1。 秘密鍵の保護…119 E.2。 アルゴリズムの選択…119 別館F(有益な): 例はコンテンツとMIMEを構造化しました…120 F.1。 一般記述…120 F.1.1。 ヘッダー情報…120 F.1.2。 満足しているコード化…121 F.1.3。 複合内容…121 F.2。 S/MIME…122 F.2.1。 pkcs7アプリケーション/パントマイムを使用します…123 F.2.2。 pkcs7アプリケーション/署名を使用します…124 別館G(有益な): ヨーロッパの指示とEESSIとの関係…125 G.1。 序論…125 G.2。 電子署名と指示…126 G.3。 ETSIの電子署名形式と指示の.127G.4。 電子署名.127G.4.1のEESSI規格とクラス。 EESSI標準化の構造…127 G.4.2。 電子署名のクラス…128 G.4.3。 電子署名のクラスとETSIの電子署名形式…128 別館H(有益な): 電子署名トークンの世代と検証のためのAPI…129時間.1。 データ縁どり…129時間.2。 IETFによって定義されたIDUP-GSS-API…131時間.3。 OMGによって定義されたCORBAセキュリティインタフェース…132 別館I(有益な): 暗号アルゴリズム…133 I.1。 アルゴリズムを読みこなしてください…133 I.1.1。 SHA-1…133
Pinkas, et al. Informational [Page 5] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[5ページ]情報のRFC5126cm
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
I.1.2。 一般…133 I.2。 デジタル署名アルゴリズム…134 I.2.1。 DSA…134 I.2.2。 RSA…135 I.2.3。 一般…135 別館J(有益な): 命名の指導…137 J.1。 名前の配分…137 J.2。 レジスト情報へのアクセスを提供します…138 J.3。 命名は計画されます…138 J.3.1。 命名は個々の国民を計画します…138 J.3.2。 命名は組織の従業員を計画します…139
1. Introduction
1. 序論
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/IEC10181-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つの会社などの間で 現在のドキュメントはどんな環境からも独立しています。 どんな環境、例えば、スマートカード、モバイルCommunication加入者識別モジュール(GSM SIM)カードのためのGlobal System、電子署名のための特別なプログラムなどにもそれを適用できます。
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".
Electronic Signaturesのための共同体フレームワークのヨーロッパのDirectiveは電子署名を以下と定義します。 「他の電子データに付属しているか、または論理的に関連していて、認証のメソッドとして機能する電子申込書のデータ。」
An electronic signature, as used in the present document, is a form of advanced electronic signature, as defined in the Directive.
現在のドキュメントで使用される電子署名は高度な電子署名のフォームです、Directiveで定義されるように。
2. Scope
2. 範囲
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].
現在のドキュメントの範囲は電子署名形式だけをカバーしています。 Electronic Signature Policiesの局面はRFC3125[RFC3125]とETSI TR102 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
現在のドキュメントは長期の間に有効なままで残ることができる電子署名を含む多くの電子署名書式を定義します。 これは正当性に関して証拠を含んでいます。
Pinkas, et al. Informational [Page 6] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[6ページ]情報のRFC5126cm
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.
現在のドキュメントは、長期の電子署名に関する必要条件を満たすためにTrusted Service Providers(例えば、Time-押し込むAuthorities)と格納される(例えば、証明書と取消しリストに交差しています)必要があるデータの使用を指定します。
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)";
- RFC3852[4]: 「暗号のメッセージ構文(cm)」。
- ISO/IEC 9594-8/ITU-T Recommendation X.509 [1]: "Information
technology - Open Systems Interconnection - The Directory:
Authentication framework";
- ISO/IEC ITU9594-8/T推薦X.509[1]: 「情報技術--オープン・システム・インターコネクション--ディレクトリ:、」 「認証フレームワーク」。
- RFC 3280 [2]: "Internet X.509 Public Key Infrastructure (PKIX)
Certificate and Certificate Revocation List (CRL) Profile";
- RFC3280[2]: 「X.509公開鍵基盤(PKIX)が証明するインターネットと証明書取消しは(CRL)プロフィールをリストアップします」。
- RFC 3161 [7]: "Internet X.509 Public Key Infrastructure
Time-Stamp Protocol (TSP)".
- RFC3161[7]: 「インターネットX.509公開鍵暗号基盤タイムスタンププロトコル(ティースプーンフル)。」
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(抽象的なSyntax Notation1)[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".
これらの形式はRFC3852[4]で定義されたCMS(暗号のMessage Syntax)に基づいています。 これらの電子署名は「cmの高度な電子署名」のためにこのようにしてCAdESと呼ばれます。
Pinkas, et al. Informational [Page 7] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[7ページ]情報のRFC5126cm
Another document, TS 101 903 [TS101903], describes formats for XML advanced electronic signatures (XAdES) built on XMLDSIG as specified in [XMLDSIG].
別のドキュメント(TS101 903[TS101903])は[XMLDSIG]の指定されるとしてのXMLDSIGで組み込まれたXMLの高度な電子署名(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.
さらに、現在のドキュメントはPublic Key Certificatesと、Attribute Certificatesと、Certificate Revocation Listsとプロトコルをサポートするために信頼できる第三者機関による使用が電子署名作成と合法化の操作をサポートするようにプロトコルが含まれる書式を定義する他のドキュメントを特定します。
Informative annexes include:
有益な別館は:
- illustrations of extended forms of Electronic Signature formats
that protect against various vulnerabilities and examples of
validation processes (Annex B);
- 様々な脆弱性から守る拡張型のElectronic Signature形式のイラストと合法化に関する例は処理されます(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);
- Trusted Service Providers(別館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);
- 電子署名(別館H)の世代と検証をサポートするAPI。
- cryptographic algorithms that may be used (Annex I); and
- 使用されるかもしれない暗号アルゴリズム(別館I)。 そして
- naming schemes (see Annex J).
- 命名は計画されます(Annex Jを見てください)。
3. Definitions and Abbreviations
3. 定義と略語
3.1. Definitions
3.1. 定義
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.
仲裁者: 仲裁者実体は、不一致がデジタル署名の正当性にあるとき、署名者と検証との論争を仲裁するのに使用されるかもしれません。
Pinkas, et al. Informational [Page 8] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[8ページ]情報のRFC5126cm
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.
権威取消しリスト(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.
認証局取消しリスト(カール): 公開鍵証明書のリストを含む取消しリストはもう証明書発行人によって有効であることは考えられない当局を証明に発行しました。
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.
認証局(カリフォルニア): 公開鍵証明書を作成して、割り当てると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)を証明してください: もう証明書発行人によって有効であることは考えられない1セットの公開鍵証明書を示す署名しているリスト。
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].
以下に注意してください。 ISO7498-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].
以下に注意してください。 電子署名[EUDirective]に関してCommunityフレームワークの欧州議会と1999年12月13日のCouncilのDirective1999/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.
電子署名を広げています: 一般的に認識された脅威を扱うためにタイムスタンプトークンや証明書取消しデータなどの追加データに基線要件を補うことによって機能アップされた電子署名。
Pinkas, et al. Informational [Page 9] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[9ページ]情報のRFC5126cm
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なシャミル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.
署名方針: 作成のための1セットの規則と電子署名の合法化特別のビジネス需要を満たすために電子署名作成と合法化のための技術的で手続き上の要件を定義して、署名が有効であることを決定できる。
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.
タイムスタンプトークン: 特定の時間までデータの表現を縛る、その結果、データがその時以前存在したという証拠を確立するデータ・オブジェクト。
Pinkas, et al. Informational [Page 10] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[10ページ]情報のRFC5126cm
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.
タイム・マーク: 特定の時間までデータの表現を縛る、その結果、データがその時以前存在したという証拠を確立するTrusted Service Providerからの監査証跡の情報。
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): 一体にして管理されて、一度に単一のタイムスタンプトークン署名キーをアクティブにする1セットのハードウェアとソフトウェア。
Trusted Service Provider (TSP): an entity that helps to build trust relationships by making available or providing some information upon request.
サービスプロバイダー(ティースプーンフル)は信じました: 要求の何らかの情報を利用可能であるか提供するようにすることによって信頼関係を築き上げるのを助ける実体。
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.
検証: 証拠について確かめる実体。
NOTE 1: See ISO/IEC 13888-1 [ISO13888-1].
注意1: ISO/IEC13888-1[ISO13888-1]を見てください。
NOTE 2: Within the context of the present document, this is an
entity that validates an electronic signature.
注意2: 現在のドキュメントの文脈の中では、これは電子署名を有効にする実体です。
3.2. Abbreviations
3.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
アーカイブ合法化データがあるAA Attribute Authority AARL Attribute Authority Revocation List ACRL Attribute Certificate Revocation List API Application Program Interface ASCII情報交換用米国標準コードASN.1の抽象的なSyntax Notation1カリフォルニア認証局CAD Card Accepting Device CAdES CMS Advanced Electronic Signature CAdES-A CAdES
Pinkas, et al. Informational [Page 11] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[11ページ]情報のRFC5126cm
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
EXtended Long合法化データカールCertificationとeXtended合法化データCAdES-X Long CAdESとのTime CAdES-X CAdESとComplete合法化データCAdES-EPES CAdES Explicit Policy Electronic Signature CAdES-T CAdESとCAdES-BES CAdES Basic Electronic Signature CAdES-C CAdES; 権威取消しの暗号のメッセージ構文CRL証明書失効リストリストcm CWA CEN(欧州標準化委員会)ワークショップ協定DERは政権のために符号化規則(ASN.1のための)DSAデジタル署名アルゴリズムEDIFACT電子データ交換を区別しました; Xを使用して、オンライン商業とヨーロッパの電子明白な方針ベースの電子輸送のES電子署名ESS警備の強化EESSI署名標準化イニシアチブEPES署名サービス(cmを高める)のIDLインターフェース定義言語MIMEマルチパーパスインターネットメールエクステンションOCSPは状態プロバイダーOIDオブジェクト識別子PKC公開鍵証明書PKIX公開鍵暗号基盤を証明します; 509 (IETF作業部会)RSA Rivest-Shamir-Adleman SHA-1は、ハッシュアルゴリズム1TSA時間の刻印権威ティースプーンフルの信じられたサービスプロバイダーTSTタイムスタンプトークンTSUが時間の刻印ユニットURI Uniform Resource Identifier URL Uniform Resource Locator XML拡張マークアップ言語XMLDSIG XMLデジタル署名であると機密保護します。
4. Overview
4. 概要
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に建てる多くのElectronic Signature(ES)書式を定義します。(付加の署名していて未署名の属性によるRFC3852[4])。
This section:
このセクション:
- provides an introduction to the major parties involved
(Section 4.1),
- かかわった大政党(セクション4.1)に序論を提供します。
Pinkas, et al. Informational [Page 12] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[12ページ]情報のRFC5126cm
- 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形式の定義に原理を提供します。
4.1. Major Parties
4.1. 大政党
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.
- 署名者。 - 検証。 - サービスプロバイダー(ティースプーンフル)は信じました。 そして、--仲裁者。
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:
Trusted Service Providers(TSPs)は署名者と検証との信頼関係を築き上げるのを助ける1つ以上の実体です。 支えて、:サービスをサポートすることによって彼らは署名者と検証を支えます。 ユーザー証明書、交差している証明書、タイムスタンプトークン、CRLs、ARLs、およびOCSP応答。 以下のTSPsは現在のドキュメントで定義された機能をサポートするのに使用されます:
- 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応答者。 - 倉庫当局(例えば、ディレクトリ)。 - 時間の刻印当局。 - 当局を時マークします。 そして、--署名方針発行人。
Pinkas, et al. Informational [Page 13] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[13ページ]情報のRFC5126cm
Certification Authorities provide users with public key certificates and a revocation service.
証明Authoritiesは公開鍵証明書と取消しサービスをユーザに提供します。
Registration Authorities allow the identification and registration of entities before a CA generates certificates.
カリフォルニアが証明書を作る前に登録Authoritiesは実体の識別と登録を許します。
Repository Authorities publish CRLs issued by CAs, signature policies issued by Signature Policy Issuers, and optionally public key certificates.
倉庫Authoritiesは任意にCAsによって発行されたCRLs、Signature Policy Issuersによって発行された署名方針を発行します。公開鍵証明書。
Time-Stamping Authorities attest that some data was formed before a given trusted time.
時間を押し込むAuthoritiesは、いくつかのデータが与えられた信じられた時の前に形成されたと証明します。
Time-Marking Authorities record that some data was formed before a given trusted time.
いくつかのデータが与えられた信じられた時の前に形成されたという時間をマークするAuthorities記録。
Signature Policy Issuers define the signature policies to be used by signers and verifiers.
署名Policy Issuersは、署名者と検証によって使用されるために署名方針を定義します。
In some cases, the following additional TSPs are needed:
いくつかの場合、以下の追加TSPsが必要です:
- Attribute Authorities.
- 当局を結果と考えてください。
Attributes Authorities provide users with attributes linked to public key certificates.
属性Authoritiesは公開鍵証明書にリンクされた属性をユーザに提供します。
An Arbitrator is an entity that arbitrates in disputes between a signer and a verifier.
Arbitratorは署名者と検証との論争を調停する実体です。
4.2. Signature Policies
4.2. 署名方針
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.
電子署名を有効にするとき、検証によって使用される署名方針は署名者でどちらも示さないで、他のデータから得ることができるか、または署名方針が不完全であると、仲裁者を含む検証は異なった結果を得るかもしれません。 したがって、両方からの署名者と検証の観点は署名合法化の一貫性を確実にする包括的な署名方針に推薦されます。
Pinkas, et al. Informational [Page 14] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[14ページ]情報のRFC5126cm
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].
- TR102 038[TR102038]。 - 現在のドキュメントのセクション5.8の.1、C.1、およびC.3.1。 - RFC3125[RFC3125]。 そして、--TR102 272[TR102272]。
4.3. Electronic Signature Formats
4.3. 電子署名形式
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 Explicit PolicyベースのElectronic Signature(CAdES-EPES)に概要を供給します。 現在のドキュメントへの順応は、署名者がこれらの形式の1つを作成するのを強制します。
4.3.1. CAdES Basic Electronic Signature (CAdES-BES)
4.3.1. ビャクシン属の木基礎電子の署名(ビャクシン属の木-BES)
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で定義されて、(RFC3852[4])。
- A collection of mandatory signed attributes, as defined in CMS
(RFC 3852 [4]) and in ESS (RFC 2634 [5]);
- 義務的の収集がCMSで定義されるように属性に署名した、(3852[4])とESSのRFC、(RFC2634[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で定義されるように。(RFC3852[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;
- 文書内容。 それは、RFC3852[4]で定義されて、署名されるEncapsulatedContentInfo価値のタイプを指定します。 詳細は.1通の現在のセクション5.7ドキュメントに明らかにされます。 包含のための原理をAnnex C.3.7に提供します。
Pinkas, et al. Informational [Page 15] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[15ページ]情報のRFC5126cm
- 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;
- メッセージダイジェスト。 それは、RFC3852[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.
- ESS署名証明書OR ESS署名証明書v2。 ESS署名証明書属性は、Enhanced Security Services(ESS)、RFC2634[5]で定義されて、ダイジェストアルゴリズムとしてSHA-1の使用を考慮するだけです。 ESS署名証明書v2属性は「ESSは以下をアップデートすること」において定義されます。 「CertID Algorithm Agilityを加えます」、RFC5035[15]、どんなダイジェストアルゴリズムの使用も考慮します。 現在のドキュメントへのコンプライアンスを要求するCAdES-BESは彼らのひとりを含まなければなりません。 セクション5.7.3これらの属性の詳細を明らかにします。 包含のための原理をAnnex 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:
任意の署名している属性はCAdES-BESに加えられるかもしれません、CMSで定義された任意の署名している属性を含んでいて(RFC3852[4])、ESS、(RFC2634[5])、および現在のドキュメント。 以下に記載されているのは、セクション5で定義されて、Annex 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で定義される、(RFC3852[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で定義される、(RFC2634[5])、1つの内容が別のものでカプセル化されるマルチ層のメッセージの最も奥深い署名している内容について説明する情報を提供します。 セクション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.
- 内容照会: ESSで定義される、(RFC2634[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.
- 満足している識別子: ESSで定義される、(RFC2634[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は原理を提供します。
Pinkas, et al. Informational [Page 16] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[16ページ]情報のRFC5126cm
- 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.
- 署名者属性: この属性は現在のドキュメントによって定義されます。 それは、要求されたか公認された役割が署名している情報に組み入れられるのを許容します。 セクション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で定義されるように(RFC3852[4])とESS、(RFC2634[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.
- CounterSignature、CMSで定義されて、(RFC3852[4])。 埋め込まれた署名(すなわち、前の署名の署名)がどこで必要であっても、それを取り入れることができます。 セクション5.9.2仕様詳細を明らかにします。 Annex 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 | |
||| | | | | |
||+---------+ +----------+ | |
|+------------------------------------+ |
+---------------------------------------+
+------Elect.Signature(ビャクシン属の木-BES)------+ |+----------------------------------- + | ||+---------+ +----------+ | | |||署名者のもの| | 署名されます。| Digital| | |||ドキュメント| |属性| 署名| | ||| | | | | | ||+---------+ +----------+ | | |+------------------------------------+ | +---------------------------------------+
Figure 1: Illustration of a CAdES-BES
図1: ビャクシン属の木-BESのイラスト
The signer's conformance requirements of a CAdES-BES are defined in Section 8.1.
署名者のCAdES-BESの順応要件はセクション8.1で定義されます。
Pinkas, et al. Informational [Page 17] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[17ページ]情報のRFC5126cm
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はElectronic Signaturesの上のヨーロッパのDirectiveで定義されるように電子署名のための法的必要条件を満たします(Directiveへの現在のドキュメントの関係のさらなる議論に関してAnnex 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かその文脈の署名しているデータの意味論はそれとなく署名方針を検証に示すかもしれません。
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.
現在のドキュメントの範囲の外に署名方針のコンテンツの仕様があります。 しかしながら、現在のドキュメントのセクション5.8のTR102 038[TR102038]、RFC3125[RFC3125]、.1、C.1、およびC.3.1に署名方針に関する詳細を提供します。
4.3.2. CAdES Explicit Policy-based Electronic Signatures (CAdES-EPES)
4.3.2. ビャクシン属の木、明白な方針ベースの電子署名(ビャクシン属の木-EPES)
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 Explicit PolicyベースのElectronic Signature(CAdES-EPES)は、特定された署名方針に従うために電子署名の定義を広げています。
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 Explicit PolicyベースのElectronic Signature(CAdES-EPES)は、電子署名を有効にするのに使用されるものとする署名方針を示しながら、署名している属性(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署名方針識別子属性の仕様に関する詳細を明らかにします。 別館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.
現在のドキュメントのセクション5.8のTR102 038[TR102038]、.1、C.1、およびC.3.1に署名方針に関する詳細を提供します。
Pinkas, et al. Informational [Page 18] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[18ページ]情報のRFC5126cm
The structure of the CAdES-EPES is illustrated in Figure 2.
CAdES-EPESの構造は図2で例証されます。
+------------- Elect.Signature (CAdES-EPES) ---------------+
| |
|+-------------------------------------------------------+ |
|| +-----------+ | |
|| | | +---------------------------+ | |
|| | | | +----------+ | | |
|| | Signer's | | |Signature | Signed | Digital | |
|| | Document | | |Policy ID | Attributes |Signature| |
|| | | | +----------+ | | |
|| | | +---------------------------+ | |
|| +-----------+ | |
|+-------------------------------------------------------+ |
| |
+----------------------------------------------------------+
+------------- Elect.Signature(ビャクシン属の木-EPES)---------------+ | | |+-------------------------------------------------------+ | || +-----------+ | | || | | +---------------------------+ | | || | | | +----------+ | | | || | 署名者のもの| | |署名| 署名されます。| Digital| | || | ドキュメント| | |方針ID| 属性|署名| | || | | | +----------+ | | | || | | +---------------------------+ | | || +-----------+ | | |+-------------------------------------------------------+ | | | +----------------------------------------------------------+
Figure 2: Illustration of a CAdES-EPES
図2: ビャクシン属の木-EPESのイラスト
The signer's conformance requirements of CAdES-EPES are defined in Section 8.2.
署名者のCAdES-EPESの順応要件はセクション8.2で定義されます。
4.4. Electronic Signature Formats with Validation Data
4.4. 合法化データがある電子署名形式
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.
合法化データは署名者、そして/または、検証によって集められるかもしれません。 属性であると署名される署名方針識別子が存在しているとき、それは署名方針に関する必要条件を満たすものとします。
Pinkas, et al. Informational [Page 19] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[19ページ]情報のRFC5126cm
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.
合法化データはCertificate Revocation Listsの形の取消し状態情報(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-EPESに加えることができる合法化データを含むことができる未署名の属性を定義します、合法化データを含んでいる電子署名形式に通じて。 下のセクションはこれらの書式とそれらの最も関連している特性をまとめます。
4.4.1. Electronic Signature with Time (CAdES-T)
4.4.1. 時間との電子署名(ビャクシン属の木T)
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.
- 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.
Trusted Serviceによって提供されたタイム・マークは署名タイムスタンプ属性に同様の影響を与えるでしょうが、この場合属性は全くESに加えられません、それがそうするのが必要であるときにTSPがタイム・マークに関する証拠を提供する責任であるので。 現在のドキュメントの範囲の外にタイム・マークの管理があります。
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.
長期の正当性を提供することに向かって信じられた時間は初期段階を提供します。 タイムスタンプ属性か時間で著しいビー/EPESとの電子署名であり、形成して、CAdES-Tは図3で例証されます。
Pinkas, et al. Informational [Page 20] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[20ページ]情報のRFC5126cm
+-------------------------------------------------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. | | | +----------------------+ | +------------------------------------------------------------------+
+-------------------------------------------------ビャクシン属の木T---------+ |+------ ビャクシン属の木-BESかビャクシン属の木-EPES-------+ | ||+-----------------------------------+ | +----------------------+ | |||+---------+ +----------+ | | | | | ||||署名者のもの| | 署名されます。| Digital| | | 署名タイムスタンプ| | ||||ドキュメント| |属性| 署名| | | 属性が必要です。| | |||| | | | | | | 使用するときには、調節してください。| | |||+---------+ +----------+ | | | スタンプ。 | | ||+-----------------------------------+ | | | | |+--------------------------------------+ | または、ビー/EPES| | | | 時間で、著しいでしょう。| | | | | | | | そして管理。| | | | 時間の支給| | | | マークはそうです。| | | | 責任| | | | ティースプーンフル。 | | | +----------------------+ | +------------------------------------------------------------------+
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: 完全な証明書参照と完全な取消し参照属性としてそのようなタイムスタンプトークンを有効にするのに現在のドキュメントで定義されるように必要である自分たちでインクルード未署名の属性がそうするかもしれないタイムスタンプトークン。
4.4.2. ES with Complete Validation Data References (CAdES-C)
4.4.2. 完全な合法化データ参照があるES(ビャクシン属の木C)
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.
現在のドキュメントによると、Complete合法化データ参照(CAdES-C)がある電子Signatureは完全な証明書参照と完全な取消し参照属性をCAdES-Tに加えます、現在のドキュメントによって定義されるように。 完全な証明書参照属性は署名について確かめるのに使用される証明経路の現在のすべての証明書の参照を含んでいます。 完全な取消し参照属性は応答が署名について確かめるのに使用したCRLs、そして/または、OCSPsの参照を含んでいます。 セクション6.2は仕様詳細を明らかにします。 参照を保存するのは、証明経路の値とCRLsかOCSPs応答がほかの場所に保存されるのを許容します、保存された電子署名形式のサイズを減少させて。
Pinkas, et al. Informational [Page 21] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[21ページ]情報のRFC5126cm
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.2へのセクションC.4.1は合法化データであって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| | | | | ||+--------------------------------++----------+ | | | | |+-----------------------------------------------+ +-------------+ | +------------------------------------------------------------------+
+------------------------- ビャクシン属の木C--------------------------------+ |+----------------------------- ビャクシン属の木T---------+ | || +----------+ | +-------------+ | || |タイムスタンプ| | | | | || |属性| | | | | ||+ビャクシン属の木-BESかビャクシン属の木-EPES------+|終わる| | | | | ||| ||デジタル| | | 完全| | |||+---------++----------+ ||署名| | | 証明書| | ||||署名者のもの|| 署名されます。| Digital||あります。| | | そして| | ||||ドキュメント||属性|署名||義務的| | | 取消し| | |||| || | ||is| | | 参照| | |||+---------++----------+ ||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: 最小限として、署名者はCAdES-BESか署名が明白な署名方針に従うのを示すときのCAdES-EPESを提供するでしょう。
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: 署名者がCAdES-Cを提供しないとき、署名者とTSPはこの危険を最小にするためにCAdES-Cを提供できました、そして、取消しの必要なコンポーネントであるときに、検証はCAdES-Cを作成するはずです、そして、合法化データは利用可能になります。 これは据置期間を必要とするかもしれません。
Pinkas, et al. Informational [Page 22] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[22ページ]情報のRFC5126cm
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
+ <。--------------据置期間--------->+----+-------+-------+--------+---------------------+----------+ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | 署名| 1番目| 2番目| 作成| 取消し| 取消し| 時間| 状態| 状態| | チェックします。| チェックします。| | | | タイムスタンプCertification Buildか経路CAdES-Cタイム・マーク工事、終わっているのと検証署名
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: CWA14171[CWA14171]は、CAdES-T、CAdES-C、および据置期間を使用することで署名合法化プロセスを指定します。 別館Bは例の合法化プロセスを提供します。 別館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.
検証の順応要件は時間で押し込まれたCAdES-Cのためのセクション8.3、および時間で著しいCAdES-Cのためのセクション8.4で定義されます。 現在のドキュメントはComplete合法化データ(CAdES-C)で検証のための順応要件をESまで定義するだけです。 これは、電子署名の広げられるのとアーカイブフォームのいずれも、セクション4.4の.3〜4.4で.4を定義するので現在のドキュメントに順応を達成するために実装される必要でないことを意味します。
4.4.3. Extended Electronic Signature Formats
4.4.3. 拡張電子署名形式
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
電子署名に未署名の属性を加えることによって、CAdES-Cを広げることができます。 そして現在のドキュメントが非常に長期の検証に、適切な未署名の様々な属性を定義する。
Pinkas, et al. Informational [Page 23] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[23ページ]情報のRFC5126cm
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.
Annexで議論するいくつかの災害状況を防ぐために、C.Annex Bは各タイプと、電子署名合法化プロセスの中でどうそれらを使用できるかに様々な拡張フォーマット、すべての必要な未署名の属性の詳細を明らかにします。 下のセクションは現在のドキュメントの様々なフォームの拡張署名形式の概要を与えます。
4.4.3.1. EXtended Long Electronic Signature (CAdES-X Long)
4.4.3.1. 拡張長い電子署名(ビャクシン属の木X長さ)
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.
現在のドキュメントによると、拡張Long形式(CAdES-X Long)は証明書値と取消し値の属性をCAdES-C形式に加えます。 最初のものは署名について確かめるのに必要である全体の証明書経路を含んでいます。 2番目のものはCRLsを含んでいます、そして、/OCSP応答が署名の合法化に必要です。 これは、情報がCAdES-Cを有効にするのを必要とした証明書と取消しの知られている倉庫を前提として、そのような情報が失せるのを防ぎます。 セクション6.3 .3 そして、.4が仕様詳細を述べる6.3。 別館B.1.1は形式の生産に関する詳細を述べます。 C.4.2へのC4.1が原理を供給する別館。
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 | | | || +-------------+ | | |+-----------------------------------------------+ | | | +------------------------------------------------------------------+
+----------------------- ビャクシン属の木Xは切望されます。-----------------------------+ |+------------------------------------ ビャクシン属の木C--+| || +----------+ | +-------------+ | ||+------ ビャクシン属の木-------------------+|タイムスタンプ| | | | | ||| || 終わる| | | 完全| | |||+---------++----------+ ||デジタル| | | 証明書| | ||||署名者のもの|| 署名されます。| Digital||署名| | | そして| | ||||ドキュメント||属性|署名|| | | | 取消し| | |||| || | ||任意| | | データ| | |||+---------++----------+ ||いつ| | | | | ||+--------------------------------+|timemarkedしました。| | | | | || +----------+ | | | | || +-------------+ | +-------------+ | || | 完全| | | || | 証明書| | | || | そして| | | || | 取消し| | | || | 参照| | | || +-------------+ | | |+-----------------------------------------------+ | | | +------------------------------------------------------------------+
Figure 6: Illustration of CAdES-X-Long
図6: ビャクシン属の木X長さのイラスト
Pinkas, et al. Informational [Page 24] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[24ページ]情報のRFC5126cm
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.
現在のドキュメントによると、時間タイプ1(CAdES-X Type1)がある拡張フォーマットはCAdES Cが時押し込んでいる属性を加えます、CAdES-C形式に。(属性の内容はCAdES-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.
これは保全と信じられた時間保護をすべての要素と参照の上に供給します。 それはカリフォルニアキー、CRLキー、またはOCSP発行人キーの後の感染の場合に証明書、CRLs、および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 Type1形式の構造は図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 | | | || +-------------+ | | |+----------------------------------------------------+ | +---------------------------------------------------------------------+
+----------------------- ビャクシン属の木Xがタイプされた1------------------------------+ |+-------------------------------------- ビャクシン属の木C-----+ | || +-------------+ | +-----------+ | ||+--------- ビャクシン属の木------------------+| タイムスタンプ| | | | | ||| || 終わる| | | | | |||+---------++----------+ || デジタル| | | | | ||||署名者のもの|| 署名されます。| Digital|| 署名| | | タイムスタンプ| | ||||ドキュメント||属性| 署名|| | | | 終わる| | |||| || | || 任意| | | ビャクシン属の木C| | |||+---------++----------+ || いつ| | | | | ||+----------------------------------+| 時間で、著しいです。| | | | | || +-------------+ | | | | || +-------------+ | +-----------+ | || | 完全| | | || | 証明書| | | || | そして| | | || | 取消し| | | || | 参照| | | || +-------------+ | | |+----------------------------------------------------+ | +---------------------------------------------------------------------+
Figure 7: Illustration of CAdES-X Type 1
図7: ビャクシン属の木Xタイプ1のイラスト
Pinkas, et al. Informational [Page 25] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[25ページ]情報のRFC5126cm
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.
現在のドキュメントによると、時間タイプ2(CAdES-X Type2)がある拡張フォーマットは内容が証明経路と取消し情報参照でのタイムスタンプトークンであるCAdES C時間が本命crls参照をスタンプで押している属性を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.
それはカリフォルニアキー、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 Type1とCAdES-X Type2の両方が同じ脅威に対抗します、そして、1かもう片方の用法は環境に依存します。 セクション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 Type2形式の構造は図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 | | | || +-------------+ | | |+---------------------------------------------------+ | +---------------------------------------------------------------------+
+------------------------- ビャクシン属の木Xがタイプされた2----------------------------+ |+----------------------------------------ビャクシン属の木C---+ | || +------------+| | ||+----- ビャクシン属の木-----------------------+| タイムスタンプ|| | ||| || 終わる|| | |||+---------+ +----------+ || デジタル|| +-------------+| ||||署名者のもの| | 署名されます。| Digital|| 署名|| | タイムスタンプ|| ||||ドキュメント| |属性| 署名|| || | 唯一|| |||| | | | || 任意|| | 完全|| |||+---------+ +----------+ || いつ|| | 証明書|| ||+-----------------------------------+| timemarkedしました。|| | そして|| || +------------+| | 取消し|| || +-------------+ | | 参照|| || | 完全| | +-------------+| || | 証明書| | | || | そして| | | || | 取消し| | | || | 参照| | | || +-------------+ | | |+---------------------------------------------------+ | +---------------------------------------------------------------------+
Figure 8: Illustration of CAdES-X Type 2
エイト環: ビャクシン属の木Xタイプ2のイラスト
Pinkas, et al. Informational [Page 26] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[26ページ]情報のRFC5126cm
4.4.3.4. EXtended Long Electronic Signature with Time (CAdES-X Long
Type 1 or 2)
4.4.3.4. 時間との拡張長い電子署名(ビャクシン属の木X長いタイプ1か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.
現在のドキュメントによると、Time(CAdES-X Long Type1か2)と拡張LongはCAdES-X Longの組み合わせと2つの元タイプのひとり(CAdES-X Type1とCAdES-X Type2)です。 別館B.1.4は時間の刻印プロセスの生産に関する詳細を述べます。 Annex 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 Type1とCAdES-X Long Type2形式の構造は図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 | | | +------------+ | +-------------------------------------------------------------------+
+------------------ ビャクシン属の木X長いタイプ1か2-----------------------+ | +--------------+| |+-------------------------------------- ビャクシン属の木C--+|+------------+|| || ||| タイムスタンプ||| ||+------- ビャクシン属の木--------------------++----------+ ||| 終わる||| ||| ||タイムスタンプ| ||| ビャクシン属の木C||| ||| ||終わる| ||+------------+|| |||+---------++----------+ ||デジタル| || OR|| ||||署名者のもの|| 署名されます。| Digital||署名| ||+------------+|| ||||ドキュメント||属性| 署名|| | ||| タイムスタンプ||| |||| || | ||任意| ||| 唯一||| |||+---------++----------+ ||いつ| ||| 完全||| ||+----------------------------------+|timemarkedしました。| ||| 証明書||| || +----------+ ||| そして||| || ||| 取消し||| || +-------------+ ||| 参照||| || | 完全| ||+------------+|| || | 証明書| |+--------------+| || | そして| | +------------+ | || | 取消し| | | 完全| | || | 参照| | |証明書| | || +-------------+ | | そして| | |+-------------------------------------------------+ |取消し| | | | 値| | | +------------+ | +-------------------------------------------------------------------+
Figure 9: Illustration of CAdES-X Long Type 1 and CAdES Long Type 2
図9: ビャクシン属の木X長いタイプ1とビャクシン属の木のイラストは長い間、2をタイプします。
4.4.4. Archival Electronic Signature (CAdES-A)
4.4.4. 記録保管所の電子署名(ビャクシン属の木a)
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
記録保管所のForm、(1つ以上のタイムスタンプを格納している属性を加えるのによる現在のドキュメント、CAdES-X Longの上の体格またはCAdES-X Long Type1か2に従ったCAdES-a)。 このフォームは長期の署名で記録保管所で使用されています。 連続したタイムスタンプは被害を受け易い論じ尽くすアルゴリズムか壊すことに対して全体の材料を保護します。
Pinkas, et al. Informational [Page 27] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[27ページ]情報のRFC5126cm
of the cryptographic material or algorithms. Section 6.4 contains the specification details. Sections C.4.5 and C.4.8 provide the rationale.
暗号では、材料かアルゴリズムセクション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 | | | || +------------+ | | |+----------------------------------------------------+ | +--------------------------------------------------------------------+
+---------------------------ビャクシン属の木A---------------------------------+ |+----------------------------------------------------+ | || +--------------+| +----------+ | ||+----------------------ビャクシン属の木C----+|+------------+|| | | | ||| +----------+ ||| タイムスタンプ||| | | | |||+---- ビャクシン属の木-BES----+|タイムスタンプ| ||| 終わる||| | | | |||| または、ビャクシン属の木-EPES|| 終わる| ||| ビャクシン属の木C||| | アーカイブ| | |||| ||デジタル| ||+------------+|| | | | |||| ||署名| || または|| |タイムスタンプ| | |||| || | ||+------------+|| | | | |||| ||任意| ||| タイムスタンプ||| | | | |||| ||いつ| ||| 唯一||| | | | |||| ||Timemarkedしました。| ||| 完全||| | | | |||+-------------------+| | ||| 証明書||| +----------+ | ||| +----------+ ||| そして||| | ||| +-------------+ ||| 取消し||| | ||| | 完全| ||| 参照||| | ||| | 証明書| ||+------------+|| | ||| | そして| |+--------------+| | ||| | 取消し| | +------------+ | | ||| | 参照| | | 完全| | | ||| +-------------+ | |証明書| | | ||| | | そして| | | ||+----------------------------------+ |取消し| | | || | 値| | | || +------------+ | | |+----------------------------------------------------+ | +--------------------------------------------------------------------+
Figure 10: Illustration of CAdES-A
図10: ビャクシン属の木Aのイラスト
4.5. Arbitration
4.5. 仲裁
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;
- 仲裁者は、どこで応答がCAdES-Cで参照をつけた署名者の証明書(まして、既にプレゼント)かすべての交差している証明書と必要なCRLsか、ACRLsか、OCSPを検索するかを知っています。
Pinkas, et al. Informational [Page 28] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[28ページ]情報のRFC5126cm
- 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での時間マークが使用していることにされるのであるとき、TimeをマークしているAuthorityからの信頼できる監査証跡は時間に関して試験に利用可能です。
- 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.
- 明らかかそれとなく署名方針を特定できるなら、仲裁者は、規則が電子署名を有効にするのが必要であることを決定できます。
4.6. Validation Process
4.6. 合法化プロセス
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.
不完全な合法化応答は、署名合法化状態が現在未知であることを示します。 不完全な合法化の場合では、追加情報をアプリケーションかユーザにとって利用可能にするかもしれません、その結果、彼らが、電子署名で何をしたらよいかを決めるのを許容します。 不完全な合法化の場合では、電子署名は追加情報が利用可能になるいつかの後の時代に再びチェックされるかもしれません。
Pinkas, et al. Informational [Page 29] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[29ページ]情報のRFC5126cm
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.
例の合法化系列はAnnex Bで例証されます。
5. Electronic Signature Attributes
5. 電子署名属性
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.
このセクションは既存のCryptographic Message Syntax(CMS)を当てにします、RFC3852[4]、およびEnhanced Security Services(ESS)で定義されるように、RFC2634[5]で定義されるように。 Electronic Signatureの全体的な構造がCMSで定義されるようにあります。Electronic Signature(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.
属性の強制されたセットとデジタル署名値は現在のドキュメントによって必要とされた最小のElectronic Signature(ES)と定義されます。 署名方針は、他の署名している属性が存在しているのを強制するかもしれません。
5.1. General Syntax
5.1. 一般構文
The general syntax of the ES is as defined in CMS (RFC 3852 [4]).
ESの一般的な構文が定義されるとしてCMSにあります。(RFC3852[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はイドデータ、イド-signedData、イド-envelopedData、イド-digestedData、イド-encryptedData、およびイド-authenticatedDataのためにcontent typeを定義します。 CMSは、他のドキュメントが他のcontent typeを定義するのを可能にしますが、タイプが定義したASN.1はCHOICEタイプであるべきではありません。 現在のドキュメントは他のcontent typeを定義しません。
5.2. Data Content Type
5.2. データcontent type
The data content type of the ES is as defined in CMS (RFC 3852 [4]).
ESのデータcontent typeが定義されるとしてCMSにあります。(RFC3852[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.
以下に注意してください。 content typeがイドデータであるなら、内容がMIMEを使用することでコード化されて、MIMEの種類がデータのプレゼンテーション形式を特定するのに使用されるのは、お勧めです。 Annex F.1を見て、使用MIMEに関する例はコード化しているタイプを特定してください。
5.3. Signed-data Content Type
5.3. 署名しているデータcontent type
The Signed-data content type of the ES is as defined in CMS (RFC 3852 [4]).
ESのSigned-データcontent typeが定義されるとしてCMSにあります。(RFC3852[4])。
Pinkas, et al. Informational [Page 30] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[30ページ]情報のRFC5126cm
5.4. SignedData Type
5.4. SignedDataはタイプします。
The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 [4]).
ESのSignedDataの構文が定義されるとしてCMSにあります。(RFC3852[4])。
The fields of type SignedData are as defined in CMS (RFC 3852 [4]).
タイプSignedDataの分野が定義されるとしてCMSにあります。(RFC3852[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を見てください)。 合法化方針はある証明書の存在のための要件を指定するかもしれません。 堕落したケースは現在のドキュメントで署名者が全くないところで有効ではありません。
5.5. EncapsulatedContentInfo Type
5.5. EncapsulatedContentInfoはタイプします。
The syntax of the EncapsulatedContentInfo type ES is as defined in CMS (RFC 3852 [4]).
EncapsulatedContentInfoタイプESの構文が定義されるとしてCMSにあります。(RFC3852[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が存在しているか、または署名されるデータが道などのように中にどんなzデータの符号化も保存するほど格納されるのが、賢明です。 検証か仲裁者のどちらかが署名を有効にするときはいつも、署名を生成するのに使用される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.
- それが存在していると、これで、どれが、署名しているデータがSignedData構造でカプセル化されるのを署名しているデータと署名の両方を含むことができるか。 しかしながら、署名しているデータは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.
- それがなくなるとき、これは、別々に署名から署名しているデータを送るか、または保存するのを許容します、そして、SignedData構造は署名を含むだけです。 署名の場合では、唯一のそれは道などのようにどんなzデータの符号化も保存するほど保存されて、分配されるその必要性であると署名されるデータです。
The degenerate case where there are no signers is not valid in the present document.
署名者が全くない堕落したケースは現在のドキュメントで有効ではありません。
5.6. SignerInfo Type
5.6. SignerInfoはタイプします。
The syntax of the SignerInfo type ES is as defined in CMS (RFC 3852 [4]).
SignerInfoタイプESの構文が定義されるとしてCMSにあります。(RFC3852[4])。
Pinkas, et al. Informational [Page 31] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[31ページ]情報のRFC5126cm
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.
1署名者あたりの情報はタイプSignerInfoで表されます。 複数の独立している署名(Annex 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で意味を定義します。(しかし、RFC3852[4])、signedAttrs分野は以下の属性を含むものとします:
- content-type, as defined in Section 5.7.1; and
- セクション5.7.1で定義されるようなcontent type そして
- message-digest, as defined in Section 5.7.2;
- セクション5.7.2で定義されるようなメッセージダイジェスト
- signing-certificate, as defined in Section 5.7.3.
- セクション5.7.3で定義されるように署名で証明します。
5.6.1. Message Digest Calculation Process
5.6.1. メッセージダイジェスト計算過程
The message digest calculation process is as defined in CMS (RFC 3852 [4]).
メッセージダイジェスト計算過程が定義されるとしてCMSにあります。(RFC3852[4])。
5.6.2. Message Signature Generation Process
5.6.2. メッセージ署名発生経過
The input to the message signature generation process is as defined in CMS (RFC 3852 [4]).
メッセージ署名発生経過への入力が定義されるとしてCMSにあります。(RFC3852[4])。
5.6.3. Message Signature Verification Process
5.6.3. メッセージ署名照合プロセス
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で定義されます。([4])の、そして、現在で高められたRFC3852は以下を記録します。 署名照合プロセスへの入力は署名者の公開鍵であるに違いありません、すなわち、RFC5035[16]からのSigningCertificateV2かESS[5]からのSigningCertificateが使用されているときSigningCertificateからの証明書識別子の系列で特定された最初の証明書からの公開鍵がデジタル署名について確かめるのに使用されるキーであるに違いありません。(それは、署名証明書の参照を含む署名証明書参照属性を使用することで同じくらい正しい状態で確かめられるものとします)。
5.7. Basic ES Mandatory Present Attributes
5.7. 基本的なES義務的な現在の属性
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で定義されます。(RFC3852[4])。
5.7.1. content-type
5.7.1. content type
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.
content type属性は署名している内容のタイプを示します。 content type属性タイプの構文が定義されるとしてCMSにあります。(RFC3852[4])部11.1。
Pinkas, et al. Informational [Page 32] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[32ページ]情報のRFC5126cm
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: RFC3852[4]に述べられているように、content type属性でEncapsulatedContentInfo価値のeContentTypeと等しい値の(すなわち、ContentType)に署名しなければなりません。
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: 署名世代をサポートする実装において、eContentがMIMEを使用することでコード化されるのは、content type属性がイドデータであるならお勧めです。 署名照合をサポートする実装のために、署名しているデータ(すなわち、eContent)がMIMEによってコード化されているなら、content type属性のOIDはイドデータでなければなりません。 どちらの場合も、データのプレゼンテーション形式を特定するのにMIME content typeを使用しなければなりません。 さらに詳しい明細についてはMIMEの使用に関してAnnex Fを見てください。
5.7.2. Message Digest
5.7.2. メッセージダイジェスト
The syntax of the message-digest attribute type of the ES is as defined in CMS (RFC 3852 [4]).
ESのメッセージダイジェスト属性タイプの構文が定義されるとしてCMSにあります。(RFC3852[4])。
5.7.3. Signing Certificate Reference Attributes
5.7.3. 証明書参照が属性であると署名します。
The Signing certificate reference attributes are supported by using either the ESS signing-certificate attribute or the ESS-signing-certificate-v2 attribute.
Signing証明書参照属性は、ESS署名証明書属性か証明書v2に署名するESS属性のどちらかを使用することによって、サポートされます。
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.
- アルゴリズムを論じ尽くすSHA-1が使用されているなら、ESS[5]で定義されたESS署名証明書属性を使用しなければなりません。
- 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署名証明書v2属性であって、「ESSは以下をアップデートすること」における定義にされる 「CertID Algorithm Agilityを加えます」、RFC5035[15](他ときにアルゴリズムを論じ尽くしながら、使用されるものとする)は使用されていることになっています。
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.
系列(すなわち、署名者からの証明書)で署名について確かめるのに使用されるべき証明書は特定されるものとします、そして、系列は空にならないでしょう。 すべての証明書を含むかもしれないプレゼントが信頼アンカーに上がったなら、署名合法化方針は他の証明書を強制するかもしれません。
Pinkas, et al. Informational [Page 33] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[33ページ]情報のRFC5126cm
5.7.3.1. ESS signing-certificate Attribute Definition
5.7.3.1. ESS署名証明書Attribute Definition
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の署名証明書属性タイプの構文は、Enhanced Security Services(ESS)、RFC2634[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署名証明書属性は署名している属性になるでしょう。 この証明書のためのESSCertIDのコード化はissuerSerial分野を含んでいるものとします。
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分野のissuerAndSerialNumberはESSCertIDの現在のissuerSerial分野に合っているものとします。 さらに、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.
以下に注意してください。 属性証明書はどこで署名者によって使用されるか、そして、役割を関連づけるか、電子署名がある署名者の他の属性。 これはセクション5.8.3で定義されるように署名者属性属性に置かれます。
5.7.3.2. ESS signing-certificate-v2 Attribute Definition
5.7.3.2. ESS署名証明書v2 Attribute Definition
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.
ESS署名証明書v2属性は上で定義されたESS署名証明書と同様です、SHA-1以外のアルゴリズムを論じ尽くすと共にこの属性を使用できるのを除いて。
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は以下をアップデートすること」において定義されるようにあります。 RFC5035[15]の、そして、一層の「付加CertID Algorithm Agility」は現在のドキュメントで資格を得ました。
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 }
この属性のためのオブジェクト識別子は以下の通りです。 イド-aa-signingCertificateV2オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)47をメンバーと同じくらい具体化させます。
Pinkas, et al. Informational [Page 34] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[34ページ]情報のRFC5126cm
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分野のissuerAndSerialNumberはESSCertIDv2の現在のissuerSerial分野に合っているものとします。 さらに、ESSCertIDv2からのcertHashはhashAlgorithm分野で指定されたハッシュ関数を使用することで計算された証明書のハッシュに合っているものとします。 特定された証明書は署名照合プロセスの間、使用されるものとします。 証明書のハッシュが署名について確かめるのに使用される証明書に合っていないなら、署名は無効であると考えられるものとします。
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: セクション5.7を見てください。RFC3126がもう片方の署名証明書属性を使用していた、(.3 同じ目的のための.3)。 この構造が、より簡単であるので、使用は現在、推奨しないです。
5.7.3.3. Other signing-certificate Attribute Definition
5.7.3.3. 他の署名証明書Attribute Definition
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.
SHA-1以外のアルゴリズムを論じ尽くすとき、ESS署名証明書への代替手段が使用されていたとき、RFC3126はもう片方の署名証明書属性を使用していました。 署名証明書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 }
イド-aa-ets-otherSigCertオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)19をメンバーと同じくらい具体化させます。
The other-signing-certificate attribute value has the ASN.1 syntax OtherSigningCertificate:
他に署名している証明書の属性値には、ASN.1構文OtherSigningCertificateがあります:
OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THE PRESENT DOCUMENT }
OtherSigningCertificate:、:= 系列本命SEQUENCE OF OtherCertID、方針SEQUENCE OF PolicyInformation OPTIONAL--、NOT USED IN THE PRESENT DOCUMENT
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL }
OtherCertID:、:= 系列otherCertHash OtherHashで、issuerSerial IssuerSerial任意です。
OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue}
OtherHash:、:= 選択sha1Hash OtherHashValue、--これがSHA-1ハッシュotherHash OtherHashAlgAndValueを含んでいる
OtherHashValue ::= OCTET STRING
OtherHashValue:、:= 八重奏ストリング
Pinkas, et al. Informational [Page 35] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[35ページ]情報のRFC5126cm
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue }
OtherHashAlgAndValue:、:= 系列hashAlgorithm AlgorithmIdentifier、hashValue OtherHashValue
5.8. Additional Mandatory Attributes for Explicit Policy-based
Electronic Signatures
5.8. 明白な方針ベースの電子署名のための追加義務的な属性
5.8.1. signature-policy-identifier
5.8.1. 署名方針識別子
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-EPESに関して、署名方針の指示するものがsignedDataに含まれているのを強制します。 この参照は明らかに特定されます。 署名方針は、電子署名の作成と合法化のために規則を決めて、あらゆるExplicit PolicyベースのElectronic Signatureと共に署名している属性として含まれています。 署名方針識別子は署名している属性になるでしょう。
The following object identifier identifies the signature-policy-identifier attribute:
以下のオブジェクト識別子は署名方針識別子属性を特定します:
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 }
イド-aa-ets-sigPolicyIdオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)15をメンバーと同じくらい具体化させます。
signature-policy-identifier attribute values have ASN.1 type SignaturePolicyIdentifier:
署名方針識別子属性値で、ASN.1はSignaturePolicyIdentifierをタイプします:
SignaturePolicyIdentifier ::= CHOICE {
signaturePolicyId SignaturePolicyId,
signaturePolicyImplied SignaturePolicyImplied
-- not used in this version
}
SignaturePolicyIdentifier:、:= 選択signaturePolicyId SignaturePolicyId、signaturePolicyImplied SignaturePolicyImplied--このバージョンでは、使用されません。
SignaturePolicyId ::= SEQUENCE {
sigPolicyId SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL}
SignaturePolicyId:、:= 系列sigPolicyId SigPolicyId、sigPolicyHash SigPolicyHash、SigPolicyQualifierInfo任意のsigPolicyQualifiers系列サイズ(1..MAX)
SignaturePolicyImplied ::= NULL
SignaturePolicyImplied:、:= ヌル
Pinkas, et al. Informational [Page 36] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[36ページ]情報のRFC5126cm
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
SigPolicyId:、:= オブジェクト識別子
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の中のhashValueは方針ハッシュ値が知られていないのを示すようにゼロに用意ができるかもしれません。
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
SigPolicyHash:、:= OtherHashAlgAndValue
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue }
OtherHashAlgAndValue:、:= 系列hashAlgorithm AlgorithmIdentifier、hashValue OtherHashValue
OtherHashValue ::= OCTET STRING
OtherHashValue:、:= 八重奏ストリング
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:
Signature Policy Identifierは資格を与える人の他の情報で資格があるかもしれません。 資格を与える人の意味論と構文はsigPolicyQualifierId分野のオブジェクト識別子に関連しています。 この資格を与える人の一般的な構文は以下の通りです:
SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId }
SigPolicyQualifierInfo:、:= 系列sigPolicyQualifierId SigPolicyQualifierId、sigPolicyQualifierIdによって少しも定義されたsigQualifier
Pinkas, et al. Informational [Page 37] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[37ページ]情報のRFC5126cm
The present document specifies the following qualifiers:
現在のドキュメントは以下の資格を与える人を指定します:
- spuri: this contains the web URI or URL reference to the
signature policy, and
- spuri: そしてこれが署名方針のウェブURIかURL参照を含んでいる。
- sp-user-notice: this contains a user notice that should be
displayed whenever the signature is validated.
- spユーザ通知: これは署名が有効にされるときはいつも、表示されるべきであるユーザ通知を含んでいます。
sigpolicyQualifierIds defined in the present document:
SigPolicyQualifierId ::= OBJECT IDENTIFIER
現在で定義されたsigpolicyQualifierIdsは以下を記録します。 SigPolicyQualifierId:、:= オブジェクト識別子
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 }
イド-spq-ets-uri OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-spq(5)1をメンバーと同じくらい具体化させます。
SPuri ::= IA5String
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 }
イド-spq-ets-unotice OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-spq(5)2をメンバーと同じくらい具体化させます。
SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
SPUserNotice:、:= 系列noticeRef NoticeReference任意であって、explicitText DisplayText任意です。
NoticeReference ::= SEQUENCE {
NoticeReference:、:= 系列
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
組織DisplayText、noticeNumbers SEQUENCE OF INTEGER
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
DisplayText:、:= 選択visibleString VisibleString(サイズ(1 .200))、bmpString BMPString(サイズ(1 .200))、utf8String UTF8String(サイズ(1 .200))
5.9. CMS Imported Optional Attributes
5.9. 任意の属性であるとインポートされたcm
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で定義される、(RFC3852[4])、現在のドキュメントにインポートされます。 適切であるところでは、属性は、現在のドキュメントによって資格があって、輪郭を描かれます。
5.9.1. signing-time
5.9.1.署名時間
The signing-time attribute specifies the time at which the signer claims to have performed the signing process.
署名時間属性は署名者がサインアップ過程を実行したと主張する時を指定します。
Pinkas, et al. Informational [Page 38] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[38ページ]情報のRFC5126cm
Signing-time attribute values for ES have the ASN.1 type SigningTime as defined in CMS (RFC 3852 [4]).
ASN.1はCMSで定義されるようにESのための署名時間属性値でSigningTimeをタイプします。(RFC3852[4])。
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.
以下に注意してください。 RFC3852[4]は、UTCTimeとして1950年1月1日と2049年12月31日(包括的な)の間の日付をコード化しなければならないと述べます。 GeneralizedTimeとして1950の前か2049以降年の値があるどんな日付もコード化しなければなりません。
5.9.2. countersignature
5.9.2. 副署
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.
ASN.1はCMSで定義されるようにESのための副署属性値でCounterSignatureをタイプします。(RFC3852[4])。 副署属性は未署名の属性になるでしょう。
5.10. ESS-Imported Optional Attributes
5.10. ESSによってインポートされた任意の属性
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で定義されて、現在のドキュメントにインポートされて、適切に資格があって、輪郭を描かれます。
5.10.1. content-reference Attribute
5.10.1. 内容照会Attribute
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.
内容照会属性は1SignedDataから別のものへのリンクです。 それは、それが参照されるオリジナルのメッセージに回答をリンクするか、または参照で1SignedDataを別のものに組み込むのに使用されるかもしれません。 内容照会属性は署名している属性になるでしょう。
content-reference attribute values for ES have ASN.1 type ContentReference, as defined in ESS (RFC 2634 [5]).
ASN.1はESSで定義されるようにESのための内容照会属性値でContentReferenceをタイプします。(RFC2634[5])。
The content-reference attribute shall be used as defined in ESS (RFC 2634 [5]).
内容照会属性はESSで定義されるように使用されるものとします。(RFC2634[5])。
5.10.2. content-identifier Attribute
5.10.2. 満足している識別子Attribute
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 attribute type values for the ES have an ASN.1 type ContentIdentifier, as defined in ESS (RFC 2634 [5]).
ASN.1はESSで定義されるようにESのための内容識別子属性タイプ値でContentIdentifierをタイプします。(RFC2634[5])。
The minimal content-identifier attribute should contain a concatenation of user-specific identification information (such as a
最小量の満足している識別子属性がユーザ特有の識別情報の連結を含むべきである、(aなど
Pinkas, et al. Informational [Page 39] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[39ページ]情報のRFC5126cm
user name or public keying material identification information), a GeneralizedTime string, and a random number.
ユーザ名か公共の合わせる材料確認情報)、GeneralizedTimeストリング、および乱数。
5.10.3. content-hints Attribute
5.10.3. 満足しているヒントAttribute
The content-hints attribute provides information on the innermost signed content of a multi-layer message where one content is encapsulated in another.
満足しているヒント属性は1つの内容が別のものでカプセル化されるマルチ層のメッセージの最も奥深い署名している内容の情報を提供します。
The syntax of the content-hints attribute type of the ES is as defined in ESS (RFC 2634 [5]).
ESの満足しているヒント属性タイプの構文が定義されるとしてESSにあります。(RFC2634[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は関連内容のタイプを示します。 content typeを定義するのは、権威によって割り当てられたオブジェクト識別子(すなわち、整数のユニークなストリング)です。 そして
- when the contentType is id-data, the contentDescription shall
define the presentation format; the format may be defined by
MIME types.
- contentTypeがイドデータであるときに、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]);
- contentTypeがCMSで定義されるようにイドデータになる、(RFC3852[4])。
- 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.
- contentDescriptionはデータのコード化を示すのに使用されて、規則に従って、RFC2045[6]を定義しました。 構造化されたコンテンツとMIMEの例に関してAnnex Fを見てください。
NOTE 1: id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
注意1: イドデータOBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(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で任意です。(RFC2634[5])。 それはほかの場所で定義されたcontentTypesの補足となるのに使用されるかもしれません。 現在のドキュメントの範囲の外にそのような定義があります。
5.11. Additional Optional Attributes Defined in the Present Document
5.11. 現在のドキュメントで定義された追加任意の属性
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
そして/またはb) 署名が実行される要求された位置。
Pinkas, et al. Informational [Page 40] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[40ページ]情報のRFC5126cm
c) claimed attributes or certified attributes of the signer,
and/or
そして/またはc)が署名者の属性か公認された属性を要求した。
d) a content time-stamp applied before the content was signed.
d) 内容が署名される前に満足しているタイムスタンプは適用されました。
5.11.1. commitment-type-indication Attribute
5.11.1. 委任タイプ指示Attribute
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.
署名方針はそれが「認識する」1セットの属性を指定します。 この「認識された」セットは署名方針の一部と定義されたそれらのすべての委任タイプを含んでいます、方針が見分けるのを選ぶかもしれないどんな外部的に定義された委任タイプと同様に。 認識された委任タイプだけがこの分野に許容されています。
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}
イド-aa-ets-commitmentTypeオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)16をメンバーと同じくらい具体化させます。
commitment-type-indication attribute values have ASN.1 type CommitmentTypeIndication.
委任タイプ指示属性値で、ASN.1はCommitmentTypeIndicationをタイプします。
CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
CommitmentTypeQualifier OPTIONAL}
CommitmentTypeIndication:、:= 系列commitmentTypeId CommitmentTypeIdentifier、CommitmentTypeQualifier任意のcommitmentTypeQualifier系列サイズ(1..MAX)
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeIdentifier:、:= オブジェクト識別子
Pinkas, et al. Informational [Page 41] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[41ページ]情報のRFC5126cm
CommitmentTypeQualifier ::= SEQUENCE {
commitmentTypeIdentifier CommitmentTypeIdentifier,
qualifier ANY DEFINED BY commitmentTypeIdentifier }
CommitmentTypeQualifier:、:= 系列commitmentTypeIdentifier CommitmentTypeIdentifier、資格を与える人いずれも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}
イド-cti-ets-proofOfOriginオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfReceiptオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfDeliveryオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfSenderオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfApprovalオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfCreationオブジェクト識別子:、:= iso(1)は(2) 私たち(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が指示であるならメッセージの受取人にとって、アクセスしやすい地元の小売店で伝言をもたらしたのを示します。
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.
承認の証拠は、署名者がメッセージの内容を承認したのを示します。
Pinkas, et al. Informational [Page 42] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[42ページ]情報のRFC5126cm
Proof of creation indicates that the signer has created the message (but not necessarily approved, nor sent it).
作成の証拠は、署名者がメッセージ(しかし、必ず承認されて、それは送られない)を作成したのを示します。
5.11.2. signer-location Attribute
5.11.2. 署名者位置のAttribute
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]).
署名者位置の属性は特定の地理的な(例えば、都市)位置の署名者に関連しているアドレスにニーモニックを指定します。 ニーモニックは、署名者が位置している国に登録されて、Public Telegram Serviceの設備に使用されます。(ITU-T Recommendation 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}
イド-aa-ets-signerLocationオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)17をメンバーと同じくらい具体化させます。
Signer-location attribute values have ASN.1 type SignerLocation:
署名者位置の属性値で、ASN.1はSignerLocationをタイプします:
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 }
SignerLocation:、:= 系列--X.500 postalAdddress[2]の場所をPostalAddress OPTIONALと命名するのに使用されるようにX.500 localityName[1]DirectoryString OPTIONALで名前a Countryに使用されて、少なくとも以下の1つが[0] プレゼント: countryNameがDirectoryString OPTIONALであったならそうする
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString
PostalAddress:、:= DirectoryStringの系列サイズ(1 .6)
5.11.3. signer-attributes Attribute
5.11.3. 署名者属性Attribute
The signer-attributes attribute specifies additional attributes of the signer (e.g., role). It may be either:
署名者属性属性は署名者(例えば、役割)の追加属性を指定します。 それはどちらかであるかもしれません:
- claimed attributes of the signer; or
- 署名者の要求された属性。 または
- certified attributes of the signer.
- 署名者の公認された属性。
The signer-attributes attribute shall be a signed attribute. The following object identifier identifies the signer-attribute attribute:
署名者属性属性は署名している属性になるでしょう。 以下のオブジェクト識別子は署名者属性属性を特定します:
id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}
イド-aa-ets-signerAttrオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)18をメンバーと同じくらい具体化させます。
Pinkas, et al. Informational [Page 43] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[43ページ]情報のRFC5126cm
signer-attributes values have ASN.1 type SignerAttribute:
署名者属性値で、ASN.1はSignerAttributeをタイプします:
SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes }
SignerAttribute:、:= 選択の系列claimedAttributes[0]ClaimedAttributes、certifiedAttributes[1]CertifiedAttributes
ClaimedAttributes ::= SEQUENCE OF Attribute
ClaimedAttributes:、:= 属性の系列
CertifiedAttributes ::= AttributeCertificate -- as defined in RFC 3281: see Section 4.1.
CertifiedAttributes:、:= AttributeCertificate--RFC3281で定義されるように: セクション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: 属性とAttributeCertificateがITU-TのRecommendations X.501[9]とX.509[1]でそれぞれ定義されるようにあります。
5.11.4. content-time-stamp Attribute
5.11.4. 満足しているタイムスタンプAttribute
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}
イド-aa-ets-contentTimestampオブジェクト識別子:、:= iso(1)メンバーは(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)20を具体化させます。
content-time-stamp attribute values have ASN.1 type ContentTimestamp: ContentTimestamp ::= TimeStampToken
満足しているタイムスタンプ属性値で、ASN.1は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.
TimeStampTokenのmessageImprintの値、(RFCで説明されるように、3161[7])は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.
以下に注意してください。 満足しているタイムスタンプは、満足しているタイムスタンプに日付を含む前に署名している情報が形成されたのを示します。
5.12. Support for Multiple Signatures
5.12. 複数の署名のサポート
5.12.1. Independent Signatures
5.12.1. 独立している署名
Multiple independent signatures (see Annex B.5) are supported by independent SignerInfo from each signer.
複数の独立している署名(Annex B.5を見る)が独立しているSignerInfoによって各署名者からサポートされます。
Pinkas, et al. Informational [Page 44] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[44ページ]情報のRFC5126cm
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.
以下に注意してください。 一般に、時間的価値と署名方針情報を除いて、同じパーティーから代替の署名アルゴリズム、その場合他の属性を使用することで複数の署名を提供するのは独立している署名が異なったパーティーからの独立している署名に異なった署名している属性を提供するのに使用されるかもしれませんか、または同じになるでしょう。
5.12.2. Embedded Signatures
5.12.2. 埋め込まれた署名
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.
複数の埋め込まれた署名(Annex C.5を見る)が、副署の未署名の属性を使用することでサポートされます(セクション5.9.2を見てください)。 それぞれのカウンタ署名は未署名の属性として副署が適用されているSignerInfoに保たれた副署で運ばれます。
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.
以下に注意してください。 一般に、時間的価値と署名方針情報を除いて、同じパーティーから代替の署名アルゴリズム、その場合他の属性を使用することで複数の署名を提供するのはカウンタ署名が異なった署名している属性を異なったパーティーからの署名に提供するのに使用されるかもしれませんか、または同じになるでしょう。
6. Additional Electronic Signature Validation Attributes
6. 追加電子署名合法化属性
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
- 署名タイムスタンプは監査証跡で値かTime-マークを電子署名に適用しました。 これはTime(CAdES-T)と共にElectronic Signatureと定義されます。 そして
- 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).
- 署名価値のタイムスタンプ、および電子署名の完全な合法化に使用されるすべての証明書(完全な証明書参照)と取消し(完全な取消し参照)情報の参照を包括する合法化データ参照を終了してください。 Completeデータ参照(CAdES-C)でこれはElectronic Signatureと定義されます。
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で定義されます。
Pinkas, et al. Informational [Page 45] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[45ページ]情報のRFC5126cm
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:
また、さらに、以下の任意の拡張型に関する合法化データは定義されます。 合法化データの拡張型の概要に関してAnnex 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(ビャクシン属の木Xタイプ1): ESの上でComplete合法化データ(CAdES-C)でタイムスタンプを包括します。 そして
- 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(ビャクシン属の木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 Type1とCAdES-X Type2のための形式はセクションの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.
- ビャクシン属の木X長さ: Complete合法化データ参照(CAdES-C)、および情報がCAdES-Cで使用したすべての証明書と取消しの実価を包括します。
NOTE 4: Formats for CAdES-X Long are illustrated in Annex B.1.1.
注意4: CAdES-X Longのための形式はAnnex 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.
- ビャクシン属の木X長いタイプ1かビャクシン属の木X長いタイプ2: X時間スタンプ(1かType2をタイプする)、および情報がCAdES-X Longに従ってCAdES-Cで使用したすべての証明書と取消しの実価を包括します。
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),
- Complete合法化データ参照(CAdES-C)
- the certificate and revocation values (as in a CAdES-X Long ),
- 証明書と取消し値(CAdES-X Longのように)
- any existing extended electronic signature time-stamps
(CAdES-X Type 1 or CAdES-X Type 2), if present, and
- そして存在しているならどんな存在も電子署名タイムスタンプ(CAdES-X Type1かCAdES-X Type2)を広げた。
- the signed user data and an additional archive time-stamp
applied over all that data.
- 署名している利用者データと追加アーカイブ時間スタンプはそのすべてのデータの上で適用されました。
Pinkas, et al. Informational [Page 46] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[46ページ]情報のRFC5126cm
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で定義されます。
6.1. signature time-stamp Attribute (CAdES-T)
6.1. 署名タイムスタンプAttribute(ビャクシン属の木T)
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で定義されるES署名価値の上の署名タイムスタンプ属性。
6.1.1. signature-time-stamp Attribute Definition
6.1.1. 署名タイムスタンプAttribute Definition
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.
署名タイムスタンプ属性は特定の署名者のために署名値で計算されたTimeStampTokenです。 それは未署名の属性です。 この属性のいくつかのインスタンスが電子署名で異なったTSAsから起こるかもしれません。
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}
イド-aa-signatureTimeStampTokenオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)14をメンバーと同じくらい具体化させます。
The signature-time-stamp attribute value has ASN.1 type SignatureTimeStampToken:
署名タイムスタンプ属性値で、ASN.1はSignatureTimeStampTokenをタイプします:
SignatureTimeStampToken ::= TimeStampToken
SignatureTimeStampToken:、:= TimeStampToken
Pinkas, et al. Informational [Page 47] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[47ページ]情報のRFC5126cm
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.
TimeStampTokenの中のmessageImprint分野の値は時間によって押し込まれたsignedDataのためのSignerInfoの中の署名分野の価値のハッシュになるでしょう。
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: 複数の署名の場合では、aを持っているのは可能です:
- TimeStampToken computed for each and all signers; or
- TimeStampTokenはそれぞれとすべての署名者のために計算しました。 または
- TimeStampToken computed on one signer's signature; and no
- TimeStampTokenは1つの署名者の署名のときに計算しました。 そして、いいえ
- 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: 複数の署名の場合では、異なったTSAsによって発行された数個のTSTsが同じsignerInfoの中に存在しているかもしれません。(RFC3852[4])を見てください。
6.2. Complete Validation Data References (CAdES-C)
6.2. 完全な合法化データ参照(ビャクシン属の木C)
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.
Complete合法化データ参照(CAdES-C)による電子署名は合法化(すなわちすべての証明書と取消し情報)に必要であるすべての追加データが利用可能である電子署名です。 このフォームは上で定義されたCAdES-T書式に造られます。
As a minimum, the Complete validation data shall include the following:
最小限として、Complete合法化データは以下を含んでいるものとします:
- 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;
- 時間、またはTimeをマークしている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で定義されるような完全な取消し参照。
6.2.1. complete-certificate-references Attribute Definition
6.2.1. 完全な証明書参照Attribute Definition
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.
完全な証明書参照属性は未署名の属性です。 それはComplete合法化データでESを有効にするのに使用されたカリフォルニア証明書のフルセットに署名者の(しかし、包含しない)証明書まで参照をつけます。 この属性のただ一つのインスタンスだけが電子署名で起こるものとします。
Pinkas, et al. Informational [Page 48] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[48ページ]情報のRFC5126cm
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}
イド-aa-ets-certificateRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)21をメンバーと同じくらい具体化させます。
The complete-certificate-references attribute value has the ASN.1 syntax CompleteCertificateRefs.
完全な証明書参照属性値には、ASN.1構文CompleteCertificateRefsがあります。
CompleteCertificateRefs ::= SEQUENCE OF OtherCertID
CompleteCertificateRefs:、:= 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.
OtherCertIDに存在しているIssuerSerial。 certHashは参照をつけられる証明書のハッシュに合っているものとします。
NOTE 2: Copies of the certificate values may be held using the
certificate-values attribute, defined in Section 6.3.3.
注意2: 証明書値のコピーは、セクション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.
この属性は証明チェーンのタイムスタンプトークンを提供するどんなTSUsの指示するものも含むかもしれません。 この場合、未署名の属性はunsignedAttrsとしてsignerInfos分野で関連タイムスタンプトークンのsignedDataに加えられるものとします。
6.2.2. complete-revocation-references Attribute Definition
6.2.2. 完全な取消し参照Attribute Definition
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でComplete合法化データで使用されるカリフォルニア証明書のフルセットに参照をつけます。
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}
イド-aa-ets-revocationRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)22をメンバーと同じくらい具体化させます。
Pinkas, et al. Informational [Page 49] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[49ページ]情報のRFC5126cm
The complete-revocation-references attribute value has the ASN.1 syntax CompleteRevocationRefs:
完全な取消し参照属性値には、ASN.1構文CompleteRevocationRefsがあります:
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CompleteRevocationRefs:、:= CrlOcspRefの系列
CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL
}
CrlOcspRef:、:= 系列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は各OtherCertIDあたり1つがCompleteCertificateRefs属性であとに続いた署名証明書のための1CrlOcspRefを含むものとします。 同次にはそれらが関係するOtherCertIDとして2番目の、そして、その後のCrlOcspRef分野があるものとします。 少なくともCRLListID、OcspListIDまたはOtherRevRefsの1つは証明書経路の「信じられた」カリフォルニア以外のすべてのために存在しているべきです。
CRLListID ::= SEQUENCE {
crls SEQUENCE OF CrlValidatedID }
CRLListID:、:= 系列crls SEQUENCE OF CrlValidatedID
CrlValidatedID ::= SEQUENCE {
crlHash OtherHash,
crlIdentifier CrlIdentifier OPTIONAL }
CrlValidatedID:、:= 系列crlHash OtherHashで、crlIdentifier CrlIdentifier任意です。
CrlIdentifier ::= SEQUENCE {
crlissuer Name,
crlIssuedTime UTCTime,
crlNumber INTEGER OPTIONAL }
CrlIdentifier:、:= 系列crlissuer Name、crlIssuedTime UTCTime、crlNumber INTEGER OPTIONAL
OcspListID ::= SEQUENCE {
ocspResponses SEQUENCE OF OcspResponsesID }
OcspListID:、:= 系列OcspResponsesIDのocspResponses系列
OcspResponsesID ::= SEQUENCE {
ocspIdentifier OcspIdentifier,
ocspRepHash OtherHash OPTIONAL
}
OcspResponsesID:、:= 系列ocspIdentifier OcspIdentifierで、ocspRepHash OtherHash任意です。
OcspIdentifier ::= SEQUENCE {
ocspResponderID ResponderID,
-- As in OCSP response data
producedAt GeneralizedTime
-- As in OCSP response data
}
OcspIdentifier:、:= 系列OCSP応答データproducedAt GeneralizedTimeのようなコネとしてのocspResponderID ResponderID、OCSP応答データ
Pinkas, et al. Informational [Page 50] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[50ページ]情報のRFC5126cm
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。(時間は発行されたCRL、存在しているなら含まれた時間thisUpdateに対応するでしょう)。 crlListID属性は未署名の属性です。 特定されたCRLがデルタCRLであり、そして、完全な取消しリストを提供するCRLsのセットの指示するものは含まれているものとします。
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番目の中で受けられた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: この属性が後方にこの仕様の以前のバージョンとの互換性を維持するためにRFC3852で指定されたOtherRevocationInfoFormatに優先して使用されるのは、お勧めです。
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.
この属性はタイムスタンプトークンを提供するどんなTSUsのためにも証明チェーンについて確かめるのに使用されたCRL、ACRL、またはOCSP応答のフルセットの指示するものを含むかもしれません。 この場合、未署名の属性はunsignedAttrsとしてsignerInfos分野で関連タイムスタンプトークンのsignedDataに加えられるものとします。
6.2.3. attribute-certificate-references Attribute Definition
6.2.3. 属性証明書参照Attribute Definition
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
属性証明書参照属性は未署名の属性です。 それはそうしたAA証明書のフルセットに参照をつけます。
Pinkas, et al. Informational [Page 51] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[51ページ]情報のRFC5126cm
been used to validate the attribute certificate. Only a single instance of this attribute shall occur with an electronic signature.
属性証明書を有効にするために、使用されます。 この属性のただ一つのインスタンスだけが電子署名で起こるものとします。
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}
イド-aa-ets-attrCertificateRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)44をメンバーと同じくらい具体化させます。
The attribute-certificate-references attribute value has the ASN.1 syntax AttributeCertificateRefs:
属性証明書参照属性値には、ASN.1構文AttributeCertificateRefsがあります:
AttributeCertificateRefs ::= SEQUENCE OF OtherCertID
AttributeCertificateRefs:、:= 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で定義された証明書値の属性を使用することで持たれているかもしれません。
6.2.4. attribute-revocation-references Attribute Definition
6.2.4. 属性取消し参照Attribute Definition
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}
イド-aa-ets-attrRevocationRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)45をメンバーと同じくらい具体化させます。
The attribute-revocation-references attribute value has the ASN.1 syntax AttributeRevocationRefs:
属性取消し参照属性値には、ASN.1構文AttributeRevocationRefsがあります:
AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef
AttributeRevocationRefs:、:= CrlOcspRefの系列
6.3. Extended Validation Data (CAdES-X)
6.3. 拡張合法化データ(ビャクシン属の木X)
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).
このセクションは拡張型の電子署名で使用される多くの任意の属性を指定します(これらのフォームに関する合法化データの概要に関してAnnex Bを見てください)。
Pinkas, et al. Informational [Page 52] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[52ページ]情報のRFC5126cm
6.3.1. Time-Stamped Validation Data (CAdES-X Type 1 or Type 2)
6.3.1. 時間で押し込まれた合法化データ(ビャクシン属の木Xタイプ1かタイプ2)
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:
拡張合法化データは以下の追加属性の1つを含むかもしれません、後のカリフォルニア感染に対する追加保護を提供して、データが使用した合法化の保全を提供するために、CAdES-X Time-スタンプ合法化データ(CAdES-X Type1かCAdES-X Type2)を形成して:
- CAdES-C Time-stamp, as defined in Section 6.3.5 (CAdES-X Type
1); or
- セクション6.3.5(CAdES-X Type1)で定義されるようなCAdES-C Time-スタンプ または
- Time-Stamped Certificates and CRLs references, as defined in
Section 6.3.6 (CAdES-X Type 2).
- セクション6.3.6(CAdES-X Type2)で定義されるような時間で押し込まれたCertificatesとCRLs参照。
6.3.2. Long Validation Data (CAdES-X Long, CAdES-X Long Type 1 or 2)
6.3.2. 長い合法化データ(ビャクシン属の木X長さビャクシン属の木X長いタイプ1か2)
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に加えて、拡張合法化データは以下の追加属性の1つを含むかもしれません、CAdES-X Long Type1かCAdES-X Long Type2を形成して。
- CAdES-C Time-stamp, as defined in Section 6.3.3 (CAdES-X long
Type 1); or
- セクション6.3.3(CAdES-Xの長いType1)で定義されるようなCAdES-C Time-スタンプ または
- Time-Stamped Certificates and CRLs references, as defined in
Section 6.3.4 (CAdES-X Long Type 2).
- セクション6.3.4(CAdES-X Long Type2)で定義されるような時間で押し込まれたCertificatesと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 Type1かCAdES-X Long Type2が後のカリフォルニア感染に対する追加保護を提供して、データが使用した合法化の保全を提供します。
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: カリフォルニアキー、CRL Issuersキー、およびOCSP応答者キーは感染されないで、暗号の攻撃に抵抗力がある限り、CAdES-X長い署名は署名の正当性の長期の証拠を提供します。
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
注意2: タイムスタンプデータが有効なままで残っている限り、CAdES-X Long Type1とCAdES-X Long Type2は以下の重要な資産を長年の署名に提供します。 一度有効であることがわかったことがあって、したがって、それは月か年間ずっとそうでしょう。
Pinkas, et al. Informational [Page 53] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[53ページ]情報のRFC5126cm
later, long after the validity period of the certificates has
expired, or after the user key has been compromised.
その後、証明書の有効期間は、ずっと後に、期限が切れたか、またはユーザキーの後に感染されました。
6.3.3. certificate-values Attribute Definition
6.3.3. 証明書値のAttribute Definition
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.
この属性は以下の形式の拡張電子署名に必要である証明書情報を含むのに使用されるかもしれません: ビャクシン属の木X長くて、ES X長いタイプ1、およびビャクシン属の木X長いタイプ2。 この形式の電子署名のイラストに関してAnnex 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}
イド-aa-ets-certValuesオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)23をメンバーと同じくらい具体化させます。
The certificate-values attribute value has the ASN.1 syntax CertificateValues.
証明書値の属性値には、ASN.1構文CertificateValuesがあります。
CertificateValues ::= SEQUENCE OF Certificate
CertificateValues:、:= 証明書の系列
Certificate is defined in Section 7.1. (which is as defined in ITU-T Recommendation X.509 [1]).
証明書はセクション7.1で定義されます。 (ITU-T Recommendation 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のための証明情報も含むかもしれません、これらの証明書がTSUs署名の一部としてTSTsに既に含まれていないなら。 この場合、未署名の属性は関連タイムスタンプトークンのsignedDataに加えられるものとします。
6.3.4. revocation-values Attribute Definition
6.3.4. 取消し値のAttribute Definition
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.
この属性は以下の形式の拡張電子署名に必要である取消し情報を含むのに使用されます: ビャクシン属の木X長くて、ES X長いタイプ1、およびビャクシン属の木X長いタイプ2。 この形式の電子署名のイラストに関してAnnex B.1.1を見てください。
The revocation-values attribute is an unsigned attribute. Only a single instance of this attribute shall occur with an electronic
取消し値の属性は未署名の属性です。 この属性のただ一つのインスタンスだけが起こるものとする、電子
Pinkas, et al. Informational [Page 54] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[54ページ]情報のRFC5126cm
signature. It holds the values of CRLs and OCSP referenced in the complete-revocation-references attribute.
署名。 それは、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.
以下に注意してください。 この属性が後方にこの仕様の以前のバージョンとの互換性を維持するためにRFC3852で指定されたOtherRevocationInfoFormatに優先して使用されるのは、お勧めです。
The following object identifier identifies the revocation-values attribute:
以下のオブジェクト識別子は取消し値の属性を特定します:
id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 24}
イド-aa-ets-revocationValuesオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)24をメンバーと同じくらい具体化させます。
The revocation-values attribute value has the ASN.1 syntax RevocationValues
取消し値の属性値には、ASN.1構文RevocationValuesがあります。
RevocationValues ::= SEQUENCE {
crlVals [0] SEQUENCE OF CertificateList OPTIONAL,
ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
otherRevVals [2] OtherRevVals OPTIONAL }
RevocationValues:、:= 系列任意のBasicOCSPResponse[2]otherRevVals OtherRevVals任意の任意のCertificateList ocspVals[1]系列のcrlVals[0]系列
OtherRevVals ::= SEQUENCE {
OtherRevValType OtherRevValType,
OtherRevVals ANY DEFINED BY OtherRevValType }
OtherRevVals:、:= 系列OtherRevValType OtherRevValType、OtherRevValTypeによって少しも定義されたOtherRevVals
OtherRevValType ::= OBJECT IDENTIFIER
OtherRevValType:、:= オブジェクト識別子
The syntax and semantics of the other revocation values (OtherRevVals) are outside the scope of the present document.
現在のドキュメントの範囲の外に他の取消し値(OtherRevVals)の構文と意味論があります。
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]).
CertificateListはセクション7.2で定義されます。 (ITU-T Recommendation X.509[1])で定義されるようにある。
BasicOCSPResponse is defined in Section 7.3. (which is as defined in RFC 2560 [3]).
BasicOCSPResponseはセクション7.3で定義されます。 (RFC2560[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のためのCRLsとOCSPsも含む取消しデータの値を含むかもしれません、これらの証明書がTSUs署名の一部としてTSTsに既に含まれていないなら。 この場合、未署名の属性は関連タイムスタンプトークンのsignedDataに加えられるものとします。
Pinkas, et al. Informational [Page 55] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[55ページ]情報のRFC5126cm
6.3.5. CAdES-C-time-stamp Attribute Definition
6.3.5. ビャクシン属の木Cタイムスタンプは定義を結果と考えます。
This attribute is used to protect against CA key compromise.
この属性は、カリフォルニアの主要な感染から守るのに使用されます。
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)の時間の刻印に使用されます。 それは以下の形式の拡張電子署名に使用されます。 ビャクシン属の木Xタイプ1とビャクシン属の木Xは長い間、1をタイプします。 この形式の電子署名のイラストに関してAnnex 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が時押し込んでいる属性は未署名の属性です。 それは電子署名と完全な合法化データ(CAdES-C)のハッシュのタイムスタンプトークンです。 CAdES-Cを時押し込むのは、専用TimeStampToken Attributeです。 この属性のいくつかのインスタンスが電子署名で異なったTSAsから起こるかもしれません。
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構造の2進のコード化は、データハッシュの再計算が一貫しているのを保証するために保存されるべきです。
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: 各属性はハッシュに外側のSEQUENCEのattrTypeとattrValues(タイプと長さを含んでいる)にもかかわらず、タイプと長さなしで含まれています。
The following object identifier identifies the CAdES-C-Timestamp 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}
イド-aa-ets-escTimeStampオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)25をメンバーと同じくらい具体化させます。
The CAdES-C-timestamp attribute value has the ASN.1 syntax ESCTimeStampToken :
CAdES Cタイムスタンプ属性値には、ASN.1構文ESCTimeStampTokenがあります:
ESCTimeStampToken ::= TimeStampToken
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の中のSignatureValue分野のOCTETSTRING。
- signature-time-stamp, or a time-mark operated by a Time-Marking
Authority;
- 署名タイムスタンプ、またはTimeをマークしているAuthorityによって操作されたタイム・マーク。
- complete-certificate-references attribute; and
- 完全な証明書参照属性。 そして
Pinkas, et al. Informational [Page 56] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[56ページ]情報のRFC5126cm
- complete-revocation-references attribute.
- 完全な取消し参照属性。
For further information and definition of the TimeStampToken, see Section 7.4.
TimeStampTokenの詳細と定義に関しては、セクション7.4を見てください。
6.3.6. time-stamped-certs-crls-references Attribute Definition
6.3.6. 時間の押し込まれた本命crls参照Attribute Definition
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.
この属性は、カリフォルニアの主要な感染から守るのに使用されます。 この属性は時間の刻印証明書と取消し参照に使用されます。 それは以下の形式の拡張電子署名に使用されます: ビャクシン属の木Xタイプ2とビャクシン属の木Xは長い間、2をタイプします。 この形式の電子署名のイラストに関してAnnex 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:
時間の押し込まれた本命crls参照属性は未署名の属性です。 それは参照をつけられた証明書とOCSP応答、そして/または、CRLsのリストが、あるカリフォルニア感染から守るように発行されたタイムスタンプトークンです。 構文は以下の通りです:
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構造の2進のコード化は、データハッシュの再計算が一貫しているのを保証するために保存されるべきです。
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: 各属性はハッシュに外側のSEQUENCEのattrTypeとattrValues(タイプと長さを含んでいる)にもかかわらず、タイプと長さなしで含まれています。
The following object identifier identifies the time-stamped-certs-crls-references attribute:
以下のオブジェクト識別子は時間の押し込まれた本命crls参照属性を特定します:
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}
イド-aa-ets-certCRLTimestampオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)26をメンバーと同じくらい具体化させます。
The attribute value has the ASN.1 syntax TimestampedCertsCRLs:
属性値には、ASN.1構文TimestampedCertsCRLsがあります:
TimestampedCertsCRLs ::= TimeStampToken
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分野の値は以下のデータ・オブジェクトの連結された値(その値のためのタイプも長さのコード化のない)のハッシュになるでしょう、ESでは、Complete合法化データ(CAdES-C)について存在しています:
- complete-certificate-references attribute; and
- 完全な証明書参照属性。 そして
- complete-revocation-references attribute.
- 完全な取消し参照属性。
Pinkas, et al. Informational [Page 57] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[57ページ]情報のRFC5126cm
6.4. Archive Validation Data
6.4. アーカイブ合法化データ
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)。 このアーカイブタイムスタンプ属性は期間の間、繰り返して適用されるかもしれません。
6.4.1. archive-time-stamp Attribute Definition
6.4.1. タイムスタンプを格納しているAttribute Definition
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.
タイムスタンプを格納している属性は電子署名におけるsignedDataの要素の多くのタイムスタンプトークンです。 証明書値と取消し値の属性が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.
タイムスタンプを格納している属性は未署名の属性です。 この属性のいくつかのインスタンスが電子署名で時間の上と、そして、異なった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}
イド-aa-ets-archiveTimestampV2オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)48をメンバーと同じくらい具体化させます。
Archive-time-stamp attribute values have the ASN.1 syntax ArchiveTimeStampToken
タイムスタンプを格納している属性値には、ASN.1構文ArchiveTimeStampTokenがあります。
ArchiveTimeStampToken ::= TimeStampToken
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系列のencapContentInfo原理。
- 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系列、いつに関する現在のCertificatesとcrls要素、。
- all data elements in the SignerInfo sequence including all
signed and unsigned attributes.
- すべての署名していて未署名の属性を含むSignerInfo系列のすべてのデータ要素。
Pinkas, et al. Informational [Page 58] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[58ページ]情報のRFC5126cm
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) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)27をメンバーと同じくらい具体化させて、TS101 733[TS101733]の先のバージョンとRFC3126で定義されます。
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.
そして、TS101 733のバージョンで定義されたarchiveTimestamp属性、1.5の前、.1、RFCでは、3126は現在のドキュメントで定義される属性と互換性がありません。 archiveTimestamp属性であり、バージョン1.5で.1〜1.6に定義されて、内容がencapContentInfoに内部であるなら、.3TS101 733が現在のドキュメントと互換性があります。 署名パーティーによって使われたTS101 733のバージョンがすべての受取人によって知られていない場合、TS101 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: 副署属性が独立しているアーカイブ時間スタンプを必要としないので、カウンタ署名は成立しました、それらがアーカイブ時間スタンプによってSignedDataが構造化する含有に対して保護されるとき。
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構造の2進のコード化が保存されるのが、お勧めであるということでないなら。
NOTE 4: The hash is calculated over the concatenated data elements
as received/stored, including the Type and Length encoding.
注意4: ハッシュはTypeを含んでいて、受け取るか、または保存する連結されたデータ要素とLengthコード化に関して計算されます。
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系列の未署名の属性として加えられるでしょう。 1ArchiveTimeStampの合法化において、すべての後のArchivTimeStampToken属性を除いて、SignerInfoのデータ要素を連結しなければなりません。
Certificates and revocation information required to validate the ArchiveTimeStamp shall be provided by one of the following methods:
以下のメソッドの1つで情報がArchiveTimeStampを有効にするのを必要とした証明書と取消しを提供するものとします:
Pinkas, et al. Informational [Page 59] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[59ページ]情報のRFC5126cm
- 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
- 必須情報がほかの場所に保存されるとき、未署名の属性としてTimeStampTokenの中で完全な証明書参照属性と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.
- 必須情報がほかの場所に保存されるとき、未署名の属性としてTimeStampTokenの中で証明書値の属性とTSPの取消し値の属性を加えます。
7. Other Standard Data Structures
7. 他の標準のデータ構造
7.1. Public Key Certificate Format
7.1. 公開鍵証明書形式
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 Recommendation X.509[1]で定義されます。 X.509 v3証明書のプロフィールはRFC3280[2]で定義されます。
7.2. Certificate Revocation List Format
7.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 Recommendation X.509[1]で定義されます。 X.509 v2 CRLのプロフィールはRFC3280[2]で定義されます。
7.3. OCSP Response Format
7.3. OCSP応答形式
The format of an OCSP token is defined in RFC 2560 [3].
OCSPトークンの書式はRFC2560[3]で定義されます。
7.4. Time-Stamp Token Format
7.4. タイムスタンプトークン形式
The format of a TimeStampToken type is defined in RFC 3161 [7] and profiled in ETSI TS 101 861 [TS101861].
TimeStampTokenタイプの書式は、RFC3161[7]で定義されて、ETSI TS101 861[TS101861]で輪郭を描かれます。
7.5. Name and Attribute Formats
7.5. 形式を命名して、結果と考えてください。
The syntax of the naming and other attributes is defined in ITU-T Recommendation X.509 [1].
命名と他の属性の構文はITU-T Recommendation 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.
以下に注意してください。 対象として自分の証明書に保持された署名者によって使用される名前は、認証局との登録のときに割り当てられて、確かめられます、直接か間接的にRegistration Authorityを通して、Certificateと共に発行される前に。
Pinkas, et al. Informational [Page 60] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[60ページ]情報のRFC5126cm
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 Recommendation X.500[12]で定義されるように分類名であるかもしれませんかいかなる他の名前フォームもsubjectAltName証明書拡大分野で持ちこたえました、ITU-T Recommendation X.509[1]で定義されるように。 対象には分類名が全くなくて、対象の名前は空の系列であるかもしれません、そして、subjectAltName拡張子は重要になるでしょう。
All Certification Authorities, Attribute Authorities, and Time-Stamping Authorities shall use distinguished names in the subject field of their certificate.
すべてのCertification Authorities、Attribute Authorities、およびTime-押し込むAuthoritiesはそれらの証明書の対象の分野で分類名を使用するものとします。
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つのアイデンティティの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を見てください。
7.6. AttributeCertificate
7.6. AttributeCertificate
The syntax of the AttributeCertificate type is defined in RFC 3281 [13].
AttributeCertificateタイプの構文はRFC3281[13]で定義されます。
8. Conformance Requirements
8. 順応要件
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つを実装しなければなりません。
Pinkas, et al. Informational [Page 61] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[61ページ]情報のRFC5126cm
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.
現在のドキュメントはComplete合法化データ(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.
検証のときに、任意の署名していて未署名の属性の包含を署名が証明可能であるという範囲だけにサポートしなければなりません。 別の方法で署名方針で指定されない場合、任意の属性の意味論はサポートされないかもしれません。
8.1. CAdES-Basic Electronic Signature (CAdES-BES)
8.1. ビャクシン属の木基本的な電子署名(ビャクシン属の木-BES)
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);
- そして、一般的なCMS構文、RFC3852[4](セクション5.1と5.2を見る)で定義されるようなcontent type
- 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);
- CMS SignedData、RFCで定義されるように、バージョンがある3852[4]は3と少なくとも1個のSignerInfoプレゼントにセットしました(セクション5.3〜5.6を見てください)。
- The following CMS attributes, as defined in RFC 3852 [4]:
- RFC3852[4]で定義されるような以下のCMS属性
- content-type; this shall always be present (see Section
5.7.1); and
- content type。 これはいつも存在するでしょう(セクション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:
- 現在のドキュメントで定義されるような以下の属性の1つ
- 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.
以下に注意してください。 セクション5.7を見てください。RFC3126がもう片方の署名証明書属性を使用していた、(.3 .3)。 署名証明書v2属性の構造がもう片方の署名証明書属性より簡単であるので、使用は現在、推奨しないです。
Pinkas, et al. Informational [Page 62] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[62ページ]情報のRFC5126cm
8.2. CAdES-Explicit Policy-based Electronic Signature
8.2. ビャクシン属の木明白な方針ベースの電子署名
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:
最小限で、現在のドキュメントによると、Policyベースの署名者をサポートするシステムは電子署名が基本的な署名者のために定義された前のコンポーネントから成る世代をサポートするものとします、プラス:
- The following attributes, as defined in Section 5.9:
- セクション5.9で定義されるような以下の属性
- signature-policy-identifier; this shall always be present
(see Section 5.8.1).
- 署名方針識別子。 これはいつも存在するでしょう(セクション5.8.1を見てください)。
8.3. Verification Using Time-Stamping
8.3. 時間の刻印を使用する検証
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 Recommendation X.509[1](セクション8.1を見ます)で定義されるような公共のKey Certificates そして
- either of:
- 以下のどちらか
- Certificate Revocation Lists, as defined in ITU-T
Recommendation X.509 [1] (see Section 8.2); or
- ITU-T Recommendation X.509[1](セクション8.2を見ます)で定義されるようにRevocation Listsを証明してください。 または
- Online Certificate Status Protocol, as defined in RFC 2560
[3] (see Section 8.3).
- RFC2560[3](セクション8.3を見る)で定義されるようなオンラインCertificate Statusプロトコル。
8.4. Verification Using Secure Records
8.4. 安全な記録を使用する検証
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で定義されるような電子署名の強制されたコンポーネントの検証
Pinkas, et al. Informational [Page 63] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[63ページ]情報のRFC5126cm
- 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;
- 署名が最初に有効にされた電子署名と時に関する記録(参照をつけられた証明書を使用して、取消し情報)を保守しなければなりません、undetectablyに記録を変更できないように。
- Public Key Certificates, as defined in ITU-T Recommendation
X.509 [1] (see Section 8.1); and
- ITU-T Recommendation X.509[1](セクション8.1を見ます)で定義されるような公共のKey Certificates そして
- either of:
- 以下のどちらか
- Certificate Revocation Lists, as defined in ITU-T
Recommendation X.509 [1] (see Section 8.2); or
- ITU-T Recommendation X.509[1](セクション8.2を見ます)で定義されるようにRevocation Listsを証明してください。 または
- online Certificate Status Protocol, as defined in RFC 2560
[3] (see Section 8.3).
- RFC2560[3](セクション8.3を見る)で定義されるようなオンラインCertificate Statusプロトコル。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[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/IEC9594-8(2001): 「情報技術--オープン・システム・インターコネクション--ディレクトリ:、」 「公開鍵とAttribute Certificateフレームワーク。」
[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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(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] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[4] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[4]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[5] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC
2634, June 1999.
[5] ホフマン、P.、エド、「S/MIMEのための警備の強化サービス」、RFC2634、6月1999日
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[6]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
Pinkas, et al. Informational [Page 64] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[64ページ]情報のRFC5126cm
[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] アダムス、C.、カイン、P.、ピンカス、D.、およびR.Zuccherato、「インターネットX.509公開鍵暗号基盤タイムスタンププロトコル(ティースプーンフル)」、RFC3161(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): 「情報技術--Syntax Notation One(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/IEC9594-1(2001): 「情報技術--オープン・システム・インターコネクション--ディレクトリはモデル化されます。」
[10] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
RFC 3370, August 2002.
[10]Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム」、RFC3370、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] ファレルとS.とR.Housley、「承認のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
[14] ITU-T Recommendation X.208 (1988): "Specification of Abstract
Syntax Notation One (ASN.1)".
[14] ITU-T推薦X.208(1988): 「抽象構文記法1(ASN.1)の仕様。」
[15] Schaad, J., "Enhanced Security Services (ESS) Update: Adding
CertID Algorithm Agility", RFC 5035, August 2007.
[15] Schaad、J.、「警備の強化サービス(ESS)は以下をアップデートします」。 「CertIDアルゴリズムの機敏さを加えます」、RFC5035、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)を統治します。」
9.2. Informative References
9.2. 有益な参照
[EUDirective] Directive 1999/93/EC of the European Parliament and of
the Council of 13 December 1999 on a community
framework for Electronic Signatures.
Electronic Signaturesのための共同体フレームワークにおける欧州議会と1999年12月13日のCouncilの[EUDirective]指示1999/93/EC。
[TS101733] ETSI Standard TS 101 733 V.1.7.3 (2005-06) Electronic
Signature Formats.
[TS101733]ETSI標準のt101 733V.1.7.3の(2005-06)の電子署名形式。
[TS101861] ETSI TS 101 861: "Time stamping profile".
[TS101861]ETSI t101 861: 「時間の刻印プロフィール。」
Pinkas, et al. Informational [Page 65] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[65ページ]情報のRFC5126cm
[TS101903] ETSI TS 101 903: "XML Advanced Electronic Signatures
(XAdES)".
[TS101903]ETSI t101 903: 「XMLは電子署名(XAdES)を進めました。」
[TR102038] ETSI TR 102 038: "Electronic Signatures and
Infrastructures (ESI); XML format for signature
policies".
[TR102038]ETSI TR102 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 TR102 272V1.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] アダムス、C.、「独立しているデータ単位保護ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース(IDUP- GSS-API)」、RFC2479、1998年12月。
[RFC2743] Linn, J., "Generic Security Service Application
Program Interface Version 2, Update 1", RFC 2743,
January 2000.
[RFC2743] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェースバージョン2、アップデート1インチ、RFC2743、2000年1月。」
[RFC3125] Ross, J., Pinkas, D., and N. Pope, "Electronic
Signature Policies", RFC 3125, September 2001.
[RFC3125] ロスとJ.とピンカス、D.とN.ポープ、「電子署名方針」、RFC3125、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] イェンソン、J.、およびB.Kaliski、「公開鍵暗号化標準(PKCS)#1:」 RSA暗号仕様バージョン2.1インチ、RFC3447、2月2003日
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
version 2 (LDAPv2) to Historic Status", RFC 3494,
March 2003.
[RFC3494]Zeilenga、2003年3月のK.、「Historic Statusへのライトウェイト・ディレクトリ・アクセス・プロトコルバージョン2(LDAPv2)」RFC3494。
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message
Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B.、エド、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1は仕様を通信する」RFC3851、7月2004日
[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] アダムス、C.、ファレル、S.、Kause、T.、およびT.Mononen、「インターネットX.509公開鍵暗号基盤証明書経営者側は(CMP)について議定書の中で述べます」、RFC4210、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.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates", RFC
4523, June 2006.
[RFC4523]Zeilenga、K.、「X.509証明書のためのライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)図式定義」、RFC4523、2006年6月。
Pinkas, et al. Informational [Page 66] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[66ページ]情報のRFC5126cm
[ISO7498-2] ISO 7498-2 (1989): "Information processing systems -
Open Systems Interconnection - Basic Reference Model -
Part 2: Security Architecture".
[ISO7498-2]ISO7498-2(1989): 「情報処理システム--オープン・システム・インターコネクション--基本的なReference Model--第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/IEC9796-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/IEC9796-4(1998): 「デジタル署名はメッセージ回復を与えながら、計画されます--4を分けてください」 「離散対数はメカニズムを基礎づけました。」
[ISO10118-1] ISO/IEC 10118-1 (2000): "Information technology -
Security techniques - Hash-functions - Part 1:
General".
[ISO10118-1]ISO/IEC10118-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".
[ISO10118-2]ISO/IEC10118-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/IEC10118-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/IEC10118-4(1998): 「情報技術--セキュリティのテクニック--ハッシュ関数--4を分けてください」 「合同算術を使用して、機能を論じ尽くしてください。」
[ISO10181-5] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework. April 1997.
[ISO10181-5]ISO/IEC10181-5: オープンシステム非拒否フレームワークにおけるセキュリティフレームワーク。 1997年4月。
[ISO13888-1] ISO/IEC 13888-1 (2004): "IT security techniques -
Non-repudiation - Part 1: General".
[ISO13888-1]ISO/IEC13888-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/IEC14888-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/IEC14888-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/IEC14888-3(1998): 「情報技術--セキュリティのテクニック--付録によるデジタル署名--3を分けてください」 「証明書ベースのメカニズム。」
Pinkas, et al. Informational [Page 67] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[67ページ]情報のRFC5126cm
[ISO15946-2] ISO/IEC 15946-2 (2002): "Information technology -
Security techniques - Cryptographic techniques based
on elliptic curves - Part 2: Digital signatures".
[ISO15946-2]ISO/IEC15946-2(2002): 「情報技術--セキュリティのテクニック--暗号のテクニックは楕円曲線--第2部を基礎づけました」 「デジタル署名。」
[CWA14171] CWA 14171 CEN Workshop Agreement: "General Guidelines
for Electronic Signature Verification".
[CWA14171]CWA14171CENワークショップ協定: 「電子署名照合のための一般的ガイドライン。」
[XMLDSIG] XMLDSIG: W3C/IETF Recommendation (February 2002):
"XML-Signature Syntax and Processing".
[XMLDSIG]XMLDSIG: W3C/IETF推薦(2002年2月): 「XML-署名構文と処理。」
[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
ServicesとProducts Download Areaを通して以下で無料でETSI技術仕様書をダウンロードできます。 http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx
Pinkas, et al. Informational [Page 68] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[68ページ]情報のRFC5126cm
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.
この別館は新しい構文のための.1の構文定義が現在のドキュメントで定義したすべてのASNの概要を提供します。
A.1. Signature Format Definitions Using X.208 ASN.1 Syntax
A.1。 X.208 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でITU-T Recommendation X.208[14]で定義された構文を使用することで定義されたASN.1モジュールはどんな闘争の場合でも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)}
ETS-ElectronicSignatureFormats-ExplicitSyntax88iso(1)が(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イドモッズ風で(2) 私たちをメンバーと同じくらい具体化させる、(0) eSignature-explicit88(28)
DEFINITIONS EXPLICIT TAGS ::=
定義、明白なタグ:、:=
BEGIN
始まってください。
-- EXPORTS All
-- すべてをエクスポートします。
IMPORTS
輸入
-- Cryptographic Message Syntax (CMS): RFC 3852
-- 暗号のメッセージ構文(cm): RFC3852
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) }
ContentInfo、ContentType、イドデータ、イド-signedData、SignedData、EncapsulatedContentInfo、SignerInfo、イド-contentType、イド-messageDigest、MessageDigest、イド-signingTime、SigningTime、イド副署、Countersignature FROM CryptographicMessageSyntax2004iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2004(24)
-- ESS Defined attributes: ESS Update -- RFC 5035 (Adding CertID Algorithm Agility)
-- ESS Defined属性: ESSアップデート--RFC5035(CertIDアルゴリズムの機敏さを加えます)
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) }
ExtendedSecurityServices-2006からのイド-aa-signingCertificate、SigningCertificate、IssuerSerial、イド-aa-contentReference、ContentReference、イド-aa-contentIdentifier、ContentIdentifier、イド-aa-signingCertificateV2iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)のイドモッズ風のess-2006(30)
-- Internet X.509 Public Key Infrastructure - Certificate and CRL -- Profile: RFC 3280
-- インターネットX.509公開鍵暗号基盤(証明書とCRL)は以下の輪郭を描きます。 RFC3280
Certificate, AlgorithmIdentifier, CertificateList, Name, DirectoryString, Attribute, BMPString, UTF8String
証明書、AlgorithmIdentifier、CertificateList、名前、DirectoryString、属性、BMPString、UTF8String
Pinkas, et al. Informational [Page 69] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[69ページ]情報のRFC5126cm
FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)}
PKIX1Explicit88からiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(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)}
PKIX1Implicit88からのGeneralNames、GeneralName、PolicyInformationiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)、イドpkix1暗黙、(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)}
PKIXAttributeCertificateからのAttributeCertificateiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズ属性本命(12)
-- OCSP - RFC 2560
-- OCSP--RFC2560
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)}
OCSPからのBasicOCSPResponse、ResponderIDiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズocsp(14)
-- Time Stamp Protocol RFC 3161
-- タイムスタンププロトコルRFC3161
TimeStampToken
FROM PKIXTSP
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
PKIXTSPからのTimeStampTokeniso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズティースプーンフル(13)
;
;
-- Definitions of Object Identifier arcs used in the present document -- ==================================================================
-- 現在のドキュメントで使用されるObject Identifierアークの定義--==================================================================
-- OID used referencing electronic signature mechanisms based on -- the present document for use with the Independent Data Unit -- Protection (IDUP) API (see Annex D)
-- 保護(IDUP)APIに基づく(無党派Data Unitとの使用のための現在のドキュメント)電子署名メカニズムに参照をつけながら使用されるOID(別館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) }
イドetsi-es-IDUPメカニズムv1オブジェクト識別子:、:= itu t(0)の特定された組織(4)etsi(0)の電子署名規格(1733)part1(1)idupMechanism(4)etsiESv1(1)
-- Basic ES CMS Attributes Defined in the present document -- =======================================================
-- 現在のドキュメントの基本的なES CMS Attributes Defined--=======================================================
Pinkas, et al. Informational [Page 70] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[70ページ]情報のRFC5126cm
-- OtherSigningCertificate - deprecated
-- OtherSigningCertificate--、推奨しなさ
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 19 }
イド-aa-ets-otherSigCertオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)19をメンバーと同じくらい具体化させます。
OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THE PRESENT DOCUMENT
}
OtherSigningCertificate:、:= 系列本命SEQUENCE OF OtherCertID、方針SEQUENCE OF PolicyInformation OPTIONAL--、NOT USED IN THE PRESENT DOCUMENT
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL }
OtherCertID:、:= 系列otherCertHash OtherHashで、issuerSerial IssuerSerial任意です。
OtherHash ::= CHOICE {
sha1Hash OtherHashValue,
-- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue}
OtherHash:、:= 選択sha1Hash OtherHashValue、--これがSHA-1ハッシュotherHash OtherHashAlgAndValueを含んでいる
-- Policy ES Attributes Defined in the present document -- ====================================================
-- 現在のドキュメントの方針ES Attributes Defined--====================================================
-- Mandatory Basic Electronic Signature Attributes as above, -- plus in addition.
-- 上の義務的なBasic Electronic Signature Attributes--追加におけるプラス。
-- Signature-policy-identifier attribute
-- 署名方針識別子属性
id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 15 }
イド-aa-ets-sigPolicyIdオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)15をメンバーと同じくらい具体化させます。
SignaturePolicy ::= CHOICE {
signaturePolicyId SignaturePolicyId,
signaturePolicyImplied SignaturePolicyImplied
-- not used in this version
}
SignaturePolicy:、:= 選択signaturePolicyId SignaturePolicyId、signaturePolicyImplied SignaturePolicyImplied--このバージョンでは、使用されません。
SignaturePolicyId ::= SEQUENCE {
sigPolicyId SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL
}
SignaturePolicyId:、:= 系列sigPolicyId SigPolicyId、sigPolicyHash SigPolicyHash、SigPolicyQualifierInfo任意のsigPolicyQualifiers系列サイズ(1..MAX)
SignaturePolicyImplied ::= NULL
SignaturePolicyImplied:、:= ヌル
Pinkas, et al. Informational [Page 71] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[71ページ]情報のRFC5126cm
SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyId:、:= オブジェクト識別子
SigPolicyHash ::= OtherHashAlgAndValue
SigPolicyHash:、:= OtherHashAlgAndValue
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue }
OtherHashAlgAndValue:、:= 系列hashAlgorithm AlgorithmIdentifier、hashValue OtherHashValue
OtherHashValue ::= OCTET STRING
OtherHashValue:、:= 八重奏ストリング
SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SigPolicyQualifierId,
sigQualifier ANY DEFINED BY sigPolicyQualifierId }
SigPolicyQualifierInfo:、:= 系列sigPolicyQualifierId SigPolicyQualifierId、sigPolicyQualifierIdによって少しも定義されたsigQualifier
SigPolicyQualifierId ::= OBJECT IDENTIFIER
SigPolicyQualifierId:、:= オブジェクト識別子
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 }
イド-spq-ets-uri OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-spq(5)1をメンバーと同じくらい具体化させます。
SPuri ::= IA5String
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 }
イド-spq-ets-unotice OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-spq(5)2をメンバーと同じくらい具体化させます。
SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
SPUserNotice:、:= 系列noticeRef NoticeReference任意であって、explicitText DisplayText任意です。
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
NoticeReference:、:= 系列組織DisplayText、noticeNumbers SEQUENCE OF INTEGER
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
DisplayText:、:= 特選、visibleString VisibleString(サイズ(1 .200))、bmpString BMPString(サイズ(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}
イド-aa-ets-commitmentTypeオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)16をメンバーと同じくらい具体化させます。
CommitmentTypeIndication ::= SEQUENCE {
CommitmentTypeIndication:、:= 系列
Pinkas, et al. Informational [Page 72] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[72ページ]情報のRFC5126cm
commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
CommitmentTypeQualifier OPTIONAL}
commitmentTypeId CommitmentTypeIdentifier、CommitmentTypeQualifier任意のcommitmentTypeQualifier系列サイズ(1..MAX)
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeIdentifier:、:= オブジェクト識別子
CommitmentTypeQualifier ::= SEQUENCE {
commitmentTypeIdentifier CommitmentTypeIdentifier,
qualifier ANY DEFINED BY commitmentTypeIdentifier }
CommitmentTypeQualifier:、:= 系列commitmentTypeIdentifier CommitmentTypeIdentifier、資格を与える人いずれも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}
イド-cti-ets-proofOfOriginオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfReceiptオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfDeliveryオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfSenderオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfApprovalオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfCreationオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-aa-ets-signerLocationオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-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 }
SignerLocation:、:= 系列--少なくとも以下の1つがX.500 localityName[1]DirectoryString OPTIONALでCountryを命名するのに使用されるようにX.500 postalAdddress[2]の場所をPostalAddress OPTIONALと命名するのに使用される現在のDirectoryString OPTIONALにcountryName[0]なる
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString
PostalAddress:、:= DirectoryStringの系列サイズ(1 .6)
-- Signer-attributes attribute
-- 署名者属性属性
Pinkas, et al. Informational [Page 73] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[73ページ]情報のRFC5126cm
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}
イド-aa-ets-signerAttrオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)18をメンバーと同じくらい具体化させます。
SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes }
SignerAttribute:、:= 選択の系列claimedAttributes[0]ClaimedAttributes、certifiedAttributes[1]CertifiedAttributes
ClaimedAttributes ::= SEQUENCE OF Attribute
ClaimedAttributes:、:= 属性の系列
CertifiedAttributes ::= AttributeCertificate -- as defined in RFC 3281: see Section 4.1
CertifiedAttributes:、:= AttributeCertificate--RFC3281で定義されるように: セクション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}
イド-aa-ets-contentTimestampオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)20をメンバーと同じくらい具体化させます。
ContentTimestamp ::= TimeStampToken
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}
イド-aa-signatureTimeStampTokenオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)14をメンバーと同じくらい具体化させます。
SignatureTimeStampToken ::= TimeStampToken
SignatureTimeStampToken:、:= TimeStampToken
-- Complete-certificate-references attribute
-- 完全な証明書参照属性
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}
イド-aa-ets-certificateRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)21をメンバーと同じくらい具体化させます。
CompleteCertificateRefs ::= SEQUENCE OF OtherCertID
CompleteCertificateRefs:、:= 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}
イド-aa-ets-revocationRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)22をメンバーと同じくらい具体化させます。
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CompleteRevocationRefs:、:= CrlOcspRefの系列
CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL
}
CrlOcspRef:、:= 系列crlids[0]CRLListID OPTIONAL、ocspids[1]OcspListID OPTIONAL、otherRev[2]OtherRevRefs OPTIONAL
Pinkas, et al. Informational [Page 74] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[74ページ]情報のRFC5126cm
CRLListID ::= SEQUENCE {
crls SEQUENCE OF CrlValidatedID}
CRLListID:、:= 系列crls SEQUENCE OF CrlValidatedID
CrlValidatedID ::= SEQUENCE {
crlHash OtherHash,
crlIdentifier CrlIdentifier OPTIONAL}
CrlValidatedID:、:= 系列crlHash OtherHashで、crlIdentifier CrlIdentifier任意です。
CrlIdentifier ::= SEQUENCE {
crlissuer Name,
crlIssuedTime UTCTime,
crlNumber INTEGER OPTIONAL }
CrlIdentifier:、:= 系列crlissuer Name、crlIssuedTime UTCTime、crlNumber INTEGER OPTIONAL
OcspListID ::= SEQUENCE {
ocspResponses SEQUENCE OF OcspResponsesID}
OcspListID:、:= 系列OcspResponsesIDのocspResponses系列
OcspResponsesID ::= SEQUENCE {
ocspIdentifier OcspIdentifier,
ocspRepHash OtherHash OPTIONAL
}
OcspResponsesID:、:= 系列ocspIdentifier OcspIdentifierで、ocspRepHash OtherHash任意です。
OcspIdentifier ::= SEQUENCE {
ocspResponderID ResponderID,
-- As in OCSP response data
producedAt GeneralizedTime
-- As in OCSP response data
}
OcspIdentifier:、:= 系列OCSP応答データproducedAt GeneralizedTimeのようなコネとしてのocspResponderID ResponderID、OCSP応答データ
OtherRevRefs ::= SEQUENCE {
otherRevRefType OtherRevRefType,
otherRevRefs ANY DEFINED BY otherRevRefType
}
OtherRevRefs:、:= 系列otherRevRefType OtherRevRefType、otherRevRefTypeによって少しも定義されたotherRevRefs
OtherRevRefType ::= OBJECT IDENTIFIER
OtherRevRefType:、:= オブジェクト識別子
-- 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}
イド-aa-ets-certValuesオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)23をメンバーと同じくらい具体化させます。
CertificateValues ::= SEQUENCE OF Certificate
CertificateValues:、:= 証明書の系列
-- 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}
イド-aa-ets-revocationValuesオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)24をメンバーと同じくらい具体化させます。
RevocationValues ::= SEQUENCE {
RevocationValues:、:= 系列
Pinkas, et al. Informational [Page 75] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[75ページ]情報のRFC5126cm
crlVals [0] SEQUENCE OF CertificateList OPTIONAL,
ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
otherRevVals [2] OtherRevVals OPTIONAL}
任意のBasicOCSPResponse[2]otherRevVals OtherRevVals任意の任意のCertificateList ocspVals[1]系列のcrlVals[0]系列
OtherRevVals ::= SEQUENCE {
otherRevValType OtherRevValType,
otherRevVals ANY DEFINED BY otherRevValType
}
OtherRevVals:、:= 系列otherRevValType OtherRevValType、otherRevValTypeによって少しも定義されたotherRevVals
OtherRevValType ::= OBJECT IDENTIFIER
OtherRevValType:、:= オブジェクト識別子
-- 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}
イド-aa-ets-escTimeStampオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)25をメンバーと同じくらい具体化させます。
ESCTimeStampToken ::= TimeStampToken
ESCTimeStampToken:、:= TimeStampToken
-- Time-Stamped Certificates and CRLs
-- 時間で押し込まれた証明書とCRLs
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}
イド-aa-ets-certCRLTimestampオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)26をメンバーと同じくらい具体化させます。
TimestampedCertsCRLs ::= TimeStampToken
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}
-- タイムスタンプ属性イド-aa-ets-archiveTimestampV2 OBJECT IDENTIFIERを格納してください:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)48をメンバーと同じくらい具体化させます。
ArchiveTimeStampToken ::= TimeStampToken
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}
イド-aa-ets-attrCertificateRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)44をメンバーと同じくらい具体化させます。
AttributeCertificateRefs ::= SEQUENCE OF OtherCertID
AttributeCertificateRefs:、:= 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}
イド-aa-ets-attrRevocationRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)45をメンバーと同じくらい具体化させます。
AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef
AttributeRevocationRefs:、:= CrlOcspRefの系列
Pinkas, et al. Informational [Page 76] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[76ページ]情報のRFC5126cm
END
終わり
A.2. Signature Format Definitions Using X.680 ASN.1 Syntax
A.2。 X.680 ASN.1構文を使用する署名形式定義
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.
以下に注意してください。 Annex A.1で定義されたASN.1モジュールはAnnex A.2でITU-T Recommendation X.680(1997)[8]でどんな闘争の場合でも定義された構文を使用することで定義されたそれの上の先行を持っています。
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)}
ETS-ElectronicSignatureFormats-ExplicitSyntax97iso(1)が(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イドモッズ風で(2) 私たちをメンバーと同じくらい具体化させる、(0) eSignature-explicit97(29)
DEFINITIONS EXPLICIT TAGS ::=
定義、明白なタグ:、:=
BEGIN
始まってください。
-- EXPORTS All -
-- すべてをエクスポートする、-
IMPORTS
輸入
-- Cryptographic Message Syntax (CMS): RFC 3852
-- 暗号のメッセージ構文(cm): RFC3852
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) }
ContentInfo、ContentType、イドデータ、イド-signedData、SignedData、EncapsulatedContentInfo、SignerInfo、イド-contentType、イド-messageDigest、MessageDigest、イド-signingTime、SigningTime、イド副署、Countersignature FROM CryptographicMessageSyntax2004iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2004(24)
-- ESS Defined attributes: ESS Update -- RFC 5035 (Adding CertID Algorithm Agility)
-- ESS Defined属性: ESSアップデート--RFC5035(CertIDアルゴリズムの機敏さを加えます)
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) }
ExtendedSecurityServices-2006からのイド-aa-signingCertificate、SigningCertificate、IssuerSerial、イド-aa-contentReference、ContentReference、イド-aa-contentIdentifier、ContentIdentifier、イド-aa-signingCertificateV2iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)のイドモッズ風のess-2006(30)
-- Internet X.509 Public Key Infrastructure -- Certificate and CRL Profile: RFC 3280
-- インターネットX.509公開鍵暗号基盤--証明書とCRLは以下の輪郭を描きます。 RFC3280
Certificate, AlgorithmIdentifier, CertificateList, Name, Attribute
証明書、AlgorithmIdentifier、CertificateList、名前、属性
FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1)
FROM PKIX1Explicit88、iso(1)の特定された組織(3)dod(6)のインターネット(1)
Pinkas, et al. Informational [Page 77] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[77ページ]情報のRFC5126cm
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)}
セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(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)}
PKIX1Implicit88からのGeneralNames、GeneralName、PolicyInformationiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1暗黙の(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)}
PKIXAttributeCertificateからのAttributeCertificateiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズ属性本命(12)
-- OCSP RFC 2560
-- OCSP RFC2560
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)}
OCSPからのBasicOCSPResponse、ResponderIDiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズocsp(14)
-- RFC 3161 Internet X.509 Public Key Infrastructure -- Time-Stamp Protocol
-- RFC3161インターネットX.509公開鍵暗号基盤--タイムスタンププロトコル
TimeStampToken
FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
PKIXTSPからのTimeStampTokeniso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズティースプーンフル(13)
-- X.520
-- X.520
DirectoryString {}
FROM SelectedAttributeTypes
{joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4}
DirectoryString、SelectedAttributeTypes共同iso-itu t ds(5)モジュール(1)selectedAttributeTypes(5)4
;
;
-- Definitions of Object Identifier arcs used in the present document -- ==================================================================
-- 現在のドキュメントで使用されるObject Identifierアークの定義--==================================================================
-- OID used referencing electronic signature mechanisms based -- on the present document for use with the IDUP API (see Annex D)
-- IDUP APIとの使用のための現在のドキュメントに基づいている電子署名メカニズムに参照をつけながら使用されるOID(別館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) }
イドetsi-es-IDUPメカニズムv1オブジェクト識別子:、:= itu t(0)の特定された組織(4)etsi(0)の電子署名規格(1733)part1(1)idupMechanism(4)etsiESv1(1)
Pinkas, et al. Informational [Page 78] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[78ページ]情報のRFC5126cm
-- Basic ES Attributes Defined in the present document -- ===================================================
-- 現在のドキュメントの基本的なES Attributes Defined--===================================================
-- CMS Attributes defined in the present document
-- 現在のドキュメントで定義されたCMS Attributes
-- OtherSigningCertificate - deprecated
-- OtherSigningCertificate--、推奨しなさ
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 19 }
イド-aa-ets-otherSigCertオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)19をメンバーと同じくらい具体化させます。
OtherSigningCertificate ::= SEQUENCE {
certs SEQUENCE OF OtherCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
-- NOT USED IN THE PRESENT DOCUMENT
}
OtherSigningCertificate:、:= 系列本命SEQUENCE OF OtherCertID、方針SEQUENCE OF PolicyInformation OPTIONAL--、NOT USED IN THE PRESENT DOCUMENT
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL }
OtherCertID:、:= 系列otherCertHash OtherHashで、issuerSerial IssuerSerial任意です。
OtherHash ::= CHOICE {
sha1Hash OtherHashValue,
-- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue}
OtherHash:、:= 選択sha1Hash OtherHashValue、--これがSHA-1ハッシュotherHash OtherHashAlgAndValueを含んでいる
-- Policy ES Attributes Defined in the present document -- ====================================================
-- 現在のドキュメントの方針ES Attributes Defined--====================================================
-- Mandatory Basic Electronic Signature Attributes, plus in addition. -- Signature Policy Identifier
-- 義務的なBasic Electronic Signature Attributes、追加におけるプラス。 -- 署名方針識別子
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 }
イド-aa-ets-sigPolicyIdオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-aa(2)15をメンバーと同じくらい具体化させます。
SignaturePolicy ::= CHOICE {
signaturePolicyId SignaturePolicyId,
signaturePolicyImplied SignaturePolicyImplied
-- not used in this version
}
SignaturePolicy:、:= 選択signaturePolicyId SignaturePolicyId、signaturePolicyImplied SignaturePolicyImplied--このバージョンでは、使用されません。
SignaturePolicyId ::= SEQUENCE {
sigPolicyId SigPolicyId,
sigPolicyHash SigPolicyHash,
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL
SignaturePolicyId:、:= 系列、sigPolicyId SigPolicyId、sigPolicyHash SigPolicyHash、SigPolicyQualifierInfo任意のsigPolicyQualifiers系列サイズ(1..MAX)
Pinkas, et al. Informational [Page 79] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[79ページ]情報のRFC5126cm
}
}
SignaturePolicyImplied ::= NULL
SignaturePolicyImplied:、:= ヌル
SigPolicyId ::= OBJECT IDENTIFIER
SigPolicyId:、:= オブジェクト識別子
SigPolicyHash ::= OtherHashAlgAndValue
SigPolicyHash:、:= OtherHashAlgAndValue
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue
}
OtherHashAlgAndValue:、:= 系列hashAlgorithm AlgorithmIdentifier、hashValue OtherHashValue
OtherHashValue ::= OCTET STRING
OtherHashValue:、:= 八重奏ストリング
SigPolicyQualifierInfo ::= SEQUENCE {
sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id
({SupportedSigPolicyQualifiers}),
qualifier SIG-POLICY-QUALIFIER.&Qualifier
({SupportedSigPolicyQualifiers}
{@sigPolicyQualifierId})OPTIONAL }
SigPolicyQualifierInfo:、:= 系列資格を与える人SIG-POLICY-QUALIFIER sigPolicyQualifierId SIG-POLICY-QUALIFIERイド(SupportedSigPolicyQualifiers)、Qualifier、(SupportedSigPolicyQualifiers、@sigPolicyQualifierId) OPTIONAL
SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::=
{ noticeToUser | pointerToSigPolSpec }
SupportedSigPolicyQualifiers SIGの方針資格を与える人:、:= noticeToUser| pointerToSigPolSpec
SIG-POLICY-QUALIFIER ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Qualifier OPTIONAL }
WITH SYNTAX {
SIG-POLICY-QUALIFIER-ID &id
[SIG-QUALIFIER-TYPE &Qualifier] }
SIGの方針資格を与える人:、:= 属してください、イドが識別子ユニークであって、資格を与える人任意の状態で反対する、構文SIG方針資格を与える人IDとイド[SIG資格を与える人タイプと資格を与える人]
noticeToUser SIG-POLICY-QUALIFIER ::= {
SIG-POLICY-QUALIFIER-ID id-spq-ets-unotice SIG-QUALIFIER-TYPE
SPUserNotice }
noticeToUser SIGの方針資格を与える人:、:= SIG POLICY-QUALIFIER IDイド-spq-ets-unotice SIG-QUALIFIER-TYPE SPUserNotice
pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= {
SIG-POLICY-QUALIFIER-ID id-spq-ets-uri SIG-QUALIFIER-TYPE SPuri }
pointerToSigPolSpec SIGの方針資格を与える人:、:= SIG POLICY-QUALIFIER 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 }
イド-spq-ets-uri OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-spq(5)1をメンバーと同じくらい具体化させます。
SPuri ::= IA5String
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 }
イド-spq-ets-unotice OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs9(9) smime(16)イド-spq(5)2をメンバーと同じくらい具体化させます。
Pinkas, et al. Informational [Page 80] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[80ページ]情報のRFC5126cm
SPUserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
SPUserNotice:、:= 系列noticeRef NoticeReference任意であって、explicitText DisplayText任意です。
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
NoticeReference:、:= 系列組織DisplayText、noticeNumbers SEQUENCE OF INTEGER
DisplayText ::= CHOICE {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
DisplayText:、:= 選択visibleString VisibleString(サイズ(1 .200))、bmpString BMPString(サイズ(1 .200))、utf8String UTF8String(サイズ(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}
イド-aa-ets-commitmentTypeオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)16をメンバーと同じくらい具体化させます。
CommitmentTypeIndication ::= SEQUENCE {
commitmentTypeId CommitmentTypeIdentifier,
commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF
CommitmentTypeQualifier OPTIONAL}
CommitmentTypeIndication:、:= 系列commitmentTypeId CommitmentTypeIdentifier、CommitmentTypeQualifier任意のcommitmentTypeQualifier系列サイズ(1..MAX)
CommitmentTypeIdentifier ::= OBJECT IDENTIFIER
CommitmentTypeIdentifier:、:= オブジェクト識別子
CommitmentTypeQualifier ::= SEQUENCE {
commitmentQualifierId COMMITMENT-QUALIFIER.&id,
qualifier COMMITMENT-QUALIFIER.&Qualifier OPTIONAL }
CommitmentTypeQualifier:、:= 系列資格を与える人COMMITMENT-QUALIFIER commitmentQualifierId COMMITMENT-QUALIFIERイド、Qualifier OPTIONAL
COMMITMENT-QUALIFIER ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Qualifier OPTIONAL }
WITH SYNTAX {
COMMITMENT-QUALIFIER-ID &id
[COMMITMENT-TYPE &Qualifier] }
委任資格を与える人:、:= 属してください、イドが識別子ユニークであって、資格を与える人任意の状態で反対する、構文委任資格を与える人IDとイド[委任タイプと資格を与える人]
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}
イド-cti-ets-proofOfOriginオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfReceiptオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfDeliveryオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6)3をメンバーと同じくらい具体化させます。
Pinkas, et al. Informational [Page 81] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[81ページ]情報のRFC5126cm
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}
イド-cti-ets-proofOfSenderオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfApprovalオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-cti-ets-proofOfCreationオブジェクト識別子:、:= iso(1)は(2) 私たち(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}
イド-aa-ets-signerLocationオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-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 }
SignerLocation:、:= 系列--少なくとも以下の1つがX.520 postalAdddress[2]の場所をPostalAddress OPTIONALと命名するために同じくらいOPTIONALで、X.520 localityName[1]DirectoryString maxSizeのa CountryをOPTIONALと命名するのに使用されるように同じくらい使用されていた状態でcountryName[0]DirectoryString maxSizeを寄贈するためにことになる
PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString{maxSize}
-- maxSize parametrization as specified in X.683
PostalAddress:、:= SEQUENCE SIZE(1 .6)OF DirectoryString maxSize--X.683の指定されるとしてのmaxSize助変数化
-- 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}
イド-aa-ets-signerAttrオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)18をメンバーと同じくらい具体化させます。
SignerAttribute ::= SEQUENCE OF CHOICE {
claimedAttributes [0] ClaimedAttributes,
certifiedAttributes [1] CertifiedAttributes }
SignerAttribute:、:= 選択の系列claimedAttributes[0]ClaimedAttributes、certifiedAttributes[1]CertifiedAttributes
ClaimedAttributes ::= SEQUENCE OF Attribute
ClaimedAttributes:、:= 属性の系列
CertifiedAttributes ::= AttributeCertificate -- as defined in RFC 3281: see Section 4.1
CertifiedAttributes:、:= AttributeCertificate--RFC3281で定義されるように: セクション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
イド-aa-ets-contentTimestampオブジェクト識別子:、:= iso(1)が(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)20をメンバーと同じくらい具体化させる、ContentTimestamp:、:= TimeStampToken
Pinkas, et al. Informational [Page 82] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[82ページ]情報のRFC5126cm
-- 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}
イド-aa-signatureTimeStampTokenオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)14をメンバーと同じくらい具体化させます。
SignatureTimeStampToken ::= TimeStampToken
SignatureTimeStampToken:、:= TimeStampToken
-- Complete Certificate Refs.
-- 証明書審判を完成してください。
id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}
イド-aa-ets-certificateRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)21をメンバーと同じくらい具体化させます。
CompleteCertificateRefs ::= SEQUENCE OF OtherCertID
CompleteCertificateRefs:、:= OtherCertIDの系列
-- Complete Revocation Refs
-- 完全な取消し審判
id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}
イド-aa-ets-revocationRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)22をメンバーと同じくらい具体化させます。
CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef
CompleteRevocationRefs:、:= CrlOcspRefの系列
CrlOcspRef ::= SEQUENCE {
crlids [0] CRLListID OPTIONAL,
ocspids [1] OcspListID OPTIONAL,
otherRev [2] OtherRevRefs OPTIONAL
}
CrlOcspRef:、:= 系列crlids[0]CRLListID OPTIONAL、ocspids[1]OcspListID OPTIONAL、otherRev[2]OtherRevRefs OPTIONAL
CRLListID ::= SEQUENCE {
crls SEQUENCE OF CrlValidatedID
}
CRLListID:、:= 系列crls SEQUENCE OF CrlValidatedID
CrlValidatedID ::= SEQUENCE {
crlHash OtherHash,
crlIdentifier CrlIdentifier OPTIONAL }
CrlValidatedID:、:= 系列crlHash OtherHashで、crlIdentifier CrlIdentifier任意です。
CrlIdentifier ::= SEQUENCE {
crlissuer Name,
crlIssuedTime UTCTime,
crlNumber INTEGER OPTIONAL
}
CrlIdentifier:、:= 系列crlissuer Name、crlIssuedTime UTCTime、crlNumber INTEGER OPTIONAL
OcspListID ::= SEQUENCE {
ocspResponses SEQUENCE OF OcspResponsesID
}
OcspListID:、:= 系列OcspResponsesIDのocspResponses系列
OcspResponsesID ::= SEQUENCE {
ocspIdentifier OcspIdentifier,
OcspResponsesID:、:= 系列、ocspIdentifier OcspIdentifier
Pinkas, et al. Informational [Page 83] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[83ページ]情報のRFC5126cm
ocspRepHash OtherHash OPTIONAL
}
ocspRepHash OtherHash任意
OcspIdentifier ::= SEQUENCE {
ocspResponderID ResponderID,
-- As in OCSP response data
producedAt GeneralizedTime
-- As in OCSP response data
}
OcspIdentifier:、:= 系列OCSP応答データproducedAt GeneralizedTimeのようなコネとしてのocspResponderID ResponderID、OCSP応答データ
OtherRevRefs ::= SEQUENCE {
otherRevRefType OTHER-REVOCATION-REF.&id,
otherRevRefs SEQUENCE OF OTHER-REVOCATION-REF.&Type
}
OtherRevRefs:、:= 系列otherRevRefType他の取消し審判イド、他の取消し審判タイプのotherRevRefs系列
OTHER-REVOCATION-REF ::= CLASS {
&Type,
&id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX {
WITH SYNTAX &Type ID &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}
イド-aa-ets-certValuesオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)23をメンバーと同じくらい具体化させます。
CertificateValues ::= SEQUENCE OF Certificate
CertificateValues:、:= 証明書の系列
-- 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}
イド-aa-ets-revocationValuesオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)24をメンバーと同じくらい具体化させます。
RevocationValues ::= SEQUENCE {
crlVals [0] SEQUENCE OF CertificateList OPTIONAL,
ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
RevocationValues:、:= 系列、BasicOCSPResponse任意の任意のCertificateList ocspVals[1]系列のcrlVals[0]系列
otherRevVals [2] OtherRevVals OPTIONAL
}
otherRevVals[2]OtherRevVals任意
OtherRevVals ::= SEQUENCE {
otherRevValType OTHER-REVOCATION-VAL.&id,
otherRevVals SEQUENCE OF OTHER-REVOCATION-REF.&Type
}
OtherRevVals:、:= 系列otherRevValTypeの他の取消しVALイド、他の取消し審判タイプのotherRevVals系列
OTHER-REVOCATION-VAL ::= CLASS {
&Type,
他のREVOCATIONヴァル:、:= クラス、タイプしてください。
Pinkas, et al. Informational [Page 84] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[84ページ]情報のRFC5126cm
&id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX {
WITH SYNTAX &Type ID &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}
-- ビャクシン属の木Cタイムスタンプイド-aa-ets-escTimeStampオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)25をメンバーと同じくらい具体化させます。
ESCTimeStampToken ::= TimeStampToken
ESCTimeStampToken:、:= TimeStampToken
-- Time-Stamped Certificates and CRLs
-- 時間で押し込まれた証明書とCRLs
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}
イド-aa-ets-certCRLTimestampオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)26をメンバーと同じくらい具体化させます。
TimestampedCertsCRLs ::= TimeStampToken
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}
イド-aa-ets-archiveTimestampV2オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)48をメンバーと同じくらい具体化させます。
ArchiveTimeStampToken ::= TimeStampToken
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}
イド-aa-ets-attrCertificateRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)44をメンバーと同じくらい具体化させます。
AttributeCertificateRefs ::= SEQUENCE OF OtherCertID
AttributeCertificateRefs:、:= 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}
イド-aa-ets-attrRevocationRefsオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)イド-aa(2)45をメンバーと同じくらい具体化させます。
AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef
AttributeRevocationRefs:、:= CrlOcspRefの系列
END
終わり
Pinkas, et al. Informational [Page 85] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[85ページ]情報のRFC5126cm
Annex 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は提供されます。 この別館は、様々な拡張電子署名形式で存在している必要がある属性を記載して、拡張フォーマットを使用することで例の合法化系列を提供します。
B.1. Extended Forms of Validation Data
B.1。 拡張型に関する合法化データ
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で例証されたComplete合法化データ(CAdES-C)は、拡張合法化データで電子署名を作成するために広げられるかもしれません。 拡張合法化を含んでいるいくつかの電子署名書式が以下で説明されます。
An X-Long electronic signature (CAdES-X Long) is the CAdES-C with the values of the certificates and revocation information.
X長い電子署名(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;
- 完全な証明経路を作るすべてのカリフォルニア証明書。
- 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:
いくつかの状況で、追加タイムスタンプは、追加属性としてElectronic Signaturesに作成されて、加えられるかもしれません。 例えば:
- 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)と共に保持されるようにすべての合法化データを時スタンプで押して、このeXtended合法化データはCAdES-X Type1と呼ばれます。 または
- time-stamping individual reference data as used for complete
validation. This form of eXtended validation data is called an
CAdES-X Type 2.
- 完全な合法化に使用される時間の刻印の個々の参考資料。 このフォームに関するeXtended合法化データはCAdES-X Type2と呼ばれます。
NOTE 1: The advantages/drawbacks for CAdES-X Type 1 and CAdES-X
Type 2 are discussed in Annex C.4.4.
注意1: Annex C.4.4でCAdES-X Type1とCAdES-X Type2のための利点/欠点について議論します。
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.
証明書チェーンに使用されるどんなカリフォルニアキーにも感染されるかもしれないのが危険を打ち返すのに必要であるときに、上のタイムスタンプフォームは役に立つ場合があります。
Pinkas, et al. Informational [Page 86] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[86ページ]情報のRFC5126cm
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つの形式の組み合わせは使用されるかもしれません。 このフォームに関するeXtended合法化データはES X長いType1かCAdES-X Long Type2と呼ばれます。 検証が値と証拠の両方を必要とするとき、この形式の電子署名は合法化データが存在した時で役に立つ場合があります。
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: Annex C.4.6でCAdES-Xの長いType1とCAdES-Xの長いType2のための利点/欠点について議論します。
B.1.1. CAdES-X Long
B.1.1。 ビャクシン属の木X長さ
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長い)を形成している電子署名は、図B.1で例証されて、以下を包括します:
- CAdES-BES or CAdES-EPES, as defined in Sections 4.3 , 5.7, or
5.8;
- CAdES-BESかCAdES-EPESセクション4.3で定義されるような5.7、または5.8。
- 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で定義されるような属性取消し参照属性。
Other unsigned attributes may be present, but are not required.
他の未署名の属性は、存在しているかもしれませんが、必要ではありません。
Pinkas, et al. Informational [Page 87] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[87ページ]情報のRFC5126cm
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.
以下に注意してください。 ユーザ属性証明書が電子署名で存在している場合にだけ、属性証明書と取消し参照は存在しています。 .3にセクション6.2 .2と6.2を見てください。
+---------------------- 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 || | || +-----------+| | |+--------------------------------------------------+ | | | +--------------------------------------------------------------------+
+---------------------- ビャクシン属の木Xは切望されます。--------------------------------+ |+-------------------------------------- ビャクシン属の木C---+ | || +----------+ | +-------------+| ||+----- ビャクシン属の木-BESかビャクシン属の木-EPES----+ |タイムスタンプ| | | || ||| | |終わる| | | 完全|| |||+---------++----------++---------+| |デジタル| | | 証明書|| |||| || || || |署名| | | そして|| ||||署名者のもの|| 署名されます。||Digital|| | | | | 取消し|| ||||ドキュメント||属性||署名|| |任意| | | データ|| |||| || || || |いつ| | | || |||+---------++----------++---------+| |timemarkedしました。| | | || ||+----------------------------------+ +----------+ | | || || +-----------+| +-------------+| || |完全|| | || |証明書|| | || |そして|| | || |取消し|| | || |参照|| | || +-----------+| | |+--------------------------------------------------+ | | | +--------------------------------------------------------------------+
Figure B.1: Illustration of CAdES-X-Long
B.1は計算します: ビャクシン属の木X長さのイラスト
B.1.2. CAdES-X Type 1
B.1.2。 ビャクシン属の木Xタイプ1
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:
追加合法化データがeXtended合法化データを形成している電子署名--タイプしてください、1、X、図B.2で例証されて、以下を包括します:
- the CAdES-BES or CAdES-EPES, as defined in Sections 4.2, 5.7, or
5.8;
- CAdES-BESかCAdES-EPESセクション4.2で定義されるような5.7、または5.8。
- 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タイムスタンプ属性。
Pinkas, et al. Informational [Page 88] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[88ページ]情報のRFC5126cm
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で定義されるような属性取消し参照属性。
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 || | || +-----------+| | |+-------------------------------------------------+ | | | +--------------------------------------------------------------------+
+------------------------ ビャクシン属の木Xがタイプされた1----------------------------+ |+---------------------------------- ビャクシン属の木C------+ | || +----------+ | +-------------+ | ||+--- ビャクシン属の木-BESかビャクシン属の木-EPES------+|タイムスタンプ| | | | | ||| ||終わる| | | | | |||+---------++----------++---------+||デジタル| | | | | ||||署名者のもの|| 署名されます。|| Digital|||署名| | | タイムスタンプ| | ||||ドキュメント||属性||署名||| | | | 終わる| | |||| || || |||任意| | | ビャクシン属の木C| | |||+---------++----------++---------+||いつ| | | | | ||+----------------------------------+|timemarkedしました。| | | | | || +----------+ | | | | || +-----------+| +-------------+ | || |完全|| | || |証明書|| | || | そして|| | || |取消し|| | || |参照|| | || +-----------+| | |+-------------------------------------------------+ | | | +--------------------------------------------------------------------+
Figure B.2: Illustration of CAdES-X Type 1
B.2は計算します: ビャクシン属の木Xタイプ1のイラスト
Pinkas, et al. Informational [Page 89] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[89ページ]情報のRFC5126cm
B.1.3. CAdES-X Type 2
B.1.3。 ビャクシン属の木Xタイプ2
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:
追加合法化データがeXtended Validation Dataを形成している電子署名--タイプしてください、2、X、図B.3で例証されて、以下を包括します:
- CAdES-BES or CAdES-EPES, as defined in Sections 4.2, 5.7, or
5.8;
- CAdES-BESかCAdES-EPESセクション4.2で定義されるような5.7、または5.8。
- 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で定義されるような時間の押し込まれた本命crls参照属性。
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で定義されるような属性取消し参照属性。
Other unsigned attributes may be present, but are not required.
他の未署名の属性は、存在しているかもしれませんが、必要ではありません。
Pinkas, et al. Informational [Page 90] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[90ページ]情報のRFC5126cm
+----------------------- 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 || | || +-----------+| | |+-------------------------------------------------+ | | | +--------------------------------------------------------------------+
+----------------------- ビャクシン属の木Xがタイプされた2-----------------------------+ |+-------------------------------------- ビャクシン属の木C--+| || +----------+ | | ||+--ビャクシン属の木-BESかビャクシン属の木-EPES-------+|タイムスタンプ| | | ||| ||終わる| | | |||+---------++----------++---------+||デジタル| | +-------------+ | |||| || || |||署名| | | タイムスタンプ| | ||||署名者のもの|| 署名されます。|| Digital||| | | | 唯一| | ||||ドキュメント||属性||署名|||任意| | | 完全| | |||| || || |||いつ| | | 証明書| | |||+---------++----------++---------+||Timemarkedしました。| | | そして| | ||+----------------------------------++----------+ | | 取消し| | || +-----------+| | 参照| | || |完全|| +-------------+ | || |証明書|| | || |そして|| | || |取消し|| | || |参照|| | || +-----------+| | |+-------------------------------------------------+ | | | +--------------------------------------------------------------------+
Figure B.3: Illustration of CAdES-X Type 2
B.3は計算します: ビャクシン属の木Xタイプ2のイラスト
B.1.4. CAdES-X Long Type 1 and CAdES-X Long Type 2
B.1.4。 ビャクシン属の木X長いタイプ1とビャクシン属の木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 Type1とCAdES-X Long Type2を形成している電子署名は、図B.4で例証されて、以下を包括します:
- CAdES-BES or CAdES-EPES, as defined in Sections 4.3, 5.7, or
5.8;
- CAdES-BESかCAdES-EPESセクション4.3で定義されるような5.7、または5.8。
- 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で定義されるような署名タイムスタンプ属性。
Pinkas, et al. Informational [Page 91] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[91ページ]情報のRFC5126cm
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で定義されるような属性取消し参照属性。
Plus one of the following attributes is required:
以下の属性のプラス1が必要です:
- CAdES-C-Timestamp attribute, as defined in Section 6.3.5;
- セクション6.3.5で定義されるようなCAdES Cタイムスタンプ属性
- time-stamped-certs-crls-references attribute, as defined in
Section 6.3.6.
- セクション6.3.6で定義されるような時間の押し込まれた本命crls参照属性。
Other unsigned attributes may be present, but are not required.
他の未署名の属性は、存在しているかもしれませんが、必要ではありません。
Pinkas, et al. Informational [Page 92] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[92ページ]情報のRFC5126cm
+---------------------- 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 | | | +------------+ | +-------------------------------------------------------------------+
+---------------------- ビャクシン属の木Xがタイプされた1か2------------------------+ | +--------------+| |+-------------------------------------- ビャクシン属の木C--+|+------------+|| || +----------+ ||| タイムスタンプ||| ||+--ビャクシン属の木-BESかビャクシン属の木-EPES-------+|タイムスタンプ| ||| 終わる||| ||| ||終わる| ||| ビャクシン属の木C||| |||+---------++----------++---------+||デジタル| | +------------+ | |||| || || |||署名| || または|| ||||署名者のもの|| 署名されます。|| Digital||| | ||+------------+|| ||||ドキュメント||属性||署名|||任意| ||| タイムスタンプ||| |||| || || |||いつ| ||| 唯一||| |||+---------++----------++---------+||timemarkedしました。| ||| 完全||| ||+----------------------------------++----------+ ||| 証明書||| || ||| そして||| || +-----------+||| 取消し||| || |完全|||| 参照||| || |証明書|||+------------+|| || |そして||+--------------+| || |取消し|| +------------+ | || |参照|| |完全| | || +-----------+| |証明書| | |+-------------------------------------------------+ | そして| | | |取消し| | | | 値| | | +------------+ | +-------------------------------------------------------------------+
Figure B.4: Illustration of CAdES-X Long Type 1
and CAdES-X Long Type 2
B.4は計算します: ビャクシン属の木X長いタイプ1とビャクシン属の木X長いタイプ2のイラスト
B.2. Time-Stamp Extensions
B.2。 タイムスタンプ拡大
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:
タイムスタンプ属性の各インスタンスはタイムスタンプのsignedDataの未署名の属性として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の属性を取消しで評価します。
Pinkas, et al. Informational [Page 93] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[93ページ]情報のRFC5126cm
Other unsigned attributes may be present, but are not required.
他の未署名の属性は、存在しているかもしれませんが、必要ではありません。
B.3. Archive Validation Data (CAdES-A)
B.3。 アーカイブ合法化データ(ビャクシン属の木a)
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)。 前のCAdES-Aを時押し込むのに使用される保護が弱くなるときはいつも、Time-押し込むプロセスは繰り返されるかもしれません。 その結果、CAdES-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.
電子署名(ES)に関する例、CAdES-CとCAdES-Xのための追加合法化データが形成されている状態で、CAdES-Aは図B.5で例証されます。
Pinkas, et al. Informational [Page 94] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[94ページ]情報のRFC5126cm
+--------------------------- 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 | | | || +------------+ | | |+----------------------------------------------------+ | +--------------------------------------------------------------------+
+--------------------------- ビャクシン属の木A---------------------------------+ |+----------------------------------------------------+ | || +--------------+| +----------+ | ||+--------------------- ビャクシン属の木C----+|+------------+|| | | | ||| +----------+ ||| タイムスタンプ||| | | | |||+--ビャクシン属の木-BES------+|タイムスタンプ| ||| 終わる||| | | | |||| または、ビャクシン属の木-EPES||終わる| ||| ビャクシン属の木C||| | アーカイブ| | |||| ||デジタル| ||+------------+|| | | | |||| ||署名| || または|| |タイムスタンプ| | |||| || | ||+------------+|| | | | |||| ||任意| ||| タイムスタンプ||| | | | |||| ||いつ| ||| 唯一||| | | | |||| ||timemarkedしました。| ||| 完全||| | | | |||+-------------------++----------+ ||| 証明書||| +----------+ | ||| ||| そして||| | ||| +-------------+||| 取消し||| | ||| | 完全|||| 参照||| | ||| | 証明書|||+------------+|| | ||| | そして||+--------------+| | ||| | 取消し|| +------------+ | | ||| | 参照|| |完全| | | ||| +-------------+| |証明書| | | ||+----------------------------------+ | そして| | | || |取消し| | | || | 値| | | || +------------+ | | |+----------------------------------------------------+ | +--------------------------------------------------------------------+
Figure B.5: Illustration of CAdES-A
B.5は計算します: ビャクシン属の木Aのイラスト
The CAdES-A comprises the following elements:
CAdES-Aは以下の要素を包括します:
- the CAdES-BES or CAdES-EPES, including their signed and unsigned
attributes;
- 彼らの署名していて未署名の属性を含む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で定義されるような署名タイムスタンプ属性。
Pinkas, et al. Informational [Page 95] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[95ページ]情報のRFC5126cm
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で定義されるような属性取消し参照属性。
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タイムスタンプ属性
- time-stamped-certs-crls-references attribute, as defined in
Section 6.3.6.
- セクション6.3.6で定義されるような時間の押し込まれた本命crls参照属性。
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.
タイムスタンプを格納している属性のいくつかのインスタンスが時間の上と、そして、電子署名と、異なったTSUsから起こるかもしれません。 タイムスタンプは、オリジナルの電子署名かタイムスタンプより強いアルゴリズム(または、より長いキー長)を使用することで作成されるべきです。
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の属性を証明書で評価します。
Pinkas, et al. Informational [Page 96] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[96ページ]情報のRFC5126cm
- 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.
他の未署名の属性は、存在しているかもしれませんが、必要ではありません。
B.4. Example Validation Sequence
B.4。 例の合法化系列
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|
+---------+ +--------+
+------------------------------------------ ビャクシン属の木C-------------+ |+------------------------------- ビャクシン属の木T------+ | ||+-------------- ビャクシン属の木------------+ | | |||+--------------------++---------+|+---------+| +-----------+ | |||| ________ || |||タイムスタンプ|| |完全| | |||||Sign.Pol| ||Digital|||終わる|| |証明書| | ||||| アイダホ州 | 署名されます。||署名|||デジタル|| | そして| | ||||| オプション| 属性|| |||署名|| |取消し| | |||||________| |+---------+|+---------+| |参照| | |||+--------------------+ | ^ | +-----------+ | ||+---------------------------------+ | | ^ | || 1 | / | | | |+---------------------- | ------------/--------+ | | +----------------------- | ---------- / --------------- / -------+ | /2 ----3-------- +----------+ | / / | | /に対して| | 署名者のもの| +---------------------+ +-------------+ | ドキュメント|、-、-、-、--、>| 合法化プロセス|、-、-、--、>|、- 有効| | | +---------------------+ 4 |- 病人| +----------+ | ^ | ^ |- 合法化| v| v| | 不完全| +---------+ +--------+ +-------------+ |署名| |信じられます。| | 方針| |サービス| | 発行人| |プロバイダー| +---------+ +--------+
Figure B.6: Illustration of a CAdES validation sequence
B.6は計算します: CAdES合法化系列のイラスト
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
署名者(1)から電子署名(CAdES)を受けたすぐ後に、デジタル署名値はチェックされるかもしれません。 合法化プロセスはタイムスタンプ(2)を少なくとも加えるものとします、署名者が検証によって信じられるものを提供していない場合。 また、合法化プロセスは、Trusted Serviceによって提供された追加データ(例えば、証明書、CRLなど)を使用することで電子署名を有効にするかもしれません。
Pinkas, et al. Informational [Page 97] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[97ページ]情報のRFC5126cm
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.
プロバイダー。 また、適切であるときに、合法化プロセスは、署名方針で指定された要件に従う必要があるでしょう。 合法化プロセスが合法化不完全であるなら、このステージからの出力は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).
ValidかInvalidとして正当性状態を確かめて、ユーザ(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で例証されます。
Pinkas, et al. Informational [Page 98] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[98ページ]情報のRFC5126cm
+----------------------------------------------------- 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|
+---------+ +--------+
+----------------------------------------------------- ビャクシン属の木X長い-+|+------------------------------- ビャクシン属の木C-------------+ | ||+-------------- ビャクシン属の木------------+ | | |||+--------------------++---------+|+---------+ |+-----------+| |||| ________ || |||タイムスタンプ| ||完全|| |||||Sign.Pol| ||Digital|||終わる| ||証明書|| ||||| アイダホ州 | 署名されます。||署名|||デジタル| || そして|| ||||| オプション| 属性|| |||署名| ||取消し|| |||||________| || ||+---------+ || 値|| |||+--------------------++---------+| ^ +-----------+|+-----------+| ||+---------------------------------+ | |完全|| ^ | || | | |証明書|| | | || | 2 | | そして|| | | || | | |取消し|| | | || | | |参照|| | | || 1 | / +-----------+| | | |+------------------------ | ------- / --------- ^-----+ / | +------------------------- | ------ / ---------- |--------- / -------+ | / ----- / ------- / +----------+ | / / 3 / 5 | | v| | | | 署名者のもの| +--------------------+ +-----------+ | ドキュメント|、-、-、-、--、>| 合法化プロセス|、-、-、-、--、>| - 有効| | | +--------------------+ 4 | - 病人| +----------+ | ^ | ^ +-----------+ v| v| +---------+ +--------+ |署名| |信じられます。| | 方針| |サービス| | 発行人| |プロバイダー| +---------+ +--------+
Figure B.7: Illustration of a CAdES validation sequence
with CAdES-X Long
B.7は計算します: CAdES-X LongとのCAdES合法化系列のイラスト
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 Type1を形成するすべてのデータを時スタンプで押すことです。
This is illustrated in Figure B.8.
これは図B.8で例証されます。
Pinkas, et al. Informational [Page 99] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[99ページ]情報のRFC5126cm
+------------------------------------------------ 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|
+---------+ +--------+
+------------------------------------------------ ビャクシン属の木Xタイプ1-----+ |+------------------------------- ビャクシン属の木C------------------+ | ||+-------------- ビャクシン属の木------------+ | | |||+--------------------++---------+|+---------++----------+|+-------+| |||| ________ || |||タイムスタンプ|| 完全||| || |||||Sign.Pol| ||Digital|||終わる|| 本命。 |||時間|| ||||| アイダホ州 | 署名されます。||署名|||デジタル|| そして|||スタンプ|| ||||| オプション| 属性|| |||署名|| revoc。 ||| 終わる|| |||||________| |+---------+|+---------+|参照|||ビャクシン属の木C|| |||+--------------------+ | ^ | ||| || ||+---------------------------------+ | +----------+|+-------+| || | | ^ | ^ | || 1 | / | | | | |+------------------------ | --------- / ----------- / -----+ | | +------------------------- | -------- / ----------- / --------- / ----+ | 2 / ---3---- / +----------+ | / / -----------5------ | | v| | / | 署名者のもの| +--------------------+ +-----------+ | ドキュメント|、-、-、-、--、>| 合法化プロセス|、-、-、-、--、>| - 有効| | | +--------------------+ 4 | - 病人| +----------+ | ^ | ^ +-----------+ v| v| +---------+ +--------+ |署名| |信じられます。| | 方針| |サービス| | 発行人| |プロバイダー| +---------+ +--------+
Figure B.8: Illustration of CAdES with eXtended validation data
CAdES-X Type 1
B.8は計算します: eXtended合法化データCAdES-X Type1があるCAdESのイラスト
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.
証明書と取消し情報参照が電子署名(しかし、署名でない)(6)を有効にするのに使用したタイムスタンプには別の代替手段があります。 結末はCAdES-X Type2と呼ばれます。
This is illustrated in Figure B.9.
これは図B.9で例証されます。
Pinkas, et al. Informational [Page 100] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[100ページ]情報のRFC5126cm
+-------------------------------------------- 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|
+---------+ +--------+
+-------------------------------------------- ビャクシン属の木Xタイプ2--------+ |+------------------------------- ビャクシン属の木C-------------+ | ||+-------------- ビャクシン属の木------------+ | | |||+--------------------++---------+|+---------+ |+-----------+| |||| ________ || |||タイムスタンプ| ||タイムスタンプ|| |||||Sign.Pol| || |||終わる| || 終わる|| ||||| アイダホ州 | 署名されます。||Digital|||デジタル| ||完全|| ||||| オプション| 属性||署名|||署名| ||証明書|| |||||________| || ||| | || || |||+--------------------++---------+|+---------+ || そして|| ||+---------------------------------+ ^ +-----------+||取消し|| || | | |完全|||参照|| || | | |証明書||+-----------+| || | | | そして|| ^ | || 1 | 2 | |取消し|| | | || | | |参照|| | | || | | +-----------+| | | |+------------------------ | --------- | --- ^ --------+ | | | | | 3 | / | | | | / ---------- | | | / / / 6 | | | / / / | | | / / / | +------------------------- | ----- | -- | -- / ----------------------+ | | | | v| | | +--------------------+ +-----------+ | 合法化プロセス|、-、-、-、--、>| - 有効| +--------------------+ 4 | - 病人| | ^ | ^ +-----------+ v| v| +---------+ +--------+ |署名| |信じられます。| | 方針| |サービス| | 発行人| |プロバイダー| +---------+ +--------+
Figure B.9: Illustration of CAdES with eXtended validation data
CAdES-X Type 2
B.9は計算します: eXtended合法化データCAdES-X Type2があるCAdESのイラスト
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で例証されます。
Pinkas, et al. Informational [Page 101] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[101ページ]情報のRFC5126cm
+----------------------------- 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|
+---------+ +--------+
+----------------------------- ビャクシン属の木A---------------------------+ | | | +--ビャクシン属の木X長いタイプ1か2----------+ | | | | +------------+ | | | | | | | | | | | アーカイブ| | | | | | タイムスタンプ| | | | | | | | | | | +------------+ | | +---------------------------------------+ ^ | | +----------+ ^ ^ ^ ^ | | | | | | | | | / | | | 署名者のもの| | | | | / | | | ドキュメント|\ | | | | / | | | | \ 1 2 | 3 | 5 | 6 | 7 / | | +----------+ \ | | | | / | | \ | | | | / | +----------------- \ --- | - | - | - | ------ / ------------------+ \ | | | | | | | | | | | | | | | | | vに対して| | | | +-----------------------------+ +-----------+ | 合法化プロセス|、-、-、-、--、>| - 有効| +-----------------------------+ 4 | - 病人| | ^ | ^ +-----------+ v| v| +---------+ +--------+ |署名| |信じられます。| | 方針| |サービス| | 発行人| |プロバイダー| +---------+ +--------+
Figure B.10: Illustration of CAdES-A
B.10は計算します: ビャクシン属の木Aのイラスト
B.5. Additional Optional Features
B.5。 追加オプション機能
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;
- 署名が作成された要求されたか公認された役割を示してください。
Pinkas, et al. Informational [Page 102] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[102ページ]情報のRFC5126cm
- 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.
以下の仕様は電子署名のそれぞれのコンポーネントが役に立つなぜと時に関する記述を含んでいるか、脆弱性と脅威の簡単な説明とそれらが打ち返される方法で。
C.1. The Signature Policy
C.1。 署名方針
The signature policy is a set of rules for the creation and validation of an electronic signature, under which the signature can be determined to be valid. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. A signature policy may be issued, for example, by a party relying on the electronic signatures and selected by the signer for use with that relying party. Alternatively, a signature policy may be established through an electronic trading association for use amongst its members. Both the signer and verifier use the same signature policy.
署名方針は、作成のための1セットの規則と電子署名の合法化です。(署名は有効であることをそれで決定できます)。 与えられた法的であるか契約上の文脈は必要条件を満たすと特定の署名方針を認識するかもしれません。 署名方針は、例えば、電子署名に依存するパーティーが発行されて、使用のためにそんなに当てにしているパーティーと共に署名者によって選択されるかもしれません。 あるいはまた、署名方針は使用のためにメンバーの中で電子商取引協会を通して確立されるかもしれません。 ともに、署名者と検証は同じ署名方針を使用します。
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;
- 特定の署名の技術的検証に適用される規則。
Pinkas, et al. Informational [Page 103] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[103ページ]情報のRFC5126cm
- 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);
- 電子署名(例えば、個人的な署名キーの秘密保持を確実にするための規則)に適用するCertificate Policiesの採用で含意されるかもしれない規則。
- 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(カードAccepting Device)の使用)によって使用される環境に関連する規則。
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);
- 許容できるTSAs(タイムスタンプトークンが使用されているなら)。
- 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.
- 長期の証拠を提供するのが必要であるときに、署名者でデータに提供されるものとする電子署名のコンポーネントを定義する規則が検証が必要です。
C.2. Signed Information
C.2。 情報であると署名されます。
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でカプセル化されたメッセージと定義されるかもしれません。 電子申込書(電子フォームの)からフォーマット済みデータ、無料のテキスト、または分野でそれを構成できます。 例えば、Adobe(tm)形式"pdf"かLanguageへのeXtensibleマーク(XML)が使用されるかもしれません。 別館Dは内容がMIMEを使用することで署名しているデータのタイプを示すためにどう構造化されるかもしれないかを定義します。
C.3. Components of an Electronic Signature
C.3。 電子署名のコンポーネント
C.3.1. Reference to the Signature Policy
C.3.1。 署名方針の参照
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
2回の独立しているパーティーが電子署名を評価したがっているとき、彼らが同じ結果を得るのは、基本的です。 この要件は会われた使用包括的な署名方針がそれであったならそうすることができます。
Pinkas, et al. Informational [Page 104] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[104ページ]情報のRFC5126cm
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.
署名合法化の一貫性を確実にしてください。 署名されるデータでそれとなく署名方針を特定できますか、または電子署名のCAdES-EPESフォームを使用することで明らかにそれらを特定できます。 CAdES-EPESは、署名者と検証の両方で一貫した署名方針を使用しなければならないのを強制します。
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でSignature Policy Identifierを署名して正式に引き渡すことによって、署名者は、その人が署名を作成する際に署名方針を適用したのを明らかに示します。
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.
明白にCAdES-EPESについて確かめるのに使用されることになっている明白な署名方針の詳細を特定するために、「署名方針」の署名、識別子、およびハッシュは署名しているデータの一部になるでしょう。 明白な方針(例えば、ドキュメントのウェブ参照)に関する追加情報は「資格を与える人」としてSignature Policy Identifierまで運ばれるかもしれません。
In order to unambiguously identify the authority responsible for defining an explicit signature policy, the "Signature policy" can be signed.
明白に明白な署名方針を定義するのに原因となる権威を特定するために、「署名方針」に署名することができます。
C.3.2. Commitment Type Indication
C.3.2。 委任タイプ指示
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.
現在のドキュメントの範囲の外に委任が署名されるデータの意味論を使用することでどう示されるかがあります。
Pinkas, et al. Informational [Page 105] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[105ページ]情報のRFC5126cm
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).
- 署名して正式に引き渡されるデータが単に人間(すなわち、無料のテキスト)が解明できる特定の意味論(意味)を持っているので署名者によってされた公約である暗黙の委任。
C.3.3. Certificate Identifier from the Signer
C.3.3。 署名者からの証明書識別子
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.
多くの現実の環境で、ユーザは、同じカリフォルニア(異なった名前のための同じ公開鍵を含む異なった証明書)から異なったCAsから得るのにおいて有能であるか、または同等になるでしょう。 主要な利点はユーザが異なる役割に同じ秘密鍵を使用できるということです。 スマートカードが秘密鍵を保護するのに使用されるとき、秘密鍵の複数の使用が利点です、スマートカードのストレージがいつも制限されるので。 数個のCAsがかかわるとき、それぞれの異なった証明書は国の国民として、または、例えば、会社からの従業員として異なったアイデンティティを含むかもしれません。 秘密鍵が様々な目的に使用されるとき、したがって、証明書が署名を生成するとき秘密鍵が使用された文脈をはっきりさせるのが必要です。 複数の秘密鍵が使用されている可能性があるところでは、署名者が使用されるために正確な証明書を検証に示すのが必要です。
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.
署名の検証に使用されるために明白に証明書を特定するために、署名者からの証明書に関する識別子は署名しているデータの一部になるでしょう。
C.3.4. Role Attributes
C.3.4。 役割の属性
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
署名者の名前は重要ですが、会社か組織の中の署名者の位置は最高のにまた、重要です。 特定の役割(例えば、Salesディレクター)でユーザによって署名される場合にだけ、何らかの情報(すなわち、契約)が有効であるかもしれません。 コネ
Pinkas, et al. Informational [Page 106] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[106ページ]情報のRFC5126cm
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.
多くのケース、販売ディレクターが本当に人であることはそんなに重要ではありませんが、署名者がSalesディレクターであるのに彼の会社によって権限を与えられるのを確信しているのは基本的です。
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.
以下に注意してください。 別の可能なアプローチは署名者のアイデンティティ証明書で役割の名を含む追加属性を使用するだろうことでした。 しかしながら、それは、証明書の管理をかなり複雑にするときこのアプローチに続かないように決められました。 例えば、署名者のアイデンティティと新しいアイデンティティキーが必要とする役割の手段に別々の証明書を使用することによって、ユーザの役割が変化するなら、発行されないでください。
C.3.4.1. Claimed Role
C.3.4.1。 役割であると主張されます。
The signer may be trusted to state his own role without any certificate to corroborate this claim; in which case, the claimed role can be added to the signature as a signed attribute.
署名者がこのクレームを確証するために少しも証明書なしで彼自身の役割を述べると信じられるかもしれません。 その場合、署名している属性として要求された役割を署名に加えることができます。
C.3.4.2. Certified Role
C.3.4.2。 役割であることが公認されます。
Unlike public key certificates that bind an identifier to a public key, Attribute Certificates bind the identifier of a certificate to some attributes, like a role. An Attribute Certificate is NOT issued by a CA but by an Attribute Authority (AA). The Attribute Authority, 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.
公開鍵に識別子を縛る公開鍵証明書と異なって、Attribute Certificatesはいくつかの属性に証明書に関する識別子を縛ります、役割のように。 カリフォルニアによって発行されるのではなく、Attribute Authority(AA)によってAttribute Certificateは発行されます。 多くの場合、Attribute Authorityが組織のコントロールの下にあったかもしれませんか、または最も良い仲間は、どの個人に、どの属性が関連しているかを知るために入賞しました。 Attribute Authorityはどんなカリフォルニアによっても発行された公開鍵証明書を、使用するか、または示すかもしれません、適切な信頼がそのカリフォルニアに置かれるかもしれなければ。 属性Certificatesには、様々な期間の正当性があるかもしれません。 その期間は例えば、1日間、かなり短いかもしれません。 新しいAttribute Certificateが毎日入手されるのが必要である間、当日有効であることで、そのような証明書の取消しは必要でないかもしれないので、これは有利である場合があります。 署名するとき、署名者は、それがどのAttribute Certificateを選択するかを指定しなければならないでしょう。 そうして、Attribute Certificateは、署名者からのデジタル署名で保護されるために署名しているデータに含まれなければならないでしょう。
Pinkas, et al. Informational [Page 107] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[107ページ]情報のRFC5126cm
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.
署名の検証に使用されるために明白に属性証明書を特定するために、署名者からの属性証明書に関する識別子は署名しているデータの一部になるでしょう。
C.3.5. Signer Location
C.3.5。 署名者位置
In some transactions, the purported location of the signer at the time he or she applies his signature may need to be indicated. For this reason, an optional location indicator 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.
その人が彼の署名を適用したとき署名者の位置のしるしを供給するために、位置の属性は署名に含まれるかもしれません。
C.3.6. Signing Time
C.3.6。 署名時間
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.
この属性を使用して、署名者は要求された署名時間である時間、署名するかもしれません。 Timeと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を見てください)、タイムスタンプに日付を含む前に署名しているオブジェクトが存在したと立証するかもしれません。
C.3.7. Content Format
C.3.7。 満足している形式
When presenting signed data to a human user, it may be important that there is no ambiguity as to the presentation of the signed information to the relying party. In order for the appropriate representation (text, sound, or video) to be selected by the relying party when data (as opposed to data that has been further signed or encrypted) is encapsulated in the SignedData (indicated by the
人間のユーザに署名しているデータを提示するとき、信用パーティーへの署名している情報のプレゼンテーションに関してあいまいさが全くないのは、重要であるかもしれません。 データ(さらに署名されるか、または暗号化されたデータと対照的に)がSignedDataでカプセル化されたらパーティーへ行って、適切な表現(テキスト、音、またはビデオ)が信用で選択されてください、(示されます。
Pinkas, et al. Informational [Page 108] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[108ページ]情報のRFC5126cm
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.
イドデータに用意ができているEncapsulatedContentInfoの中のeContentType)、さらに情報をタイプするのは、署名される書類のタイプを特定するのに使用されるべきです。 一般に、これは、RFC2045[6])で定義されたメカニズムをタイプして、コード化するMIME内容を使用することで達成されます。 Annex FでMIMEの使用に関する詳細を与えます。
C.3.8. content-hints
C.3.8満足しているヒント
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.
コンテンツヒント属性は1つの内容が別のものでカプセル化されるマルチ層のメッセージの最も奥深い署名している内容の情報を提供します。 これは暗号化されて、署名しているデータがそれ自体であるなら役に立つかもしれません。
C.3.9. Content Cross-Referencing
C.3.9。 満足している十字参照箇所
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で定義されて、(RFC2634[5])、要求と応答メッセージをリンクする能力を2回のパーティーの間の交換に提供してください。
C.4. Components of Validation Data
C.4。 合法化データの成分
C.4.1. Revocation Status Information
C.4.1。 取消し状態情報
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: 「据置期間」が必要であるなら、電子署名を有効にして、取消し状態情報をチェックするとき、それは、適当に「土壇場」の取消し要求と取消しシステムを通して伝播するという要求のために処理するかかわった権威を許容できるくらい長い必要があります。 タイムスタンプトークンで含まれていた時間かタイム・マークにこの据置期間を加えることになっています、そして、その結果、据置期間の終わりの後に取消し状態情報を得るべきです。
Pinkas, et al. Informational [Page 109] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[109ページ]情報のRFC5126cm
C.4.1.1. CRL Information
C.4.1.1。 CRL情報
When using CRLs to get revocation information, a verifier will have to make sure that he or she gets, at the time of the first verification, the appropriate certificate revocation information from the signer's CA. This should be done as soon as possible to minimize the time delay between the generation and verification of the signature. However, a "grace period" is required to allow CAs time to process revocation requests.
取消し情報を得るのにCRLsを使用するとき、検証は、その人が最初の検証時点で署名者のカリフォルニアから適切な証明書取消し情報を得るのを確実にしなければならないでしょう。 できるだけ早く、署名の世代と検証の間の時間遅れを最小にするためにこれをするべきです。 しかしながら、「据置期間」が、取消し要求を処理する時間を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を発行するすぐ前に取消し要求はカリフォルニアに到着するかもしれません、そして、そこでは、改訂された取消し状態情報を含むことができるくらいの時間、到着しないかもしれません。 これは、署名者証明書通し番号が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に現れても、署名は正当な持ち主によってさえ吊した証明書が使用されるべきでないので有効であるとして考えられないことです。
C.4.1.2. OCSP Information
C.4.1.2。 OCSP情報
When using OCSP to get revocation information, a verifier will have to make sure that he or she gets, at the time of the first verification, an OCSP response that contains the status "valid". This should be done as soon as possible after the generation of the signature, 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応答は、一時的であり、それが安全な場所に保存されるのを確実にするのは、あらゆる検証の責任であっても、その結果、カリフォルニアを含むどんなTSPによっても格納されません。 最も簡単な道は電子署名に関連していた状態でそれらを保存することです。 代替手段は、次に、容易にそれらを検索できるようにそれらを保存して、CAdES-Cフォームとしてそれらの参照を電子署名自体に取り入れるだろうことです。
Pinkas, et al. Informational [Page 110] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[110ページ]情報のRFC5126cm
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のような同じコメントは適用されます。
C.4.2. Certification Path
C.4.2。 証明経路
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つの信じられた根からの自己署名入りの証書のものに上がっている署名者と結末からのそれらから始めて。 適切であるときに、これはSignature Policyの一部として指定されるかもしれません。 さらに、チェーンからのCAsのいずれも署名時点で取り消されなかったと立証するために、Certificate Authority Revocation Lists(CARLs)をキャプチャするのが必要でしょう。 一方、このすべての材料が電子署名で組み込んでいるかもしれません(ES Xは形成します)。 代替手段は、容易にそれを検索できるようにこの情報を保存して、CAdES-Cフォームとしてそれの参照を電子署名自体に取り入れるだろうことです。
C.4.3. Time-Stamping for Long Life of Signatures
C.4.3。 署名の長寿のための時間の刻印
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.
署名者、検証、または両方が提供するのに必要であるかもしれません、要求に応じて、デジタル署名が証明書経路を作るすべての証明書の有効期間の間作成されたか、または確かめられたという証拠。 また、この場合、署名者、検証、または両方が、署名が作成されたか、または確かめられたとき、有効な証明経路を形成するのに使用される署名者の証明書とすべてのカリフォルニア証明書が取り消されなかったという証拠を提供するのに必要でしょう。
Pinkas, et al. Informational [Page 111] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[111ページ]情報のRFC5126cm
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.
証明書が署名時点で、有効でしたが、その後取り消されたのは、事実であるかもしれません。 このイベントでは、証拠は署名キーが取り消される前に書類が署名されたかどうかということでしょう。 Time-押し込むAuthority(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.
タイムスタンプはBasic Electronic Signatureの部品ではありませんが、それは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.
現在のドキュメントでは、タイムスタンプトークンが署名者のデジタル署名値が時間で押し込まれることであるなら、Time-押し込む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.
現在のドキュメントは、電子署名がComplete合法化データでESになることができる前に署名者のデジタル署名値が時間によって信頼できるソースによって押し込まれるのを必要とします。 許容できるTSAsはSignature Validation Policyで指定されるかもしれません。
This technique is referred to as CAdES-C in the present document.
このテクニックは現在のドキュメントのCAdES-Cと呼ばれます。
Pinkas, et al. Informational [Page 112] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[112ページ]情報のRFC5126cm
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個のタイムスタンプの間の受入れられた時間遅れを指定してください。
C.4.4. Time-Stamping for Long Life of Signature before CA Key
Compromises
C.4.4。 カリフォルニアの主要な感染の前の署名の長寿のための時間の刻印
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.
時間で押し込まれます、証明書チェーンで主要なカリフォルニアの可能性を守るという感染される要件があるとき、拡張電子署名が必要です。 検証が提供するのに必要であるかもしれません、要求に応じて、署名時点で使用された証明経路と取消し情報が有効であったという証拠、発行キーかOCSP応答者キーの1つに後で感染される場合でさえ。
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;
- Complete合法化データがあるESを時押し込んでください、OCSP応答が署名者(CAdES-X Type1)から証明書の状態を得るのに使用されるとき。 この形式は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)から証明書の状態を得るのに使用されたら証明経路と取消し情報参照だけを時スタンプで押してください。 この形式はCRLsと共に使用されているのにおいて適当です、時間で押し込まれた情報が1つ以上の署名に使用されるかもしれないので(同じカリフォルニアが署名者でそれらの証明書を発行して、同じCRLsを使用することで署名をチェックできるとき)。
NOTE: The signer, verifier, or both may obtain the time-stamp.
以下に注意してください。 署名者、検証、または両方がタイムスタンプを入手するかもしれません。
C.4.4.1. Time-Stamping the ES with Complete Validation Data (CAdES-X
Type 1)
C.4.4.1。 完全な合法化データがあるESを時押し込みます。(ビャクシン属の木Xタイプ1)
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
OCSP応答が使用されているとき、応答者からのキーがそうする場合における応答が感染されるのが特にタイムスタンプに必要です。 OCSP応答に含まれた情報がユーザ特有であって、時間特有であるので、個々のタイムスタンプが受けられたあらゆる署名に必要です。 証明経路参照と取消し情報参照だけの上にタイムスタンプを置くことの代わりに、タイムスタンプはCAdES-Cに置かれます。参照はOCSP応答を含んでいます。 証明経路と取消し情報指示するものがESにComplete合法化データで含まれているので、また、それらは保護されます。 同じくらいのために
Pinkas, et al. Informational [Page 113] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[113ページ]情報のRFC5126cm
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.
暗号の価格、これはESの上の保全メカニズムにComplete合法化データを提供します。 すぐに、どんな変更も検出できます。 Complete合法化データがある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 Type1と呼ばれます。
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.
それが追加データのコピーが参照をつけるように保つどんな理由でも望まれているなら、追加データは電子署名に添付されるかもしれません、その場合、電子署名がCAdES-X Long Type1になります、現在のドキュメントによって定義されるように。
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 Type1は単にCAdES-X Type1の連結です、追加データのコピーが参照をつけられている状態で。
C.4.4.2. Time-Stamping Certificates and Revocation Information
References (CAdES-X Type 2)
C.4.4.2。 時間の刻印証明書と取消し情報参照(ビャクシン属の木Xタイプ2)
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.
Complete合法化データがある上で定義されるそれぞれ時間の刻印ESは効率的でないかもしれません、特に同じセットのカリフォルニア証明書と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.
時間の刻印カリフォルニア証明書によって、どんな攻撃者もカリフォルニアキーが感染される前に存在すると主張できたにせのカリフォルニア証明書を発行できないでしょう。 どんなにせの時間で押し込まれたカリフォルニア証明書も、正統のカリフォルニアキーが感染された後に証明書が作成されたのを示すでしょう。 同様に、時間の刻印カリフォルニアCRLsは、どんな攻撃者もカリフォルニアキーが感染される前に存在すると主張できたにせのカリフォルニアCRLsを発行するのを止めるでしょう。
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
サービスプロバイダーは例えば、会社の中、または、中心で一般的に使用された証明書とCRLsの時間の刻印ができます。 このメソッドは検証がタイムスタンプに持っているデータ量を減少させます。 すなわち、中例えば、それが1日あたりちょうど1個のタイムスタンプまで減少できた、(。
Pinkas, et al. Informational [Page 114] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[114ページ]情報のRFC5126cm
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が一日中適用するケース) 時間によって押し込まれる必要がある情報が実際の証明書とCRLsではありませんが、それらの明白な参照は、証明書とCRLsです。
This technique is referred to as CAdES-X Type 2 in the present document and requires the following:
このテクニックは、現在のドキュメントにCAdES-X Type2と呼ばれて、以下を必要とします:
- 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.
- CAdES-Cを有効にする際に使用されるすべてのカリフォルニアの証明書参照と取消し情報参照(すなわち、CRLs)が1個以上のタイムスタンプで含まれています。
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+.
したがって、すべてのカリフォルニアとCRL参照が時間で時間によって押し込まれたT1+であるなら有効であると時間T1のタイムスタンプ署名価値があるCAdES-Cを立証できます。
C.4.5. Time-Stamping for Archive of Signature
C.4.5。 署名のアーカイブのための時間の刻印
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.
期間の間、弱点は電子署名を作成するのに使用される(例えば、cryptoanalyticalのテクニックで暗号解読、または改良に空いている時間のため)暗号アルゴリズムで起こるかもしれません。 そのような弱点がありそうになる前に、検証は、電子署名の正当性を維持するために特別策を取るはずです。 弱められた暗号の本質によって、この目標を達成するのにいくつかのテクニックを使用できました。 件を簡素化するために、すべてのケースをカバーしていて、アーカイブ合法化データと呼ばれるただ一つのテクニックは現在のドキュメントで使用されています。
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.
アーカイブ合法化データはデータであって、電子署名と共に時間によって押し込まれた合法化データ、完全な証明書、および取消しから成ります。 署名を作成するのに使用されたハッシュ関数と暗号アルゴリズムがもう安全でないなら、アーカイブ合法化データが必要です。 また、Timeを押し込んでいるAuthorityによって使用されたハッシュ関数が安全であると思うことができないなら、Archived Electronic Signatureの入れ子にされたタイムスタンプが必要です。
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
TSP(s)が、より強い暗号と、より良い主要な保護を使用すると予想されるので、Trusted Service Providerにおける潜在的(TSP)の主要な感染はユーザキーよりかなり低いはずです。 新しいアルゴリズム(または、より大きいキー長がある古いもの)が使用されると予想できます。 このような場合には、タイムスタンプの系列は偽造から守るでしょう。 各タイムスタンプは、付けられる必要があります。
Pinkas, et al. Informational [Page 115] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[115ページ]情報のRFC5126cm
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.
署名キーの感染かTSAによって使用されたアルゴリズムの分解のどちらかの前に。 TSAs(時間を押し込むAuthorities)には、長いキー(例えば、現在のドキュメントを作成する時点で署名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と呼ばれます。
C.4.6. Reference to Additional Data
C.4.6。 追加データの参照
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 Type1かCAdES-X Type2の拡張合法化データを使用して、検証は、まだ署名を有効にするのに使用されたすべてのコンポーネントの動向をおさえる必要があります、再び後でそれらを検索できるように。 これらのコンポーネントはTrusted Service Providerのような外部電源によって格納されるかもしれません。 その場合、ESの一部としてComplete合法化データ(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 Type1かCAdES-X Long Type2と呼ばれます。
C.4.7. Time-Stamping for Mutual Recognition
C.4.7。 相互承認のための時間の刻印
In some business scenarios, both the signer and the verifier need to time-stamp their own copy of the signature value. Ideally, the two time-stamps should be as close as possible to each other.
いくつかのビジネスシナリオでは、署名者と検証の両方がそれら自身の署名価値のコピーをタイムスタンプに必要とします。 理想的に、2個のタイムスタンプができるだけ互いの近くにあるはずです。
EXAMPLE: A contract is signed by two parties, A and B,
representing their respective organizations; to time-stamp the
signer and verifier data, two approaches are possible:
例: 彼らのそれぞれの組織を代表して、契約は2パーティー、A、およびB時までに調印されます。 署名者と検証データを時スタンプで押すために、2つのアプローチが可能です:
- under the terms of the contract, a predefined common
"trusted" TSA may be used;
- 契約の条件により、事前に定義された一般的な「信じられた」TSAは使用されるかもしれません。
Pinkas, et al. Informational [Page 116] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[116ページ]情報のRFC5126cm
- 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回のパーティーの間の取引関係をサポートするのに使用されるかもしれない同意された署名方針の一部である相談ずくのSignature Validation Policyの一部であるかもしれません。
C.4.8. TSA Key Compromise
C.4.8。 TSAの主要な感染
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個のタイムスタンプを含んでいます。 異なったTime-押し込むAuthorityキーが追加タイムスタンプを作り出すためにかかわるとき、そのタイムスタンプを作り出すのに使用される個人的な署名キーの感染から守るために、アーカイブ合法化データを使用できます。 以前のタイムスタンプを提供する際に使用されるTSAキーが今までに感染されるかもしれない(例えば、有効期間に)と信じられているなら、CAdES-Aは使用されるべきです。 非常に長い期間、これは、繰り返して新しいTSAキーを使用することで適用されるかもしれません。
This technique is referred to as a nested CAdES-A in the present document.
このテクニックは現在のドキュメントに入れ子にされたCAdES-Aと呼ばれます。
Pinkas, et al. Informational [Page 117] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[117ページ]情報のRFC5126cm
C.5. Multiple Signatures
C.5。 複数の署名
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.
彼らが1つ以上の署名に堪える場合にだけ、いくつかの電子署名が有効であるかもしれません。 契約が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.
独立している署名は署名の注文が重要でないところの平行な署名です。 同じデータの上の1つ以上の独立している署名を持つ能力を提供するものとします。
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で説明されます。 すべての他の複数の署名体系、例えば、副署がある署名しているドキュメント、二重副署、または複数の署名を上の2つのケースの1回以上の発生まで減らすことができます。
Annex D (Informative): Data Protocols to Interoperate with TSPs
別館D(有益な): ティースプーンフルで共同利用するデータプロトコル
D.1. Operational Protocols
D.1。 操作上のプロトコル
The following protocols can be used by signers and verifiers to interoperate with Trusted Service Providers during the electronic signature creation and validation.
以下のプロトコルは署名者と検証によって使用されて、電子署名作成と合法化の間、Trusted Service Providersと共に共同利用できます。
D.1.1. Certificate Retrieval
D.1.1。 証明書検索
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].
倉庫からRFC3494[RFC3494]で定義されるようにライトウェイト・ディレクトリ・アクセス・プロトコルを使用することでユーザー証明書、カリフォルニア証明書、および交差している証明書を検索できます、図式がRFC4523[RFC4523]で定義されている状態で。
D.1.2. CRL Retrieval
D.1.2。 CRL検索
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].
倉庫からライトウェイト・ディレクトリ・アクセス・プロトコルを使用することで権威取消しリストと部分的なCRL異形を含む証明書失効リストは検索できます、RFC3494[RFC3494]で定義されるように、図式がRFC4523[RFC4523]で定義されている状態で。
Pinkas, et al. Informational [Page 118] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[118ページ]情報のRFC5126cm
D.1.3. Online Certificate Status
D.1.3。 オンライン証明書状態
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].
証明書失効リストの使用に代わる手段として、Online Certificate Statusプロトコル(OCSP)を使用することで証明書の状態をチェックできます、RFC2560[3]で定義されるように。
D.1.4. Time-Stamping
D.1.4。 時間の刻印
The time-stamping service can be accessed using the Time-Stamping Protocol defined in RFC 3161 [7].
RFC3161[7]で定義されたTime-押し込むプロトコルを使用することでタイムスタンピングサービスにアクセスできます。
D.2. Management Protocols
D.2。 管理プロトコル
Signers and verifiers can use the following management protocols to manage the use of certificates.
署名者と検証は、証明書の使用を管理するのに以下の管理プロトコルを使用できます。
D.2.1. Request for Certificate Revocation
D.2.1。 証明書には、取消しを要求してください。
Request for a certificate to be revoked can be made using the revocation request and response messages defined in RFC 4210 [RFC4210].
RFC4210[RFC4210]で定義された取消し要求と応答メッセージを使用することで証明書を取り消させることができるよう要求してください。
Annex E (Informative): Security Considerations
別館E(有益な): セキュリティ問題
E.1. Protection of Private Key
E.1。 秘密鍵の保護
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.
実装は、秘密鍵に感染することができないのを保証するために手を打つべきです。
E.2. Choice of Algorithms
E.2。 アルゴリズムの選択
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.
Implementersは時間に従って暗号アルゴリズムが、より弱くなるのを意識しているべきです。 新しい暗号解読のテクニックが開発されていて、性能を計算するのが向上するのに従って、特定の暗号アルゴリズムを破るワーク・ファクタは減少するでしょう。 したがって、新しいアルゴリズムが容易に挿入されるのを許容して、暗号アルゴリズム実装はモジュールであるべきです。 すなわち、implementersは、実装するために義務的なアルゴリズムのセットが時間がたつにつれて変化するように準備されているべきです。
Pinkas, et al. Informational [Page 119] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[119ページ]情報のRFC5126cm
Annex F (Informative): Example Structured Contents and MIME
別館F(有益な): 例はコンテンツとMIMEを構造化しました。
F.1. Use of MIME to Encode Data
F.1。 データを暗号化する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を使用することで構造化されるかもしれない、(マルチパーパスインターネットメールエクステンション--RFC2045[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.
複合内容をサポートするためにこの構造を広げることができます。
F.1.1. Header Information
F.1.1。 ヘッダー情報
A MIME header includes:
MIMEヘッダーは:
MIME Version information: e.g., MIME-Version: 1.0
MIMEバージョン情報: 例えば、MIMEバージョン: 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".
必要に応じてcontent type情報。(その情報は内容についてユーザにそれを提示できるくらい説明する情報かアプリケーション・プロセスを含んでいます)。 これは、「メディアタイプ」(例えば、テキスト、イメージ、オーディオ)の情報かそれともデータが特定のタイプの適用に通るものであるかを含んでいます。 テキストの場合では、content typeは文字集合で使用される情報、例えばコンテントタイプを含んでいます: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」
Content-encoding information, which defines how the content is encoded (see below about encoding supported by MIME).
満足している符号化情報。(その符号化情報は内容がどうコード化されるかを(以下でMIMEによってサポートされたコード化を取り計らってください)定義します)。
Pinkas, et al. Informational [Page 120] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[120ページ]情報のRFC5126cm
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
パントマイムバージョン: 1.0コンテントタイプ: テキスト/平野。 charset=ISO-8859-1の満足している転送コード化: 引用されて印刷可能です。
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"
コンテントタイプ: pdf Content転送アプリケーション/コード化: base64 Content-記述: JCFV201.pdfの満足している気質: ファイル名="JCFV201.pdf"
F.1.2. Content Encoding
F.1.2。 満足しているコード化
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コード化はインターネットで使用されます。
F.1.3. Multi-Part Content
F.1.3。 複合内容
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.
特別な「複合」のcontent typeを使用することで数個のオブジェクト(例えば、テキストとファイル付属)を一緒に、関連づけることができます。 これはストリングのしるしによる「複合」のcontent typeによって示されて、各部分の間の分離を示しながら、使用されます。
In addition to a header for the overall multipart content, each part includes its own header information indicating the inner content type and encoding.
総合的な複合内容のためのヘッダーに加えて、各部分は内側のcontent typeとコード化を示すそれ自身のヘッダー情報を含んでいます。
Pinkas, et al. Informational [Page 121] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[121ページ]情報のRFC5126cm
An example of a multipart content is:
複合内容に関する例は以下の通りです。
Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC4599.98004A80" Content-Transfer-Encoding: 7bit
パントマイムバージョン: 1.0コンテントタイプ: 複合か混ぜられる。 「境界=」---- =_NextPartの_の000_01BC4599.98004A80"の満足している転送コード化: 7ビット
------=_NextPart_000_01BC4599.98004A80 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
------=_NextPart_000_01BC4599.98004A80コンテントタイプ: テキスト/平野。 charset=ISO-8859-1の満足している転送コード化: 7ビット
Per your request, I've attached our proposal for the Java Card Version 2.0 API and the Java Card FAQ.
あなたの要求に従って、私はJavaCardバージョン2.0APIとJavaCard 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"
------=_NextPart_000_01BC4599.98004A80コンテントタイプ: アプリケーション/pdf。 ="JCFV201.pdf"満足している転送コード化を命名してください: base64 Content-記述: JCFV201.pdfの満足している気質: 付属。 ファイル名="JCFV201.pdf"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA////////////////////////////// //////////AANhAAQAYg==
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA////////////////////////////// //////////AANhAAQAYg==
------=_NextPart_000_01BC4599.98004A80--
------=_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).
複合内容を入れ子にすることができます。 それで、別のオブジェクト(例えば、テキスト)へのただ一つの付属として1セットの関連オブジェクト(例えば、HTMLテキストとイメージ)を扱うことができます。
The Content-Type from each part of the S/MIME message indicates the type of content.
S/MIMEメッセージの各部分からのコンテントタイプは内容のタイプを示します。
F.2. S/MIME
F.2。 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アプリケーション/パントマイム」オブジェクトは2進の付属として運ばれました(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に含まれるかもしれません。(SignedDataはただ一つのS/MIMEオブジェクトにそれ自体で含まれるかもしれません)。 [RFC3851]、セクション3.4.2を見てください: 「SignedDataと共にUsingがpkcs7アプリケーション/パントマイムであると署名します」と図F.1将来。
Pinkas, et al. Informational [Page 122] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[122ページ]情報のRFC5126cm
or
または
- a "multipart/signed" object with the signed data and the
signature encoded as separate MIME objects.
- 署名しているデータと署名がある「複合か署名している」オブジェクトは別々のMIMEとしてオブジェクトをコード化しました。
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を見てください: 「署名の複合のUsing/署名しているFormat」と図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 || / -----+ / ------+ |
| || \ -----+ \ ------+ |
| || \| || \| |+------------+
| || |+-------------+
| |+----------+
+-------------+
+-------------++----------++-------------++------------+ | || || || | | S/MIME|| ビャクシン属の木|| MIME|| pdfファイル| | || || || | |コンテントタイプ=||SignedData||コンテントタイプ=||MrSmith様| |アプリケーション/|| eContent||アプリケーション/||受信します。| |pkcs7-パントマイム|| ||pdf|| 100ブリキ缶| | || || || | |smimeタイプ=|| /| || /| || ジョーンズさん| |署名しているデータ|| / -----+ / ------+ | | || \ -----+ \ ------+ | | || \| || \| |+------------+ | || |+-------------+ | |+----------+ +-------------+
Figure F.1: Signing Using application/pkcs7-mime
F.1は計算します: Usingがpkcs7アプリケーション/パントマイムであると署名します。
F.2.1. Using application/pkcs7-mime
F.2.1。 pkcs7アプリケーション/パントマイムを使用します。
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
コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプは署名しているデータと等しいです。 満足している転送コード化: base64 Content-気質: 付属。 ファイル名=smime.p7m
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh6YT64V0GhIGfHfQbnj75
Pinkas, et al. Informational [Page 123] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[123ページ]情報のRFC5126cm
F.2.2. Using application/pkcs7-signature
F.2.2。 pkcs7アプリケーション/署名を使用します。
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を見てください: 「署名の複合のUsing/署名しているFormat」と図F.2将来。
An example of signed data encoded using this approach is:
このアプローチを使用することでコード化された署名しているデータに関する例は以下の通りです。
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
コンテントタイプ: 複合か署名される。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1。 境界=boundary42
--boundary42
Content-Type: text/plain
--boundary42コンテントタイプ: テキスト/平野
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
コンテントタイプ: pkcs7アプリケーション/署名。 =smime.p7s Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=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プロセスを通り抜けて、MIMEであると署名される複数の部分構造の一部として運ばれます、図F.2で例証されるように。 CMS構造はただ電子署名を保持します。
Pinkas, et al. Informational [Page 124] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[124ページ]情報のRFC5126cm
+---------------++----------++-------------++------------+ | || || || | | 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|| | | || | | /| || | | / -------+ | | \ -------+ | | \| ||----------+ | | +---------------+
+---------------++----------++-------------++------------+ | || || || | | MIME|| ビャクシン属の木|| MIME|| pdfファイル| | || || || | |コンテントタイプ=||SignedData||コンテントタイプ=||MrSmith様| |複合/|| ||アプリケーション/||受信します。| |署名されます。|| ||pdf|| 100ブリキ缶| | /| || || || | | / -------------------+ /| || ジョーンズさん| | \ -------------------+ / -----+ | | \| || || \ -----+ | |コンテントタイプ=|| || \| |+------------+ |アプリケーション/|| |+-------------+ |pdf|| | | || | |コンテントタイプ=|| | |アプリケーション/|| | |pkcs7-署名|| | | || | | /| || | | / -------+ | | \ -------+ | | \| ||----------+ | | +---------------+
Figure F.2: Signing Using application/pkcs7-signature
F.2は計算します: Usingがpkcs7アプリケーション/署名であると署名します。
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.
CMSによってコード化された電子署名を認識しないでも、アプローチ(複合の、または、署名している)が署名しているデータが持つことができる利点を持っているこの秒にあらゆるMIMEコンパチブルシステムによって解読されてください。
Annex G (Informative): Relationship to the European Directive and EESSI
別館G(有益な): ヨーロッパの指示とEESSIとの関係
G.1. Introduction
G.1。 序論
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.
この別館は電子署名の間の電子署名のためにCommunityフレームワークで欧州議会とCouncil Directiveの下で現在のドキュメントと要件で下作成された関係のしるしを供給します。
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.
現在のドキュメントはElectronic Signaturesにおける、ヨーロッパのDirectiveに伴う対応することの電子署名製品とソリューションのための「ヨーロッパの電子署名標準化イニシアチブ」(EESSI)で定義された1セットの規格の1つです。
Pinkas, et al. Informational [Page 125] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[125ページ]情報のRFC5126cm
G.2. Electronic Signatures and the Directive
G.2。 電子署名と指示
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";
- それは、Annex Iで与えられた詳細な評価基準を満たす指示の証明書に基づいていて、指示のAnnex 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".
- それは「デバイス」によって作成されます。(指示はAnnex IIIでそれに関して詳細な評価基準に与えられています)。 そのようなデバイスは「安全な署名作成デバイス」を参照されます。
This form of electronic signature is referred to as a "qualified electronic signature" in EESSI (see below).
この形式の電子署名はEESSIに「適切な電子署名」と呼ばれます(以下を見てください)。
Pinkas, et al. Informational [Page 126] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[126ページ]情報のRFC5126cm
G.3. ETSI Electronic Signature Formats and the Directive
G.3。 ETSIの電子署名形式と指示
An electronic signature created in accordance with the present document is:
現在のドキュメントによると、作成された電子署名は以下の通りです。
a) considered to be an "electronic signature" under the terms of
the Directive;
Directiveに関する諸条件における「電子署名」であると考えられたa)。
b) considered to be an "advanced electronic signature" under the
terms of the Directive;
b) Directiveに関する諸条件における「高度な電子署名」であると考えられます。
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.
Annex I、II、およびIII Directiveの追加必要条件が満たされるなら「適切な電子署名」であると考えられたc)。 Annex I、II、およびIII Directiveの要件は、現在のドキュメントの範囲の外にあって、ほかの場所での標準化を受けることがあります。
G.4. EESSI Standards and Classes of Electronic Signature
G.4。 電子署名のEESSI規格とクラス
G.4.1. Structure of EESSI Standardization
G.4.1。 EESSI標準化の構造
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ウェブサイトを見てください:
- use of X.509 public key certificates as qualified certificates;
- 限定事項付き証明としてのX.509公開鍵証明書の使用。
- security Management and Certificate Policy for CSPs Issuing
Qualified Certificates;
- CSPs Issuing Qualified CertificatesのためのセキュリティManagementとCertificate Policy。
- security requirements for trustworthy systems used by CSPs
Issuing Qualified Certificates;
- CSPs Issuing Qualified Certificatesによって使用された信頼できるシステムのためのセキュリティ要件。
- security requirements for Secure Signature Creation Devices;
- Secure Signature Creation Devicesのためのセキュリティ要件。
- security requirements for Signature Creation Systems;
- Signature Creation Systemsのためのセキュリティ要件。
- procedures for Electronic Signature Verification;
- Electronic Signature Verificationのための手順。
- electronic signature syntax and encoding formats;
- 電子署名構文とコード化形式。
- protocol to interoperate with a Time-Stamping Authority;
- Time-押し込むAuthorityと共に共同利用するには、議定書を作ってください。
- Policy requirements for Time-Stamping Authorities; and
- Time-押し込むAuthoritiesのための方針要件。 そして
- XML electronic signature formats.
- XMLの電子署名形式。
Pinkas, et al. Informational [Page 127] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[127ページ]情報のRFC5126cm
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.
それぞれのこれらの規格はさまざまな要件を扱います、Qualified Electronic Signaturesの要件を含んでいて、DirectiveのArticle5.1で指定されるように。 しかしながら、また、彼らの何人かがDirectiveのArticle5.2のカテゴリにすべてなるビジネスと電子商取引のための電子署名の一般的な要件を扱います。 要件のそのような変化は異なったレベルか異なったオプションとして特定されるかもしれません。
G.4.2. Classes of Electronic Signatures
G.4.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.
これらの規格のいくつかがさまざまな要件を扱うので、特定の企業が必要性であると扱うために1セットの規格を特定するのは役に立つかもしれません。 そのような1セットの規格と彼らの用途は電子署名のクラスを定義します。 既に特定された一流はDirectiveのArticle5.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.
- 限られた値がある企業取引のための電子署名。
G.4.3. Electronic Signature Classes and the ETSI Electronic Signature
Format
G.4.3。 電子署名のクラスとETSIの電子署名形式
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を見る)による属性の追加で、適切な電子署名は長期の正当性をサポートします。
Pinkas, et al. Informational [Page 128] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[128ページ]情報のRFC5126cm
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(アプリケーションProgramming Interfaces)が存在しているかどうかということです。 そのような少なくとも2つのAPIが定義されました。 1つはIETFでセットしました、そして、OMG(オブジェクトManagement Group)で別のものはセットしました。
H.1. Data Framing
H.1。 データ縁どり
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のどちらかを使用できるように、メカニズムから独立しているトークン形式を使用する以前に定義された電子署名データ構造を縁どるのが必要でしょう。 RFC2743[RFC2743]のセクション3.1はGSS-API文脈設立系列の初期のトークンの表現をカプセル化して、その文脈で使用されるためにメカニズムタイプに関する識別子を取り入れて、トークンが解釈されるのをunabmiguouslyに可能にするメカニズムから独立しているレベルを指定します。
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) 0×60--RFC2743のために、系列にタグ付けをしてください。 その組み立てられたフォーム、コード化が続く明確な長さを示します。
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未満であるなら、「0インチと値を表す残っているビット」に設定されたビット8(高位)でそれはただ一つの八重奏で表されるものとします。
Pinkas, et al. Informational [Page 129] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[129ページ]情報のRFC5126cm
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以上であるなら、それは2つ以上の八重奏で表されるものとします、「1インチと追加八重奏の数を指定する最初の八重奏の残っているビット」に設定された最初の八重奏のビット8で。 その後の八重奏は最初に、最も重要なケタで値を1八重奏あたり8ビット運びます。 八重奏の最小の数は、長さをコード化するのに使用されるものとします(長さのコード化の中にすなわち、先行ゼロを表す八重奏を全く含んでいないものとします)。
3) 0x06 -- Tag for OBJECT IDENTIFIER.
3) 0×06--オブジェクト識別子のために、タグ付けをします。
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) オブジェクト識別子の長さ--1 2a)と2bで説明される規則あたり要素5で含まれて、コード化されたコード化されたオブジェクト識別子の長さ(八重奏の数)) 上。
5) object identifier octets -- variable number of octets, encoded
per ASN.1 BER rules:
5)のオブジェクト識別子八重奏--ASN.1BER規則単位でコード化された可変数の八重奏:
- The first octet contains the sum of two values:
- 最初の八重奏は合計2つの値を含んでいます:
(1) the top-level object identifier component, multiplied by
40 (decimal); and
(1) 40(10進)が掛けられたトップレベルオブジェクト識別子の部品。 そして
(2) the second-level object identifier component.
(2) 第2レベルオブジェクト識別子の部品。
This special case is the only point within an object
identifier encoding where a single octet represents
contents of more than one component.
この特別なケースはただ一つの八重奏が1つ以上のコンポーネントのコンテンツを表すところでコード化されるオブジェクト識別子の中の唯一のポイントです。
- 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).
- 必要なら、その後の八重奏は表されたオブジェクト識別子の相次ぐ下側のコンポーネントをコード化します。 コンポーネントのコード化は複数の八重奏にかかるかもしれません、1八重奏あたり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.
メカニズムで定義されたトークンオブジェクトはすぐに、トークンタグを支えます。 オブジェクト識別子価値に続いて、どんな独立しているサイズ特許説明書の作成書も介入しないことに注意して、メカニズムで定義されたトークンオブジェクトのサイズを示してください。
Pinkas, et al. Informational [Page 130] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[130ページ]情報のRFC5126cm
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) }
イドetsi-es-IDUPメカニズムv1オブジェクト識別子:、:= itu t(0)の特定された組織(4)etsi(0)の電子署名規格(1733)part1(1)IDUPMechanism(4)etsiESv1(1)
H.2. IDUP-GSS-APIs Defined by the IETF
H.2。 IETFによって定義されたIDUP-GSS-API
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(独立しているData装置保護機構)という名でRFC(RFC2479[RFC2479])を生産しました。
The IDUP-GSS-API includes support for non-repudiation services.
IDUP-GSS-APIは非拒否サービスのサポートを含んでいます。
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.
.3セクション2.3IDUPが証拠(「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.
_使用されるトークン_詳細に与えられた入力トークンに対応する属性をアプリケーションに返させてください。 IDUP-GSS-APIトークンが呼ぶアプリケーションに不伝導性であることが意味されるので、この機能で、IDUPの不透明意志に違反する必要はなくて、アプリケーションはトークンの情報を決定できます。 プライマリ重要性はメカニズムタイプ(次に、アプリケーションはトークンを処理させる正しい環境を確立するためにIDUP_Establish_Env()呼び出しに入力されるように使用できる)です。
Generate_token generates a non-repudiation token using the current environment.
現在の環境を使用して、トークンが生成する_に非拒否トークンを生成してください。
Pinkas, et al. Informational [Page 131] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[131ページ]情報のRFC5126cm
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.
_証拠について確かめてください。現在の環境を使用することで証拠トークンについて確かめます。 この操作はトークンに含まれた証拠が完全であるかどうか(すなわち、首尾よく、(恐らく何年もの)後に確かめることができます)決定するのに使用できる主要な_ステータスコードを返します。 トークンの証拠が完全であることで、別のAPIにトークンを通過できるということでないなら、_完全な_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.
証拠トークン自体が検証に必要であるすべてのデータを含まないとき、_の完全な_フォームPIDUは主として使用されます、そして、それがトークンで保存されない場合トークンで保存されなかったいくつかのデータが世代の証拠トークンと検証の間隔の間入手できなくなるかもしれないと予期されます。 Form_Complete_PIDU操作は、検証が将来の何時でも可能になるように保証されているように、なくなった情報を集めて、トークンにそれを含んでいます。
H.3. CORBA Security Interfaces Defined by the OMG
H.3。 OMGによって定義されたCORBAセキュリティインタフェース
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.
非拒否インタフェースは「CORBAセキュリティ」、OMGによって製作されたドキュメント(オブジェクトManagement Group)で定義されました。 これらのインタフェースは、IDL(インタフェースDefinition Language)で説明されて、任意です。
The handling of "tokens" supporting non-repudiation is done through the following interfaces:
以下のインタフェースを通して非拒否をサポートする「トークン」の取り扱いをします:
- set_NR_features specifies the features to apply to future
evidence generation and verification operations;
- NR_が特集するセット_は将来の証拠世代と検証操作に適用する特徴を指定します。
- get_NR_features returns the features that will be applied to
future evidence generation and verification operations;
- 将来の証拠世代に適用される特徴を_NR_特徴リターンに得て、操作を検証に得てください。
- generate_token generates a non-repudiation token using the
current non-repudiation features;
- 現在の非拒否機能を使用することでトークンが生成する_に非拒否トークンを生成してください。
- verify_evidence verifies the evidence token using the current
non-repudiation features;
- _について確かめてください。証拠は現在の非拒否機能を使用することで証拠トークンについて確かめます。
- get_tokens_details returns information about an input
non-repudiation token. The information returned depends upon
the type of token;
- 入力非拒否トークンの情報を_トークン_詳細リターンに得てください。 返された情報をトークンのタイプに頼っています。
- 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
- 証拠トークン自体が検証に必要であるすべてのデータを含んでいなくて、トークンで保存されなかったいくつかのデータが世代の間隔の間入手できなくなるかもしれないと予期されると完全な_証拠が使用されているフォーム_
Pinkas, et al. Informational [Page 132] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[132ページ]情報のRFC5126cm
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.
それがトークンで保存されない場合、トークンと検証を証明してください。 フォーム_完全な_証拠操作は、検証が将来の何時でも可能になるように保証されているように、なくなった情報を集めて、トークンにそれを含んでいます。
NOTE: The similarity between the two sets of APIs is noticeable.
以下に注意してください。 2セットのAPIの間の類似性はめぼしいです。
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.
RFC3370[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.
RFC3370[10]の公表以来、MD5は壊れています。 このアルゴリズムは、もう適切であることは考えられないで、アルゴリズムのリストから削除されました。
I.1. Digest Algorithms
I.1。 ダイジェストアルゴリズム
I.1.1. SHA-1
I.1.1。 SHA-1
The SHA-1 digest algorithm is defined in FIPS Pub 180-1. The algorithm identifier for SHA-1 is:
SHA-1ダイジェストアルゴリズムはFIPS Pub180-1で定義されます。 SHA-1のためのアルゴリズム識別子は以下の通りです。
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14)
secsig(3) algorithm(2) 26 }
sha-1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)oiw(14) secsig(3)アルゴリズム(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.1NULLを含むものとします。 実装はNULLパラメタと同様に欠けているパラメタがあるSHA-1 AlgorithmIdentifiersを受け入れるべきです。 実装はNULLパラメタがあるSHA-1 AlgorithmIdentifiersを生成するべきです。
I.1.2. General
I.1.2。 一般
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/IEC10118-1(1994)[ISO10118-1]: 「情報技術--セキュリティのテクニック--ハッシュ関数--第1部:、」 「一般です」。 ISO/IEC10118-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/IEC10118-2(1994)[ISO10118-2]: 「情報技術--セキュリティのテクニック--ハッシュ関数--第2部:、」 「n-ビットを使用するハッシュ関数が暗号アルゴリズムを妨げます。」 ISO/IEC10118-2はブロック暗号からハッシュ関数を構成する2つの方法を指定します。
Pinkas, et al. Informational [Page 133] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[133ページ]情報のRFC5126cm
- 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/IEC10118-3(1997)[ISO10118-3]: 「情報技術--セキュリティのテクニック--ハッシュ関数--3を分けてください」 「ひたむきなハッシュ関数。」 ISO/IEC10118-3は以下のひたむきなハッシュ関数を指定します:
- SHA-1 (FIPS 180-1);
- RIPEMD-128;
- RIPEMD-160.
- SHA-1(FIPS180-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/IEC10118-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.
- RFC1320(PS1992): 「MD4メッセージダイジェストアルゴリズム。」 RFC1320はハッシュ関数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.
- RFC1321(I1992): 「MD5メッセージダイジェストアルゴリズム。」 RFC1321(情報の)はハッシュ関数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公表180-1(1995): 「ハッシュ規格を保証してください。」 FIPS180-1はSecure Hash Algorithm(SHA)、DSAとの使用のために開発されたひたむきなハッシュ機能を指定します。 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-バージョンを指定します。
- 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はハッシュアルゴリズムを指定します。
I.2. Digital Signature Algorithms
I.2。 デジタル署名アルゴリズム
I.2.1. DSA
I.2.1。 DSA
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 Pub186で定義されます。 DSAはSHA-1メッセージダイジェストアルゴリズムでいつも使用されます。 DSAのためのアルゴリズム識別子は以下の通りです。
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57 (10040) x9cm(4) 3 }
sha1 OBJECT IDENTIFIERとイドdsa:、:= iso(1)は(2) 私たち(840)x9-57(10040)x9cm(4)3をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameters field shall not be present.
AlgorithmIdentifierパラメタ分野は存在しないでしょう。
Pinkas, et al. Informational [Page 134] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[134ページ]情報のRFC5126cm
I.2.2. RSA
I.2.2。 RSA
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署名アルゴリズムはRFC3447[RFC3447]で定義されます。 RFC3370[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 }
Sha1WithRSAEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)5をメンバーと同じくらい具体化させます。
NOTE: RFC 3370 [10] recommends that MD5 not be used for new
implementations.
以下に注意してください。 RFC3370[10]は、MD5が新しい実装に使用されないことを勧めます。
I.2.3. General
I.2.3。 一般
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公表186(1994): 「デジタル署名基準。」 NISTのDigital Signature Algorithm(DSA)はElGamalのDiscrete Logarithmベースのデジタル署名メカニズムの異形です。 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;
- 「従来」のDiscrete Logarithm(DL)ベースのテクニック、すなわち、ディフィーヘルマン(DH)の主要な協定、メネゼス-Qu-Vanstone(MQV)の主要な協定、Digital Signature Algorithm(DSA)、およびニーベルグ-Rueppel(NR)デジタル署名。
- 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-メカニズムの楕円形のCurve(EC)ベースの異形、すなわち、EC-DH、EC-MQV、EC-DSA、およびEC-NR。 楕円曲線のために、実装オプションは多項式があるモッズpと独特の2か通常の基底表現を含んでいます。
- Integer Factoring (IF)-based techniques, including RSA
encryption, RSA digital signatures, and RSA-based key transport.
- RSA暗号化、RSAデジタル署名、およびRSAベースの主要な輸送を含む整数のFactoring (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/IEC9796-2(1997)[ISO9796-2]: 「情報技術--セキュリティのテクニック--デジタル署名は回復--第2部をメッセージに与えながら、計画されます」 「ハッシュ関数を使用するメカニズム。」 ISO/IEC9796-2は部分的なメッセージ回復に伴うまた、RSAのテクニックに基づいていますが、ハッシュ関数を利用するデジタル署名メカニズムを指定します。
Pinkas, et al. Informational [Page 135] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[135ページ]情報のRFC5126cm
- 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/IEC9796-4(1998)[ISO9796-4]: 「デジタル署名はメッセージ回復を与えながら、計画されます--4を分けてください」 「離散対数はメカニズムを基礎づけました。」 ISO/IEC9796-4は部分的なメッセージ回復に伴うDiscrete Logarithmのテクニックに基づいているデジタル署名メカニズムを指定します。 ドキュメントはニーベルグ-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/IEC14888-1[ISO14888-1]: 「付録--第1部とのデジタル署名:、」 「一般です」。 ISO/IEC14888-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/IEC14888-2[ISO14888-2]: 「付録--第2部とのデジタル署名:、」 「アイデンティティベースのメカニズム。」 ISO/IEC14888-2は付録があるアイデンティティベースの合わせることの使用を物質的にするデジタル署名計画を指定します。 ドキュメントはFiat-シャミルとギユー-Quisquaterの無知識のテクニックを含んでいます。
- 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/IEC14888-3[ISO14888-3]: 「付録によるデジタル署名--3を分けてください」 「証明書ベースのメカニズム。」 ISO/IEC14888-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のDigital Signature Algorithmの楕円曲線ベースのアナログ。 - Pointcheval-Vaudeney署名。 - 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/IEC15946-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のDigital Signature Algorithmの楕円曲線ベースのアナログ。
- EC-AMV, an elliptic curve-based analog of the Agnew-Muller-
Vanstone signature algorithm.
- EC-AMV、アグニュー-ミュラーVanstoneの楕円曲線ベースのアナログ、署名アルゴリズム。
Pinkas, et al. Informational [Page 136] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[136ページ]情報のRFC5126cm
- 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はDSA、NISTのDigital Signature Algorithmを指定します。
- 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はElliptic Curve Digital Signature Algorithm、楕円曲線を使用するNISTのDigital Signature Algorithm(DSA)のアナログを指定します。 付録は、基本的な数学の家庭教師の情報を楕円曲線暗号に提供して、多くの例を出します。
Annex J (Informative): Guidance on Naming
別館J(有益な): 命名の指導
J.1. Allocation of Names
J.1。 名前の配分
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.
ユニークさを確実にするためにRegistration 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");
- 名前はレジスト情報に基づいています、資格を与える人の追加がユニークさを確実にするために登録局によって加えられている状態で(例えば、「ピアー・ジュランド、12インチ)、」、。
- the registration information is kept private by the registration
authority and the registration authority allocates a
"pseudonym".
- レジスト情報は登録局によって個人的に保たれます、そして、登録局は「匿名」を割り当てます。
Pinkas, et al. Informational [Page 137] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[137ページ]情報のRFC5126cm
J.2. Providing Access to Registration Information
J.2。 レジスト情報へのアクセスを提供します。
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のための地域にかかわる事柄です。 しかしながら、開架が必要であるなら、セキュリティー対策の添加がクライアント認証でデータ保護必要条件(例えば、Transport Layer Security--RFC4346[RFC4346])を満たすのに必要な状態でRFC2068年などのHTTP--標準プロトコル(インターネットウェブAccessプロトコル)は使われるかもしれません。
J.3. Naming Schemes
J.3。 計画を命名します。
J.3.1. Naming Schemes for Individual Citizens
J.3.1。 個々の国民の計画を命名します。
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.
どのような場合でも、Registration Authorityはすべてではなく、登録時点の情報が証明書に置かれるという情報を得るでしょう。 要件の反対側でこれらの2の間のバランスを獲得するために、いくつかの追加属性のハッシュ値を公開鍵証明書に置くことができます。 証明書所有者がこれらの追加属性を提供すると、それらについて確かめることができます。 生体認証属性を使用すると、人は明白に特定されるかもしれません。 使用できる生体認証属性に関する例は: 証明書所有者からの絵か手書きの署名。
Pinkas, et al. Informational [Page 138] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[138ページ]情報のRFC5126cm
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.
あらかじめサインされたドキュメントを受け取ったなら、手書きの署名を使用するかもしれません。 このような場合には、第一交換のときに手書きの署名の図面を送ります、そして、検証で証明書に含まれた細切れ肉料理を使用して、それが正しい手書きの署名であることを確かめるかもしれません。 次の交換のときに、再び手書きの署名によって送られる必要はありません。
J.3.2. Naming Schemes for Employees of an Organization
J.3.2。 組織の従業員の計画を命名します。
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.
組織名は通常登録名、すなわち、その日その日のビジネスの中古であるビジネスか取り引き名です。 この名前は、Naming Authorityによって登録されて、別の組織に混乱できません。(Naming Authorityは組織の登録名が明白であることを保証します)。
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.
与えられた登録された組織名に関する詳しい情報を得るために、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
例えば、人の組織部隊かオフィスが位置している都市の名前を与えることによって、より多くの属性を証明書に置くのは、1つの解決策であるかもしれません。 しかしながら、情報は、より多いです。
Pinkas, et al. Informational [Page 139] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[139ページ]情報のRFC5126cm
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.
証明書に置かれて、変化が組織構造か職場にあれば、より多くの問題が起こります。 それで、これは最も良い解決策でないかもしれません。 代替手段は会社によって維持されたディレクトリへのアクセスで、より多くの属性(組織部隊と職場のような)を提供することです。 Registration Authorityは登録時点で、そのような追加情報が組織だけにアクセスしやすい倉庫に置かれるなら何が証明書に置かれたかより多くの情報を得そうでした。
Acknowledgments
承認
Special thanks to Russ Housley for reviewing the document.
ドキュメントを再検討するためのラスHousleyのおかげで、特別です。
Authors' Addresses
作者のアドレス
Denis Pinkas Bull SAS Rue Jean-Jaures 78340 Les Clayes sous Bois CEDEX FRANCE EMail: Denis.Pinkas@bull.net
デニスピンカスBull SAS Rueジーン-ジョーレス78340レスClayes小銭Bois CEDEXフランスEMail: 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
長いCrendonエールズベリー雄ジカHP18 9EQイギリスのメールに法王Thales eSecurity草地視点家に傷を付けてください: 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
ジョンロスSecurityと規格コンサルタント業のLtdウォーターハウスビジネスはチェルムズフォードエセックスCM1 2QEイギリスのメールを2クローマーWayに集中させます: ross@secstan.com
Pinkas, et al. Informational [Page 140] RFC 5126 CMS Advanced Electronic Signatures February 2008
ピンカス、他 電子署名2008年2月に高度な[140ページ]情報のRFC5126cm
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Pinkas, et al. Informational [Page 141]
ピンカス、他 情報[141ページ]
一覧
スポンサーリンク
