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