Network Working Group T. Gondrom
Request for Comments: 4998 Open Text Corporation
Category: Standards Track R. Brandner
InterComponentWare AG
U. Pordesch
Fraunhofer Gesellschaft
August 2007
Evidence Record Syntax (ERS)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data.
多くのシナリオでは、ユーザーは、時間の長い、おそらく未定期間にわたって共通で再現可能な方法で、デジタル署名されたデータを含め、データの存在と整合性を証明できなければなりません。この文書では、証拠の記録、データの存在の長期的な否認防止をサポートするように設計された構造の構文と処理を指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. General Overview and Requirements . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Conventions Used in This Document . . . . . . . . . . . . 6
2. Identification and References . . . . . . . . . . . . . . . . 7
2.1. ASN.1 Module Definition . . . . . . . . . . . . . . . . . 7
2.1.1. ASN.1 Module Definition for 1988 ASN.1 Syntax . . . . 7
2.1.2. ASN.1 Module Definition for 1997-ASN.1 Syntax . . . . 7
2.2. ASN.1 Imports and Exports . . . . . . . . . . . . . . . . 7
2.2.1. Imports and Exports Conform with 1988 ASN.1 . . . . . 8
2.2.2. Imports and Exports Conform with 1997-ASN.1 . . . . . 8
2.3. LTANS Identification . . . . . . . . . . . . . . . . . . . 9
3. Evidence Record . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 11
4. Archive Timestamp . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 15
5. Archive Timestamp Chain and Archive Timestamp Sequence . . . . 16
5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 19
6. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1. EncryptionInfo in 1988 ASN.1 . . . . . . . . . . . . . 21
6.1.2. EncryptionInfo in 1997-ASN.1 . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Evidence Record Using CMS . . . . . . . . . . . . . . 26
Appendix B. ASN.1-Module with 1988 Syntax . . . . . . . . . . . . 27
Appendix C. ASN.1-Module with 1997 Syntax . . . . . . . . . . . . 29
In many application areas of electronic data exchange, a non-repudiable proof of the existence of digital data must be possible. In some cases, this proof must survive the passage of long periods of time. An important example is digitally signed data. Digital signatures can be used to demonstrate data integrity and to perform source authentication. In some cases, digitally signed data must be archived for 30 years or more. However, the reliability of digital signatures over long periods is not absolute. During the archival period, hash algorithms and public key algorithms can become weak or certificates can become invalid. These events complicate the reliance on digitally signed data after many years by increasing the likelihood that forgeries can be created. To avoid losing the desired security properties derived from digital signatures, it is necessary to prove that the digitally signed data already existed before such a critical event. This can be accomplished using a timestamp. However, some timestamps rely upon mechanisms that will be subject to the same problems. To counter this problem, timestamps are renewed by simply obtaining a new timestamp that covers the original data and its timestamps prior to the compromise of mechanisms used to generate the timestamps. This document provides a syntax to support the periodic renewal of timestamps.
電子データ交換の多くの応用分野では、デジタルデータの存在の非repudiable証明が可能でなければなりません。いくつかのケースでは、この証明は、時間の長い期間の経過後も存続しなければなりません。重要な例は、デジタルデータに署名しています。デジタル署名は、データの整合性を証明するために、ソースの認証を実行するために使用することができます。いくつかのケースでは、デジタル署名されたデータは、30年以上保管しなければなりません。しかし、長期間にわたってデジタル署名の信頼性は絶対的ではありません。アーカイブ期間中は、ハッシュアルゴリズムや公開鍵アルゴリズムが弱くなることができますか証明書が無効になることができます。これらのイベントは、偽造を作成することができる可能性を高めることにより、多くの年後に、デジタル署名されたデータへの依存を複雑にします。デジタル署名由来必要なセキュリティの特性を失わないようにするには、デジタル署名されたデータがすでに、このような重要なイベントの前に存在していたことを証明する必要があります。これは、タイムスタンプを用いて達成することができます。しかし、いくつかのタイムスタンプは、同じ問題の対象となるメカニズムに依存しています。この問題に対処するために、タイムスタンプは、単にタイムスタンプを生成するために使用される機構の妥協する前に、元のデータとタイムスタンプをカバーする新しいタイムスタンプを取得することによって更新されます。この文書では、タイムスタンプの定期的な更新をサポートするための構文を提供します。
It is necessary to standardize the data formats and processing procedures for such timestamps in order to be able to verify and communicate preservation evidence. A first approach was made by IETF within [RFC3126], where an optional Archive Timestamp Attribute was specified for integration in signatures according to the Cryptographic Messages Syntax (CMS) [RFC3852].
保存証拠を検証し、通信できるようにするために、このようなタイムスタンプのためのデータフォーマット及び処理手順を標準化する必要があります。第一のアプローチは、オプションのアーカイブタイムスタンプ属性が暗号メッセージ構文（CMS）[RFC3852]に従ってシグネチャに統合のために指定された[RFC3126]、内IETFによって作られました。
Evidence Record Syntax (ERS) broadens and generalizes this approach for data of any format and takes long-term archive service requirements [RFC4810] into account -- in particular, the handling of large sets of data objects. ERS specifies a syntax for an EvidenceRecord, which contains a set of Archive Timestamps and some additional data. This Evidence Record can be stored separately from the archived data, as a file, or integrated into the archived data, i.e., as an attribute. ERS also specifies processes for generation and verification of Evidence Records. Appendix A describes the integration and use of an EvidenceRecord in context of signed and enveloped messages according to the Cryptographic Message Syntax (CMS). ERS does not specify a protocol for interacting with a long-term archive system. The Long-term Archive Protocol specification being developed by the IETF LTANS WG addresses this interface.
証拠レコード構文（ERS）が広がり、任意の形式のデータのためにこのアプローチを一般化し、アカウントに長期アーカイブサービス要件[RFC4810]をとり - 特に、データオブジェクトの大きなセットの取り扱い。 ERSは、アーカイブタイムスタンプといくつかの追加データのセットが含まれているEvidenceRecord、の構文を指定します。この証拠レコードは、属性として、すなわち、ファイルのように、アーカイブされたデータとは別に格納され、またはアーカイブされたデータに統合することができます。 ERSはまた、証拠レコードの生成と検証のためのプロセスを指定します。付録Aは、暗号メッセージ構文（CMS）に係る署名され、エンベロープメッセージの文脈におけるEvidenceRecordの統合および使用を記載しています。 ERSは、長期的なアーカイブシステムと対話するためのプロトコルを指定しません。 IETF LTANS WGによって開発された長期アーカイブプロトコル仕様では、このインターフェースに対応しています。
ERS is designed to meet the requirements for data structures set forth in [RFC4810].
ERSは、[RFC4810]に記載されたデータ構造の要件を満たすように設計されています。
The basis of the ERS are Archive Timestamps, which can cover a single data object (as an RFC3161 compliant timestamp does) or can cover a group of data objects. Groups of data objects are addressed using hash trees, first described by Merkle [MER1980], combined with a timestamp. The leaves of the hash tree are hash values of the data objects in a group. A timestamp is requested only for the root hash of the hash tree. The deletion of a data object in the tree does not influence the provability of others. For any particular data object, the hash tree can be reduced to a few sets of hash values, which are sufficient to prove the existence of a single data object. Similarly, the hash tree can be reduced to prove existence of a data group, provided all members of the data group have the same parent node in the hash tree. Archive Timestamps are comprised of an optional reduced hash tree and a timestamp.
ERSの基礎は単一のデータオブジェクト（RFC3161準拠のタイムスタンプが行うように）覆うことができる、またはデータオブジェクトのグループをカバーすることができるアーカイブタイムスタンプです。データオブジェクトのグループは、タイムスタンプと組み合わせた第一マークル[MER1980]によって記載されたハッシュ木を用いてアドレス指定されます。ハッシュツリーの葉は、グループ内のデータオブジェクトのハッシュ値です。タイムスタンプは、唯一のハッシュツリーのルートハッシュのために要求されています。ツリー内のデータオブジェクトの削除は、他人の証明可能性に影響を与えません。任意の特定のデータオブジェクトに対して、ハッシュ木は、単一のデータ・オブジェクトの存在を証明するのに十分であるハッシュ値、数セットに低減することができます。同様に、ハッシュ木は、データグループのすべてのメンバーは、ハッシュツリーの同じ親ノードを有して設けられ、データ群の存在を証明するために低減することができます。アーカイブタイムスタンプは、オプションの減少ハッシュ木とタイムスタンプで構成されています。
An EvidenceRecord may contain many Archive Timestamps. For the generation of the initial Archive Timestamp, the data objects to be timestamped have to be determined. Depending on the context, this could be a file or a data object group consisting of multiple files, such as a document and its associated digital signature.
EvidenceRecordは多くのアーカイブタイムスタンプが含まれていてもよいです。初期のアーカイブ・タイムスタンプを生成するため、タイムスタンプされるデータオブジェクトを決定しなければなりません。文脈に応じて、これは、ファイル又は文書及びその関連デジタル署名などの複数のファイルからなるデータオブジェクトグループとすることができます。
Before the cryptographic algorithms used within the Archive Timestamp become weak or timestamp certificates become invalid, Archive Timestamps have to be renewed by generating a new Archive Timestamp. (Note: Information about the weakening of the security properties of public key and hash algorithms, as well as the risk of compromise of private keys of Time Stamping Units, has to be closely watched by the Long-Term Archive provider or the owner of the data objects himself. This information should be gathered by "out-of-band" means and is out of scope of this document.) ERS distinguishes two ways for renewal of an Archive Timestamp: Timestamp Renewal and Hash-Tree Renewal.
アーカイブ・タイムスタンプ内で使用される暗号化アルゴリズムが弱いまたはタイムスタンプ証明書が無効になるになる前に、アーカイブタイムスタンプが新しいアーカイブタイムスタンプを生成することによって、更新する必要があります。 （注意：公開鍵とハッシュアルゴリズムのセキュリティプロパティの弱体化だけでなく、タイムスタンプ単位の秘密鍵の妥協のリスクについての情報は、密接に長期アーカイブプロバイダまたはの所有者が注目する必要があります。データは自分自身をオブジェクトこの情報は、「アウトオブバンド」の手段によって収集し、この文書の範囲外であるべきである）ERSは、アーカイブタイムスタンプの更新のための二つの方法区別：タイムスタンプリニューアルとハッシュ木リニューアルを。
Depending on the conditions, the respective type of renewal is required: The timestamp renewal is necessary if the private key of a Timestamping Unit has been compromised, or if an asymmetric algorithm or a hash algorithm used for the generation of the timestamps is no longer secure for the given key size. If the hash algorithm used to build the hash trees in the Archive Timestamp loses its security properties, the Hash-Tree Renewal is required.
条件によっては、更新のそれぞれのタイプが必要です：タイムスタンプユニットの秘密鍵が危殆化した場合、または非対称アルゴリズムやタイムスタンプの生成に使用されるハッシュアルゴリズムはもはや安全でない場合は、タイムスタンプの更新が必要です指定されたキーのサイズについて。アーカイブタイムスタンプにハッシュツリーを構築するために使用されるハッシュアルゴリズムは、そのセキュリティプロパティを失った場合、ハッシュ木リニューアルが必要です。
In the case of Timestamp Renewal, the timestamp of an Archive Timestamp has to be hashed and timestamped by a new Archive Timestamp. This mode of renewal can only be used when it is not necessary to access the archived data objects covered by the timestamp. For example, this simple form of renewal is sufficient if the public key algorithm of the timestamp is going to lose its security or the timestamp authority certificate is about to expire. This is very efficient, in particular, if Archive Timestamping is done by an archiving system or service, which implements a central management of Archive Timestamps.
タイムスタンプ更新の場合は、アーカイブタイムスタンプのタイムスタンプが新しいアーカイブタイムスタンプでハッシュされ、タイムスタンプする必要があります。タイムスタンプでカバーアーカイブされたデータオブジェクトにアクセスする必要がない場合、更新のこのモードでのみ使用することができます。タイムスタンプの公開鍵アルゴリズムは、そのセキュリティを失うことになるだろうか、タイムスタンプ局の証明書が期限切れになる場合たとえば、更新のこの単純な形で十分です。アーカイブタイムスタンプは、アーカイブタイムスタンプの集中管理を実現するアーカイブシステムまたはサービスによって行われる場合、これは、特に、非常に効率的です。
Timestamp renewal is not sufficient if the hash algorithm used to build the hash tree of an Archive Timestamp becomes insecure. In the case of Hash-Tree Renewal, all evidence data must be accessed and timestamped. This includes not only the timestamps but also the complete Archive Timestamps and the archived data objects covered by the timestamps, which must be hashed and timestamped again by a new Archive Timestamp.
アーカイブタイムスタンプのハッシュツリーを構築するために使用されるハッシュアルゴリズムが安全でないとなった場合、タイムスタンプの更新は十分ではありません。ハッシュ木リニューアルの場合は、すべての証拠データにアクセスし、タイムスタンプされなければなりません。また、これは、タイムスタンプが、完全なアーカイブタイムスタンプと新しいアーカイブタイムスタンプによって再びハッシュされ、タイムスタンプされなければならないタイムスタンプで覆われてアーカイブされたデータオブジェクトだけでなく、。
Archived data object: A data unit that is archived and has to be preserved for a long time by the Long-term Archive Service.
アーカイブされたデータオブジェクト：アーカイブおよび長期アーカイブサービスで長期保存する必要がありますされたデータユニット。
Archived data object group: A set of two or more of data objects, which for some reason belong together. For example, a document file and a signature file could be an archived data object group, which represent signed data.
アーカイブされたデータオブジェクトグループ：いくつかの理由のために一緒に属する2つの以上のデータオブジェクトのセット。例えば、文書ファイルと署名ファイルは、データに署名した表すアーカイブされたデータオブジェクトグループ、とすることができます。
Archive Timestamp: A timestamp and typically lists of hash values, which allow the verification of the existence of several data objects at a certain time. (In its most simple variant, when it covers only one object, it may only consist of the timestamp.)
アーカイブタイムスタンプ：特定の時間にいくつかのデータオブジェクトの存在の検証を許可し、タイムスタンプと、通常のハッシュ値のリスト、。 （その最も単純な変形例では、それは1つのオブジェクトのみをカバーする場合、それが唯一のタイムスタンプから構成されてもよいです。）
Archive Timestamp Chain: Part of an Archive Timestamp Sequence, it is a time-ordered sequence of Archive Timestamps, where each Archive Timestamp preserves non-repudiation of the previous Archive Timestamp, even after the previous Archive Timestamp becomes invalid. Overall non-repudiation is maintained until the new Archive Timestamp itself becomes invalid. The process of generating such an Archive Timestamp Chain is called Timestamp Renewal.
アーカイブ・タイムスタンプチェーン：アーカイブタイムスタンプ配列の部分は、それがそれぞれのアーカイブ・タイムスタンプは、前のアーカイブ・タイムスタンプが無効になった後も、以前のアーカイブタイムスタンプの否認防止を維持するアーカイブタイムスタンプの時間順のシーケンスです。新しいアーカイブタイムスタンプ自体が無効になるまで全体的に否認防止が維持されています。そのようなアーカイブタイムスタンプチェーンを生成するプロセスは、タイムスタンプリニューアルと呼ばれています。
Archive Timestamp Sequence: Part of the Evidence Record, it is a sequence of Archive Timestamp Chains, where each Archive Timestamp Chain preserves non-repudiation of the previous Archive Timestamp Chains, even after the hash algorithm used within the previous Archive Timestamp's hash tree became weak. Non-repudiation is preserved until the last Archive Timestamp of the last chain becomes invalid. The process of generating such an Archive Timestamp Sequence is called Hash-Tree Renewal.
アーカイブ・タイムスタンプシーケンス：証拠記録の一部は、以前のアーカイブタイムスタンプのハッシュツリー内で使用されるハッシュアルゴリズムが弱くなった後も、各アーカイブ・タイムスタンプチェーンは、前のアーカイブ・タイムスタンプチェーンの否認防止を維持する場合は、アーカイブ・タイムスタンプチェーンのシーケンスであります。最後のチェーンの最後のアーカイブ・タイムスタンプが無効になるまで、否認防止が保存されています。そのようなアーカイブタイムスタンプのシーケンスを生成するプロセスは、ハッシュ木リニューアルと呼ばれています。
Evidence: Information that may be used to resolve a dispute about various aspects of authenticity of archived data objects.
証拠：アーカイブされたデータオブジェクトの真正性のさまざまな側面についての紛争を解決するために使用することができる情報。
Evidence record: Collection of evidence compiled for one or more given archived data objects over time. An evidence record includes all Archive Timestamps (within structures of Archive Timestamp Chains and Archive Timestamp Sequences) and additional verification data, like certificates, revocation information, trust anchors, policy details, role information, etc.
証拠レコード：証拠の収集が1用にコンパイルされた以上の時間をかけて、アーカイブデータオブジェクトを与えられました。証拠の記録は、証明書、失効情報、トラストアンカー、ポリシーの詳細、役割情報などのような、追加の検証データ、（アーカイブタイムスタンプチェーンおよびアーカイブタイムスタンプ配列の構造内）のすべてのアーカイブタイムスタンプを含んでいます
Long-term Archive (LTA) Service: A service responsible for preserving data for long periods of time, including generation and collection of evidence, storage of archived data objects and evidence, etc.
長期アーカイブ（LTA）サービス：アーカイブされたデータオブジェクトや証拠などの発生や証拠の収集、保存などの長時間のためにデータを保存する責任サービス
Reduced hash tree: The process of reducing a Merkle hash tree [MER1980] to a list of lists of hash values. This is the basis of storing the evidence for a single data object.
減少ハッシュツリー：ハッシュ値のリストのリストに[MER1980]マークルハッシュ木を削減するプロセス。これは、単一のデータ・オブジェクトのための証拠を格納する基礎です。
Timestamp: A cryptographically secure confirmation generated by a Time Stamping Authority (TSA). [RFC3161] specifies a structure for timestamps and a protocol for communicating with a TSA. Besides this, other data structures and protocols may also be appropriate, e.g., such as defined in [ISO-18014-1.2002], [ISO-18014-2.2002], [ISO-18014-3.2004], and [ANSI.X9-95.2005].
タイムスタンプ：タイムスタンプ局（TSA）によって生成された暗号化された安全な確認。 [RFC3161]は、タイムスタンプとTSAと通信するためのプロトコルの構造を指定します。この他にも、他のデータ構造及びプロトコルはまた、[ISO-18014から1.2002]、[ISO-18014から2.2002]、[ISO-18014から3.2004]、および[ANSI.X9-95.2005で定義されたような、例えば、適切であるかもしれません]。
An Archive Timestamp relates to a data object, if the hash value of this data object is part of the first hash value list of the Archive Timestamp. An Archive Timestamp relates to a data object group, if it relates to every data object of the group and no other data objects. An Archive Timestamp Chain relates to a data object / data object group, if its first Archive Timestamp relates to this data object/data object group. An Archive Timestamp Sequence relates to a data object / data object group, if its first Archive Timestamp Chain relates to this data object/data object group.
このデータ・オブジェクトのハッシュ値がアーカイブ・タイムスタンプの第1のハッシュ値のリストの一部である場合、アーカイブ・タイムスタンプは、データ・オブジェクトに関する。それはグループのすべてのデータオブジェクトと他のデータオブジェクトに関連する場合アーカイブ・タイムスタンプは、データオブジェクトグループに関する。その最初のアーカイブ・タイムスタンプは、このデータオブジェクト/データ・オブジェクト・グループに関連する場合のアーカイブタイムスタンプ鎖は、データオブジェクト/データ・オブジェクト・グループに関する。その最初のアーカイブ・タイムスタンプチェーンは、このデータオブジェクト/データ・オブジェクト・グループに関連する場合アーカイブ・タイムスタンプ・シーケンスは、データオブジェクト/データ・オブジェクト・グループに関する。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
As many open ASN.1 compilers still support the 1988 syntax, this standard offers to support two versions of ASN.1 1997-ASN.1 and 1988- ASN.1. (For specification of ASN.1 refer to [CCITT.X208.1988], [CCITT.X209.1988], [CCITT.X680.2002] and [CCITT.X690.2002].) This specification defines the two ASN.1 modules, one for 1988 conform ASN.1 and another in 1997-ASN.1 syntax. Depending on the syntax version of your compiler implementation, you can use the imports for the 1988 conformant ASN.1 syntax or the imports for the 1997-ASN.1 syntax. The appendix of this document lists the two complete alternative ASN.1 modules. If there is a conflict between both modules, the 1988-ASN.1 module precedes.
多くのオープンASN.1コンパイラは、まだ1988構文をサポートするように、この標準はASN.1 1997-ASN.1および1988- ASN.1の2つのバージョンをサポートするために提供しています。 （ASN.1の仕様については[CCITT.X690.2002] [CCITT.X208.1988]を参照し、[CCITT.X209.1988]、[CCITT.X680.2002]と。）この仕様は、2つのASN.1を定義モジュールは、1988年のための1つは、1997-ASN.1構文のASN.1と他に準拠しています。あなたのコンパイラの実装の構文のバージョンに応じて、1997年、ASN.1構文の1988準拠のASN.1構文を輸入または輸入を使用することができます。このドキュメントの付録には、2つの完全な代替ASN.1モジュールを示しています。両方のモジュールの間に矛盾がある場合は、1988-ASN.1モジュールが先行します。
1988 ASN.1 Module start
1988 ASN.1モジュールの開始
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers88(2) id-mod-ers88-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ASN.1 Module start
ASN.1モジュールの開始
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers(1) id-mod-ers-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
The specification exports all definitions and imports various definitions. Depending on the ASN.1 syntax version of your implementation, you can use the imports for the 1988 conform ASN.1 syntax below or the imports for the 1997-ASN.1 syntax in Section 2.2.2.
仕様は、すべての定義と輸入様々な定義をエクスポートします。実装のASN.1構文のバージョンによっては、ASN.1の下の構文または2.2.2 1997-ASN.1構文の輸入に準拠1988年のための輸入を使用することができます。
-- EXPORTS ALL --
- すべてのエクスポート -
IMPORTS
輸入
-- Imports from RFC 3852 Cryptographic Message Syntax ContentInfo, Attribute FROM CryptographicMessageSyntax2004 -- FROM [RFC3852] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
- RFC 3852からの輸入暗号メッセージ構文ContentInfo、CryptographicMessageSyntax2004から属性 - [RFC3852] {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME FROM （16）モジュール（0）CMS-2004（24）}
-- Imports from RFC 3280 [RFC3280], Appendix A.1 AlgorithmIdentifier FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) } ;
- RFC 3280 [RFC3280]、付録A.1のAlgorithmIdentifierがPKIX1Explicit88 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）MODからの輸入（ 0）pkix1、明示的な（18）}。
-- EXPORTS ALL --
- すべてのエクスポート -
IMPORTS
輸入
-- Imports from PKCS-7 ContentInfo FROM PKCS7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-7(7) modules(0)}
- PKCS7 FROM PKCS7 ContentInfoから輸入{ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-7（7）モジュール（0）}
-- Imports from AuthenticationFramework AlgorithmIdentifier FROM AuthenticationFramework {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4}
- AuthenticationFramework FROM AuthenticationFrameworkのAlgorithmIdentifierから輸入{関節イソ - ITU-T DS（5）モジュール（1）authenticationFramework（7）4}
-- Imports from InformationFramework Attribute FROM InformationFramework {joint-iso-itu-t ds(5) module(1) informationFramework(1) 4} ;
- InformationFrameworkから輸入InformationFrameworkから属性{関節イソITU-TのDS（5）モジュール（1）informationFramework（1）4}。
This document defines the LTANS object identifier tree root.
この文書では、LTANSオブジェクト識別子ツリーのルートを定義します。
LTANS Object Identifier tree root
LTANSオブジェクト識別子ツリーのルート
ltans OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) }
An Evidence Record is a unit of data, which can be used to prove the existence of an archived data object or an archived data object group at a certain time. The Evidence Record contains Archive Timestamps, generated during a long archival period and possibly useful data for validation. It is possible to store this Evidence Record separately from the archived data objects or to integrate it into the data itself. For data types, signed data and enveloped data of the CMS integration are specified in Appendix A.
証拠レコードは、特定の時間にアーカイブされたデータ・オブジェクトまたはアーカイブされたデータ・オブジェクト・グループの存在を証明するために使用され得るデータの単位です。証拠のレコードは、検証のためのアーカイブ長期アーカイブ期間中に生成されたタイムスタンプ、およびおそらく有用なデータが含まれています。アーカイブされたデータオブジェクトとは別に、この証拠の記録を保存したり、データ自体に統合することが可能です。データ型の場合、データに署名し、CMSの統合のデータは、付録Aに指定されている包ま
Evidence Record has the following ASN.1 Syntax:
証拠の記録は、次のASN.1構文があります。
ASN.1 Evidence Record
ASN.1証拠レコード
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) } ,
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryptionInfo [1] EncryptionInfo OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence
}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute
The fields have the following meanings:
各フィールドの意味は次のとおりです。
The 'version' field indicates the syntax version, for compatibility with future revisions of this specification and to distinguish it from earlier non-conformant or proprietary versions of the ERS. The value 1 indicates this specification. Lower values indicate an earlier version of the ERS has been used. An implementation conforming to this specification SHOULD reject a version value below 1.
「バージョン」フィールドは、この仕様の将来のリビジョンとの互換性のため、構文のバージョンを示し、ERSの以前の非準拠または独自のバージョンからそれを区別します。値1は、この仕様を示しています。低い値は、ERSの以前のバージョンが使用されたことを示します。この仕様に準拠した実装は、1以下のバージョン値を拒絶すべきです。
digestAlgorithms is a sequence of all the hash algorithms used to hash the data object over the archival period. It is the union of all digestAlgorithm values from the ArchiveTimestamps contained in the EvidenceRecord. The ordering of the values is not relevant.
digestAlgorithmsは、アーカイブ期間にわたるデータ・オブジェクトをハッシュするために使用される全てのハッシュアルゴリズムの配列です。それはEvidenceRecordに含まれるArchiveTimestampsからすべてdigestAlgorithm値の和集合です。値の順序は関係ありません。
cryptoInfos allows the storage of data useful in the validation of the archiveTimeStampSequence. This could include possible Trust Anchors, certificates, revocation information, or the current definition of the suitability of cryptographic algorithms, past and present (e.g., RSA 768-bit valid until 1998, RSA 1024-bit valid until 2008, SHA1 valid until 2010). These items may be added based on the policy used. Since this data is not protected within any timestamp, the data should be verifiable through other mechanisms. Such verification is out of scope of this document.
cryptoInfosはarchiveTimeStampSequenceの検証に有用データの保存を可能にします。これは、可能なトラストアンカー、証明書、失効情報、または過去と現在の暗号化アルゴリズムの適合性の現在の定義（2008年までは例えば、RSA 1998までの768ビットの有効、RSA 1024ビットの有効、2010年まで有効なSHA1）を含めることができます。これらのアイテムは、使用されるポリシーに基づいて添加してもよいです。このデータは、任意のタイムスタンプ内で保護されていないので、データは、他の機構を介して検証可能であるべきです。このような検証は、この文書の範囲外です。
encryptionInfo contains the necessary information to support encrypted content to be handled. For discussion of syntax, please refer to Section 6.1.
encryptionInfoが処理される暗号化されたコンテンツをサポートするために必要な情報が含まれています。構文の説明については、6.1節を参照してください。
ArchiveTimeStampSequence is a sequence of ArchiveTimeStampChain, described in Section 5.
ArchiveTimeStampSequenceは、第5節で説明した、ArchiveTimeStampChainのシーケンスです。
If the archive data objects were encrypted before generating Archive Timestamps but a non-repudiation proof is needed for unencrypted data objects, the optional encryptionInfos field contains data necessary to unambiguously re-encrypt data objects. If omitted, it means that data objects are not encrypted or that a non-repudiation proof for the unencrypted data is not required. For further details, see Section 6.
アーカイブデータオブジェクトがアーカイブタイムスタンプを生成する前に暗号化されたが、否認防止証明は暗号化されていないデータオブジェクトのために必要な場合は、オプションのencryptionInfosフィールドが明確に再暗号化データオブジェクトに必要なデータが含まれています。省略した場合は、データオブジェクトが暗号化されていないことや、暗号化されていないデータの否認防止の証拠が必要とされていないことを意味します。詳細については、第6章を参照してください。
The generation of an EvidenceRecord can be described as follows:
次のようにEvidenceRecordの発生を説明することができます。
2. Create the initial Archive Timestamp (see Section 4, "Archive Timestamp").
2.初期のアーカイブ・タイムスタンプを（第4節、「アーカイブ・タイムスタンプ」を参照）を作成します。
3. Refresh the Archive Timestamp when necessary, by Timestamp Renewal or Hash-Tree Renewal (see Section 5).
必要なとき3.タイムスタンプリニューアルやハッシュ木リニューアル（第5節を参照）により、アーカイブ・タイムスタンプを更新します。
The process of generation depends on whether the Archive Timestamps are generated, stored, and managed by a centralized instance. In the case of central management, it is possible to collect many data objects, build hash trees, store them, and reduce them later. In case of local generation, it might be easier to generate a simple Archive Timestamp without building hash trees. This can be accomplished by omitting the reducedHashtree field from the ArchiveTimestamp. In this case, the ArchiveTimestamp covers a single data object. Using this approach, it is possible to "convert" existing timestamps into ArchiveTimestamps for renewal.
生成プロセスは、アーカイブタイムスタンプが、生成された格納され、集中インスタンスによって管理されているかどうかに依存します。中央管理の場合、多くのデータオブジェクトを収集し、ハッシュ木を構築し、それらを保存し、後でそれを低減することが可能です。地元の世代の場合は、ハッシュ木を構築することなく、簡単なアーカイブ・タイムスタンプを生成する方が簡単かもしれません。これはArchiveTimestampからreducedHashtreeフィールドを省略することによって達成することができます。この場合、ArchiveTimestampは、単一のデータ・オブジェクトを覆っています。このアプローチを使用して、更新のためArchiveTimestampsに既存のタイムスタンプを「変換」することが可能です。
The Verification of an EvidenceRecord overall can be described as follows:
次のようにEvidenceRecordの検証は、全体的に説明することができます。
2. Re-encrypt data object/data object group, if encryption field is used (for details, see Section 6).
暗号化領域が使用される場合2.再暗号化データ・オブジェクト/データオブジェクトグループ、（詳細はセクション6を参照）。
3. Verify Archive Timestamp Sequence (details in Section 4 and Section 5).
3.アーカイブ・タイムスタンプシーケンス（第4及び第5の詳細）を確認してください。
An Archive Timestamp is a timestamp and a set of lists of hash values. The lists of hash values are generated by reduction of an ordered Merkle hash tree [MER1980]. The leaves of this hash tree are the hash values of the data objects to be timestamped. Every inner node of the tree contains one hash value, which is generated by hashing the concatenation of the children nodes. The root hash value, which represents unambiguously all data objects, is timestamped.
アーカイブ・タイムスタンプは、タイムスタンプとハッシュ値のリストの集合です。ハッシュ値のリストは、注文したマークルハッシュ木[MER1980]の還元によって生成されます。このハッシュツリーの葉は、データオブジェクトのハッシュ値をタイムスタンプすることがあります。ツリーのすべての内部ノードは、子ノードの連結をハッシュすることによって生成された1つのハッシュ値を含んでいます。明確にすべてのデータオブジェクトを表すルートハッシュ値は、タイムスタンプです。
An Archive Timestamp has the following ASN.1 Syntax:
アーカイブ・タイムスタンプは、次のASN.1構文があります。
ASN.1 Archive Timestamp
ASN.1アーカイブタイムスタンプ
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
attributes [1] Attributes OPTIONAL,
reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
timeStamp ContentInfo}
PartialHashtree ::= SEQUENCE OF OCTET STRING
Attributes ::= SET SIZE (1..MAX) OF Attribute
The fields of type ArchiveTimeStamp have the following meanings: digestAlgorithm identifies the digest algorithm and any associated parameters used within the reduced hash tree. If the optional field digestAlgorithm is not present, the digest algorithm of the timestamp MUST be used. Which means, if timestamps according to [RFC3161] are used in this case, the content of this field is identical to hashAlgorithm of messageImprint field of TSTInfo.
タイプArchiveTimeStampのフィールドは以下の意味を有する：digestAlgorithmダイジェストアルゴリズムおよび還元ハッシュツリー内で使用される任意の関連するパラメータを識別する。オプションフィールドdigestAlgorithmが存在しない場合、タイムスタンプのダイジェストアルゴリズムが使用されなければなりません。 [RFC3161]に記載のタイムスタンプが、この場合に使用される場合れる手段と、このフィールドの内容はTSTInfoのmessageImprintフィールドのhashAlgorithmと同一です。
attributes contains information an LTA might want to provide to document individual renewal steps and the creation of the individual ArchiveTimeStamps, e.g., applied policies. As the structure of the ArchiveTimeStamp may be protected by hash and timestamps, the ordering is relevant, which is why a SET is used instead of a SEQUENCE.
属性はLTAは、個々の更新手順と、個々のArchiveTimeStampsの作成を文書化する提供したい可能性がある情報が含まれ、例えば、ポリシーを適用します。 ArchiveTimeStampの構造はハッシュとタイムスタンプによって保護することができるように、順序付けは、SETの代わりに配列の使用されている理由であり、適切です。
reducedHashtree contains lists of hash values, organized in PartialHashtrees for easier understanding. They can be derived by reducing a hash tree to the nodes necessary to verify a single data object. Hash values are represented as octet strings. If the optional field reducedHashtree is not present, the ArchiveTimestamp simply contains an ordinary timestamp.
reducedHashtreeは、理解を容易にするためのPartialHashtreesで編成、ハッシュ値のリストが含まれています。彼らは、単一のデータ・オブジェクトを検証するために必要なノードにハッシュツリーを低減することによって導出することができます。ハッシュ値は、オクテット文字列として表されます。オプションのフィールドreducedHashtreeが存在しない場合、ArchiveTimestampは単に通常のタイムスタンプが含まれています。
timeStamp should contain the timestamp as defined in Section 1.3. (e.g., as defined with TimeStampToken in [RFC3161]). Other types of timestamp MAY be used, if they contain time data, timestamped data, and a cryptographically secure confirmation from the TSA of these data.
セクション1.3で定義されたタイムスタンプは、タイムスタンプが含まれている必要があります。 （例えば、[RFC3161]にTimeStampTokenので定義されたように）。彼らは時間データ、タイムスタンプデータ、およびこれらのデータのTSAから暗号化された安全確認が含まれている場合、タイムスタンプの他のタイプは、使用されるかもしれません。
The lists of hash values of an Archive Timestamp can be generated by building and reducing a Merkle hash tree [MER1980].
アーカイブタイムスタンプのハッシュ値のリストが構築しマークルハッシュ木[MER1980]を還元することにより生成することができます。
Such a hash tree can be built as follows:
次のようなハッシュ木を構築することができます。
2. Choose a secure hash algorithm H and generate hash values for the data objects. These values will be the leaves of the hash tree.
2.セキュアハッシュアルゴリズムHを選択して、データオブジェクトのハッシュ値を生成します。これらの値は、ハッシュツリーの葉になります。
3. For each data group containing more than one document, its respective document hashes are binary sorted in ascending order, concatenated, and hashed. The hash values are the complete output from the hash algorithm, i.e., leading zeros are not removed, with the most significant bit first.
3つ以上の文書を含む各データ群について、そのそれぞれの文書のハッシュは、昇順にソートバイナリ連結、およびハッシュされます。ハッシュ値は、最初の最上位ビットとハッシュアルゴリズムから完全な出力、すなわち、先行ゼロが削除されていない、です。
4. If there is more than one hash value, place them in groups and sort each group in binary ascending order. Concatenate these values and generate new hash values, which are inner nodes of this tree. (If additional hash values are needed, e.g., so that all nodes have the same number of children, any data may be hashed using H and used.) Repeat this step until there is only one hash value, which is the root node of the hash tree.
4.複数のハッシュ値が存在する場合、グループにそれらを配置し、バイナリ昇順で各グループを並べ替えます。これらの値を連結し、このツリーの内部ノードであり、新たなハッシュ値を生成します。 （すべてのノードが子の同じ数を有するように、例えば、追加のハッシュ値が必要な場合は、任意のデータは、Hを用いてハッシュして用いてもよい。）のルートノードでのみ1つのハッシュ値が存在するまで、この手順を繰り返しハッシュツリー。
5. Obtain a timestamp for this root hash value. The hash algorithm in the timestamp request MUST be the same as the hash algorithm of the hash tree, or the digestAlgorithm field of the ArchiveTimeStamp MUST be present and specify the hash algorithm of the hash tree.
5.このルートハッシュ値のタイムスタンプを取得します。タイムスタンプ要求にハッシュアルゴリズムは、ハッシュツリーのハッシュアルゴリズムと同じであるか、またはArchiveTimeStampのdigestAlgorithmフィールドが存在し、ハッシュツリーのハッシュアルゴリズムを指定しなければなりません。
An example of a constructed hash tree for 3 data groups, where data groups 1 and 3 only contain one document, and data group 2 contains 3 documents:
構成されたデータグループ1及び3は、1つのドキュメントのみを含む3つのデータ群、のハッシュツリー、およびデータ群2の例では、3つの文書が含まれています。
+------+
| h123 |
+------+
/ \
/ \
+----+ +----+
| h12| | h3 |
+----+ +----+
/ \
/ \
+----+ +-------+
| h1 | | h2abc |
+----+ +-------+
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
| h2a| | h2b| | h2c|
+----+ +----+ +----+
Figure 1: Hash tree
図1：ハッシュツリー
h1 = H(d1) where d1 is the only data object in data group 1 h3 = H(d3) where d3 is the only data object in data group 3 h12 = H( binary sorted and concatenated (h1, h2abc)) h123 = H( binary sorted and concatenated (h12, h3)) h2a = H(first data object of data object group 2) h2b = H(second data object of data object group 2) h2c = H(third data object of data object group 2) h2abc = H( binary sorted and concatenated (h2a, h2b, h2c))
H1 = H（D1）D1〜D3は3 H12 = H（バイナリソートと連結さ（H1、h2abc））H123 =データ群にのみデータオブジェクトであるデータグループ1 H3 = H（D3）でのみデータオブジェクトでありますH（バイナリソートと連結（H12、H3））H2A = H（データオブジェクトグループ2の第1のデータオブジェクト）H2B = H H 2 C = Hデータオブジェクトグループ2の（第3のデータオブジェクト（データオブジェクトグループ2の第2のデータオブジェクト） ）h2abc = H（バイナリソートと連結（H2A、H2B、H2C））
The hash tree can be reduced to lists of hash values, necessary to have a proof of existence for a single data object:
ハッシュツリーは、単一のデータオブジェクトの存在の証拠を持っているために、ハッシュ値のリストに必要な削減することができます。
1. Generate hash value h of the data object, using hash algorithm H of the hash tree.
1.ハッシュツリーのハッシュアルゴリズムHを用いて、データオブジェクトのハッシュ値hを生成します。
2. Select all hash values, which have the same father node as h. Generate the first list of hash values by arranging these hashes, in binary ascending order. This will be stored in the structure of the PartialHashtree. Repeat this step for the father node of all hashes until the root hash is reached. The father nodes themselves are not saved in the hash lists -- they are computable.
時間と同じ父親のノードを持つすべてのハッシュ値を、選択します。バイナリ昇順で、これらのハッシュを配置することにより、ハッシュ値の最初のリストを生成します。これはPartialHashtreeの構造体に格納されます。ルートハッシュに到達するまで、すべてのハッシュの父ノードに対して、この手順を繰り返します。父は自身がハッシュリストに保存されていないノード - 彼らは計算されています。
3. The list of all partialHashtrees finally is the reducedHashtree. (All of the specified hash values under the same father node, except the father node of the nodes below, are grouped in a PartialHashtree. The sequence list of all Partialhashtrees is the reducedHashtree.)
3.すべてのpartialHashtreesのリストは最終的にreducedHashtreeです。 （同じ父ノードの下に指定されたハッシュ値の全ては、以下のノードの父ノードを除いて、PartialHashtreeにグループ化されている。全てPartialhashtreesの配列リストはreducedHashtreeです。）
4. Finally, add the timestamp and the info about the hash algorithm to get an Archive Timestamp.
4.最後に、アーカイブ・タイムスタンプを取得するには、タイムスタンプとハッシュアルゴリズムに関する情報を追加します。
Assuming that the sorted binary ordering of the hashes in Figure 1 is: h2abc < h1, then the reduced hash tree for data group 1 (d1) is:
図1のハッシュのソートされたバイナリ順序であると仮定すると：h2abc <H1、データ群1（D1）に対して減少ハッシュツリーは、次のとおりです。
+--------------------------------+
| +-----------------+ +--------+ |
| | +------+ +----+ | | +----+ | |
| | | h2abc| | h1 | | | | h3 | | |
| | +------+ +----+ | | +----+ | |
| +-----------------+ +--------+ |
+--------------------------------+
Figure 2: Reduced hash tree for data group 1
図2：データグループ1に対して減少ハッシュツリー
The pseudo ASN1 for this reduced hash tree rht1 would look like: rht1 = SEQ(pht1, pht2)
この減少したハッシュツリーrht1のための疑似ASN1は、次のようになります。rht1 = SEQ（PHT1、PHT2）
with the PartialHashtrees pht1 and pht2 pht1 = SEQ (h2abc, h1) pht2 = SEQ (h3)
PartialHashtreesのPHT1とPHT2のPHT1 = SEQ（h2abc、H1）PHT2 = SEQ（H3）と
Assuming the same hash tree as in Figure 1, the reduced hash tree for all data objects in data group 2 is identical.
図1と同一のハッシュツリーを仮定すると、データグループ2内のすべてのデータ・オブジェクトの減少ハッシュツリーは同じです。
+-------------------------------------------------+
| +----------------------+ +--------+ +--------+ |
| | +----+ +----+ +----+ | | +----+ | | +----+ | |
| | | h2b| | h2c| | h2a| | | | h1 | | | | h3 | | |
| | +----+ +----+ +----+ | | +----+ | | +----+ | |
| +----------------------+ +--------+ +--------+ |
+-------------------------------------------------+
Figure 3: Reduced hash tree for data object group 2
図3：データオブジェクトグループ2に対して減少ハッシュツリー
The pseudo ASN1 for this reduced hash tree would look like: rht2 = SEQ(pht3, pht4, pht5)
この減少したハッシュツリーの疑似ASN1は、次のようになります。rht2 = SEQ（PHT3、pht4、pht5）
with the PartialHashtrees pht3, pht4, and pht5 pht3 = SEQ (h2b, h2c, h2a) pht4 = SEQ (h1) pht5 = SEQ (h3)
PartialHashtreesのPHT3、pht4、及びpht5のPHT3持つ= SEQ（H2B、H2C、H2A）pht4 = SEQ（H1）pht5 = SEQ（H3）
Note there are no restrictions on the quantity or length of hash-value lists. Also note that it is profitable but not required to build hash trees and reduce them. An Archive Timestamp may consist only of one list of hash-values and a timestamp or only a timestamp with no hash value lists.
ハッシュ値リストの量や長さに制限はありません注意してください。また、それが有益であることに注意しますが、ハッシュ木を構築し、それらを軽減する必要はありません。アーカイブ・タイムスタンプは、唯一のハッシュ値のリストなしハッシュ値リストとタイムスタンプまたはタイムスタンプだけで構成することができます。
The data (e.g. certificates, Certificate Revocation Lists (CRLs), or Online Certificate Status Protocol (OCSP) responses) needed to verify the timestamp MUST be preserved, and SHOULD be stored in the timestamp itself unless this causes unnecessary duplication. A timestamp according to [RFC3161] is a CMS object in which certificates can be stored in the certificates field and CRLs can be stored in the crls field of signed data. OCSP responses can be stored as unsigned attributes [RFC3126]. Note [ANSI.X9-95.2005], [ISO-18014-2.2002], and [ISO-18014-3.2004], which specify verifiable timestamps that do not depend on certificates, CRLs, or OCSP responses.
データ（例えば証明書、証明書失効リスト（CRL）、またはオンライン証明書状態プロトコル（OCSP）応答が）、これは不要な重複が発生しない限り、タイムスタンプが保存されなければならない、とタイムスタンプ自体に格納する必要が検証する必要がありました。 [RFC3161]に記載のタイムスタンプが、証明書が証明書フィールドに格納することができ、CRLが署名されたデータのCRLのフィールドに格納することができるCMSオブジェクトです。 OCSP応答が署名属性[RFC3126]として保存することができます。なお、[ANSI.X9-95.2005]、[ISO-18014から2.2002]、および証明書、CRLの、またはOCSP応答に依存しない検証可能なタイムスタンプを指定し、[ISO-18014から3.2004]、。
An Archive Timestamp shall prove that a data object existed at a certain time, given by timestamp. This can be verified as follows:
アーカイブ・タイムスタンプは、データオブジェクトがタイムスタンプによって与えられた、ある特定の時点で存在していることを証明しなければなりません。これは以下のように検証することができます。
1. Calculate hash value h of the data object with hash algorithm H given in field digestAlgorithm of the Archive Timestamp.
1.アーカイブ・タイムスタンプのフィールドdigestAlgorithmで与えられたハッシュアルゴリズムHを有するデータオブジェクトのハッシュ値hを計算します。
2. Search for hash value h in the first list (partialHashtree) of reducedHashtree. If not present, terminate verification process with negative result.
reducedHashtreeの最初のリスト（partialHashtree）でハッシュ値h 2.検索。存在しない場合は、否定的結果と検証プロセスを終了します。
3. Concatenate the hash values of the actual list (partialHashtree) of hash values in binary ascending order and calculate the hash value h' with algorithm H. This hash value h' MUST become a member of the next higher list of hash values (from the next partialHashtree). Continue step 3 until a root hash value is calculated.
3.バイナリ昇順にハッシュ値の実際のリスト（partialHashtree）のハッシュ値を連結から（ハッシュ値の次に高いリストのメンバーにならなければなりません「アルゴリズムH.このハッシュ値Hと」ハッシュ値hを算出します次のpartialHashtree）。ルートハッシュ値が計算されるまで、ステップ3を続けます。
4. Check timestamp. In case of a timestamp according to [RFC3161], the root hash value must correspond to hashedMessage, and digestAlgorithm must correspond to hashAlgorithm field, both in messageImprint field of timeStampToken. In case of other timestamp formats, the hash value and digestAlgorithm must also correspond to their equivalent fields if they exist.
4.チェックタイムスタンプ。 [RFC3161]に記載のタイムスタンプの場合には、ルートハッシュ値はhashedMessageに対応する必要があり、そしてdigestAlgorithm両方TimeStampTokenのmessageImprintの分野において、hashAlgorithmフィールドに対応しなければなりません。それらが存在する場合、他のタイムスタンプ形式の場合には、ハッシュ値とdigestAlgorithmはまた、それらの等価のフィールドに対応しなければなりません。
If a proof is necessary for more than one data object, steps 1 and 2 have to be done for all data objects to be proved. If an additional proof is necessary that the Archive Timestamp relates to a data object group (e.g., a document and all its signatures), it can be verified additionally, that only the hash values of the given data objects are in the first hash-value list.
証明は複数のデータ・オブジェクトのために必要であれば、1と2が証明されるすべてのデータオブジェクトのために行う必要があり、手順。追加の証拠は、アーカイブ・タイムスタンプは、データオブジェクトグループ（例えば、文書とそのすべての署名）に関係することが必要である場合、与えられたデータ・オブジェクトのみのハッシュ値が第1のハッシュ値であることを、さらに確認することができますリスト。
An Archive Timestamp proves the existence of single data objects or data object group at a certain time. However, this first Archive Timestamp in the first ArchiveTimeStampChain can become invalid, if hash algorithms or public key algorithms used in its hash tree or timestamp become weak or if the validity period of the timestamp authority certificate expires or is revoked.
アーカイブ・タイムスタンプは、特定の時間に単一のデータオブジェクトまたはデータオブジェクトのグループの存在を証明します。タイムスタンプ局の証明書の有効期間が満了したか取り消された場合、そのハッシュツリーまたはタイムスタンプに使用されるハッシュアルゴリズムや公開鍵アルゴリズムが弱くなったり場合は、最初のArchiveTimeStampChainで、この最初のアーカイブ・タイムスタンプは、無効になることができます。
Prior to such an event, the existence of the Archive Timestamp or archive timestamped data has to be reassured. This can be done by creating a new Archive Timestamp. Depending on whether the timestamp becomes invalid or the hash algorithm of the hash tree becomes weak, two kinds of Archive Timestamp renewal are possible:
以前、このようなイベントに、アーカイブタイムスタンプの存在やアーカイブタイムスタンプのデータが安心する必要があります。これは、新しいアーカイブタイムスタンプを作成することによって行うことができます。タイムスタンプが無効になるか、ハッシュツリーのハッシュアルゴリズムが弱くなるかどうかに応じて、アーカイブタイムスタンプの更新の2種類が考えられます。
o Timestamp Renewal: A new Archive Timestamp is generated, which covers the timestamp of the old one. One or more Archive Timestamps generated by Timestamp Renewal yield an Archive Timestamp Chain for a data object or data object group.
Oタイムスタンプ更新：新しいアーカイブタイムスタンプは、古いもののタイムスタンプをカバーする、生成されます。タイムスタンプ更新によって生成された一つ以上のアーカイブタイムスタンプは、データオブジェクトまたはデータオブジェクトのグループのアーカイブタイムスタンプチェーンを得ました。
o Hash-Tree Renewal: A new Archive Timestamp is generated, which covers all the old Archive Timestamps as well as the data objects. A new Archive Timestamp Chain is started. One or more Archive Timestamp Chains for a data object or data object group yield an Archive Timestamp Sequence.
ハッシュ木リニューアルO：新しいアーカイブタイムスタンプは、すべての古いアーカイブタイムスタンプなどのデータオブジェクトをカバーする、生成されます。新しいアーカイブタイムスタンプチェーンが開始されます。データオブジェクトまたはデータオブジェクトのグループのための1つ以上のアーカイブ・タイムスタンプ鎖がアーカイブ・タイムスタンプのシーケンスを得ます。
After the renewal, always only the last (i.e., most recent) ArchiveTimeStamp and the algorithms and timestamps used by it must be watched regarding expiration and loss of security.
リニューアル後は、常に最後の（すなわち、最も最近）ArchiveTimeStampし、それによって使用されるアルゴリズムとタイムスタンプが有効期限とセキュリティの損失について注目しなければなりません。
ArchiveTimeStampChain and ArchiveTimeStampSequence have the following ASN.1 Syntax:
ArchiveTimeStampChainとArchiveTimeStampSequenceは、次のASN.1構文があります。
ASN.1 ArchiveTimeStampChain and ArchiveTimeStampSequence
ASN.1 ArchiveTimeStampChainとArchiveTimeStampSequence
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF
ArchiveTimeStampChain
ArchiveTimeStampChain and ArchiveTimeStampSequence MUST be ordered ascending by time of timestamp. Within an ArchiveTimeStampChain, all reducedHashtrees of the contained ArchiveTimeStamps MUST use the same Hash-Algorithm.
ArchiveTimeStampChainとArchiveTimeStampSequenceは、タイムスタンプの時間によって昇順に注文する必要があります。 ArchiveTimeStampChain内に、含まArchiveTimeStampsの全てreducedHashtreesは同じハッシュアルゴリズムを使用しなければなりません。
The initial Archive Timestamp relates to a data object or a data object group. Before cryptographic algorithms that are used within the most recent Archive Timestamp (which is, at the beginning, the initial one) become weak or their timestamp certificates become invalid, Archive Timestamps have to be renewed by generating a new Archive Timestamp.
最初のアーカイブ・タイムスタンプは、データオブジェクトまたはデータオブジェクトのグループに関する。 （これは、初めに、最初の1）が弱くなったり、タイムスタンプ証明書が無効になり、最新のアーカイブタイムスタンプの中で使用されている暗号化アルゴリズムの前に、アーカイブタイムスタンプが新しいアーカイブタイムスタンプを生成することによって、更新する必要があります。
In the case of Timestamp Renewal, the content of the timeStamp field of the old Archive Timestamp has to be hashed and timestamped by a new Archive Timestamp. The new Archive Timestamp MAY not contain a reducedHashtree field, if the timestamp only simply covers the previous timestamp. However, generally one can collect a number of old Archive Timestamps and build the new hash tree with the hash values of the content of their timeStamp fields.
タイムスタンプ更新の場合は、古いアーカイブタイムスタンプのタイムスタンプフィールドの内容は、ハッシュ化され、新しいアーカイブタイムスタンプによってタイムスタンプする必要があります。タイムスタンプは単に前のタイムスタンプをカバーする場合、新しいアーカイブタイムスタンプは、reducedHashtreeフィールドを含めることはできません。しかし、一般的に、1つは、古いアーカイブタイムスタンプの数を収集し、そのタイムスタンプフィールドの内容のハッシュ値を持つ新しいハッシュツリーを構築することができます。
The new Archive Timestamp MUST be added to the ArchiveTimestampChain. This hash tree of the new Archive Timestamp MUST use the same hash algorithm as the old one, which is specified in the digestAlgorithm field of the Archive Timestamp or, if this value is not set (as it is optional), within the timestamp itself.
新しいアーカイブタイムスタンプがArchiveTimestampChainに追加する必要があります。新しいアーカイブタイムスタンプのこのハッシュツリーは、タイムスタンプ自体の中に、この値が設定されていない場合（これはオプションであるとして）、アーカイブタイムスタンプのdigestAlgorithmフィールドで指定されたか、され、古いものと同じハッシュアルゴリズムを使用しなければなりません。
In the case of Hash-Tree Renewal, the Archive Timestamp and the archived data objects covered by the Archive Timestamp must be hashed and timestamped again, as described below:
後述のようにハッシュ木更新の場合には、アーカイブ・タイムスタンプとアーカイブタイムスタンプによって覆われたアーカイブされたデータオブジェクトは、再度ハッシュされ、タイムスタンプされなければなりません。
2. Select data objects d(i) referred to by initial Archive Timestamp (objects that are still present and not deleted). Generate hash values h(i) = H((d(i)). If data groups with more than one document are present, then one will have more than one hash for a group, i.e., h(i_a), h(i_b).., h(i_n)
2.選択したデータをd（i）は、最初のアーカイブ・タイムスタンプ（まだ存在していない、削除されたオブジェクト）によって参照されるオブジェクト。ハッシュ値h（i）を生成する= H（（D（I））。複数の文書とデータグループが存在する場合、一つのグループ、すなわち、H（I_A）、時間つ以上のハッシュを有するであろう（I_B ）..、 こんにちは、N）
3. atsc(i) is the encoded ArchiveTimeStampSequence, the concatenation of all previous Archive Timestamp Chains (in chronological order) related to data object d(i). Generate hash value ha(i) = H(atsc(i)). Note: The ArchiveTimeStampChains used are DER encoded, i.e., they contain sequence and length tags.
3. ATSC（i）は符号化ArchiveTimeStampSequence、データオブジェクトD（I）に関連したすべての以前のアーカイブ・タイムスタンプチェーン（時系列順）の連結です。ハッシュ値ヘクタール（I）= H（ATSC（i））が生成します。注：使用ArchiveTimeStampChainsは、DER、すなわち、それらは配列および長さのタグを含む、符号化されます。
4. Concatenate each h(i) with ha(i) and generate hash values h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: h(i_a)' = H (h(i_a)+ ha(i)) h(i_b)' = H (h(i_b)+ ha(i)), etc.
HA（I）4.連結し、各H（i）とハッシュ値H（I）」= H（H（I）+ HA（I））を生成します。マルチドキュメントグループの場合、これは：H（I_A） '= H（H（I_A）+ HA（I））H（I_B）' = H（H（I_B）+ HA（I））、等
5. Build a new Archive Time Stamp for each h(i)'. (Hash-tree generation and reduction is defined in Section 4.2; note that each h(i)' will be treated in Section 4.2 as the document hash. The first hash value list in the reduced hash tree should only contain h(i)'. For a multi-document group, the first hash value list will contain the new hashes for all the documents in this group, i.e., h(i_a)', h(i_b)'.., h(i_n)')
5.各時間（I）」の新しいアーカイブタイムスタンプを作成します。 （ハッシュツリー生成および還元はセクション4.2で定義され、それぞれ、H（i）は注意「文書ハッシュとして4.2節で処理される第1のハッシュ値のリストを減少ハッシュツリーにのみ、H（Iを含むべきです）」。 。マルチドキュメントグループでは、第1のハッシュ値の一覧は「時間（I_B）」は、このグループ内のすべての文書、すなわち、H（I_A）のための新しいハッシュを含んでいます..時間（値Inを） '）
6. Create new ArchiveTimeStampChain containing the new Archive Timestamp and append this ArchiveTimeStampChain to the ArchiveTimeStampSequence.
6.新しいアーカイブタイムスタンプを含む新しいArchiveTimeStampChainを作成し、ArchiveTimeStampSequenceにこのArchiveTimeStampChainを追加します。
+-------+
| h123' |
+-------+
/ \
/ \
+-----+ +----+
| h12'| | h3'|
+-----+ +----+
/ \
/ \
+----+ +--------+
| h1'| | h2abc' |
+----+ +--------+
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|h2a'| |h2b'| |h2c'|
+----+ +----+ +----+
Figure 4: Hash tree from Hash-Tree Renewal
図4：ハッシュ木リニューアルからハッシュツリー
Let H be the new secure hash algorithm ha(1), ha(2), ha(3) are as defined in step 4 above h1' = H( binary sorted and concatenated (H(d1), ha(1))) d1 is the original document from data group 1 h3' = H( binary sorted and concatenated (H(d3), ha(3))) d3 is the original document from data group 3
Hは、新しいセキュアハッシュアルゴリズムHAとする（1）、HA（2）、HA（3）= H、H1' 、上記ステップ4で定義した通りである（バイナリソート及び連結（H（D1）、HA（1））） D1がD3は、データグループ3からの原稿である（（3））、HA、バイナリソート及び連結（H（D3））データグループ1 H3' = Hからオリジナル文書であります
h2a = H(first data object of data object group 2) ... h2c = H(third data object of data object group 2) h2a' = H( binary sorted and concatenated (h2a, ha(2))) ... h2c' = H( binary sorted and concatenated (h2c, ha(2)))
H2A = H（データオブジェクトグループ2の第1のデータオブジェクト）... H2C = H H2A（データオブジェクトグループ2の第3のデータオブジェクト）」= H（バイナリソートと連結（H2A、HA（2）））... H2C」= H（バイナリソートと連結（H2C、HA（2）））
h2abc = H( binary sorted and concatenated (h2a', h2b', h2c'))
h2abc = H（バイナリソートと連結（H2A 'H2B'、H 2 '））
ArchiveTimeStamps that are not necessary for verification should not be added to an ArchiveTimeStampChain or ArchiveTimeStampSequence.
検証のために必要ではないArchiveTimeStampsはArchiveTimeStampChainまたはArchiveTimeStampSequenceに追加されるべきではありません。
To get a non-repudiation proof that a data object existed at a certain time, the Archive Timestamp Chains and their relations to each other and to the data objects have to be proved:
データオブジェクトが特定の時刻に存在したことを否認防止証明を取得するには、相互にデータオブジェクトへのアーカイブ・タイムスタンプ・チェーンおよびその関係を立証する必要があります。
1. Verify that the first Archive Timestamp of the first ArchiveTimestampChain (the initial Archive Timestamp) contains the hash value of the data object.
まずArchiveTimestampChainの最初のアーカイブ・タイムスタンプ（初期アーカイブタイムスタンプ）がデータオブジェクトのハッシュ値が含まれていることを確認します。
2. Verify each ArchiveTimestampChain. The first hash value list of each ArchiveTimeStamp MUST contain the hash value of the timestamp of the Archive Timestamp before. Each Archive Timestamp MUST be valid relative to the time of the following Archive Timestamp. All Archive Timestamps within a chain MUST use the same hash algorithm and this algorithm MUST be secure at the time of the first Archive Timestamp of the following ArchiveTimeStampChain.
2.各ArchiveTimestampChainを確認してください。各ArchiveTimeStampの第1のハッシュ値の一覧は、前のアーカイブタイムスタンプのタイムスタンプのハッシュ値を含まなければなりません。各アーカイブ・タイムスタンプは、以下のアーカイブ・タイムスタンプの時間に対して有効でなければなりません。チェーン内のすべてのアーカイブタイムスタンプは、同じハッシュアルゴリズムを使用しなければならないし、このアルゴリズムは、以下のArchiveTimeStampChainの最初のアーカイブタイムスタンプの時に安全でなければなりません。
3. Verify that the first hash value list (partialHashtree) of the first Archive Timestamp of all other ArchiveTimeStampChains contains a hash value of the concatenation of the data object hash and the hash value of all older ArchiveTimeStampChain. Verify that this Archive Timestamp was generated before the last Archive Timestamp of the ArchiveTimeStampChain became invalid.
3.他のすべてのArchiveTimeStampChainsの最初のアーカイブ・タイムスタンプの第1のハッシュ値リスト（partialHashtree）がデータオブジェクトハッシュを連結し、すべての古いArchiveTimeStampChainのハッシュ値のハッシュ値が含まれていることを確認します。 ArchiveTimeStampChainの最後のアーカイブ・タイムスタンプが無効になる前に、このアーカイブタイムスタンプが生成されたことを確認します。
In order to complete the non-repudiation proof for the data objects, the last Archive Timestamp has to be valid at the time the verification is performed.
データ・オブジェクトの否認防止証明を完了するためには、最後のアーカイブ・タイムスタンプは、検証が行われた時点で有効にする必要があります。
If the proof is necessary for more than one data object, steps 1 and 3 have to be done for all these data objects. To prove the Archive Timestamp Sequence relates to a data object group, verify that each first Archive Timestamp of the first ArchiveTimeStampChain of the ArchiveTimeStampSequence of each data object does not contain other hash values in its first hash value list (than the hash values of the other data objects).
証明は複数のデータ・オブジェクトのために必要な場合は、手順1と3は、これらすべてのデータオブジェクトに対して実行する必要があります。アーカイブ・タイムスタンプのシーケンスは、データオブジェクトグループに関する証明するために、各データ・オブジェクトのArchiveTimeStampSequenceの最初ArchiveTimeStampChainの各最初のアーカイブタイムスタンプが他のハッシュ値よりも（その第1のハッシュ値リストに他のハッシュ値を含んでいないことを確認データ・オブジェクト）。
If service providers are used to archive data and generate Archive Timestamps, it might be desirable or required that clients only send encrypted data to be archived. However, this means that evidence records refer to encrypted data objects. ERS directly protects the integrity of the bit-stream and this freezes the bit structure at the time of archiving. This precludes changing of the encryption scheme during the archival period, e.g., if the encryption scheme is no longer secure, a change is not possible without losing the integrity proof of the EvidenceRecord. In such cases, the services of a data transformation (and by this also possible re-encryption) done by a notary service might be a possible solution. To avoid problems when using the evidence records in the future, additional special precautions have to be taken: o Evidence generated to prove the existence of encrypted data cannot always be relied upon to prove the existence of unencrypted data. It may be possible to choose an algorithm or a key for decryption that is not the algorithm or key used for encryption. In this case, the evidence record would not be a non-repudiation proof for the unencrypted data. Therefore, only encryption methods should be used that make it possible to prove that archive-timestamped encrypted data objects unambiguously represent unencrypted data objects. All data necessary to prove unambiguous representation should be included in the archived data objects. (Note: In addition, the long-term security of the encryption schemes should be analyzed to determine if it could be used to create collision attacks.)
サービスプロバイダは、データをアーカイブし、アーカイブタイムスタンプを生成するために使用されている場合、それは望ましいことやクライアントにのみアーカイブするための暗号化されたデータを送信することが必要かもしれません。しかし、これは証拠のレコードは暗号化されたデータオブジェクトを参照することを意味します。 ERSは、直接ビットストリームの完全性を保護し、これはアーカイブの時のビット構造をフリーズします。暗号化方式は、もはや安全である場合、これは、例えば、アーカイブ期間中に暗号化方式の変更排除していない変更がEvidenceRecordの整合性の証明を失うことなく、可能ではありません。このような場合には、公証人サービスによって行わデータ変換のサービス（および再暗号化これも可能では）可能な解決策かもしれません。将来的には証拠のレコードを使用した場合の問題を回避するには、追加の特別な予防措置が取られる必要があります：暗号化されたデータの存在を証明するために生成された証拠は、常に暗号化されていないデータが存在することを証明するために依拠することはできませんoを。アルゴリズムや暗号化に使用するアルゴリズムやキーではありません復号化用のキーを選択することも可能です。この場合、証拠の記録は暗号化されていないデータのための否認防止の証拠ではないでしょう。したがって、唯一の暗号化方式は、そのアーカイブ・タイムスタンプ付きの暗号化されたデータオブジェクトを明確に暗号化されていないデータオブジェクトを表すことを証明することを可能にし、その使用すべきです。明確な表現を証明するために必要なすべてのデータがアーカイブされたデータオブジェクトに含まれるべきです。 （注意：また、暗号化方式の長期的なセキュリティは、衝突攻撃を作成するために使用することができるかどうかを決定するために分析する必要があります。）
o When a relying party uses an evidence record to prove the existence of encrypted data objects, it may be desirable for clients to only store the unencrypted data objects and to delete the encrypted copy. In order to use the evidence record, it must then be possible to unambiguously re-encrypt the unencrypted data to get exactly the data that was originally archived. Therefore, additional data necessary to re-encrypt data objects should be inserted into the evidence record by the client, i.e., the LTA never sees these values.
証明書利用者が暗号化されたデータオブジェクトの存在を証明する証拠レコードを使用する場合、クライアントが唯一の暗号化されていないデータオブジェクトを格納し、暗号化されたコピーを削除するために、O、それが望ましいことがあります。証拠のレコードを使用するためには、その後、明確に元々アーカイブされた正確なデータを取得するために暗号化されていないデータを再暗号化することが可能でなければなりません。そのため、再暗号化データオブジェクトに必要な追加データは、すなわち、LTAは、これらの値を見たことがない、クライアントによる証拠記録に挿入する必要があります。
An extensible structure is defined to store the necessary parameters of the encryption methods. The use of the specified encryptionInfoType and encryptionInfoValue may be heavily dependent on the mechanisms and has to be defined in other specifications.
拡張可能構造は、暗号化方法の必要なパラメータを格納するために定義されています。指定encryptionInfoTypeとencryptionInfoValueの使用は、メカニズムに大きく依存していてもよく、他の仕様で定義されなければなりません。
The EncryptionInfo field in EvidenceRecord has the following syntax depending on the version of ASN.1.
EvidenceRecordでEncryptionInfoフィールドは、ASN.1のバージョンに応じて、次の構文を持っています。
1988 ASN.1 EncryptionInfo
1988 ASN.1 EncryptionInfo
EncryptionInfo ::= SEQUENCE {
encryptionInfoType OBJECT IDENTIFIER,
encryptionInfoValue ANY DEFINED BY encryptionInfoType
}
1997-ASN.1 EncryptionInfo
1997年、ASN.1 EncryptionInfo
EncryptionInfo ::= SEQUENCE {
encryptionInfoType ENCINFO-TYPE.&id
({SupportedEncryptionAlgorithms}),
encryptionInfoValue ENCINFO-TYPE.&Type
({SupportedEncryptionAlgorithms}{@encryptionInfoType})
}
ENCINFO-TYPE ::= TYPE-IDENTIFIER
SupportedEncryptionAlgorithms ENCINFO-TYPE ::= {...}
encryptionInfo contains information necessary for the unambiguous re-encryption of unencrypted content so that it exactly matches with the encrypted data objects protected by the EvidenceRecord.
それは正確にEvidenceRecordで保護暗号化されたデータオブジェクトと一致するようにencryptionInfoは暗号化されていないコンテンツの明確な再暗号化のために必要な情報が含まれています。
Secure Algorithms
セキュアなアルゴリズム
Cryptographic algorithms and parameters that are used within Archive Timestamps must be secure at the time of generation. This concerns the hash algorithm used in the hash lists of Archive Timestamp as well as hash algorithms and public key algorithms of the timestamps. Publications regarding security suitability of cryptographic algorithms ([NIST.800-57-Part1.2006] and [ETSI-TS102176-1-2005]) have to be considered by verifying components. A generic solution for automatic interpretation of security suitability policies in electronic form is desirable but not the subject of this specification.
アーカイブタイムスタンプの中で使用されている暗号化アルゴリズムとパラメータは、生成時に安全でなければなりません。これは、アーカイブタイムスタンプのハッシュリストだけでなく、ハッシュアルゴリズムやタイムスタンプの公開鍵アルゴリズムで使用されるハッシュアルゴリズムに関するものです。暗号アルゴリズムのセキュリティ適性（[NIST.800-57-Part1.2006]および[ETSI-TS102176-1-2005]）に関する刊行物は、成分を確認することによって考慮されなければなりません。電子形式のセキュリティ適合ポリシーを自動的に解釈するための一般的な解決策は、本明細書の主題望ましいができません。
Redundancy
冗長性
Retrospectively, certain parts of an Archive Timestamp may turn out to have lost their security suitability before this has been publicly known. For example, retrospectively, it may turn out that algorithms have lost their security suitability, and that even TSAs are untrustworthy. This can result in Archive Timestamps using those losing their probative force. Many TSAs are using the same signature algorithms. While the compromise of a private key will only affect the security of one specific TSA, the retrospective loss of security of a signature algorithm will have impact on a potentially large number of TSAs at once. To counter such risks, it is recommended to generate and manage at least two redundant Evidence Records with ArchiveTimeStampSequences using different hash algorithms and different TSAs using different signature algorithms.
遡及的に、アーカイブタイムスタンプの特定の部分は、これが公に知られている前に、セキュリティの適合性を失っていると判明することがあります。例えば、遡及的に、それは、アルゴリズムは、セキュリティ適合性を失っていることを、とさえのTSAが信用できないであることをなるかもしれません。これは彼らの証拠力を失ったものを使用してアーカイブタイムスタンプをもたらす可能性があります。多くのTSAは、同じ署名アルゴリズムを使用しています。秘密鍵の妥協点が1つの特定TSAのセキュリティに影響しますが、署名アルゴリズムのセキュリティの回顧損失は一度のTSAの潜在的に大きな数に影響を与えます。このようなリスクに対処するために、異なる署名アルゴリズムを使用して、異なるハッシュアルゴリズムと異なるのTSAを用いArchiveTimeStampSequences有する少なくとも2つの冗長証拠レコードを生成して管理することが推奨されます。
To best achieve and manage this redundancy, it is recommended to manage the Archive Timestamps in a central LTA.
最高のこの冗長性を実現し、管理するためには、中央のLTAにアーカイブタイムスタンプを管理することをお勧めします。
Secure Timestamps
セキュアなタイムスタンプ
Archive Timestamping depends upon the security of normal time stamping. Security requirements for Time Stamping Authorities stated in security policies have to be met. Renewed Archive Timestamps should have the same or higher quality as the initial Archive Timestamp. Archive Timestamps used for signature renewal of signed data, should have the same or higher quality than the maximum quality of the signatures.
アーカイブタイムスタンプは、通常時のスタンプのセキュリティに依存します。セキュリティポリシーに記載されているタイムスタンプ当局のセキュリティ要件が満たされなければなりません。リニューアルアーカイブタイムスタンプは、最初のアーカイブタイムスタンプと同じか、より高い品質を持っている必要があります。署名されたデータの署名更新のために使用されるアーカイブタイムスタンプは、シグネチャの最大品質と同等以上の品質を有するべきです。
Secure Encryption
セキュアな暗号化
For non-repudiation proof, it does not matter whether encryption has been broken or not. Nevertheless, users should keep secret their private keys and randoms used for encryption and disclose them only if needed, e.g., in a lawsuit to a judge or expert. They should use encryption algorithms and parameters that are prospected to be unbreakable as long as confidentiality of the archived data is important.
否認防止の証明のために、暗号化が破られているか否かは問題ではありません。裁判官や専門家への訴訟では、例えば、それにもかかわらず、ユーザーは暗号化に使用される秘密自分の秘密鍵とrandomsを維持する必要があり、必要な場合にのみ、それらを開示しています。彼らは、アーカイブされたデータの機密性が重要である限り、割れないように見込みされている暗号化アルゴリズムとパラメータを使用する必要があります。
[CCITT.X208.1988] International Telephone and Telegraph Consultative Committee, "Specification of Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.208, November 1988.
[CCITT.X208.1988]国際電信電話諮問委員会、「抽象構文記法1（ASN.1）の仕様」、CCITT勧告X.208、1988年11月。
[CCITT.X209.1988] International Telephone and Telegraph Consultative Committee, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.209, 1988.
[CCITT.X209.1988]国際電信電話諮問委員会、CCITT勧告X. 209、1988、「抽象構文記法1（ASN.1）のための基本的な符号化規則の仕様」。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[RFC3161]アダムス、C.、カイン、P.、ピンカス、D.、およびR. Zuccherato、 "インターネットX.509公開鍵インフラストラクチャのタイムスタンププロトコル（TSP）"、RFC 3161、2001年8月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[ANSI.X9-95.2005] American National Standard for Financial Services, "Trusted Timestamp Management and Security", ANSI X9.95, June 2005.
[ANSI.X9-95.2005]金融サービスのための米国標準規格は、ANSI X9.95、2005年6月「タイムスタンプの管理とセキュリティを信頼しました」。
[CCITT.X680.2002] International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", CCITT Recommendation X.680, July 2002.
[CCITT.X680.2002]国際電信電話諮問委員会、「抽象構文記法1（ASN.1）：基本的な表記法の仕様」、CCITT勧告X.680、2002年7月。
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[CCITT.X690.2002]国際電信電話諮問委員会、「ASN.1エンコーディング規則：基本的な符号化規則（BER）、Canonicalの符号化規則（CER）との識別符号化規則（DER）の仕様」、CCITT勧告X.690 、2002年7月。
[ETSI-TS102176-1-2005] European Telecommunication Standards Institute (ETSI), Electronic Signatures and Infrastructures (ESI);, "Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms", ETSI TS 102 176-1 V1.2.1, July 2005.
[ETSI-TS102176-1-2005]欧州電気通信規格協会（ETSI）、電子署名やインフラ（ESI）;,「アルゴリズムと安全な電子署名のためのパラメータ;パート1：ハッシュ関数と非対称アルゴリズム」、ETSI TS 102 176- 1 V1.2.1、2005年7月。
[ISO-18014-1.2002] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1: Framework", ISO ISO-18014-1, February 2002.
[ISO-18014から1.2002] ISO / IEC JTC 1 / SC 27、 "タイムスタンプサービス - 第1部：フレームワーク"、ISO ISO-18014から1、2002年2月。
[ISO-18014-2.2002] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2: Mechanisms producing independent tokens", ISO ISO-18014-2, December 2002.
[ISO-18014から2.2002] ISO / IEC JTC 1 / SC 27、 "タイムスタンプサービス - 第2部：独立したトークンを生成するメカニズム"、ISO ISO-18014から2、2002年12月。
[ISO-18014-3.2004] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3: Mechanisms producing linked tokens", ISO ISO-18014-3, February 2004.
[ISO-18014から3.2004] ISO / IEC JTC 1 / SC 27、 "タイムスタンプサービス - 第3部：リンクされたトークンを生成するメカニズム"、ISO ISO-18014から3、2004年2月。
[MER1980] Merkle, R., "Protocols for Public Key Cryptosystems, Proceedings of the 1980 IEEE Symposium on Security and Privacy (Oakland, CA, USA)", pages 122-134, April 1980.
[MER1980]マークル、R.、 "公開鍵暗号のプロトコル、セキュリティとプライバシー（オークランド、CA、USA）の1980 IEEEシンポジウム"、ページ122から134、1980年4月。
[NIST.800-57-Part1.2006] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revised)", NIST 800-57 Part1, May 2006.
[NIST.800-57-Part1.2006]米国国立標準技術研究所、 "キー管理のための提言 - パート1：一般（改訂）"、NIST 800-57パート1、2006年5月。
[RFC3126] Pinkas, D., Ross, J., and N. Pope, "Electronic Signature Formats for long term electronic signatures", RFC 3126, September 2001.
[RFC3126]ピンカス、D.、ロス、J.、およびN.法王、 "長期電子署名する電子署名フォーマット"、RFC 3126、2001年9月。
[RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term Archive Service Requirements", RFC 4810, March 2007.
[RFC4810]ウォレス、C.、Pordesch、U.、およびR. Brandner、 "長期アーカイブサービスの要件"、RFC 4810、2007年3月。
Appendix A. Evidence Record Using CMS
CMSを使用した付録A.証拠録音
An Evidence Record can be added to signed data or enveloped data in order to transfer them in a conclusive way. For CMS, a sensible place to store such an Evidence Record is an unsigned attribute (signed message) or an unprotected attribute (enveloped message).
証拠レコードは決定的な方法でそれらを転送するために署名されたデータまたはエンベロープデータに付加することができます。 CMSのために、そのような証拠のレコードを格納するための賢明な場所は、符号なし属性（署名されたメッセージ）、または保護されていない属性（エンベロープメッセージ）です。
One advantage of storing the Evidence Record within the CMS structure is that all data can be transferred in one conclusive file and is directly connected. The documents, the signatures, and their Evidence Records can be bundled and managed together. The description in the appendix contains the normative specification of how to integrate ERS in CMS structures.
CMS構造内証拠レコードを格納することの一つの利点は、すべてのデータが1つの決定的ファイルで転送することができ、直接接続されていることです。文書、署名、およびその証拠記録がバンドルと一緒に管理することができます。付録の説明はCMS構造にERSを統合する方法の規範的な仕様が含まれています。
The Evidence Record also contains information about the selection method that was used for the generation of the data objects to be timestamped. In the case of CMS, two selection methods can be distinguished:
証拠レコードはまた、タイムスタンプされるデータオブジェクトの生成に使用された選択方法についての情報を含みます。 CMSの場合は、2つの選択方法を区別することができます。
1. The CMS Object as a whole including contentInfo is selected as data object and archive timestamped. This means that a hash value of the CMS object MUST be located in the first list of hash values of Archive Timestamps.
1. contentInfo含め全体としてCMSオブジェクトは、データオブジェクトとアーカイブタイムスタンプとして選択されます。これは、CMSオブジェクトのハッシュ値がアーカイブタイムスタンプのハッシュ値の最初のリストに配置しなければならないことを意味しています。
2. The CMS Object and the signed or encrypted content are included in the Archive Timestamp as separated objects. In this case, the hash value of the CMS Object as well as the hash value of the content have to be stored in the first list of hash values as a group of data objects.
2. CMSオブジェクトと署名または暗号化されたコンテンツを分離オブジェクトとしてアーカイブ・タイムスタンプに含まれています。この場合、CMSオブジェクトのハッシュ値並びにコンテンツのハッシュ値は、データオブジェクトのグループとしてハッシュ値の最初のリストに格納されなければなりません。
However, other selection methods could also be applied, for instance, as in [RFC3126].
しかしながら、他の選択方法は、[RFC3126]のように、例えば、適用することができます。
In the case of the two selection methods defined above, the Evidence Record has to be added to the first signature of the CMS Object of signed data. Depending on the selection method, the following Object Identifiers are defined for the Evidence Record:
上記で定義された2つの選択方法の場合には、証拠レコードは署名されたデータのCMSオブジェクトの最初の署名に追加されなければなりません。選択方法に応じて、次のオブジェクト識別子は、証拠の録音用に定義されています。
ASN.1 Internal EvidenceRecord Attribute
ASN.1内部EvidenceRecord属性
id-aa-er-internal OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 49 }
ASN.1 External EvidenceRecord Attribute
ASN.1外部EvidenceRecord属性
id-aa-er-external OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 50 }
The attributes SHOULD only occur once. If they appear several times, they have to be stored within the first signature in chronological order.
属性は一度だけ発生する必要があります。彼らは数回表示された場合、彼らは時系列順に最初の署名内に格納する必要があります。
If the CMS object doesn't have the EvidenceRecord Attributes -- which indicates that the EvidenceRecord has been provided externally -- the archive timestamped data object has to be generated over the complete CMS object within the existing coding.
CMSオブジェクトが持っていない場合EvidenceRecord属性 - アーカイブタイムスタンプ付きのデータオブジェクトは、既存のコードの中に完全なCMSオブジェクト上に生成する必要がある - EvidenceRecordは、外部から提供されたことを示しています。
In case of verification, if only one EvidenceRecord is contained in the CMS object, the hash value must be generated over the CMS object without the one EvidenceRecord. This means that the attribute has to be removed before verification. The length of fields containing tags has to be adapted. Apart from that, the existing coding must not be modified.
唯一EvidenceRecordがCMSオブジェクトに含まれている場合、検証の場合には、ハッシュ値は1 EvidenceRecordなしCMSオブジェクト上に生成されなければなりません。これは、属性は、検証前に取り除かなければならないことを意味します。タグを含むフィールドの長さを適合させなければなりません。それとは別に、既存のコードを変更することはできません。
If several Archive Timestamps occur, the data object has to be generated as follows:
いくつかのアーカイブタイムスタンプが発生した場合は、データオブジェクトは、次のように生成することがあります。
o During verification of the first (in chronological order) EvidenceRecord, all EvidenceRecord have to be removed in order to generate the data object.
O証拠レコード（時系列で）最初の検証時に、すべての証拠記録は、データオブジェクトを生成するために除去しなければなりません。
o During verification of the nth one EvidenceRecord, the first n-1 attributes should remain within the CMS object.
O n番目の1 EvidenceRecordの検証時に、最初のn-1の属性は、CMSオブジェクト内のままであるべきです。
o The verification of the nth one EvidenceRecord must result in a point of time when the document must have existed with the first n attributes. The verification of the n+1th attribute must prove that this requirement has been met.
文書は、最初のn個の属性で存在していなければならない時点を生じなければならないEvidenceRecord n番目の一方の検証O。 N + 1番目の属性の検証は、この要件が満たされていることを証明しなければなりません。
Appendix B. ASN.1-Module with 1988 Syntax
1988構文と付録B. ASN.1-モジュール
ASN.1-Module
ASN.1-モジュール
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers88(2) id-mod-ers88-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
- すべてのエクスポート -
IMPORTS
輸入
-- Imports from RFC 3852 Cryptographic Message Syntax ContentInfo, Attribute
- RFC 3852暗号メッセージ構文ContentInfo、属性からの輸入
FROM CryptographicMessageSyntax2004 -- FROM [RFC3852]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
-- Imports from RFC 3280 [RFC3280], Appendix A.1 AlgorithmIdentifier FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) } ;
- RFC 3280 [RFC3280]、付録A.1のAlgorithmIdentifierがPKIX1Explicit88 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）MODからの輸入（ 0）pkix1、明示的な（18）}。
ltans OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) }
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) } ,
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryptionInfo [1] EncryptionInfo OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence
}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
attributes [1] Attributes OPTIONAL,
reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
timeStamp ContentInfo}
PartialHashtree ::= SEQUENCE OF OCTET STRING
Attributes ::= SET SIZE (1..MAX) OF Attribute
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF
ArchiveTimeStampChain
EncryptionInfo ::= SEQUENCE {
encryptionInfoType OBJECT IDENTIFIER,
encryptionInfoValue ANY DEFINED BY encryptionInfoType}
id-aa-er-internal OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 49 }
id-aa-er-external OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 50 }
END
終わり
Appendix C. ASN.1-Module with 1997 Syntax
1997構文と付録C. ASN.1-モジュール
ASN.1-Module
ASN.1-モジュール
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers(1) id-mod-ers-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
- すべてのエクスポート -
IMPORTS
輸入
-- Imports from PKCS-7 ContentInfo FROM PKCS7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-7(7) modules(0)}
- PKCS7 FROM PKCS7 ContentInfoから輸入{ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-7（7）モジュール（0）}
-- Imports from AuthenticationFramework AlgorithmIdentifier FROM AuthenticationFramework {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4}
- AuthenticationFramework FROM AuthenticationFrameworkのAlgorithmIdentifierから輸入{関節イソ - ITU-T DS（5）モジュール（1）authenticationFramework（7）4}
-- Imports from InformationFramework Attribute FROM InformationFramework {joint-iso-itu-t ds(5) module(1) informationFramework(1) 4} ;
- InformationFrameworkから輸入InformationFrameworkから属性{関節イソITU-TのDS（5）モジュール（1）informationFramework（1）4}。
ltans OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) }
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) } ,
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryptionInfo [1] EncryptionInfo OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence
}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute
(WITH COMPONENTS {
...,
valuesWithContext ABSENT
})
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
attributes [1] Attributes OPTIONAL,
reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
timeStamp ContentInfo}
PartialHashtree ::= SEQUENCE OF OCTET STRING
Attributes ::= SET SIZE (1..MAX) OF Attribute
(WITH COMPONENTS {
...,
valuesWithContext ABSENT
})
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF
ArchiveTimeStampChain
EncryptionInfo ::= SEQUENCE {
encryptionInfoType ENCINFO-TYPE.&id
({SupportedEncryptionAlgorithms}),
encryptionInfoValue ENCINFO-TYPE.&Type
({SupportedEncryptionAlgorithms}{@encryptionInfoType})
}
ENCINFO-TYPE ::= TYPE-IDENTIFIER
SupportedEncryptionAlgorithms ENCINFO-TYPE ::= {...}
id-aa-er-internal OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 49 }
id-aa-er-external OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 50 }
米国（840）RSADSI（113549）PKCS（1）pkcs9（9）SMIME（16）ID-AA（2）50}
END
終わり
Authors' Addresses
著者のアドレス
Tobias Gondrom Open Text Corporation Werner-von-Siemens-Ring 20 Grasbrunn, Munich D-85630 Germany
トビアスGondromオープンテキスト社ヴェルナー・フォン・シーメンス・リング20 Grasbrunn、ミュンヘンD-85630ドイツ
Phone: +49 (0) 89 4629-1816 Fax: +49 (0) 89 4629-33-1816 EMail: tobias.gondrom@opentext.com
電話：+49（0）89 4629から1816ファックス：+49（0）89 4629-33-1816 Eメール：tobias.gondrom@opentext.com
Ralf Brandner InterComponentWare AG Industriestra?e 41 Walldorf D-69119 Germany
ラルフBrandner InterComponentWare AG Industriestra？S 41ウォルドルフD-69119ドイツ
EMail: ralf.brandner@intercomponentware.com
メールアドレス：ralf.brandner@intercomponentware.com
Ulrich Pordesch Fraunhofer Gesellschaft Rheinstra?e 75 Darmstadt D-64295 Germany
ウルリッヒPordeschフラウンホーファー研究機構Rheinstra？S 75ダルムシュタットD-64295ドイツ
EMail: ulrich.pordesch@zv.fraunhofer.de
メールアドレス：ulrich.pordesch@zv.fraunhofer.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。