[要約] RFC 4998は、Evidence Record Syntax (ERS)に関する標準仕様であり、デジタル証拠の記録と検証を目的としています。ERSは、証拠の整合性と信頼性を確保するためのデータ構造と手順を提供します。
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)
証拠記録構文（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）The IETF Trust（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.
電子データ交換の多くのアプリケーション領域では、デジタルデータの存在のrepudationできない証明が可能でなければなりません。場合によっては、この証拠は長期間の通過を生き延びなければなりません。重要な例は、デジタル署名データです。デジタル署名を使用して、データの整合性を実証し、ソース認証を実行できます。場合によっては、デジタル署名されたデータを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].
保存証拠を検証および伝達できるようにするには、そのようなタイムスタンプのデータ形式と処理手順を標準化する必要があります。[RFC3126]内のIETFによって最初のアプローチが作成されました。ここでは、暗号化メッセージの構文（CMS）[RFC3852]に従って、署名に統合するためにオプションのアーカイブタイムスタンプ属性が指定されました。
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）に従って、署名された包括的なメッセージと包括的なメッセージのコンテキストでの証拠の統合と使用について説明します。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に準拠したタイムスタンプが行うように）、またはデータオブジェクトのグループをカバーできます。データオブジェクトのグループは、最初にMerkle [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は、アーカイブタイムスタンプの更新のための2つの方法を区別します：タイムスタンプの更新とハッシュツリーの更新。
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.
アーカイブタイムスタンプは、このデータオブジェクトのハッシュ値がアーカイブタイムスタンプの最初のハッシュ値リストの一部である場合、データオブジェクトに関連しています。アーカイブタイムスタンプは、グループのすべてのデータオブジェクトと他のデータオブジェクトがない場合、データオブジェクトグループに関連しています。アーカイブタイムスタンプチェーンは、最初のアーカイブタイムスタンプがこのデータオブジェクト /データオブジェクトグループに関連する場合、データオブジェクト /データオブジェクトグループに関連しています。アーカイブタイムスタンプシーケンスは、最初のアーカイブタイムスタンプチェーンがこのデータオブジェクト /データオブジェクトグループに関連する場合、データオブジェクト /データオブジェクトグループに関連しています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.x208.1988]、[ccitt.x209.1988]、[ccitt.x680.2002]、[ccitt.x690.2002]を参照してください。）この仕様は2つのasn.1を定義します。モジュール、1つは1988年のASN.1に適合し、もう1つは1997-ASN.1構文に準拠しています。コンパイラの実装の構文バージョンに応じて、1988年のコンフォーマントASN.1構文のインポートまたは1997-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構文バージョンに応じて、1988年のコンフフォームASN.1構文のインポートまたはセクション2.2.2の1997-ASN.1構文のインポートを使用できます。
-- 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) }
-- 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) }
;
-- 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)}
-- Imports from AuthenticationFramework AlgorithmIdentifier FROM AuthenticationFramework {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4}
-AuthenticationFrameworkからのインポートAuthenticationFramework {Joint-Iso-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属性からのインポート{Joint-ISO-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.
消化器gorthmsは、アーカイブ期間中にデータオブジェクトをハッシュするために使用されるすべてのハッシュアルゴリズムのシーケンスです。これは、Evidencerecordに含まれるArchiveTimestampsからのすべての消化器gorthmの値の結合です。値の順序は関連していません。
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を使用すると、ArchiveTimestamp sequenceの検証に役立つデータの保存が可能になります。これには、可能な信頼アンカー、証明書、取り消し情報、または過去と現在の暗号化アルゴリズムの適合性の現在の定義が含まれます（例：1998年まで有効なRSA 768ビット、2008年まで有効なRSA 1024ビット、SHA1有効2010年まで有効）。これらの項目は、使用されるポリシーに基づいて追加される場合があります。このデータはタイムスタンプ内で保護されていないため、データは他のメカニズムを通じて検証可能である必要があります。このような検証は、このドキュメントの範囲外です。
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.
ArchiveTimestampのシーケンスは、セクション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.
アーカイブデータオブジェクトがアーカイブタイムスタンプを生成する前に暗号化されたが、暗号化されていないデータオブジェクトには非繰り返しの証明が必要な場合、オプションの暗号化infosフィールドには、データオブジェクトを明確に再暗号化するために必要なデータが含まれます。省略すると、データオブジェクトが暗号化されていないこと、または暗号化されていないデータの非repudiation証明が不要であることを意味します。詳細については、セクション6を参照してください。
The generation of an EvidenceRecord can be described as follows:
evidencerecordの生成は、次のように説明できます。
1. Select a data object or group of data objects to archive.
1. アーカイブするデータオブジェクトまたはデータオブジェクトのグループを選択します。
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全体の検証は、次のように説明できます。
1. Select an archived data object or group of data objects
1. アーカイブされたデータオブジェクトまたはデータオブジェクトのグループを選択します
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のフィールドには、次の意味があります。消化器gorityは、Digestアルゴリズムと、還元されたハッシュツリー内で使用される関連パラメーターを識別します。オプションのフィールド消化器gorthmが存在しない場合、タイムスタンプのダイジェストアルゴリズムを使用する必要があります。つまり、この場合、[RFC3161]に従ってタイムスタンプが使用されている場合、このフィールドの内容は、TSTINFOのMessageImprintフィールドのハスハルゴリズムと同一です。
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が個々の更新ステップと個々のアーキベティメスタンプの作成を文書化するために提供する可能性のある情報が含まれています。ArchiveTimestampの構造はハッシュおよびタイムスタンプによって保護される可能性があるため、順序は関連しているため、シーケンスの代わりにセットが使用されます。
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.
reductionhashtreeには、理解しやすくするためにpartialhashtreeで編成されたハッシュ値のリストが含まれています。これらは、単一のデータオブジェクトを検証するために必要なノードにハッシュツリーを減らすことで導出できます。ハッシュ値は、オクテット弦として表されます。オプションのフィールドreductionhashtreeが存在しない場合、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:
このようなハッシュツリーは、次のように構築できます。
1. Collect data objects to be timestamped.
1. データオブジェクトを収集して、タイムスタンプになります。
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の消化器gortimフィールドが存在し、ハッシュツリーのハッシュアルゴリズムを指定する必要があります。
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))
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.
2. hと同じ父ノードを持つすべてのハッシュ値を選択します。これらのハッシュをバイナリの昇順で配置することにより、ハッシュ値の最初のリストを生成します。これは、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. すべてのPartialHashtreeのリストは、最終的にRedumenthashtreeです。（下のノードの父ノードを除く、同じ父ノードの下で指定されたハッシュ値はすべて、部分的なハシュトリーにグループ化されています。すべてのPartialHashtreeのシーケンスリストは、Redumenthashtreeです。）
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.
注意してください。ハッシュ値リストの量または長さに制限はありません。また、それは収益性がありますが、ハッシュツリーを構築して削減するために必要ではないことに注意してください。アーカイブタイムスタンプは、ハッシュ値とタイムスタンプの1つのリスト、またはハッシュ値リストのないタイムスタンプのみで構成されている場合があります。
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.
タイムスタンプを確認するために必要なデータ（証明書、証明書の取り消しリスト（CRLS）、またはオンライン証明書ステータスプロトコル（OCSP）応答）は保存する必要があり、これが不必要な重複を引き起こさない限りタイムスタンプ自体に保存する必要があります。[RFC3161]によるタイムスタンプは、証明書フィールドに証明書を保存できるCMSオブジェクトであり、CRLSは署名データのCRLSフィールドに保存できます。OCSP応答は、符号なし属性[RFC3126]として保存できます。注[ansi.x9-95.2005]、[ISO-18014-2.2002]、および[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. アーカイブタイムスタンプのフィールド消化器gorithmで与えられたハッシュアルゴリズムhを使用して、データオブジェクトのハッシュ値Hを計算します。
2. Search for hash value h in the first list (partialHashtree) of reducedHashtree. If not present, terminate verification process with negative result.
2. reductionhashtreeの最初のリスト（partialhashtree）でハッシュ値hを検索します。存在しない場合は、否定的な結果で検証プロセスを終了します。
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 'を計算します。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]によるとタイムスタンプの場合、ルートハッシュ値はハッシュメッセージに対応する必要があり、消化器gorthmは、TimestAmptokenのMessageImprintフィールドの両方でハスハルゴリズムフィールドに対応する必要があります。他のタイムスタンプ形式の場合、ハッシュ値と消化器gorthmは、存在する場合は同等のフィールドにも対応する必要があります。
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を実行する必要があります。アーカイブタイムスタンプがデータオブジェクトグループ（例：ドキュメントとそのすべての署名）に関連することを追加の証明が必要な場合、指定されたデータオブジェクトのハッシュ値のみが最初のハッシュ値にあることをさらに検証できます。リスト。
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.
アーカイブタイムスタンプは、特定の時間に単一のデータオブジェクトまたはデータオブジェクトグループの存在を証明します。ただし、ハッシュツリーまたはタイムスタンプで使用されているハッシュアルゴリズムまたは公開キーアルゴリズムが弱くなった場合、またはタイムスタンプ当局証明書の有効期間が期限切れになった場合、または取り消された場合、最初のアーキベティメスタンプチェーンのこの最初のアーカイブタイムスタンプは無効になる可能性があります。
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 タイムスタンプの更新：古いもののタイムスタンプをカバーする新しいアーカイブタイムスタンプが生成されます。タイムスタンプの更新によって生成された1つ以上のアーカイブタイムスタンプは、データオブジェクトまたはデータオブジェクトグループのアーカイブタイムスタンプチェーンを生成します。
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とArchivetimestampameの順序には、次のASN.1構文があります。
ASN.1 ArchiveTimeStampChain and ArchiveTimeStampSequence
asn.1 ArchivetimestampchainおよびArchivetimestamp sequence
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とArchivetimestampの順序は、タイムスタンプの時間までに上昇するように命じなければなりません。ArchiveTimestampchain内では、含まれているArchiveTimestampのすべてが同じハッシュアルゴリズムを使用する必要があります。
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.
初期アーカイブタイムスタンプは、データオブジェクトまたはデータオブジェクトグループに関連しています。最新のアーカイブタイムスタンプ内で使用される暗号化アルゴリズム（最初は、最初のもの）が弱くなるか、タイムスタンプ証明書が無効になります。アーカイブタイムスタンプは、新しいアーカイブタイムスタンプを生成することで更新する必要があります。
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.
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に追加する必要があります。新しいアーカイブタイムスタンプのこのハッシュツリーは、古いアルゴリズムと同じハッシュアルゴリズムを使用する必要があります。古いアルゴリズムは、アーカイブタイムスタンプの消化器gortimフィールドで指定されているか、この値が設定されていない場合（オプションであるため）、タイムスタンプ自体内にあります。
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:
ハッシュツリーの更新の場合、アーカイブタイムスタンプとアーカイブタイムスタンプで覆われたアーカイブされたデータオブジェクトは、以下に説明するように、再びハッシュしてタイムスタンプする必要があります。
1. Select a secure hash algorithm H.
1. 安全なハッシュアルゴリズムHを選択します。
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）、h（i_b）があります。）..、h（i_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）は、データオブジェクトD（I）に関連する以前のすべてのアーカイブタイムスタンプチェーン（時系列）の連結である、エンコードされたアーキベティメスタンプシーケンスです。ハッシュ値ha（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.
4. 各h（i）をHA（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. 各h（i）の新しいアーカイブタイムスタンプを構築します。（ハッシュツリーの生成と還元はセクション4.2で定義されています。各H（i） 'はセクション4.2でドキュメントハッシュとして扱われることに注意してください。減少したハッシュツリーの最初のハッシュ値リストには、H（i）のみを含む必要があります。。マルチドキュメントグループの場合、最初のハッシュ値リストには、このグループのすべてのドキュメントの新しいハッシュ、つまりh（i_a） '、h（i_b）' ..、h（i_n） '）が含まれます。
6. Create new ArchiveTimeStampChain containing the new Archive Timestamp and append this ArchiveTimeStampChain to the ArchiveTimeStampSequence.
6. 新しいアーカイブタイムスタンプを含む新しいArchivetimestampchainを作成し、このアーキベティメスタンプチェーンを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
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)))
h2abc = H( binary sorted and concatenated (h2a', h2b', h2c'))
H2ABC = H（バイナリソート付きおよび連結（H2A '、H2B'、H2C '））
ArchiveTimeStamps that are not necessary for verification should not be added to an ArchiveTimeStampChain or 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.
データオブジェクトが特定の時間に存在するという非repudiationの証明を取得するには、アーカイブタイムスタンプチェーンと互いにその関係とデータオブジェクトとの関係を証明する必要があります。1。最初のアーキベティメスタンプチェーンの最初のアーカイブタイムスタンプを確認する（初期アーカイブタイムスタンプ）には、データオブジェクトのハッシュ値が含まれています。
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の最初のハッシュ値リストには、アーカイブタイムスタンプのタイムスタンプのハッシュ値が含まれている必要があります。各アーカイブタイムスタンプは、次のアーカイブタイムスタンプの時間に対して有効でなければなりません。チェーン内のすべてのアーカイブタイムスタンプは、同じハッシュアルゴリズムを使用する必要があり、このアルゴリズムは、次のArchiveTamestampchainの最初のアーカイブタイムスタンプの時点で安全でなければなりません。
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. 他のすべてのArchiveTamestampchainsの最初のアーカイブタイムスタンプの最初のハッシュ値（PartialHashtree）には、データオブジェクトのハッシュの連結とすべての古いArchivetimestampchainのハッシュ値のハッシュ値が含まれていることを確認します。このアーカイブタイムスタンプが、ArchiveTamestampchainの最後のアーカイブタイムスタンプが無効になる前に生成されたことを確認します。
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を実行する必要があります。アーカイブタイムスタンプシーケンスがデータオブジェクトグループに関連することを証明するために、各データオブジェクトのアーキベチメスタンプの最初のアーキベティメスタンプチェーンの最初のアーカイブタイムスタンプが、最初のハッシュ値リストに他のハッシュ値が含まれていないことを確認します（他のハッシュ値よりも他のハッシュ値よりもデータオブジェクト）。
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.
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が同じ署名アルゴリズムを使用しています。秘密鍵の妥協は、特定のTSAのセキュリティにのみ影響しますが、署名アルゴリズムのセキュリティの遡及的損失は、潜在的に多数のTSAに一度に影響を与えます。このようなリスクに対抗するには、異なるハッシュアルゴリズムと異なる署名アルゴリズムを使用して、異なるハッシュアルゴリズムと異なるTSAを使用して、少なくとも2つの冗長証拠レコードをArchiveTimestampAckenceを使用して生成および管理することをお勧めします。
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.
非繰り返しの証明の場合、暗号化が壊れているかどうかは関係ありません。それにもかかわらず、ユーザーは、暗号化に使用されるプライベートキーやランダムを秘密に保ち、必要に応じて、たとえば裁判官や専門家への訴訟でのみ開示する必要があります。アーカイブされたデータの機密性が重要である限り、壊れないように吸引される暗号化アルゴリズムとパラメーターを使用する必要があります。
[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]国際電話および電信協議委員会、「抽象的構文表記の仕様（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]国際電話および電信協議委員会、「抽象的構文表記1（asn.1）の基本エンコーディングルールの仕様」、CCITT推奨X.209、1988。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「Internet 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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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）、標準エンコードルール（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] Merkle、R。、「公開キークリプトシステムのプロトコル、1980年のIEEE Symposium on Security and Privacy（米国カリフォルニア州オークランド）の議事録」、1980年4月122〜134ページ。
[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 PART1、2006年5月。
[RFC3126] Pinkas, D., Ross, J., and N. Pope, "Electronic Signature Formats for long term electronic signatures", RFC 3126, September 2001.
[RFC3126] Pinkas、D.、Ross、J。、およびN. Pope、「長期電子署名用の電子署名形式」、RFC 3126、2001年9月。
[RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term Archive Service Requirements", RFC 4810, March 2007.
[RFC4810] Wallace、C.、Pordesch、U.、およびR. Brandner、「長期アーカイブサービス要件」、RFC 4810、2007年3月。
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つの利点は、すべてのデータが1つの決定的なファイルで転送され、直接接続されることです。ドキュメント、署名、およびそれらの証拠記録をバンドルして一緒に管理することができます。付録の説明には、CMS構造にERを統合する方法の規範的な仕様が含まれています。
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属性がない場合 - これは、evidencerecordが外部から提供されていることを示しています。アーカイブタイムスタンプ付きデータオブジェクトは、既存のコーディング内の完全なCMSオブジェクトで生成する必要があります。
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.
検証の場合、CMSオブジェクトに1つのevidencerecordのみが含まれている場合、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 最初の（時系列の）evidencerecordの検証中に、データオブジェクトを生成するためにすべてのevidencerecordを削除する必要があります。
o During verification of the nth one EvidenceRecord, the first n-1 attributes should remain within the CMS object.
o nth one 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.
o nth one evidencerecordの検証は、最初のn属性とともにドキュメントが存在していたに違いない時点にならなければなりません。N 1番目の属性の検証は、この要件が満たされていることを証明する必要があります。
ASN.1-Module
asn.1-module
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) }
;
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}
encryptionInfotypeオブジェクト識別子、encryptionInfovalue exryptionInfotype}で定義されています}
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
終わり
ASN.1-Module
asn.1-module
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)}
-- Imports from AuthenticationFramework AlgorithmIdentifier FROM AuthenticationFramework {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4}
-AuthenticationFrameworkからのインポートAuthenticationFramework {Joint-Iso-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属性からのインポート{Joint-ISO-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 }
END
終わり
Authors' Addresses
著者のアドレス
Tobias Gondrom Open Text Corporation Werner-von-Siemens-Ring 20 Grasbrunn, Munich D-85630 Germany
Tobias Gondrom Open Text Corporation werner-von-siemens-ring 20 grasbrunn、ミュンヘンD-85630ドイツ
Phone: +49 (0) 89 4629-1816
Fax: +49 (0) 89 4629-33-1816
EMail: tobias.gondrom@opentext.com
Ralf Brandner InterComponentWare AG Industriestra?e 41 Walldorf D-69119 Germany
RALF Brandner Intercomponentware Ag Industriestra？E 41 Walldorf D-69119ドイツ
EMail: ralf.brandner@intercomponentware.com
Ulrich Pordesch Fraunhofer Gesellschaft Rheinstra?e 75 Darmstadt D-64295 Germany
Ulrich Pordesch Fraunhofer Gesellschaft Rheinstra？e 75 Darmstadt D-64295ドイツ
EMail: ulrich.pordesch@zv.fraunhofer.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。