[要約] RFC 6283は、XMLERSの構文と目的について説明しています。XMLERSは、証拠記録のための拡張可能なマークアップ言語であり、デジタル証拠の収集と保存を容易にすることを目的としています。
Internet Engineering Task Force (IETF) A. Jerman Blazic
Request for Comments: 6283 S. Saljic
Category: Standards Track SETCCE
ISSN: 2070-1721 T. Gondrom
July 2011
Extensible Markup Language Evidence Record Syntax (XMLERS)
拡張可能なマークアップ言語の証拠レコード構文（xmlers）
Abstract
概要
In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non-repudiation of existence and integrity of data. The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML.
多くのシナリオでは、ユーザーは、長期または未確定期間にわたって署名されたデータを含むデータの存在、整合性、および妥当性を（時間の）（時間）実証できる必要があります。このドキュメントは、XMLの構文と処理ルールを指定し、データの存在と完全性の長期的な非和解の証拠を作成します。拡張可能なマークアップ言語の証拠レコード構文XMLERSは、XMLを使用してASN.1（抽象的構文表記1）（エビデンスレコード構文）（RFC 4998）構文に代替の構文と処理ルールを提供します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6283.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6283で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. General Overview and Requirements ..........................4
1.3. Terminology ................................................6
1.4. Conventions Used in This Document ..........................7
2. Evidence Record .................................................7
2.1. Structure ..................................................8
2.2. Generation ................................................12
2.3. Verification ..............................................13
3. Archive Time-Stamp .............................................13
3.1. Structure .................................................13
3.1.1. Hash Tree ..........................................13
3.1.2. Time-Stamp .........................................14
3.1.3. Cryptographic Information List .....................15
3.2. Generation ................................................16
3.2.1. Generation of Hash Tree ............................17
3.2.2. Reduction of Hash Tree .............................19
3.3. Verification ..............................................21
4. Archive Time-Stamp Sequence and Archive Time-Stamp Chain .......22
4.1. Structure .................................................23
4.1.1. Digest Method ......................................23
4.1.2. Canonicalization Method ............................24
4.2. Generation ................................................25
4.2.1. Time-Stamp Renewal .................................25
4.2.2. Hash Tree Renewal ..................................26
4.3. Verification ..............................................27
5. Encryption .....................................................28
6. Version ........................................................29
7. Storage of Policies ............................................30
8. XSD Schema for the Evidence Record .............................30
9. Security Considerations ........................................34
9.1. Secure Algorithms .........................................34
9.2. Redundancy ................................................34
9.3. Secure Time-Stamps ........................................35
9.4. Time-Stamp Verification ...................................35
10. IANA Considerations ...........................................36
11. References ....................................................37
11.1. Normative References .....................................37
11.2. Informative References ...................................39
Appendix A. Detailed Verification Process of an Evidence Record ...41
The purpose of the document is to define XML schema and processing rules for Evidence Record Syntax in XML (Extensible Markup Language) format. The document is related to initial ASN.1 (Abstract Syntax Notation One) syntax for Evidence Record Syntax as defined in [RFC4998].
ドキュメントの目的は、XML（拡張可能なマークアップ言語）形式で構文を記録する証拠のためのXMLスキーマと処理ルールを定義することです。ドキュメントは、[RFC4998]で定義されているように、初期asn.1（要約構文表記1）に関連しています。
The evolution of electronic commerce and electronic data exchange in general requires introduction of non-repudiable proof of data existence as well as data integrity and authenticity. Such data and non-repudiable proof of existence must endure for long periods of time, even when the initial information to prove its existence and integrity weakens or ceases to exist. Mechanisms such as digital signatures defined in [RFC5652], for example, do not provide absolute reliability on a long-term basis. Algorithms and cryptographic material used to create a signature can become weak in the course of time, and information needed to validate digital signatures may become compromised or simply cease to exist, for example, due to the disbanding of a certificate service provider. Providing a stable environment for electronic data on a long-term basis requires the introduction of additional means to continually provide an appropriate level of trust in evidence on data existence, integrity, and authenticity.
一般に、電子商取引と電子データ交換の進化には、データの統合と信頼性だけでなく、データの存在の繰り返しのない証明を導入する必要があります。そのようなデータと繰り返されない存在の証明は、その存在と完全性が弱くなったり存在しなくなったりするための初期情報が存在することを証明する場合でも、長期間耐えなければなりません。たとえば、[RFC5652]で定義されているデジタル署名などのメカニズムは、長期的に絶対的な信頼性を提供しません。署名を作成するために使用されるアルゴリズムと暗号化資料は、時間の経過とともに弱くなる可能性があり、デジタル署名を検証するために必要な情報は、たとえば、証明書サービスプロバイダーの解散により、侵害されるか、単に存在しなくなる可能性があります。長期的に電子データに安定した環境を提供するには、データの存在、完全性、および信頼性に関する証拠に適切なレベルの信頼を継続的に提供するための追加手段を導入する必要があります。
All integrity and authenticity protecting techniques used today suffer from the problem of degrading reliability over time, including techniques for Time-Stamping, which are generally recognized as data existence and integrity proof mechanisms. Over long periods of time cryptographic algorithms used may become weak or encryption keys compromised. Some of the problems might not even be of technical nature like a Time-Stamping Authority going out of business and ceasing its service. To create a stable environment where proof of existence and integrity can endure well into the future a new technical approach must be used.
今日使用されているすべての整合性と信頼性保護技術は、一般的にデータの存在と完全性の証明メカニズムとして認識されるタイムスタンプの技術を含む、時間の経過とともに信頼性を低下させる問題に悩まされています。使用される長期にわたって暗号化アルゴリズムが弱くなったり、暗号化キーが侵害されたりする可能性があります。いくつかの問題は、タイムスタンプ当局が廃業し、そのサービスを停止するような技術的な性質でさえないかもしれません。存在と完全性の証拠が未来に耐えることができる安定した環境を作成するには、新しい技術的アプローチを使用する必要があります。
Long-term non-repudiation of data existence and demonstration of data integrity techniques have been already introduced, for example, by long-term signature syntaxes like those defined in [RFC5126]. Long-term signature syntaxes and processing rules address only the long-term endurance of the digital signatures themselves, while Evidence Record Syntax broadens this approach for data of any type or format including digital signatures.
データの存在とデータの整合性技術のデモの長期的な非和解は、たとえば[RFC5126]で定義されているような長期的な署名構文によってすでに導入されています。長期的な署名の構文と処理ルールは、デジタル署名自体の長期的な持久力のみに対処しますが、証拠記録の構文は、デジタル署名を含むあらゆるタイプまたは形式のデータに対してこのアプローチを広げます。
XMLERS (Extensible Markup Language Evidence Record Syntax) is based on Evidence Record Syntax as defined in [RFC4998] and is addressing the same problem of long-term non-repudiable proof of data existence and demonstration of data integrity on a long-term basis. XMLERS does not supplement the [RFC4998] specification. Following extensible markup language standards and [RFC3470] guidelines it introduces the same approach but in a different format and with adapted processing rules.
XMLERS（拡張可能なマークアップ言語証拠レコードの構文）は、[RFC4998]で定義されている証拠レコード構文に基づいており、長期的なデータの存在とデータの完全性のデモンストレーションの長期的な非繰り返しの証明という同じ問題に対処しています。Xmlersは[RFC4998]仕様を補完しません。拡張可能なマークアップ言語標準と[RFC3470]ガイドラインに従って、同じアプローチを導入しますが、異なる形式で、処理ルールが適応されます。
The use of Extensible Markup Language (XML) format is already recognized by a wide range of applications and services and is being selected as the de facto standard for many applications based on data exchange. The introduction of Evidence Record Syntax in XML format broadens the horizon of XML use and presents a harmonized syntax with a growing community of XML-based standards including those related to security services such as [XMLDSig] or [XAdES].
拡張可能なマークアップ言語（XML）形式の使用は、幅広いアプリケーションとサービスによってすでに認識されており、データ交換に基づく多くのアプリケーションの事実上の標準として選択されています。XML形式で証拠を記録する構文の導入は、XMLの使用の地平線を広げ、[XMLDSIG]や[Xades]などのセキュリティサービスに関連するXMLベースの標準の成長するコミュニティと調和した構文を提示します。
Due to the differences in XML processing rules and other characteristics of XML, XMLERS does not present a direct transformation of ERS in ASN.1 syntax. XMLERS is based on different processing rules as defined in [RFC4998] and it does not support, for example, the import of ASN.1 values in XML tags. Creating Evidence Records in XML syntax must follow the steps as defined in this document. XMLERS is a standalone document and is based on [RFC4998] conceptually only. The content of this document provides enough information for implementation of Evidence Record Syntax (represented in XML format). References to [RFC4998] are for informative purposes only.
XML処理ルールの違いとXMLのその他の特性のため、XMLersはASN.1構文におけるERSの直接的な変換を提示しません。XMLERSは、[RFC4998]で定義されているさまざまな処理ルールに基づいており、たとえばXMLタグのASN.1値のインポートをサポートしていません。XML構文で証拠レコードを作成すると、このドキュメントで定義されている手順に従う必要があります。Xmlersはスタンドアロンのドキュメントであり、[RFC4998]概念的にのみに基づいています。このドキュメントの内容は、証拠記録構文（XML形式で表される）の実装に十分な情報を提供します。[RFC4998]への参照は、有益な目的のみを目的としています。
Evidence Record Syntax in XML format is based on long-term archive service requirements as defined in [RFC4810]. XMLERS delivers the same (level of) non-repudiable proof of data existence as ASN.1 ERS [RFC4998]. The XML syntax supports archive data grouping (and de-grouping) together with simple or complex Time-Stamp renewal processes. Evidence Records can be embedded in the data itself or stored separately as a standalone XML file.
XML形式の証拠記録構文は、[RFC4810]で定義されている長期アーカイブサービス要件に基づいています。Xmlersは、ASN.1 ERS [RFC4998]と同じデータの存在の非控除不可能な証明を提供します。XML構文は、単純または複雑なタイムスタンプ更新プロセスとともに、アーカイブデータグループ（およびグループ化）をサポートしています。エビデンスレコードは、データ自体に埋め込むか、スタンドアロンXMLファイルとして個別に保存することができます。
XMLERS specifies the XML syntax and processing rules for creating evidence for the long-term non-repudiation of existence and integrity of data in a unit called the "Evidence Record". XMLERS is defined to meet the requirements for data structures as set out in [RFC4810]. This document also refers to the ASN.1 ERS specification as defined in [RFC4998].
XMLERSは、「エビデンスレコード」と呼ばれるユニット内のデータの存在と完全性の長期的な非和解の証拠を作成するためのXML構文と処理ルールを指定します。Xmlersは、[RFC4810]に記載されているデータ構造の要件を満たすために定義されています。このドキュメントは、[RFC4998]で定義されているASN.1 ERS仕様も参照しています。
An Evidence Record may be generated and maintained for a single data object or a group of data objects that form an archive object. A data object (binary chunk or a file) may represent any kind of document or part of it. Dependencies among data objects, their validation, or any other relationship than "a data object is a part of particular archived object" are outside the scope of this document.
証拠レコードは、単一のデータオブジェクトまたはアーカイブオブジェクトを形成するデータオブジェクトのグループに対して生成および維持される場合があります。データオブジェクト（バイナリチャンクまたはファイル）は、あらゆる種類のドキュメントまたはその一部を表す場合があります。データオブジェクト、それらの検証、または「データオブジェクトは特定のアーカイブオブジェクトの一部」以外の関係間の依存関係は、このドキュメントの範囲外です。
Evidence Record is closely related to Time-Stamping techniques. However, Time-Stamps as defined in [RFC3161] can cover only a single unit of data and do not provide processing rules for maintaining a long-term stability of Time-Stamps applied over a data object. Evidence for an archive object is created by acquiring a Time-Stamp from a trustworthy authority for a specific value that is unambiguously related to a single or more data objects. Relationship between several data objects and a single Time-Stamped value is addressed using a hash tree, a technique first described by Merkle [MER1980] and later in [RFC4998], with data structures and procedures as specified in this document. The Evidence Record Syntax enables processing of several archive objects within a single processing pass using a hash tree technique and acquiring only one Time-Stamp to protect all archive objects. The leaves of the hash tree are hash values of the data objects in a group. A Time-Stamp 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 Time-Stamps are comprised of an optional reduced hash tree and a Time-Stamp.
証拠記録は、タイムスタンピング技術に密接に関連しています。ただし、[RFC3161]で定義されているタイムスタンプは、単一のデータのみをカバーでき、データオブジェクトに適用されるタイムスタンプの長期的な安定性を維持するための処理ルールを提供しません。アーカイブオブジェクトの証拠は、単一のデータオブジェクトに明確に関連する特定の価値のために、信頼できる権限からタイムスタンプを取得することにより作成されます。いくつかのデータオブジェクトと単一のタイムスタンプ値との関係は、ハッシュツリーを使用してアドレス指定されます。これは、Merkle [Mer1980]によって最初に記述され、後に[RFC4998]で説明され、このドキュメントで指定されているデータ構造と手順を使用します。証拠記録構文により、ハッシュツリーテクニックを使用して単一の処理パス内で複数のアーカイブオブジェクトを処理し、すべてのアーカイブオブジェクトを保護するために1つのタイムスタンプのみを取得できます。ハッシュツリーの葉は、グループ内のデータオブジェクトのハッシュ値です。ハッシュツリーのルートハッシュにのみタイムスタンプが要求されます。ツリー内のデータオブジェクトの削除は、他者の提供性に影響しません。特定のデータオブジェクトでは、ハッシュツリーを数回のハッシュ値セットに縮小できます。これは、単一のデータオブジェクトの存在を証明するのに十分です。同様に、データグループのすべてのメンバーがハッシュツリーに同じ親ノードを持っている場合、ハッシュツリーをデータグループの存在を証明するために縮小することができます。アーカイブタイムスタンプは、オプションの縮小ハッシュツリーとタイムスタンプで構成されています。
Besides a Time-Stamp other artifacts are also preserved in Evidence Record: data necessary to verify the relationship between a time-stamped value and a specific data object, packed into a structure called a "hash tree", and long-term proofs for the formal verification of the included Time-Stamp(s).
タイムスタンプに加えて、他のアーティファクトは証拠記録にも保存されています：タイムスタンプの値と特定のデータオブジェクトの関係を検証するために必要なデータ、「ハッシュツリー」と呼ばれる構造、および付属のタイムスタンプの正式な検証。
Because digest algorithms or cryptographic methods used may become weak or certificates used within a Time-Stamp (and signed data) may be revoked or expire, the collected evidence data must be monitored and renewed before such events occur. This document introduces XML-based syntax and processing rules for the creation and continuous renewal of evidence data.
使用されるダイジェストアルゴリズムまたは暗号化方法は弱くなるか、タイムスタンプ内で使用される証明書（および署名データ）が取り消されたり期限切れになったりする可能性があるため、収集された証拠データは、そのようなイベントが発生する前に監視および更新する必要があります。このドキュメントでは、証拠データの作成と継続的な更新に関するXMLベースの構文と処理ルールを紹介します。
Archive Data Object: An archive data object is a data unit that is archived and has to be preserved for a long time by the long-term archive service.
アーカイブデータオブジェクト：アーカイブデータオブジェクトは、アーカイブされたデータユニットであり、長期的なアーカイブサービスによって長時間保存する必要があります。
Archive Data Object Group: An archive data object group is a set of archive data objects that, for some reason, (logically) belong together; e.g., a group of document files or a document file and a signature file could represent an archive data object group.
アーカイブデータオブジェクトグループ：アーカイブデータオブジェクトグループは、何らかの理由で（論理的に）一緒に属するアーカイブデータオブジェクトのセットです。たとえば、ドキュメントファイルのグループまたはドキュメントファイルと署名ファイルは、アーカイブデータオブジェクトグループを表すことができます。
Archive Object (AO): An AO is an archive data object or an archive data object group.
アーカイブオブジェクト（AO）：AOは、アーカイブデータオブジェクトまたはアーカイブデータオブジェクトグループです。
Archive Time-Stamp (ATS): An ATS contains a Time-Stamp Token, useful data for validation, and optionally a set of ordered lists of hash values (a hash tree). An Archive Time-Stamp relates to a data object if the hash value of this data object is part of the first hash value list of the Archive Time-Stamp or its hash value matches the Time-Stamped value. An Archive Time-Stamp relates to a data object group if it relates to every data object of the group and no other data object (i.e., the hash values of all but no other data objects of the group are part of the first hash value list of the Archive Time-Stamp) (see Section 3).
アーカイブタイムスタンプ（ATS）：ATSには、タイムスタンプトークン、検証のための有用なデータ、およびオプションではハッシュ値（ハッシュツリー）の順序付けリストのセットが含まれています。アーカイブタイムスタンプは、このデータオブジェクトのハッシュ値がアーカイブタイムスタンプの最初のハッシュ値リストの一部である場合、またはそのハッシュ値がタイムスタンプの値と一致する場合、データオブジェクトに関連します。アーカイブタイムスタンプは、グループのすべてのデータオブジェクトと他のデータオブジェクトがない場合にデータオブジェクトグループに関連しています（つまり、グループの他のデータオブジェクトを除くすべてのハッシュ値は、最初のハッシュ値リストの一部ではありませんアーカイブタイムスタンプの）（セクション3を参照）。
Archive Time-Stamp Chain (ATSC): An ATSC holds a sequence of Archive Time-Stamps generated during the preservation period.
アーカイブタイムスタンプチェーン（ATSC）：ATSCは、保存期間中に生成された一連のアーカイブタイムスタンプを保持します。
Archive Time-Stamp Sequence (ATSSeq): AN ATSSeq is a sequence of Archive Time-Stamp Chains.
アーカイブタイムスタンプシーケンス（ATSSEQ）：ATSSEQは、アーカイブタイムスタンプチェーンのシーケンスです。
Canonicalization: Canonicalization refers to processing rules for transforming an XML document into its canonical form. Two XML documents may have different physical representations, but they may have the same canonical form. For example, a sort order of attributes does not change the meaning of the document as defined in [XMLC14N].
標準化：標準化とは、XMLドキュメントを標準形式に変換するための処理ルールを指します。2つのXMLドキュメントには異なる物理的表現がある場合がありますが、同じ標準的な形式がある場合があります。たとえば、[XMLC14N]で定義されているドキュメントの意味を変えることはありません。
Cryptographic Information: Cryptographic information is data or part of data related to the validation process of signed data, e.g., digital certificates, digital certificate chains, and Certificate Revocation Lists.
暗号化情報：暗号化情報は、署名されたデータ、デジタル証明書、デジタル証明書チェーン、証明書の取り消しリストの検証プロセスに関連するデータまたはデータの一部です。
Digest Method: Digest method is a digest algorithm, which is a strong one-way function, for which it is computationally infeasible to find an input that corresponds to a given output or to find two different input values that correspond to the same output. A digest algorithm transforms input data into a short value of fixed length. The output is called digest value, hash value, or data fingerprint.
ダイジェスト方法：ダイジェスト法はダイジェストアルゴリズムであり、これは強力な一方向関数であり、特定の出力に対応する入力を見つけるか、同じ出力に対応する2つの異なる入力値を見つけることは計算的に実行不可能です。ダイジェストアルゴリズムは、入力データを固定長の短い値に変換します。出力は、ダイジェスト値、ハッシュ値、またはデータ指紋と呼ばれます。
Evidence: Evidence is information that may be used to resolve a dispute about various aspects of authenticity, validity, and existence of archived data objects.
証拠：証拠は、アーカイブされたデータオブジェクトの信頼性、妥当性、存在のさまざまな側面に関する紛争を解決するために使用される可能性のある情報です。
Evidence Record: An Evidence Record is a collection of evidence compiled for a given archive object over time. An Evidence Record includes ordered collection of ATSs, which are grouped into ATSCs and ATSSeqs.
証拠記録：証拠記録は、時間の経過とともに特定のアーカイブオブジェクトに対してまとめられた証拠のコレクションです。証拠記録には、ATSSとATSSEQSにグループ化されたATSSの順序付けられたコレクションが含まれています。
Long-Term Archive (LTA): An LTA is a service responsible for generation, collection, and maintenance (renewal) of evidence data. An LTA may also preserve data for long periods of time, e.g. storage of archive data and associated evidences.
長期アーカイブ（LTA）：LTAは、証拠データの生成、収集、およびメンテナンス（更新）を担当するサービスです。LTAは、データを長期間保存することもあります。アーカイブデータと関連する証拠の保存。
Hash Tree: A hash tree is a collection of hash values of protected objects (input data objects and generated evidence within archival period) that are unambiguously related to the Time-Stamped value within an Archive Time-Stamp.
ハッシュツリー：ハッシュツリーは、アーカイブタイムスタンプ内のタイムスタンプ値に明確に関連する保護されたオブジェクト（アーカイブ期間内に入力データオブジェクトと生成された証拠）のハッシュ値のコレクションです。
Time-Stamp Token (TS): A TS is a cryptographically secure confirmation generated by a Time-Stamping Authority (TSA), e.g., [RFC3161], which specifies a structure for Time-Stamps and a protocol for communicating with a Time-Stamp Authority. Besides this, other data structures and protocols may also be appropriate, such as defined in [ISO-18014-1.2002], [ISO-18014-2.2002], [ISO-18014-3.2004], and [ANSI.X9-95.2005].
タイムスタンプトークン（TS）：A TSは、タイムスタンプ（RFC3161]などのタイムスタンプ機関（TSA）によって生成される暗号化的に安全な確認です。これは、タイムスタンプの構造とタイムスタンプと通信するためのプロトコルを指定します。権限。これに加えて、[ISO-18014-1.2002]、[ISO-18014-2.2002]、[ISO-18014-3.2004]、[ansi.x9-95.2005]で定義されているような、他のデータ構造とプロトコルも適切である可能性があります。
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]に記載されているように解釈される。
An Evidence Record is a unit of data that is to be used to prove the existence of an archive object (a single archive data object or a archive data object group) at a certain time. Through the lifetime of an archive object, an Evidence Record also demonstrates the data objects' integrity and non-repudiability. To achieve this, cryptographic means are used, i.e., the LTA obtains Time-Stamp Tokens from the Time-Stamping Authority (TSA). It is possible to store the Evidence Record separately from the archive object or to integrate it into the data itself.
証拠レコードは、特定の時間にアーカイブオブジェクト（単一のアーカイブデータオブジェクトまたはアーカイブデータオブジェクトグループ）の存在を証明するために使用されるデータの単位です。アーカイブオブジェクトの生涯を通じて、エビデンスレコードは、データオブジェクトの整合性と非整合性も示しています。これを達成するために、暗号化手段が使用されます。つまり、LTAはタイムスタンプ機関（TSA）からタイムスタンプトークンを取得します。証拠記録をアーカイブオブジェクトとは別に保存したり、データ自体に統合することもできます。
As cryptographic means are used to support Evidence Records, such records may lose their value over time. Time-Stamps obtained from Time-Stamping Authorities may become invalid for a number of reasons, usually due to time constraints of Time-Stamp validity or when cryptographic algorithms lose their security properties. Before the used Time-Stamp Tokens become unreliable, the Evidence Record has to be renewed. This may result in a series of Time-Stamp Tokens, which are linked between themselves according to the cryptographic methods and algorithms used.
暗号化手段は証拠記録をサポートするために使用されるため、そのような記録は時間の経過とともにその価値を失う可能性があります。通常、タイムスタンプの有効性の時間制約や暗号化アルゴリズムがセキュリティプロパティを失った場合、時間刻み当局から得られたタイムスタンプは、多くの理由で無効になる可能性があります。使用済みのタイムスタンプトークンが信頼できなくなる前に、証拠記録を更新する必要があります。これにより、一連のタイムスタンプトークンが発生する可能性があります。これらのトークンは、使用される暗号化方法とアルゴリズムに従って自分自身の間にリンクされています。
Evidence Records can be supported with additional information, which can be used to ease the processes of Evidence Record validation and renewal. Information such as digital certificates and Certificate Revocation Lists as defined in [RFC5280] or other cryptographic material can be collected, enclosed, and processed together with archive object data (i.e., Time-Stamped).
証拠記録は、追加情報をサポートできます。これは、証拠の記録的な検証と更新のプロセスを容易にするために使用できます。[RFC5280]で定義されているデジタル証明書や証明書の取り消しリストやその他の暗号化資料などの情報は、アーカイブオブジェクトデータ（つまり、タイムスタンプ）とともに収集、囲み、処理できます。
The Evidence Record contains one or several Archive Time-Stamps (ATSs). An ATS contains a Time-Stamp Token and optionally other useful data for Time-Stamp validation, e.g., certificates, CRLs (Certificate Revocation Lists), or OCSP (Online Certificate Status Protocol) responses and also specific attributes such as service policies.
証拠記録には、1つまたは複数のアーカイブタイムスタンプ（ATS）が含まれています。ATSには、タイムスタンプトークン、およびタイムスタンプ検証のためのオプションの他の有用なデータ、例えば証明書、CRL（証明書の取り消しリスト）、またはOCSP（オンライン証明書ステータスプロトコル）応答、およびサービスポリシーなどの特定の属性が含まれています。
Initially, an ATS is acquired and later, before it expires or becomes invalid, a new ATS is acquired, which prolongs the validity of the archived object (its data objects together with all previously generated Archive Time-Stamps). This process MUST continue during the desired archiving period of the archive data object(s). A series of successive Archive Time-Stamps is collected in Archive Time-Stamp Chains and a series of chains in Archive Time-Stamp Sequence.
当初、ATSが取得され、その後、有効期限が切れるか無効になる前に、新しいATSが取得され、アーカイブされたオブジェクトの有効性（以前に生成されたすべてのアーカイブタイムスタンプと一緒にデータオブジェクト）が延長されます。このプロセスは、アーカイブデータオブジェクトの目的のアーカイブ期間中に継続する必要があります。一連の連続したアーカイブタイムスタンプは、アーカイブタイムスタンプチェーンとアーカイブタイムスタンプシーケンスの一連のチェーンで収集されます。
In XML syntax the Evidence Record is represented by the <EvidenceRecord> root element, which has the following structure described in Pseudo-XML with the full XML schema defined in Section 8 (where "?" denotes zero or one occurrences, "+" denotes one or more occurrences, and "*" denotes zero or more occurrences):
XML構文では、エビデンスレコードは<evidencerecord>ルート要素で表されます。これは、セクション8で定義された完全なXMLスキーマを持つ擬似XMLで説明されている次の構造を持っています（ ""はゼロまたは1つの発生を意味します、」またはそれ以上の発生、および「*」はゼロ以上の出現を示します）：
<EvidenceRecord Version>
<evidencerecordバージョン>
<EncryptionInformation>
<EncryptionInformationType>
<EncryptionInformationValue>
</EncryptionInformation> ?
<SupportingInformationList>
<SupportingInformation Type /> +
</SupportingInformationList> ?
<ArchiveTimeStampSequence>
<ArchiveTimeStampChain Order>
<DigestMethod Algorithm />
<CanonicalizationMethod Algorithm />
<ArchiveTimeStamp Order>
<HashTree /> ?
<TimeStamp>
<TimeStampToken Type />
<CryptographicInformationList>
<CryptographicInformation Order Type /> +
</CryptographicInformationList> ?
</TimeStamp>
<Attributes>
<Attribute Order Type /> +
</Attributes> ?
</ArchiveTimeStamp> +
</ArchiveTimeStampChain> +
</ArchiveTimeStampSequence>
</EvidenceRecord>
The syntax of an Evidence Record is defined as an XML schema [XMLSchema], see Section 8. The schema uses the following XML namespace [XMLName] urn:ietf:params:xml:ns:ers as default namespace with a detailed xml schema header listed in Section 8.
エビデンスレコードの構文はXMLスキーマ[XMLSchema]として定義されています。セクション8を参照してください。スキーマは、次のXMLネームスペース[XMLName] urnを使用します。セクション8にリストされています。
The XML elements and attributes have the following meanings:
XML要素と属性には次の意味があります。
The "Version" attribute MUST be included and indicates the syntax version, for compatibility with future revisions of this specification and to distinguish it from earlier non-conformant or proprietary versions of XMLERS. Current version of XMLERS is 1.0. The used versioning scheme is described in detail in Section 6. <EncryptionInformation> element is OPTIONAL and holds information on cryptographic algorithms and cryptographic material used to encrypt archive data (in case archive data is encrypted, e.g., for privacy purposes). This optional information is needed to unambiguously re-encrypt data objects when processing Evidence Records. When omitted, data objects are not encrypted or non-repudiation proof is not needed for the unencrypted data. Details on how to process encrypted archive data and generate Evidence Record(s) are described in Section 5.
「バージョン」属性を含める必要があり、この仕様の将来の改訂と互換性があり、XMLERSの以前の不適合バージョンまたは独自のバージョンと区別するための構文バージョンを示します。Xmlersの現在のバージョンは1.0です。使用済みバージョンスキームはセクション6で詳細に説明されています<encryptioninformation>要素はオプションであり、アーカイブデータを暗号化するために使用される暗号化アルゴリズムと暗号化資料に関する情報を保持しています（たとえば、プライバシーの目的でアーカイブデータが暗号化されます）。このオプションの情報は、証拠記録を処理する際にデータオブジェクトを明確に再構築するために必要です。省略すると、データオブジェクトは暗号化されていないデータには暗号化されていないか、非繰り返しの証明は必要ありません。暗号化されたアーカイブデータを処理し、証拠レコードを生成する方法の詳細については、セクション5で説明します。
<SupportingInformationList> element is OPTIONAL and can hold information to support processing of Evidence Records. An example of this supporting information may be a processing policy, like a cryptographic policy (e.g., [RFC5698]) or archiving policies, which can provide input about preservation and evidence validation. Each data object is put into a separate child element <SupportingInformation>, with an OPTIONAL Type attribute to indicate its type for processing directions. As outlined, Types to be used must be defined in the specification of the information structure to be stored or in this standard. As outlined in Section 9.4, cryptographic information may also be stored in the SupportingInformation element, in which case its Section 3.1.3 defined type MUST be used. Or as defined in Section 7 cryptographic policies [RFC5698] MAY be stored, in which case the used type is defined in the relevant RFC. Note that if supporting information and policies are relevant for and already available at or before the time of individual renewal steps (e.g., to indicate the DSSC crypto policy [RFC5698]) that was used at the time of the individual renewal) they SHOULD be stored in the <Attributes> element of the individual Archive Time-Stamp (see below) as this is integrity protected by the Archive Time-Stamps. Supporting information that is relevant for the whole Evidence Record (like the LTA's current Cryptographic Algorithms Security Suitability policy (DSSC, [RFC5698]) or that was not available at the time of renewal (and therefore could not later be stored in the protected <Attributes> element) can be stored in this <SupportingInformation> element.
<SupportingInformationList>要素はオプションであり、証拠記録の処理をサポートするための情報を保持できます。このサポート情報の例は、暗号化ポリシー（[RFC5698]など）や、保存と証拠の検証に関する入力を提供できるアーカイブポリシーなどの処理ポリシーです。各データオブジェクトは、個別の子要素<supportingInformation>に配置され、オプションのタイプ属性を使用して、処理方向のタイプを示します。概説したように、使用するタイプは、保存する情報構造の仕様またはこの標準で定義する必要があります。セクション9.4で概説されているように、暗号化情報はサポート情報要素にも保存される場合があります。この場合、セクション3.1.3定義型を使用する必要があります。または、セクション7で定義されているとおり、暗号化ポリシー[RFC5698]が保存される場合があります。この場合、使用型タイプは関連するRFCで定義されています。情報とポリシーをサポートすることが、個々の更新ステップの期間または前に既に利用可能である場合（たとえば、個々の更新時に使用されていたDSSC Cryptoポリシー[RFC5698]を示すために）、保存する必要があることに注意してください。これは、アーカイブタイムスタンプによって保護されている整合性であるため、個々のアーカイブタイムスタンプの<属性>要素（以下を参照）です。証拠記録全体に関連する情報のサポート（LTAの現在の暗号化アルゴリズムセキュリティ適合性ポリシー（DSSC、[RFC5698]）など、更新時には利用できなかった（したがって、保護された<属性に保存できなかった）>要素）は、この<SupportingInformation>要素に保存できます。
<ArchiveTimeStampSequence> is REQUIRED and contains a sequence of one or more <ArchiveTimeStampChain>.
<archivetimestampecence>が必要であり、1つ以上の<archivetimestampchain>のシーケンスが含まれています。
<ArchiveTimeStampChain> is a REQUIRED element that holds a sequence of Archive Time-Stamps generated during the preservation period. Details on Archive Time-Stamp Chains and Archive Time-Stamp Sequences are described in Section 4. The sequences of Archive Time-Stamp Chains and Archive Time-Stamps MUST be ordered and the order MUST be indicated with "Order" attribute of the <ArchiveTimeStampChain> and <ArchiveTimeStamp> elements.
<archivetimestampchain>は、保存期間中に生成されたアーカイブタイムスタンプのシーケンスを保持する必要な要素です。アーカイブタイムスタンプチェーンとアーカイブタイムスタンプシーケンスの詳細については、セクション4で説明します。アーカイブタイムスタンプチェーンとアーカイブタイムスタンプのシーケンスを注文する必要があり、注文は<Archivetimestampchainの「順序」属性で示される必要があります。>および<Archivetimestamp>要素。
<DigestMethod> is a REQUIRED element and contains an attribute "Algorithm" that identifies the digest algorithm used within one Archive Time-Stamp Chain to calculate digest values from the archive data object(s), previous Archive Time-Stamp Sequence, Time-Stamps, and within a Time-Stamp Token.
<DigestMethod>は必須要素であり、1つのアーカイブタイムスタンプチェーン内で使用されるダイジェストアルゴリズムを識別する属性「アルゴリズム」が含まれています。、およびタイムスタンプトークン内。
<CanonicalizationMethod> is a REQUIRED element that specifies which canonicalization algorithm is applied to the archive data for XML data objects or <ArchiveTimeStampSequence> or <TimeStamp> elements prior to performing digest value calculations.
<canonicalizationmethod>は、消化値計算を実行する前にXMLデータオブジェクトのアーカイブデータまたは<archivetimestampence>要素のアーカイブデータに適用される標準化アルゴリズムを指定する必要な要素です。
<HashTree> is an OPTIONAL element that holds a structure as described in Section 3.1.1.
<hashtree>は、セクション3.1.1で説明されているように構造を保持するオプションの要素です。
<TimeStamp> is REQUIRED and holds a <TimeStampToken> element with a Time-Stamp Token (as defined in Section 3.1.2) provided by the Time-Stamping Authority and an OPTIONAL element <CryptographicInformationList>.
<timestamp>が必要であり、タイムスタンプ機関とオプションの要素<cryptographicInformationList>によって提供されるタイムスタンプトークン（セクション3.1.2で定義）を備えた<TimestAmptoken>要素を保持します。
<CryptographicInformationList> is an OPTIONAL element that allows the storage of data needed in the process of Time-Stamp Token validation in case when such data is not provided by the Time-Stamp Token itself. This could include possible trust anchors, certificates, revocation information, or the current definition of the suitability of cryptographic algorithms, past and present. Each data object is put into a separate child element <CryptographicInformation>, with a REQUIRED Order attribute to indicate the order within its parent element. These items may be added based on the policy used. This data is protected by successive Time-Stamps in the sequence of the Archive Time-Stamps.
<CryptographicInformationList>は、タイムスタンプトークン自体によってそのようなデータが提供されない場合に、タイムスタンプトークン検証のプロセスで必要なデータの保存を許可するオプションの要素です。これには、可能な信頼のアンカー、証明書、取り消し情報、または過去および現在の暗号化アルゴリズムの適合性の現在の定義が含まれます。各データオブジェクトは、親要素内で順序を示すために必要な順序属性を使用して、別の子要素<暗号化情報>に配置されます。これらの項目は、使用されるポリシーに基づいて追加される場合があります。このデータは、アーカイブタイムスタンプのシーケンスで連続したタイムスタンプによって保護されています。
<Attributes> element is OPTIONAL and contains additional information that may be provided by an LTA used to support processing of Evidence Records. An example of this supporting information may be a processing policy, like a renewal, a cryptographic (e.g., [RFC5698]), or an archiving policy. Such policies can provide inputs, which are relevant for preservation of the data object(s) and evidence validation at a later stage. Each data object is put into a separate child element <Attribute>, with a REQUIRED Order attribute to indicate the order within the parent element and an OPTIONAL Type attribute to indicate processing directions. The type to be used must be defined in the specification of the information structure. For example, the type to be used when storing a cryptographic policy [RFC5698] is defined in Appendix A.2 of [RFC5698].
<属性>要素はオプションであり、証拠記録の処理をサポートするために使用されるLTAによって提供される可能性のある追加情報が含まれています。このサポート情報の例は、更新、暗号化（[RFC5698]など）、またはアーカイブポリシーなどの処理ポリシーです。このようなポリシーは、データオブジェクトの保存と後の段階での証拠の検証に関連する入力を提供できます。各データオブジェクトは、親要素内の順序を示すために必要な順序属性と、処理方向を示すオプションの型属性を示すために必要な注文属性を持つ個別の子要素<属性>に配置されます。使用するタイプは、情報構造の仕様で定義する必要があります。たとえば、暗号化ポリシー[RFC5698]を保存するときに使用するタイプは、[RFC5698]の付録A.2に定義されています。
The Order attribute is REQUIRED in all cases when one or more XML elements with the same name occur on the same level in XMLERS' <ArchiveTimeStampSequence> structure. Although most of the XML parsers will preserve the order of the sibling elements having the same name, within XML structure there is no definition how to unambiguously define such order. Preserving the correct order in such cases is of significant importance for digest value calculations over XML structures.
同じ名前の1つ以上のXML要素がXMLers '<Archivetimestampence>構造で同じレベルで発生する場合、すべての場合に順序属性が必要です。XMLパーサーのほとんどは同じ名前を持つ兄弟要素の順序を保持しますが、XML構造内では、そのような順序を明確に定義する方法はありません。そのような場合に正しい順序を保存することは、XML構造にわたる消化値計算にとって非常に重要です。
The generation of an <EvidenceRecord> element MUST be as follows:
<evidencerecord>要素の生成は次のとおりでなければなりません。
1. Select an archive object (a data object or a data object group) to archive.
1. アーカイブにアーカイブオブジェクト（データオブジェクトまたはデータオブジェクトグループ）を選択します。
2. Create the initial <ArchiveTimeStamp>. This is the first ATS within the initial <ArchiveTimeStampChain> element of the <ArchiveTimeStampSequence> element.
2. 初期<archivetimestamp>を作成します。これは、<archivetimestampecence>要素の初期<archivetimestampchain>要素内の最初のATSです。
3. Refresh the <ArchiveTimeStamp> when necessary by Time-Stamp renewal or hash tree renewal (see Section 4).
3. 必要に応じて、<archivetimestamp>を更新して、タイムスタンプの更新またはハッシュツリーの更新で更新します（セクション4を参照）。
The Time-Stamping service may be, for a large number of archived objects, expensive and time-demanding, so the LTA may benefit from acquiring one Time-Stamp Token for many archived objects, which are not otherwise related to each other. It is possible to collect many archive objects, build a hash tree to generate a single value to be Time-Stamped, and respectively reduce that hash tree to small subsets that for each archive object provide necessary binding with the Time-Stamped hash value (see Section 3.2.1).
タイムスタンピングサービスは、高価でタイムデマンな多数のアーカイブされたオブジェクトの場合があるため、LTAは、他の方法では互いに関連していない多くのアーカイブされたオブジェクトの1つのタイムスタンプトークンを取得することで利益を得ることがあります。多くのアーカイブオブジェクトを収集し、ハッシュツリーを構築してタイムスタンプの単一値を生成し、それぞれ各アーカイブオブジェクトに対してタイムスタンプのハッシュ値で必要なバインディングを提供する小さなサブセットにハッシュツリーを減らすことができます（参照セクション3.2.1）。
For performance reasons or in case of local Time-Stamp generation, building a hash tree (<HashTree> element) can be omitted. It is also possible to convert existing Time-Stamps into an ATS for renewal.
パフォーマンス上の理由またはローカルタイムスタンプの生成の場合、ハッシュツリー（<hashtree>要素）を構築することは省略できます。また、既存のタイムスタンプを更新のためにATSに変換することも可能です。
The case when only essential parts of documents or objects shall be protected is out of scope for this standard, and an application that is not defined in this document must ensure that the correct unambiguous extraction of binary data is made for the generation of Evidence Record.
ドキュメントまたはオブジェクトの重要な部分のみが保護されている場合、この標準の範囲外であり、このドキュメントで定義されていないアプリケーションは、証拠記録の生成のためにバイナリデータの正しい抽出が行われることを保証する必要があります。
An application may also provide evidence such as certificates, revocation lists, etc. needed to verify and validate signed data objects or a data object group. This evidence may be added to the archive data object group and will be protected within the initial (and successive) Time-Stamp(s).
アプリケーションは、署名されたデータオブジェクトまたはデータオブジェクトグループを検証および検証するために必要な証明書、取り消しリストなどの証拠を提供する場合があります。この証拠は、アーカイブデータオブジェクトグループに追加される場合があり、初期（および連続した）タイムスタンプ内で保護されます。
Note that the <CryptographicInformationList> element of Evidence Record is not to be used to store and protect cryptographic material related to signed archive data. The use of this element is limited to cryptographic material related to the Time-Stamp(s).
証拠記録の<CryptographicInformationList>要素は、署名されたアーカイブデータに関連する暗号化資料を保存および保護するために使用されないことに注意してください。この要素の使用は、タイムスタンプに関連する暗号化材料に限定されています。
The overall verification of an Evidence Record MUST be as follows:
証拠記録の全体的な検証は次のとおりでなければなりません。
1. Select an archive object (a data object or a data object group).
1. アーカイブオブジェクト（データオブジェクトまたはデータオブジェクトグループ）を選択します。
2. Re-encrypt data object or data object group, if encryption field is used (for details, see Section 5).
2. [暗号化]フィールドを使用する場合、データオブジェクトまたはデータオブジェクトグループを再暗号化します（詳細については、セクション5を参照）。
3. Verify Archive Time-Stamp Sequence (details in Sections 3.3 and 4.3).
3. アーカイブタイムスタンプシーケンスを確認します（セクション3.3および4.3の詳細）。
An Archive Time-Stamp is a Time-Stamp with additional artifacts that allow the verification of the existence of several data objects at a certain time.
アーカイブタイムスタンプは、特定の時間に複数のデータオブジェクトの存在を検証できる追加のアーティファクトを備えたタイムスタンプです。
The process of construction of an ATS must support evidence on a long-term basis and prove that the archive object existed and was identical, at the time of the Time-Stamp, to the currently present archive object (at the time of verification). To achieve this, an ATS MUST be renewed before it becomes invalid (which may happen for several reasons such as, e.g., weakening used cryptographic algorithms, invalidation of digital certificate, or a TSA terminating its business or ceasing its service).
ATSの構築プロセスは、長期的に証拠を支持し、アーカイブオブジェクトが存在し、タイムスタンプの時点で現在存在するアーカイブオブジェクトと同一であることを証明する必要があります（検証時）。これを達成するには、ATSを無効にする前に更新する必要があります（例えば、使用済みの暗号化アルゴリズム、デジタル証明書の無効化、またはそのビジネスを終了するTSAなど、いくつかの理由で発生する可能性があります）。
An Archive Time-Stamp contains a Time-Stamp Token, with useful data for its validation (cryptographic information), such as the certificate chain or Certificate Revocation Lists, an optional ordered set of ordered lists of hash values (a hash tree) that were protected with the Time-Stamp Token and optional information describing the renewal steps (<Attributes> element). A hash tree may be used to store data needed to bind the Time-Stamped value with protected objects by the Archive Time-Stamp. If a hash tree is not present, the ATS simply refers to a single object, either input data object or a previous TS.
アーカイブタイムスタンプには、タイムスタンプトークンが含まれており、証明書チェーンや証明書の取り消しリストなどの検証に役立つデータ（暗号化情報）が含まれています。タイムスタンプトークンと更新ステップ（<属性>要素）を説明するオプションの情報で保護されています。ハッシュツリーを使用して、タイムスタンプの値をアーカイブタイムスタンプで保護されたオブジェクトにバインドするために必要なデータを保存することができます。ハッシュツリーが存在しない場合、ATSは、入力データオブジェクトまたは以前のTSのいずれかの単一オブジェクトを単に指します。
Hash tree structure is an optional container for significant values, needed to unambiguously relate a Time-Stamped value to protected data objects, and is represented by the <HashTree> element. The root hash value that is generated from the values of the hash tree MUST be the same as the Time-Stamped value.
ハッシュツリー構造は、タイムスタンプの値を保護されたデータオブジェクトに明確に関連付けるために必要な重要な値のオプションのコンテナであり、<hashtree>要素で表されます。ハッシュツリーの値から生成されるルートハッシュ値は、タイムスタンプの値と同じでなければなりません。
<HashTree>
<Sequence Order>
<DigestValue>base64 encoded hash value</DigestValue> +
</Sequence> +
</HashTree>
The algorithm by which a root hash value is generated from the <HashTree> element is as follows: the content of each <DigestValue> element within the first <Sequence> element is base64 ([RFC4648], using the base64 alphabet not the base64url alphabet) decoded to obtain a binary value (representing the hash value). All collected hash values from the sequence are ordered in binary ascending order, concatenated and a new hash value is generated from that string. With one exception to this rule: when the first <Sequence> element has only one <DigestValue> element, then its binary value is added to the next list obtained from the next <Sequence> element.
ルートハッシュ値が<hashtree>要素から生成されるアルゴリズムは次のとおりです。最初の<シーケンス>要素内の各<ダイジェストバリュー>要素の含有量は、base64urlアルファベットではなくbase64アルファベットを使用してbase64（[rfc4648]です。）バイナリ値を取得するためにデコードされた（ハッシュ値を表す）。シーケンスから収集されたすべてのハッシュ値は、バイナリの昇順で順序付けられ、連結され、その文字列から新しいハッシュ値が生成されます。このルールの1つの例外を除いて、最初の<Sequence>要素に1つの<DigestValue>要素しかない場合、そのバイナリ値は次の<シーケンス>要素から取得した次のリストに追加されます。
The newly calculated hash value is added to the next list of hashes obtained from the next <Sequence> element and the previous step is repeated until there is only one hash value left, i.e., when there are no <Sequence> elements left. The last calculated hash value is the root hash value. When an archive object is a group and composed of more than one data object, the first hash list MUST contain the hash values of all its data objects.
新しく計算されたハッシュ値は、次の<シーケンス>要素から取得したハッシュの次のリストに追加され、前のステップは、1つのハッシュ値が残っているまで、つまり<シーケンス>要素が残っていない場合に繰り返されます。最後に計算されたハッシュ値は、ルートハッシュ値です。アーカイブオブジェクトがグループであり、複数のデータオブジェクトで構成される場合、最初のハッシュリストには、すべてのデータオブジェクトのハッシュ値を含める必要があります。
When a single Time-Stamp is obtained for a set of archive objects, the LTA MUST construct a hash tree to generate a single hash value to bind all archive objects from that group and then a reduced hash tree MUST be calculated from the hash tree for each archive object respectively (see Section 3.2.1).
一連のアーカイブオブジェクトに対して単一のタイムスタンプが取得される場合、LTAはハッシュツリーを構築して単一のハッシュ値を生成する必要があります。それぞれのアーカイブオブジェクト（セクション3.2.1を参照）。
For example: A SHA-1 digest value is a 160-bit string. The text value of the <DigestValue> element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream. And to continue the example, using an example message digest value of A9993E364706816ABA3E25717850C26C9CD0D89D (note this is a HEX encoded value of the 160-bit message digest), its base64 representation would be <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>.
たとえば、SHA-1ダイジェスト値は160ビット文字列です。<DigestValue>要素のテキスト値は、20オクテットのオクテットストリームと見なされるこのビット文字列のbase64エンコードでなければなりません。例を継続するために、A9993E364706816ABA3E25717850C26C9CD0D89D（これは160ビットメッセージダイジェストの六角エンコード値です）のメッセージダイジェスト値を使用して、そのbase64表現は<digestvalue> qzcggwqgwqgwqgwqgwqgwqgwqibxefdcbjzであります。
Time-Stamp Token is an attestation generated by a TSA that a data item existed at a certain time. The Time-Stamp Token is a signed data object that contains the hash value, the identity of the TSA, and the exact time (obtained from trusted time source) of Time-Stamping. This proves that the given data existed before the time of Time-Stamping. For example, [RFC3161] specifies a structure for signed Time-Stamp Tokens in ASN.1 format. Since at the time being there is no standard for an XML Time-Stamp, the following structure example is provided [TS-ENTRUST], which is a digital signature compliant to [XMLDSig] specification containing Time-Stamp specific data, such as Time-Stamped value and time within the <Object> element of a signature.
タイムスタンプトークンは、データ項目が特定の時間に存在したというTSAによって生成される証明です。タイムスタンプトークンは、ハッシュ値、TSAのアイデンティティ、およびタイムスタンピングの正確な時間（信頼された時間源から取得）を含む署名されたデータオブジェクトです。これは、特定のデータがタイムスタンピングの時代前に存在することを証明しています。たとえば、[RFC3161]は、asn.1形式で署名されたタイムスタンプトークンの構造を指定します。当時はXMLタイムスタンプの標準がないため、次の構造例が提供されます[TS-Enterust]は、[XMLDSIG]タイムスタンプ固有のデータを含む[XMLDSIG]仕様に準拠したデジタル署名です。署名の<オブジェクト>要素内の刻印された値と時間。
<element name="TimeStampInfo">
<complexType>
<sequence>
<element ref="Policy" />
<element ref="Digest" />
<element ref="SerialNumber" minOccurs="0" />
<element ref="CreationTime" />
<element ref="Accuracy" minOccurs="0" />
<element ref="Ordering" minOccurs="0" />
<element ref="Nonce" minOccurs="0" />
<element ref="Extensions" minOccurs="0" />
</sequence>
</complexType>
</element>
A <TimeStamp> element of ATS holds a complete structure of Time-Stamp Token as provided by a TSA. Time-Stamp Token may be in XML or ASN.1 format. The Attribute type MUST be used to indicate the format for processing purposes, with values "XMLENTRUST" or "RFC3161" respectively. For an RFC3161 type Time-Stamp Token, the <TimeStamp> element MUST contain base64 encoding of a DER-encoded ASN1 data. These type values are registered by IANA (see Section 10). For support of future types of Time-Stamps (in particular for future XML Time-Stamp standards), these need to be registered there as well.
ATSの<タイムスタンプ>要素は、TSAが提供するように、タイムスタンプトークンの完全な構造を保持しています。タイムスタンプトークンは、XMLまたはASN.1形式である場合があります。属性タイプを使用して、それぞれ「xmlentrust」または「rfc3161」を使用して、処理目的で形式を示す必要があります。RFC3161タイプタイムスタンプトークンの場合、<TimestAmp>要素には、derエンコードされたASN1データのbase64エンコードを含める必要があります。これらのタイプの値はIANAによって登録されています（セクション10を参照）。将来のタイムスタンプのサポート（特に将来のXMLタイムスタンプ基準のために）をサポートするには、これらも登録する必要があります。
For example:
例えば：
<TimeStamp Type="RFC3161">MIAGCSqGSIb3DQEH...</TimeStamp>
or
また
<TimeStamp Type="XMLENTRUST"><dsig:Signature>...</dsig:Signature>
</TimeStamp>
Digital certificates, CRLs (Certificate Revocation Lists), SCVP (Server-Based Certificate Validation Protocol), or OCSP-Responses (Online Certificate Status Protocol) needed to verify the Time-Stamp Token SHOULD be stored in the Time-Stamp Token itself. When this is not possible, such data MAY be stored in the
デジタル証明書、CRLS（証明書の取り消しリスト）、SCVP（サーバーベースの証明書検証プロトコル）、またはOCSP応答（オンライン証明書ステータスプロトコル）は、タイムスタンプトークンをタイムスタンプトークン自体に保存する必要があります。これが不可能な場合、そのようなデータは
<CryptographicInformationList> element; each data object is stored into a separate <CryptographicInformation> element, with a REQUIRED Order attribute.
<CryptographicInformationList> element;各データオブジェクトは、必要なオーダー属性を持つ個別の<cryptographicInformation>要素に保存されます。
The attribute Type is REQUIRED and is used to store processing information about the type of stored cryptographic information. The Type attribute MUST use a value registered with IANA, as identifiers: CRL, OCSP, SCVP, or CERT, and for each type the content MUST be encoded respectively:
属性タイプが必要であり、保存された暗号化情報の種類に関する処理情報を保存するために使用されます。型属性は、識別子としてIANAに登録された値を使用する必要があります：CRL、OCSP、SCVP、またはCERT、および各タイプについて、コンテンツをそれぞれエンコードする必要があります。
o for type CRL, a base64 encoding of a DER-encoded X.509 CRL [RFC5280]
o タイプCRLの場合、derエンコードX.509 CRL [RFC5280]のbase64エンコード
o for type OCSP, a base64 encoding of a DER-encoded OCSPResponse [RFC2560]
o タイプOCSPの場合、derエンコードされたocspresponse [rfc2560]のbase64エンコード
o for type SCVP, a base64 encoding of a DER-encoded CVResponse; [RFC5055]
o タイプSCVPの場合、derエンコードされたcVResponseのbase64エンコード。[RFC5055]
o for type CERT, a base64 encoding of a DER-encoded X.509 certificate [RFC5280]
o タイプ証明書の場合、derエンコードされたx.509証明書のbase64エンコード[RFC5280]
The supported type identifiers are registered by IANA (see Section 10). Future supported types can be registered there (for example, to support future validation standards).
サポートされているタイプ識別子はIANAによって登録されています（セクション10を参照）。将来のサポートされているタイプをそこで登録できます（たとえば、将来の検証基準をサポートするため）。
An initial ATS relates to a data object or a data object group that represents an archive object. The generation of the initial ATS element can be done in a single process pass for one or for many archived objects. It MUST be done as described in the following steps:
初期ATSは、アーカイブオブジェクトを表すデータオブジェクトまたはデータオブジェクトグループに関連しています。初期ATS要素の生成は、1つまたは多くのアーカイブされたオブジェクトの単一プロセスパスで実行できます。次の手順で説明するように行う必要があります。
1. Collect one or more archive objects to be Time-Stamped.
1. 1つ以上のアーカイブオブジェクトを収集して、タイムスタンプします。
2. Select a canonicalization method C to be used for obtaining binary representation of archive data and for Archive Time-Stamp at a later stage in the renewing process (see Section 4). Note that the selected canonicalization method MUST be used also for archive data when data is represented in XML format.
2. アーカイブデータのバイナリ表現を取得するために使用される標準化方法Cを選択し、更新プロセスの後期段階でアーカイブタイムスタンプを使用します（セクション4を参照）。データがXML形式で表されている場合、選択した正規化法もアーカイブデータに使用する必要があることに注意してください。
3. Select a valid digest algorithm H. The selected secure hash algorithm MUST be the same as the hash algorithm used in the Time-Stamp Token and for the hash tree computations.
3. 有効なダイジェストアルゴリズムHを選択します。選択した安全なハッシュアルゴリズムは、タイムスタンプトークンおよびハッシュツリー計算で使用されるハッシュアルゴリズムと同じでなければなりません。
4. Generate a hash tree for selected archive object (see Section 3.2.1).
4. 選択したアーカイブオブジェクトのハッシュツリーを生成します（セクション3.2.1を参照）。
The hash tree may be omitted in the initial ATS, when an archive object has a single data object; then the Time-Stamped value MUST match the digest value of that single data object.
アーカイブオブジェクトに単一のデータオブジェクトがある場合、ハッシュツリーは最初のATSで省略される場合があります。次に、タイムスタンプの値は、その単一のデータオブジェクトのダイジェスト値と一致する必要があります。
5. Acquire Time-Stamp token from TSA for root hash value of a hash tree (see Section 3.1.1). If the Time-Stamp token is valid, the initial Archive Time-Stamp may be generated.
5. ハッシュツリーのルートハッシュ値については、TSAからタイムスタンプトークンを取得します（セクション3.1.1を参照）。タイムスタンプトークンが有効な場合、初期アーカイブタイムスタンプが生成される場合があります。
The <DigestValue> elements within the <Sequence> element MUST be ordered in binary ascending order to ensure the correct calculation of digest values at the time of renewal and later for verification purposes. Note that the text value of the <DigestValue> element is base64 encoded, so it MUST be base64 decoded in order to obtain a binary representation of the hash value.
<Sequence>要素内の<DigestValue>要素は、更新時にダイジェスト値の正しい計算を確保するために、検証目的でダイジェスト値の正しい計算を確保するために、バイナリ昇順で順序付けなければなりません。<digestvalue>要素のテキスト値はbase64エンコードされているため、ハッシュ値のバイナリ表現を取得するには、base64デコードする必要があることに注意してください。
A hash tree MUST be generated when the Time-Stamped value is not equal to the hash value of the input data object. This is the case when either of the following is true:
タイムスタンプの値が入力データオブジェクトのハッシュ値に等しくない場合、ハッシュツリーを生成する必要があります。これは、次のいずれかが真である場合です。
1. When an archive object has more than one data object (i.e., is an archive data object group), its digest value is the digest value of binary ascending ordered and concatenated digest values of all its containing data objects. Note that in this case the first list of the hash tree MUST contain hash values of all data objects and only those values.
1. アーカイブオブジェクトに複数のデータオブジェクト（つまり、アーカイブデータオブジェクトグループ）がある場合、そのダイジェスト値は、そのすべてのデータオブジェクトのバイナリ上昇順序付けおよび連結ダイジェスト値のダイジェスト値です。この場合、ハッシュツリーの最初のリストには、すべてのデータオブジェクトとそれらの値のみのハッシュ値が含まれている必要があることに注意してください。
2. When for more than one archive object a single Time-Stamp Token is generated, then the hash tree is a reduced hash tree extracted from the hash tree for that archive object (see Section 3.2.2).
2. 複数のアーカイブオブジェクトの場合、単一のタイムスタンプトークンが生成されると、ハッシュツリーは、そのアーカイブオブジェクトのハッシュツリーから抽出されたハッシュツリーを減らします（セクション3.2.2を参照）。
The hash tree for a set of archive objects is built from the leaves to the root. First the leaves of the tree are collected, each leaf representing the digest value of an archive object. You MUST use the following procedure to calculate the hash tree:
アーカイブオブジェクトのセットのハッシュツリーは、葉から根まで構築されています。最初に木の葉が収集され、各葉はアーカイブオブジェクトのダイジェスト値を表します。ハッシュツリーを計算するには、次の手順を使用する必要があります。
1. Collect archive objects and for each archive object its corresponding data objects.
1. アーカイブオブジェクトを収集し、各アーカイブオブジェクトについて、対応するデータオブジェクト。
2. Choose a secure hash algorithm H and calculate the digest values for the data objects and put them into the input list for the hash tree as follows: a digest value of an archive object is the digest value of its data object, if there is only one data object in the archive object; if there is more than one data object in the archive object (i.e., it is an archive data object group) the digest value is the digest value of binary sorted, concatenated digest values of all its containing data objects.
2. 安全なハッシュアルゴリズムhを選択し、データオブジェクトのダイジェスト値を計算し、次のようにハッシュツリーの入力リストに配置します。アーカイブオブジェクトのダイジェスト値は、そのデータオブジェクトのダイジェスト値です。アーカイブオブジェクト内のデータオブジェクト。アーカイブオブジェクトに複数のデータオブジェクトがある場合（つまり、アーカイブデータオブジェクトグループです）、ダイジェスト値は、そのすべてのデータオブジェクトのバイナリソート、連結ダイジェスト値のダイジェスト値です。
Note that for an archive object group (having more than one data object), lists of their sub-digest values are stored and later, when creating a reduced hash tree for that archive object, they will become members of the first hash list.
アーカイブオブジェクトグループ（複数のデータオブジェクトを持つ）の場合、サブダイジェスト値のリストが保存され、後でそのアーカイブオブジェクトのハッシュツリーが削減されると、最初のハッシュリストのメンバーになることに注意してください。
3. Group together items in the input list by the order of N (e.g., for a binary tree group in pairs, for a tertiary tree group in triplets, and so forth) and for each group: binary ascending sort, concatenate, and calculate the hash value. The result is a new input for the next list. For improved processing it is RECOMMENDED to have the same number of children for each node. For this purpose you MAY extend the tree with arbitrary values to make every node have the same number of children.
3. 入力リストに項目を組み合わせて、N ORD of of of of of of of（例：ペアのバイナリツリーグループ、トリプレットの三次ツリーグループなど）および各グループの場合：バイナリアセンディングソート、連結、およびハッシュの計算を計算する価値。結果は、次のリストの新しい入力です。改善された処理には、各ノードに同じ数の子供を持つことをお勧めします。この目的のために、任意の値でツリーを拡張して、すべてのノードを同じ数の子供にすることができます。
4. Repeat step 3, until only one digest value is left; this is the root value of the hash tree, which is Time-Stamped.
4. ダイジェスト値が1つだけ残るまで、ステップ3を繰り返します。これは、ハッシュツリーのルート値であり、タイムスタンプです。
Note that the selected secure hash algorithm MUST be the same as the one defined in the <DigestMethod> element of the ATSChain.
選択したセキュアハッシュアルゴリズムは、Atschainの<DigestMethod>要素で定義されているものと同じでなければならないことに注意してください。
Example: An input list with 18 hash values, where the h'1 is generated for a group of data objects (d4, d5, d6, and d7) and has been grouped by 3. The group could be of any size (2, 3...). Note that the addition of the arbitrary values h''6 and h'''3 are OPTIONAL and can be used for improved processing as outlined in step 3 above.
例：18のハッシュ値を持つ入力リスト。ここで、H'1はデータオブジェクトのグループ（D4、D5、D6、およびD7）のグループに対して生成され、3によってグループ化されています。グループは任意のサイズ（2、3 ...）。任意の値h''6およびh '' '3の追加はオプションであり、上記のステップ3で概説されているように改善された処理に使用できることに注意してください。
----------
d1 -> h1 \
\
G1 d2 -> h2 |-> h''1
+--------+ / \
|d4 -> h4|\ d3 -> h3 / \
|d5 -> h5| \ ---------- |
| | | -> h'1\ |
|d6 -> h6| / \ |
|d7 -> h7|/ d8 -> h8 |-> h''2 |-> h'''1
+--------+ / | \
d9 -> h9 / | \
---------- | |
d10 -> h10\ / |
\ / |
d11 -> h11 |-> h''3 |
/ |
d12 -> h12/ |-> root hash value
---------- |
d13 -> h13\ |
\ |
d14 -> h14 |-> h''4 |
/ \ |
d15 -> h15/ \ |
---------- |-> h'''2 |
d16 -> h16\ | |
\ | |
d17 -> h17 |-> h''5 | |
/ | |
d18 -> h18/ | |
---------- / |
/ /
(any arbitrary) h''6 /
(any arbitrary) h'''3
Figure 1. Generation of the Merkle Hash Tree
図1.マークルハッシュツリーの生成
Note that there are no restrictions on the quantity of hash value lists and of their length. Also note that it is beneficial but not required to build hash trees and reduce hash trees. An Archive Time-Stamp may consist only of one list of hash values and a Time-Stamp or in an extreme case only a Time-Stamp with no hash value lists.
ハッシュ値リストとその長さの量に制限がないことに注意してください。また、それは有益ですが、ハッシュツリーを構築し、ハッシュツリーを減らすために必要ではないことに注意してください。アーカイブタイムスタンプは、ハッシュ値とタイムスタンプの1つのリストのみで構成されている場合、または極端な場合は、ハッシュ値リストがないタイムスタンプのみです。
The generated Merkle hash tree can be reduced to lists of hash values, necessary as a proof of existence for a single archive object as follows: 1. For a selected archive object (AO) select its hash value h within the leaves of the hash tree.
生成されたメルクルハッシュツリーは、次のように単一のアーカイブオブジェクトの存在の証明として必要なハッシュ値のリストに縮小できます。1。選択したアーカイブオブジェクト（AO）の場合、ハッシュツリーの葉の中でハッシュ値hを選択します。
2. Put h as base64 encoded text value of a new <DigestValue> element within a first <Sequence> element. If the selected AO is a data object group (i.e., has more than one data object), the first <Sequence> element MUST in this case be formed from the hash values of all AOs data objects, each within a separate <DigestValue> element.
2. hをbase64エンコードされたテキスト値として、first <sequence>要素内のnew <digestvalue>要素のテキスト値を使用します。選択したAOがデータオブジェクトグループである場合（つまり、複数のデータオブジェクトを持っています）、この場合、すべてのAOSデータオブジェクトのハッシュ値から最初の<シーケンス>要素を形成する必要があります。。
3. Select all hash values that have the same father node as hash value h. Place these hash values each as a base64 encoded text value of a new <DigestValue> element within a new <Sequence> element, increasing its Order attribute value by 1.
3. ハッシュ値hと同じ父ノードを持つすべてのハッシュ値を選択します。これらのハッシュ値をそれぞれ、base64エンコードされたテキスト値の新しい<digestvalue>要素の新しい<sequence>要素内に配置し、次数属性値を1増加させます。
4. Repeat step 3 for the parent node until the root hash value is reached, with each step create a new <Sequence> element and increase its Order attribute by one. Note that node values are not saved as they are computable.
4. ルートハッシュ値に到達するまで、親ノードのステップ3を繰り返し、各ステップで新しい<シーケンス>要素を作成し、その順序属性を1つだけ増やします。ノード値は計算可能であるため、保存されないことに注意してください。
The order of <DigestValue> elements within each <Sequence> element MUST be binary ascending (by base64 decoded values).
各<Sequence>要素内の<DigestValue>要素の順序は、バイナリ上昇する必要があります（Base64デコードされた値による）。
Reduced hash tree for data object d4 (from the previous example, presented in Figure 1):
データオブジェクトD4のハッシュツリーを削減しました（前の例から、図1に示す）：
<HashTree>
<Sequence Order='1'>
<DigestValue>base64 encoded h4</DigestValue>
<DigestValue>base64 encoded h5</DigestValue>
<DigestValue>base64 encoded h6</DigestValue>
<DigestValue>base64 encoded h7</DigestValue>
</Sequence>
<Sequence Order='2'>
<DigestValue>base64 encoded h8</DigestValue>
<DigestValue>base64 encoded h9</DigestValue>
</Sequence>
<Sequence Order='3'>
<DigestValue>base64 encoded h''1</DigestValue>
<DigestValue>base64 encoded h''3</DigestValue>
</Sequence>
<Sequence Order='4'>
<DigestValue>base64 encoded h'''2</DigestValue>
</Sequence>
</HashTree>
Reduced hash tree for data object d2 (from the previous example, presented in Figure 1):
データオブジェクトD2のハッシュツリーを削減しました（前の例から、図1に示します）：
<HashTree>
<Sequence Order='1'>
<DigestValue>base64 encoded h2</DigestValue>
</Sequence>
<Sequence Order='2'>
<DigestValue>base64 encoded h1</DigestValue>
<DigestValue>base64 encoded h3</DigestValue>
</Sequence>
<Sequence Order='3'>
<DigestValue>base64 encoded h''2</DigestValue>
<DigestValue>base64 encoded h''3</DigestValue>
</Sequence>
<Sequence Order='4'>
<DigestValue>base64 encoded h'''2</DigestValue>
</Sequence>
</HashTree>
The initial Archive Time-Stamp shall prove that an archive object existed at a certain time, indicated by its Time-Stamp Token. The verification procedure MUST be as follows:
最初のアーカイブタイムスタンプは、タイムスタンプトークンで示されている特定の時間にアーカイブオブジェクトが存在することを証明するものとします。検証手順は次のとおりでなければなりません。
1. Identify hash algorithm H (from <DigestMethod> element) and calculate the hash value for each data object of the archive object.
1. ハッシュアルゴリズムH（<DigestMethod>要素から）を識別し、アーカイブオブジェクトの各データオブジェクトのハッシュ値を計算します。
2. If the hash tree is present, search for hash values in the first <Sequence> element. If hash values are not present, terminate verification process with negative result. If the verifying party also seeks additional proof that the Archive Time-Stamp relates to a data object group (e.g., a document and all its digital signatures), it SHOULD also be verified that only the hash values of the data objects that are members of the given data object group are in the first hash value list.
2. ハッシュツリーが存在する場合は、最初の<シーケンス>要素でハッシュ値を検索します。ハッシュ値が存在しない場合は、マイナスの結果で検証プロセスを終了します。検証党が、アーカイブタイムスタンプがデータオブジェクトグループ（例：ドキュメントとそのすべてのデジタル署名）に関連するという追加の証拠を求めている場合、そのメンバーであるデータオブジェクトのハッシュ値のみが確認する必要があります。指定されたデータオブジェクトグループは、最初のハッシュ値リストにあります。
3. If the hash tree is present, calculate its root hash value. Compare the root hash value with the Time-Stamped value. If they are not equal, terminate the verification process with negative result.
3. ハッシュツリーが存在する場合、そのルートハッシュ値を計算します。ルートハッシュ値をタイムスタンプの値と比較します。それらが等しくない場合は、否定的な結果で検証プロセスを終了します。
4. If the hash tree is omitted, compare the hash value of the single data object with the Time-Stamped value. If they are not equal, terminate the verification process with negative result. If an archive object is having more data objects and the hash tree is omitted, also exit with negative result.
4. ハッシュツリーが省略されている場合は、単一のデータオブジェクトのハッシュ値をタイムスタンプの値と比較します。それらが等しくない場合は、否定的な結果で検証プロセスを終了します。アーカイブオブジェクトがより多くのデータオブジェクトを持っている場合、ハッシュツリーが省略されている場合、負の結果も出ます。
5. Check the validity of the Time-Stamp Token. If the needed information to verify formal validity of the Time-Stamp Token is not available or found within the <TimeStampToken> element or within the <CryptographicInformationList> element or in <SupportingInformationList> (see Section 9.4), exit with a negative result.
5. タイムスタンプトークンの妥当性を確認してください。タイムスタンプトークンの正式な妥当性を確認するために必要な情報が<Timestamptoken>要素または<CryptographicInformationList>要素内または<supportinginformationList>（セクション9.4を参照）内で使用できないか、見つかりません。
Information for formal verification of the Time-Stamp Token includes digital certificates, Certificate Revocation Lists, Online Certificate Status Protocol responses, etc. This information needs to be collected prior to the Time-Stamp renewal process and protected with the succeeding Time-Stamp, i.e., included in the <TimeStampToken> or <CryptographicInformation> element (see Section 9.4 for additional information and Section 4.2.1 for details on the Time-Stamp renewal process). For the current (latest) Time-Stamp), information for formal verification of the (latest) Time-Stamp should be provided by the Time-Stamping Authority. This information can also be provided with the Evidence Record within the <SupportingInformation> element, which is not protected by any Time-Stamp.
タイムスタンプトークンの正式な検証のための情報には、デジタル証明書、証明書の取り消しリスト、オンライン証明書ステータスプロトコル応答などが含まれます。この情報は、タイムスタンプ更新プロセスの前に収集し、後続のタイムスタンプで保護する必要があります。、<timestamptoken>または<cryptographicInformation>要素に含まれています（追加情報についてはセクション9.4を参照し、セクション4.2.1を参照してください。現在の（最新の）タイムスタンプ）の場合、（最新の）タイムスタンプの正式な検証のための情報は、タイムスタンピング当局によって提供されるべきです。この情報には、<SupportingInformation>要素内の証拠記録を提供することもできますが、これはどのタイムスタンプでも保護されていません。
An Archive Time-Stamp proves the existence of single data objects or a data object group at a certain time. However, the initial Evidence Record created can become invalid due to losing the validity of the Time-Stamp Token for a number of reasons: hash algorithms or public key algorithms used in its hash tree or the Time-Stamp may become weak or the validity period of the Time-Stamp authority certificate expires or is revoked.
アーカイブタイムスタンプは、特定の時間に単一のデータオブジェクトまたはデータオブジェクトグループの存在を証明します。ただし、作成された初期の証拠記録は、いくつかの理由でタイムスタンプトークンの妥当性を失うために無効になる可能性があります：ハッシュツリーまたはタイムスタンプで使用されるハッシュアルゴリズムまたは公開キーアルゴリズムは弱くなったり、妥当性の期間になる可能性がありますタイムスタンプ当局証明書の有効期限が切れるか、取り消されます。
To preserve the validity of an Evidence Record before such events occur, the Evidence Record has to be renewed. This can be done by creating a new ATS. Depending on the reason for renewing the Evidence Record (the Time-Stamp becomes invalid or the hash algorithm of the hash tree becomes weak) two types of renewal processes are possible:
そのようなイベントが発生する前に証拠記録の妥当性を維持するには、証拠記録を更新する必要があります。これは、新しいATSを作成することで実行できます。証拠記録を更新する理由（タイムスタンプが無効になるか、ハッシュツリーのハッシュアルゴリズムが弱くなる）に応じて、2つのタイプの更新プロセスが可能です。
o Time-Stamp renewal: For this process a new Archive Time-Stamp is generated, which is applied over the last Time-Stamp created. The process results in a series of Archive Time-Stamps, which are contained within a single Archive Time-Stamp Chain (ATSC).
o タイムスタンプの更新：このプロセスでは、新しいアーカイブタイムスタンプが生成され、作成された最後のタイムスタンプに適用されます。このプロセスは、単一のアーカイブタイムスタンプチェーン（ATSC）内に含まれる一連のアーカイブタイムスタンプをもたらします。
o Hash tree renewal: For this process a new Archive Time-Stamp is generated, which is applied to all existing Time-Stamps and data objects. The newly generated Archive Time-Stamp is placed in a new Archive Time-Stamp Chain. The process results in a series of Archive Time-Stamp Chains, which are contained within a single Archive Time-Stamp Sequence (ATSSeq).
o ハッシュツリーの更新：このプロセスでは、新しいアーカイブタイムスタンプが生成され、既存のすべてのタイムスタンプとデータオブジェクトに適用されます。新しく生成されたアーカイブタイムスタンプは、新しいアーカイブタイムスタンプチェーンに配置されています。このプロセスは、単一のアーカイブタイムスタンプシーケンス（ATSSEQ）内に含まれる一連のアーカイブタイムスタンプチェーンをもたらします。
After the renewal process, only the most recent (i.e., the last generated) Archive Time-Stamp has to be monitored for expiration or validity loss.
更新プロセスの後、最新の（つまり、最後に生成された）アーカイブタイムスタンプのみを、有効期限または妥当性の損失を監視する必要があります。
Archive Time-Stamp Chain and Archive Time-Stamp Sequence are containers for sequences of Archive Time-Stamp(s) that are generated through renewal processes. The renewal process results in a series of Evidence Record elements: the <ArchiveTimeStampSequence> element contains an ordered sequence of <ArchiveTimeStampChain> elements, and the <ArchiveTimeStampChain> element contains an ordered sequence of <ArchiveTimeStamp> elements. Both elements MUST be sorted by time of the Time-Stamp in ascending order. Order is indicated by the Order attribute.
アーカイブタイムスタンプチェーンとアーカイブタイムスタンプシーケンスは、更新プロセスを通じて生成されるアーカイブタイムスタンプのシーケンスのコンテナです。更新プロセスは、一連の証拠を記録する要素をもたらします。<archivetimestampecence>要素には、<archivetimestampchain>要素の順序付けられたシーケンスが含まれ、<archivetimestampchain>要素には<archivetimestamp>要素の順序付きシーケンスが含まれます。両方の要素は、昇順でタイムスタンプの時間によってソートする必要があります。順序は順序属性によって示されます。
When an Archive Time-Stamp must be renewed, a new <ArchiveTimeStamp> element is generated and depending on the generation process, it is either placed:
アーカイブタイムスタンプを更新する必要がある場合、新しい<Archivetimestamp>要素が生成され、生成プロセスに応じて、次のいずれかが配置されます。
o as the last <ArchiveTimeStamp> child element in a sequence of the last <ArchiveTimeStampChain> element in case of Time-Stamp renewal or
o タイムスタンプの更新の場合の最後の<Archivetimestampchain>要素のシーケンスの最後の<Archivetimestamp>子要素として
o as the first <ArchiveTimeStamp> child element in a sequence of the newly created <ArchiveTimeStampChain> element in case of hash tree renewal.
o ハッシュツリーの更新の場合の新しく作成された<Archivetimestampchain>要素のシーケンスにおける最初の<Archivetimestamp>子要素として。
The ATS with the largest Order attribute value within the ATSC with the largest Order attribute value is the latest ATS and MUST be valid at the present time.
ATSC内の最大の注文属性値を持つATSは、最大の属性値を持つATSC内のATSが最新のATSであり、現時点では有効でなければなりません。
Digest method is a required element that identifies the digest algorithm used to calculate hash values of archive data (and node values of hash tree). The digest method is specified in the <ArchiveTimeStampChain> element by the required <DigestMethod> element and indicates the digest algorithm that MUST be used for all hash value calculations related to the Archive Time-Stamps within the Archive Time-Stamp Chain.
ダイジェスト法は、アーカイブデータのハッシュ値（およびハッシュツリーのノード値）を計算するために使用されるダイジェストアルゴリズムを識別する必須要素です。ダイジェスト法は、必要な<DigestMethod>要素によって<archivetimestampchain>要素で指定され、アーカイブタイムスタンプチェーン内のアーカイブタイムスタンプに関連するすべてのハッシュ値計算に使用する必要があるダイジェストアルゴリズムを示します。
The Algorithm attribute contains URIs [RFC3986] for identifiers that MUST be used as defined in [RFC3275] and [RFC4051]. For example, when the SHA-1 algorithm is used, the algorithm identifier is:
アルゴリズム属性には、[RFC3275]および[RFC4051]で定義されているように使用する必要がある識別子のURIS [RFC3986]が含まれています。たとえば、SHA-1アルゴリズムを使用する場合、アルゴリズム識別子は次のとおりです。
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
Within a single ATSC, the digest algorithms used for the hash trees of its Archive Time-Stamps and the Time-Stamp Tokens MUST be the same. When algorithms used by a TSA are changed (e.g., upgraded) a new ATSC MUST be started using an equal or stronger digest algorithm.
単一のATSC内で、アーカイブタイムスタンプのハッシュツリーとタイムスタンプトークンに使用されるダイジェストアルゴリズムは同じでなければなりません。TSAで使用されるアルゴリズムが変更された場合（たとえば、アップグレード）、等しいまたはより強力なダイジェストアルゴリズムを使用して新しいATSCを開始する必要があります。
Prior to hash value calculations of an XML element, a proper binary representation must be extracted from its (abstract) XML data presentation. The binary representation is determined by UTF-8 [RFC3629] encoding and canonicalization of the XML element. The XML element includes the entire text of the start and end tags as well as all descendant markup and character data (i.e., the text and sub-elements) between those tags.
XML要素のハッシュ値計算の前に、適切なバイナリ表現を（要約）XMLデータプレゼンテーションから抽出する必要があります。バイナリ表現は、XML要素のエンコードと標準化のUTF-8 [RFC3629]によって決定されます。XML要素には、開始タグとエンドタグのテキスト全体と、それらのタグ間のすべての子孫マークアップおよびキャラクターデータ（つまり、テキストとサブエレメント）が含まれます。
<CanonicalizationMethod> is a required element that identifies the canonicalization algorithm used to obtain binary representation of an XML element or elements. Algorithm identifiers (URIs) MUST be used as defined in [RFC3275] and [RFC4051]. For example, when Canonical XML 1.0 (omits comments) is used, algorithm identifier is
<canonicalizationmethod>は、XML要素または要素のバイナリ表現を取得するために使用される正規化アルゴリズムを識別する必要な要素です。アルゴリズム識別子（URI）は、[RFC3275]および[RFC4051]で定義されているように使用する必要があります。たとえば、標準XML 1.0（コメントを省略）が使用される場合、アルゴリズム識別子は
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-
xml-c14n-20010315"/>
Canonicalization MUST be applied over XML structured archive data and MUST be applied over elements of Evidence Record (namely, ATS and ATSC in the renewing process).
標準化は、XML構造化アーカイブデータを介して適用する必要があり、証拠記録の要素（すなわち、更新プロセスでのATSおよびATSC）に適用する必要があります。
The canonicalization method is specified in the <Algorithm> attribute of the <CanonicalizationMethod> element within the <ArchiveTimeStampChain> element and indicates the canonicalization method that MUST be used for all binary representations of the Archive Time-Stamps within that Archive Time-Stamp Chain. In case of succeeding ATSC the canonicalization method indicated within the ATSC must also be used for the calculation of the digest value of the preceding ATSC. Note that the canonicalization method is unlikely to change over time as it does not impose the same constraints as the digest method. In theory, the same canonicalization method can be used for a whole Archive Time-Stamp Sequence. Although alternative canonicalization methods may be used, it is recommended to use c14n-20010315 [XMLC14N].
標準化法は、<archivetimestampchain>要素内の<cononicalizationmethod>要素の<アルゴリズム>属性で指定されており、そのアーカイブタイムスタンプチェーン内のアーカイブタイムスタンプのすべてのバイナリ表現に使用する必要がある標準化方法を示します。ATSCが成功した場合、ATSC内に示されている標準化法は、前のATSCのダイジェスト値の計算にも使用する必要があります。標準化法は、ダイジェスト法と同じ制約を課さないため、時間の経過とともに変化する可能性は低いことに注意してください。理論的には、同じ標準化法をアーカイブタイムスタンプシーケンス全体に使用できます。代替の標準化方法を使用する場合がありますが、C14N-20010315 [XMLC14N]を使用することをお勧めします。
Before the cryptographic algorithms used within the most recent Archive Time-Stamp become weak or the Time-Stamp certificates are invalidated, the LTA has to renew the Archive Time-Stamps by generating a new Archive Time-Stamp using one of two procedures: Time-Stamp renewal or hash tree renewal.
最新のアーカイブタイムスタンプ内で使用される暗号化アルゴリズムが弱くなるか、タイムスタンプ証明書が無効になる前に、LTAは2つの手順のいずれかを使用して新しいアーカイブタイムスタンプを生成することにより、アーカイブタイムスタンプを更新する必要があります。スタンプの更新またはハッシュツリーの更新。
In case of Time-Stamp renewal, i.e., if the digest algorithm (H) to be used in the renewal process is the same as digest algorithm (H') used in the last Archive Time-Stamp, the complete content of the last <TimeStamp> element MUST be Time-Stamped and a new <ArchiveTimeStamp> element created as follows:
タイムスタンプの更新の場合、つまり、更新プロセスで使用されるダイジェストアルゴリズム（h）が最後のアーカイブタイムスタンプで使用されるダイジェストアルゴリズム（h '）と同じである場合、最後の<の完全なコンテンツはTimestamp>要素は、タイムスタンプと、次のように作成された新しい<Archivetimestamp>要素である必要があります。
1. If the current <ArchiveTimeStamp> element does not contain needed proof for long-term formal validation of its Time-Stamp Token within the <TimeStamp> element, collect needed data such as root certificates, Certificate Revocation Lists, etc., and include them in the <CryptographicInformationList> element of the last Archive Time-Stamp (each data object into a separate <CryptographicInformation> element).
1. 現在の<Archivetimestamp>要素に、<timestamp>要素内でのタイムスタンプトークンの長期的な正式な検証に必要な証明が含まれていない場合、ルート証明書、証明書の取り消しリストなどの必要なデータを収集し、それらを含めます。最後のアーカイブタイムスタンプの<CryptographicInformationList>要素（各データオブジェクトは別の<CryptographicInformation>要素に）。
2. Select the canonicalization method from the <CanonicalizationMethod> element and select the digest algorithm from the <DigestMethod> element. Calculate hash value from binary representation of the <TimeStamp> element of the last <ArchiveTimeStamp> element including added cryptographic information. Acquire the Time-Stamp for the calculated hash value. If the Time-Stamp is valid, the new Archive Time-Stamp may be generated.
2. <cononicalizationmethod>要素から正規化方法を選択し、<digestmethod>要素からダイジェストアルゴリズムを選択します。追加された暗号化情報を含む、最後の<Archivetimestamp>要素の<タイムスタンプ>要素のバイナリ表現からハッシュ値を計算します。計算されたハッシュ値のタイムスタンプを取得します。タイムスタンプが有効な場合、新しいアーカイブタイムスタンプが生成される場合があります。
3. Increase the value order of the new ATS by one and place the new ATS into the last <ArchiveTimeStampChain> element.
3. 新しいATSの値順序を1つだけ増やし、新しいATSを最後の<Archivetimestampchain>要素に入れます。
The new ATS and its hash tree MUST use the same digest algorithm as the preceding one, which is specified in the <DigestMethod> element within the <ArchiveTimeStampChain> element. Note that the new ATS MAY not contain a hash tree. However, the Time-Stamp renewal process may be optimized to acquire one Time-Stamp for many Archive Time-Stamps using a hash tree. Note that each hash of the <TimeStamp> element is treated as the document hash in Section 3.2.1.
新しいATSとそのハッシュツリーは、<Archivetimestampchain>要素内の<DigestMethod>要素で指定されている前のものと同じダイジェストアルゴリズムを使用する必要があります。新しいATSにはハッシュツリーが含まれていない場合があることに注意してください。ただし、タイムスタンプの更新プロセスは、ハッシュツリーを使用して多くのアーカイブタイムスタンプの1つのタイムスタンプを取得するために最適化される場合があります。<タイムスタンプ>要素の各ハッシュは、セクション3.2.1のドキュメントハッシュとして扱われることに注意してください。
The process of hash tree renewal occurs when the new digest algorithm is different from the one used in the last Archive Time-Stamp (H <> H'). In this case the complete Archive Time-Stamp Sequence and the archive data objects covered by existing Archive Time-Stamp must be Time-Stamped as follows:
ハッシュツリー更新のプロセスは、新しいダイジェストアルゴリズムが最後のアーカイブタイムスタンプ（H <> H '）で使用されているものと異なる場合に発生します。この場合、完全なアーカイブタイムスタンプシーケンスと、既存のアーカイブタイムスタンプで覆われたアーカイブデータオブジェクトは、次のようにタイムスタンプする必要があります。
1. Select one or more archive objects to be renewed and their current <ArchiveTimeStamp> elements.
1. 更新する1つ以上のアーカイブオブジェクトと現在の<Archivetimestamp>要素を選択します。
2. For each archive object check the current <ArchiveTimeStamp> element. If it does not contain the proof needed for long-term formal validation of its Time-Stamp Token within the Time-Stamp Token, collect the needed data such as root certificates, Certificate Revocation Lists, etc., and include them in the <CryptographicInformationList> element of the last Archive Time-Stamp (each data object into a separate <CryptographicInformation> element).
2. 各アーカイブオブジェクトについて、現在の<Archivetimestamp>要素を確認します。タイムスタンプトークン内でのタイムスタンプトークンの長期的な正式な検証に必要な証拠が含まれていない場合、ルート証明書、証明書の取り消しリストなどの必要なデータを収集し、<cryptographicinformationListに含める>最後のアーカイブタイムスタンプの要素（各データオブジェクトに個別の<暗号化>要素にオブジェクト）。
3. Select a canonicalization method C and select a new secure hash algorithm H.
3. 標準化方法Cを選択し、新しい安全なハッシュアルゴリズムHを選択します。
4. For each archive object select its data objects d(i). Generate hash values h(i) = H(d(i)), for example: h(1), h(2).., h(n).
4. アーカイブオブジェクトごとに、データオブジェクトd（i）を選択します。ハッシュ値h（i）= h（d（i））、たとえば、h（1）、h（2）..、h（n）を生成します。
5. For each archive object calculate a hash hseq=H(ATSSeq) from binary representation of the <ArchiveTimeStampSequence> element, corresponding to that archive object. Note that Archive Time-Stamp Chains and Archive Time-Stamps MUST be chronologically ordered, each respectively to its Order attribute, and that the canonicalization method C MUST be applied.
5. 各アーカイブオブジェクトについて、そのアーカイブオブジェクトに対応する<archivetimestampence>要素のバイナリ表現からハッシュhseq = h（atsseq）を計算します。アーカイブタイムスタンプチェーンとアーカイブタイムスタンプは、それぞれその順序属性にそれぞれ年代順に順序付けられなければならず、標準化法cを適用する必要があることに注意してください。
6. For each archive object sort in binary ascending order and concatenate all h(i) and the hseq. Generate a new digest value h(j)=H(h(1)..h(n),hseq).
6. 各アーカイブオブジェクトについては、バイナリの昇順でソートし、すべてのH（i）とHSEQを連結します。新しいダイジェスト値h（j）= h（h（1）.. h（n）、hseq）を生成します。
7. Build a new Archive Time-Stamp for each h(j) (hash tree generation and reduction is defined in Sections 3.2.1 and 3.2.2). Note that each h(j) is treated as the document hash in Section 3.2.1. The first hash value list in the reduced hash tree should only contain h(i) and hseq.
7. 各H（j）の新しいアーカイブタイムスタンプを構築します（ハッシュツリーの生成と削減は、セクション3.2.1および3.2.2で定義されています）。各H（j）は、セクション3.2.1のドキュメントハッシュとして扱われることに注意してください。縮小ハッシュツリーの最初のハッシュ値リストには、H（I）とHSEQのみを含む必要があります。
8. Create the new <ArchiveTimeStampChain> containing the new <ArchiveTimeStamp> element (with order number 1), and place it into the existing <ArchiveTimeStampSequence> as a last child with the order number increased by one.
8. 新しい<archivetimestampchain>を作成して、新しい<archivetimestamp>要素（注文番号1を含む）を含み、既存の<archivetimestampecence>に配置します。
Example for an archive object with 3 data objects: Select a new hash algorithm and canonicalization method. Collect all 3 data objects and currently generated Archive Time-Stamp Sequence.
3つのデータオブジェクトを持つアーカイブオブジェクトの例：新しいハッシュアルゴリズムと正規化方法を選択します。3つのデータオブジェクトをすべて収集し、現在生成されているアーカイブタイムスタンプシーケンスを生成します。
AO
ao
/ | \
d1 d2 d3
D1 D2 D3
ATSSeq ATSChain1: ATS0, ATS1
ATSSEQ ATSCHAIN1：ATS0、ATS1
ATSChain2: ATS0, ATS1, ATS2
ATSCHAIN2：ATS0、ATS1、ATS2
The hash values MUST be calculated with the new hash algorithm H for all data objects and for the whole ATSSeq. Note that ATSSeq MUST be chronologically ordered and canonicalized before retrieving its binary representation.
ハッシュ値は、すべてのデータオブジェクトとATSSEQ全体について、新しいハッシュアルゴリズムhで計算する必要があります。ATSSEQは、バイナリ表現を取得する前に、時系列に順序付けられ、正規化する必要があることに注意してください。
When generating the hash tree for the new ATS, the first sequence become values: H(d1), H(d2),..., H(dn), H(ATSSeq). Note: hash values MUST be sorted in binary ascending order.
新しいATSのハッシュツリーを生成するとき、最初のシーケンスは値になります：H（d1）、h（d2）、...、h（dn）、h（atsseq）。注：ハッシュ値は、バイナリ昇順でソートする必要があります。
<HashTree>
<Sequence Order='1'>
<DigestValue>H(d1)</DigestValue>
<DigestValue>H(d2)</DigestValue>
<DigestValue>H(d3)</DigestValue>
<DigestValue>H(ATSSeq)</DigestValue>
</Sequence>
</HashTree>
Note that if the group processing is being performed, the hash value of the concatenation of the first sequence is an input hash value into the hash tree.
グループ処理が実行されている場合、最初のシーケンスの連結のハッシュ値は、ハッシュツリーへの入力ハッシュ値であることに注意してください。
An Evidence Record shall prove that an archive object existed and has not been changed from the time of the initial Time-Stamp Token within the first ATS. In order to complete the non-repudiation proof for an archive object, the last ATS has to be valid and ATSCs and their relations to each other have to be proved:
証拠記録は、アーカイブオブジェクトが存在し、最初のATS内の最初のタイムスタンプトークンの時代から変更されていないことを証明するものとします。アーカイブオブジェクトの非繰り返し証明を完了するためには、最後のATSが有効でなければならず、ATSCと互いの関係を証明する必要があります。
1. Select archive object and re-encrypt its data object or data object group, if <EncryptionInformation> field is used. Select the initial digest algorithm specified within the first Archive Time-Stamp Chain and calculate the hash value of the archive object. Verify that the initial Archive Time-Stamp contains (identical) hash value of the AO's data object (or hash values of AO's data object group). Note that when the hash tree is omitted, calculated AO's value MUST match the Time-Stamped value.
1. [アーカイブオブジェクト]を選択し、<encryptioninformation>フィールドが使用される場合、データオブジェクトまたはデータオブジェクトグループを再クリップします。最初のアーカイブタイムスタンプチェーン内で指定された初期ダイジェストアルゴリズムを選択し、アーカイブオブジェクトのハッシュ値を計算します。初期アーカイブタイムスタンプがAOのデータオブジェクト（またはAOのデータオブジェクトグループのハッシュ値）の（同一の）ハッシュ値が含まれていることを確認します。ハッシュツリーが省略された場合、計算されたAOの値はタイムスタンプの値と一致する必要があることに注意してください。
2. Verify each Archive Time-Stamp Chain and each Archive Time-Stamp within. If the hash tree is present within the second and the next Archive Time-Stamps of an Archive Time-Stamp Chain, the first <Sequence> MUST contain the hash value of the <TimeStamp> element before. Each Archive Time-Stamp MUST be valid relative to the time of the succeeding Archive Time-Stamp. All Archive Time-Stamps with the Archive Time-Stamp Chain MUST use the same hash algorithm, which was secure at the time of the first Archive Time-Stamp of the succeeding Archive Time-Stamp Chain.
2. 各アーカイブタイムスタンプチェーンと各アーカイブタイムスタンプを内部に確認します。ハッシュツリーがアーカイブタイムスタンプチェーンの2番目と次のアーカイブタイムスタンプ内に存在する場合、最初の<シーケンス>には<Timestamp>要素のハッシュ値が含まれている必要があります。各アーカイブタイムスタンプは、後続のアーカイブタイムスタンプの時間に対して有効でなければなりません。アーカイブタイムスタンプチェーンを備えたすべてのアーカイブタイムスタンプは、同じハッシュアルゴリズムを使用する必要があります。これは、後続のアーカイブタイムスタンプチェーンの最初のアーカイブタイムスタンプの時点で安全でした。
3. Verify that the first hash value list of the first Archive Time-Stamp of all succeeding Archive Time-Stamp Chains contains hash values of data object and the hash value of Archive Time-Stamp Sequence of the preceding Archive Time-Stamp Chains. Verify that Archive Time-Stamp was created when the last Archive Time-Stamp of the preceding Archive Time-Stamp Chain was valid.
3. 後続のすべてのアーカイブタイムスタンプチェーンの最初のアーカイブタイムスタンプの最初のハッシュ値リストには、データオブジェクトのハッシュ値と、前述のアーカイブタイムスタンプチェーンのアーカイブタイムスタンプシーケンスのハッシュ値が含まれていることを確認します。前のアーカイブタイムスタンプチェーンの最後のアーカイブタイムスタンプが有効であるときに、アーカイブタイムスタンプが作成されたことを確認します。
4. To prove the Archive Time-Stamp Sequence relates to a data object group, verify that the first Archive Time-Stamp of the first Archive Time-Stamp Chain does not contain other hash values in its first hash value list than the hash values of those data objects.
4. アーカイブタイムスタンプシーケンスがデータオブジェクトグループに関連することを証明するには、最初のアーカイブタイムスタンプチェーンの最初のアーカイブタイムスタンプが、それらのデータのハッシュ値よりも最初のハッシュ値リストに他のハッシュ値が含まれていないことを確認しますオブジェクト。
For non-repudiation proof for the data object, the last Archive Time-Stamp MUST be valid at the time of verification process.
データオブジェクトの非繰り返し証明の場合、最後のアーカイブタイムスタンプは、検証プロセスの時点で有効でなければなりません。
In some archive services scenarios it may be required that clients send encrypted data only, preventing information disclosure to third parties, such as archive service providers. In such scenarios it must be clear that Evidence Records generated refer to encrypted data objects. Evidence Records in general protect the bit-stream (or binary representation of XML data), which freezes the bit structure at the time of archiving. Encryption schemes in such scenarios cannot be changed afterwards without losing the integrity proof. Therefore, an ERS record must hold and preserve encryption information in a consistent manner. To avoid problems when using Evidence Records in the future, additional special precautions have to be taken.
一部のアーカイブサービスシナリオでは、クライアントが暗号化されたデータのみを送信し、アーカイブサービスプロバイダーなどの第三者への情報開示を防ぐことが必要になる場合があります。このようなシナリオでは、生成された証拠記録が暗号化されたデータオブジェクトを指していることは明らかでなければなりません。一般的な証拠記録は、アーカイブ時にビット構造をフリーズするビットストリーム（またはXMLデータのバイナリ表現）を保護します。このようなシナリオの暗号化スキームは、整合性の証明を失うことなく、その後変更することはできません。したがって、ERSレコードは、暗号化情報を一貫した方法で保持および保存する必要があります。将来の証拠記録を使用する際に問題を回避するには、追加の特別な予防措置を講じる必要があります。
Encryption is a two-way process, whose result depends on the cryptographic material used, e.g., encryption keys and encryption algorithms. Encryption and decryption keys as well as algorithms must match in order to reconstruct the original message or data that was encrypted. 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 different cryptographic material, i.e., 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 Time-Stamped encrypted data objects unambiguously represent unencrypted data objects. In cases when evidence was generated to prove the existence of encrypted data the corresponding algorithm and decryption keys used for encryption must become a part of the Evidence Record and is used to unambiguously represent original (unencrypted) data that was encrypted. (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.) Cryptographic material may also be used in scenarios when a client submits encrypted data to the archive service provider for preservation but stores himself the data only in an unencrypted form. In such scenarios cryptographic material is used to re-encrypt the unencrypted data kept by a client for the purpose of performing validation of the Evidence Record, which is related to the encrypted form of client's data. An OPTIONAL extensible structure <EncryptionInformation> is defined to store the necessary parameters of the encryption methods. Its <EncryptionInformationType> element is used to store the type of stored encryption information, e.g., whether it is an encryption algorithm or encryption key. The <EncryptionInformationValue> element then contains the relevant encryption information itself. The use of encryption elements heavily depends on the cryptographic mechanism and has to be defined by other specifications.
暗号化は双方向のプロセスであり、その結果は、暗号化キーや暗号化アルゴリズムなどの暗号化材料に依存します。暗号化と復号化キー、およびアルゴリズムは、暗号化された元のメッセージまたはデータを再構築するために一致する必要があります。暗号化されたデータの存在を証明するために生成された証拠は、暗号化されていないデータの存在を証明するために常に依存することはできません。異なる暗号化材料、つまり、暗号化に使用されるアルゴリズムまたはキーではない復号化のアルゴリズムまたはキーを選択することが可能かもしれません。この場合、証拠記録は、暗号化されていないデータの非和解証明ではありません。したがって、タイムスタンプの暗号化されたデータオブジェクトが暗号化されていないデータオブジェクトを明確に表すことをアーカイブすることを証明することを可能にする暗号化方法のみを使用する必要があります。暗号化されたデータの存在を証明する証拠が生成された場合、暗号化に使用される対応するアルゴリズムと復号化キーは証拠記録の一部になり、暗号化された元の（暗号化されていない）データを明確に表すために使用されます。（注：さらに、暗号化スキームの長期的なセキュリティを分析して、衝突攻撃を作成するために使用できるかどうかを判断する必要があります。）暗号化資料は、クライアントが暗号化されたデータをアーカイブサービスプロバイダーに提出する場合にも使用できます。保存のためには、暗号化されていない形式でのみデータを保存します。このようなシナリオでは、暗号化されたフォームのクライアントのデータに関連する証拠レコードの検証を実行するために、クライアントが保持していない暗号化されていないデータを再暗号化するために暗号化資料を使用しています。オプションの拡張可能な構造<necryptionInformation>は、暗号化方法の必要なパラメーターを保存するために定義されています。その<encryptioninformationType>要素は、暗号化アルゴリズムであろうと暗号化キーであろうと、保存された暗号化情報のタイプを保存するために使用されます。<encryptioninformationValue>要素には、関連する暗号化情報自体が含まれます。暗号化要素の使用は、暗号化メカニズムに大きく依存し、他の仕様によって定義する必要があります。
The numbering scheme for XMLERS versions is "<major>.<minor>". The major and minor numbers MUST be treated as separate integers and each number MAY be incremented higher than a single digit. Thus, "2.4" would be a lower version than "2.13", which in turn would be lower than "12.3". Leading zeros (e.g., "6.01") MUST be ignored by recipients and MUST NOT be sent.
Xmlersバージョンの番号付けスキームは「<major>。<minor>」です。主要な数字とマイナー数は、個別の整数として扱う必要があり、各数値は1桁よりも高く増加することができます。したがって、「2.4」は「2.13」よりも低いバージョンであり、「12.3」よりも低くなります。主要なゼロ（例：「6.01」）は受信者によって無視され、送信されないでください。
The major version number will be incremented only if the data format has changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the elements and attributes it did not understand and took the actions defined in the older specification.
メジャーバージョン番号は、データ形式が非常に劇的に変更された場合にのみインクリメントされます。これにより、古いバージョンのエンティティは、理解できなかった要素と属性を単に無視し、定義されたアクションを取得した場合に、新しいバージョンエンティティと相互運用できません。古い仕様。
The minor version number will be incremented if significant new capabilities have been added to the core format (e.g., new optional elements).
重要な新しい機能がコア形式に追加された場合（例：新しいオプション要素）、マイナーバージョン番号が増加します。
As explained above policies can be stored in the Evidence Record in the <Attribute> or the <SupportingInformation> element. In the case of storing DSSC policies [RFC5698], the types to be used in the <Attribute> or <SupportingInformation> element are defined in Appendix A.2 of [RFC5698] for both ASN.1 and XML representation.
上記のように、ポリシーは、<属性>または<supportingInformation>要素の証拠記録に保存できます。DSSCポリシー[RFC5698]を保存する場合、<属性>または<supportinginformation>要素で使用するタイプは、ASN.1およびXML表現の両方の[RFC5698]の付録A.2で定義されています。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:ers"
targetNamespace="urn:ietf:params:xml:ns:ers"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="EvidenceRecord" type="EvidenceRecordType"/>
<!-- TYPE DEFINITIONS-->
<xs:complexType name="EvidenceRecordType">
<xs:sequence>
<xs:element name="EncryptionInformation"
type="EncryptionInfo" minOccurs="0"/>
<xs:element name="SupportingInformationList"
type="SupportingInformationType" minOccurs="0"/>
<xs:element name="ArchiveTimeStampSequence"
type="ArchiveTimeStampSequenceType"/>
</xs:sequence>
<xs:attribute name="Version" type="xs:decimal" use="required"
fixed="1.0"/>
</xs:complexType>
<xs:complexType name="EncryptionInfo">
<xs:sequence>
<xs:element name="EncryptionInformationType"
type="ObjectIdentifier"/>
<xs:element name="EncryptionInformationValue">
<xs:complexType mixed="true">
<xs:sequence>
<xs:any minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArchiveTimeStampSequenceType">
<xs:sequence>
<xs:element name="ArchiveTimeStampChain" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DigestMethod"
type="DigestMethodType"/>
<xs:element name="CanonicalizationMethod"
type="CanonicalizationMethodType"/>
<xs:element name="ArchiveTimeStamp"
type="ArchiveTimeStampType"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArchiveTimeStampType">
<xs:sequence>
<xs:element name="HashTree" type="HashTreeType" minOccurs="0"/>
<xs:element name="TimeStamp" type="TimeStampType"/>
<xs:element name="Attributes" type="Attributes" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType" use="required"/>
</xs:complexType>
<xs:complexType name="DigestMethodType" mixed="true">
<xs:sequence>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="CanonicalizationMethodType" mixed="true">
<xs:sequence minOccurs="0">
<xs:any namespace="##any" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="TimeStampType">
<xs:sequence>
<xs:element name="TimeStampToken">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="CryptographicInformationList"
type="CryptographicInformationType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="HashTreeType">
<xs:sequence>
<xs:element name="Sequence" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DigestValue" type="xs:base64Binary"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Attributes">
<xs:sequence>
<xs:element name="Attribute" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
<xs:attribute name="Type" type="xs:string"
use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CryptographicInformationType">
<xs:sequence>
<xs:element name="CryptographicInformation"
maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="SupportingInformationType">
<xs:sequence>
<xs:element name="SupportingInformation"
maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Type" type="xs:string"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="ObjectIdentifier">
<xs:restriction base="xs:token">
<xs:pattern value="[0-2](\.[1-3]?[0-9]?(\.\d+)*)?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="OrderType">
<xs:restriction base="xs:int">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Cryptographic algorithms and parameters that are used within Archive Time-Stamps must always be secure at the time of generation. This concerns the hash algorithm used in the hash lists of Archive Time-Stamp as well as hash algorithms and public key algorithms of the Time-Stamps. Publications regarding security suitability of cryptographic algorithms ([NIST.800-57-Part1.2006] and [ETSI-TS-102-176-1-V2.0.0]) have to be considered during the verification. A generic solution for automatic interpretation of security suitability policies in electronic form is not the subject of this specification.
アーカイブタイムスタンプ内で使用される暗号化アルゴリズムとパラメーターは、生成時に常に安全でなければなりません。これは、アーカイブタイムスタンプのハッシュリストで使用されるハッシュアルゴリズム、およびタイムスタンプのハッシュアルゴリズムと公開キーアルゴリズムに関係しています。暗号化アルゴリズムのセキュリティ適合性に関する出版物（[nist.800-57-part1.2006]および[ETSI-TS-102-176-1-V2.0.0]）を検証中に考慮する必要があります。電子形式でのセキュリティ適合性ポリシーを自動的に解釈するための一般的なソリューションは、この仕様の主題ではありません。
Evidence Records may become affected by weakening cryptographic algorithms even before this is publicly known. Retrospectively this has an impact on Archive Time-Stamps generated and renewed during the archival period. In this case the validity of Evidence Records created may end without any options for retroactive action.
証拠記録は、これが公に知られる前であっても、暗号化アルゴリズムを弱めることで影響を受ける可能性があります。遡及的に、これはアーカイブ期間中に生成および更新されたアーカイブタイムスタンプに影響を与えます。この場合、作成された証拠記録の妥当性は、遡及的なアクションの選択肢がなくて終わる可能性があります。
Many TSAs are using the same cryptographic algorithms. While compromise of a private key of a TSA may compromise the security of only one TSA (and only one Archive Time-Stamp, for example), weakening cryptographic algorithms used to generate Time-Stamp Tokens would affect many TSAs at the same time.
多くのTSAが同じ暗号化アルゴリズムを使用しています。TSAの秘密鍵の妥協は、1つのTSAのみ（たとえば1つのアーカイブタイムスタンプのみ）のセキュリティを損なう可能性がありますが、タイムスタンプトークンを生成するために使用される暗号化アルゴリズムの弱体化は、同時に多くのTSAに影響を与えます。
To manage such risks and to avoid the loss of Evidence Record validity due to weakening cryptographic algorithms used, it is RECOMMENDED to generate and manage at least two redundant Evidence Records for a single data object. In such scenarios redundant Evidence Records SHOULD use different hash algorithms within Archive Time-Stamp Sequences and different TSAs using different cryptographic algorithms for Time-Stamp Tokens.
そのようなリスクを管理し、使用された暗号化アルゴリズムの弱体化による証拠の記録の妥当性の喪失を回避するには、単一のデータオブジェクトの少なくとも2つの冗長証拠記録を生成および管理することをお勧めします。このようなシナリオでは、冗長な証拠レコードは、タイムスタンプトークンの異なる暗号アルゴリズムを使用して、アーカイブタイムスタンプシーケンスおよび異なるTSA内の異なるハッシュアルゴリズムを使用する必要があります。
Archive Time-Stamps depend upon the security of normal Time-Stamping provided by TSA and stated in security policies. Renewed Archive Time-Stamps MUST have the same or higher quality as the initial Archive Time-Stamp of archive data. Archive Time-Stamps used for signed archive data SHOULD have the same or higher quality than the maximum quality of the signatures.
アーカイブタイムスタンプは、TSAが提供し、セキュリティポリシーに記載されている通常のタイムスタンプのセキュリティに依存しています。更新されたアーカイブタイムスタンプは、アーカイブデータの初期アーカイブタイムスタンプと同じまたは高品質を持つ必要があります。署名されたアーカイブデータに使用されるアーカイブタイムスタンプは、署名の最大品質と同じまたは高品質でなければなりません。
It is important to consider for renewal and verification that when a new Time-Stamp is applied, it MUST be ascertained that prior to the time of renewal (i.e., when the new Time-Stamp is applied) the certificate of the before current Time-Stamp was not revoked due to a key compromise. Otherwise, in the case of a key compromise, there is the risk that the authenticity of the used Time-Stamp and therefore its security in the chain of evidence cannot be guaranteed. Other revocation reasons like the revocation for cessation of activity do not necessarily pose this risk, as in that case the private key of the Time-Stamp unit would have been previously destroyed and thus cannot be used nor compromised.
更新と検証のために、新しいタイムスタンプが適用された場合、更新の時間（つまり、新しいタイムスタンプが適用される場合）の前に現在の時間の証明書の証明書を確認する必要があることを検討することが重要です。重要な妥協のためにスタンプは取り消されませんでした。それ以外の場合、重要な妥協の場合、使用済みのタイムスタンプの信ity性、したがって証拠の連鎖におけるそのセキュリティを保証できないというリスクがあります。活動の停止の取り消しのような他の取り消しの理由は、タイムスタンプユニットの秘密鍵が以前に破壊されていたため、使用も妥協もできなかったため、必ずしもこのリスクをもたらすわけではありません。
Both elements <CryptographicInformationList> and <Attribute> are protected by future Archive Time_Stamp renewals and can store information as outlined in Section 2.1 that is available at or before the time of the renewal of the specific Archive Time-Stamp. At the time of renewal all previous Archive Time-Stamp data structures become protected by the new Archive Time-Stamp and frozen by it, i.e., no data MUST be added or modified in these elements afterwards. If, however, some supporting information is relevant for the overall Evidence Record or information that only becomes available later, this can be provided in the Evidence Record in the <SupportingInformationList> element. Data in the <SupportingInformatonList> can be added later to an Evidence Record, but it must rely on its own authenticity and integrity protection mechanism, like, for example, signed by current strong cryptographic means and/or provided by a trusted source (for example, this could be the LTA providing its current system DSSC policy, signed with current strong cryptographic means).
どちらの要素<cryptographicInformationList>および<Attribute>は、将来のアーカイブTime_Stampの更新によって保護されており、特定のアーカイブタイムスタンプの更新時以前に利用可能なセクション2.1で概説されているように情報を保存できます。更新時に、以前のすべてのアーカイブタイムスタンプデータ構造は、新しいアーカイブタイムスタンプによって保護され、それによって凍結されます。つまり、これらの要素にデータを追加または変更する必要はありません。ただし、一部のサポート情報が、後で利用可能になる全体的な証拠記録または情報に関連する場合、これは<supportinginformationList>要素の証拠記録で提供できます。<supportingInformatonList>のデータは後で証拠記録に追加できますが、たとえば現在の強力な暗号手段で署名したり、信頼できるソースによって提供されたりするなど、独自の信頼性と整合性保護メカニズムに依存する必要があります（たとえば、これは、現在の強力な暗号化手段で署名された現在のシステムDSSCポリシーを提供するLTAである可能性があります）。
For all IANA registrations related to this document, the "Specification Required" [RFC5226] allocation policies MUST be used.
このドキュメントに関連するすべてのIANA登録については、「必要な仕様」[RFC5226]割り当てポリシーを使用する必要があります。
This document defines the XML namespace "urn:ietf:params:xml:ns:ers" according to the guidelines in [RFC3688]. This namespace has been registered in the IANA XML Registry.
このドキュメントでは、[RFC3688]のガイドラインに従って、XMLネームスペース「urn：ietf：params：xml：ns：ers」を定義します。この名前空間は、IANA XMLレジストリに登録されています。
This document defines an XML schema (see Section 8) according to the guidelines in [RFC3688]. This XML schema has been registered in the IANA XML Registry and can be identified with the URN "urn:ietf:params:xml:schema:ers".
このドキュメントは、[RFC3688]のガイドラインに従ってXMLスキーマ（セクション8を参照）を定義しています。このXMLスキーマはIANA XMLレジストリに登録されており、urn「urn：ietf：params：xml：schema：ers」で識別できます。
This specification defines a new IANA registry entitled "XML Evidence Record Syntax (XMLERS)". This registry contains two sub-registries entitled "Time-Stamp Token Type" and "Cryptographic Information Type". The policy for future assignments to both sub-registries is "RFC Required".
この仕様では、「XML Evidence Record Syntax（XMLERS）」というタイトルの新しいIANAレジストリを定義しています。このレジストリには、「タイムスタンプトークンタイプ」と「暗号化情報タイプ」というタイトルの2つのサブリージストリが含まれています。両方のサブレジストリへの将来の割り当てのポリシーは「RFC必須」です。
The sub-registry "Time-Stamp Token Type" contains textual names and description, which should refer to the specification or standard defining that type. It serves as assistance when validating a Time-Stamp Token.
サブレジストリ「タイムスタンプトークンタイプ」には、テキスト名と説明が含まれています。これには、そのタイプを定義する仕様または標準を参照する必要があります。タイムスタンプトークンを検証する際の支援として役立ちます。
When registering a new Time-Stamp Token type, the following information MUST be provided:
新しいタイムスタンプトークンタイプを登録する場合、次の情報を提供する必要があります。
o The textual name of the Time-Stamp Token type (value). The value MUST conform to the XML datatype "xs:NMTOKEN".
o タイムスタンプトークンタイプ（値）のテキスト名。値は、XMLデータ型「XS：NMTOKEN」に準拠する必要があります。
o A reference to a publicly available specification that defines the Time-Stamp Token type (description).
o タイムスタンプトークンタイプ（説明）を定義する公開されている仕様への参照。
The initial values for the "Time-Stamp Token Type" sub-registry are:
「タイムスタンプトークンタイプ」サブレジストリの初期値は次のとおりです。
Value
Description
Reference
-------------
RFC3161 RFC3161 Time-Stamp RFC 3161
RFC3161 RFC3161タイムスタンプRFC 3161
XMLENTRUST EnTrust XML Schema http://www.si-tsa.gov.si/dokumenti/timestamp-protocol-20020207.xsd
XMLENTRUSTはXML Schema http://www.si-tsa.gov.si/dokumenti/timestamp-protocol-2002020207.xsd
The sub-registry "Cryptographic Information Type" contains textual names and description, which should refer to a specification or standard defining that type. It serves as assistance when validating cryptographic information such as digital certificates, CRLs, or OCSP-Responses.
サブレジストリ「暗号化情報タイプ」には、テキスト名と説明が含まれています。これには、そのタイプを定義する仕様または標準を参照する必要があります。デジタル証明書、CRL、OCSP応答などの暗号化情報を検証する際の支援として役立ちます。
When registering a new cryptographic information type, the following information MUST be provided:
新しい暗号情報情報タイプを登録する場合、次の情報を提供する必要があります。
o The textual name of the cryptographic information type (value). The value MUST conform to the XML datatype "xs:NMTOKEN".
o 暗号化情報タイプ（値）のテキスト名。値は、XMLデータ型「XS：NMTOKEN」に準拠する必要があります。
o A reference to a publicly available specification that defines the cryptographic information type (description).
o 暗号化情報タイプ（説明）を定義する公開されている仕様への参照。
The initial values for the "Cryptographic Information Type" sub-registry are:
「暗号化情報タイプ」のサブレジストリの初期値は次のとおりです。
Value Description Reference
----- ------------------ -----------------
CERT DER-encoded X.509 Certificate RFC 5280
CERT DER-ENCODED X.509証明書RFC 5280
CRL DER-encoded X.509 RFC 5280 Certificate Revocation List
CRL DER-ENCODED X.509 RFC 5280証明書の取り消しリスト
OCSP DER-encoded OCSPResponse RFC 2560
OCSP Der-Encoded OCSPRESPONSE RFC 2560
SCVP DER-encoded SCVP response RFC 5055 (CVResponse)
SCVP Der-Encoded SCVP応答RFC 5055（cvResponse）
[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月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、RFC 2560、1999年6月。
[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月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] EastLake 3rd、D.、Reagle、J。、およびD. Solo、 "（拡張可能なマークアップ言語）XML-Signature構文と処理"、RFC 3275、2002年3月。
[RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005.
[RFC4051] EastLake 3rd、D。、「追加のXMLセキュリティユニフォームリソース識別子（URIS）」、RFC 4051、2005年4月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007.
[RFC4998] Gondrom、T.、Brandner、R。、およびU. Pordesch、「証拠記録構文（ERS）」、RFC 4998、2007年8月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055] Freeman、T.、Housley、R.、Malpani、A.、Cooper、D。、およびW. Polk、「サーバーベースの証明書検証プロトコル（SCVP）」、RFC 5055、2007年12月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[XMLC14N] Boyer, J., "Canonical XML", W3C Recommendation, March 2001.
[XMLC14N] Boyer、J。、「Canonical XML」、W3C推奨、2001年3月。
[XMLDSig] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Roessler, T., "XML-Signature Syntax and Processing", XMLDSig, W3C Recommendation, July 2006.
[Xmldsig] Eastlake、D.、Reagle、J.、Solo、D.、Hirsch、F.、Roessler、T。、「XML-Signature構文と処理」、XMLDSIG、W3C推奨、2006年7月。
[XMLName] Layman, A., Hollander, D., Tobin, R., and T. Bray, "Namespaces in XML 1.0 (Second Edition)", W3C Recommendation, August 2006.
[XMLName] Layman、A.、Hollander、D.、Tobin、R。、およびT. Bray、「XML 1.0の名前空間（第2版）」、W3C推奨、2006年8月。
[XMLSchema] Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004.
[xmlschema]トンプソン、H。、ビーチ、D。、メンデルソーン、N。、およびM.マロニー、「XMLスキーマパート1：Structures Second Edition」、W3C推奨、2004年10月。
[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月。
[ETSI-TS-102-176-1-V2.0.0] 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 V2.0.0 (2007-11), November 2007.
[ETSI-TS-102-176-1-V2.0.0] ETSI、「電子署名とインフラストラクチャ（ESI）、安全な電子署名のためのアルゴリズムとパラメーター;パート1：ハッシュ関数と非対称アルゴリズム」、ETSI TS 102 176-1v2.0.0（2007-11）、2007年11月。
[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月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470] Hollenbeck、S.、Rose、M。、およびL. Masinter、「IETFプロトコル内の拡張マークアップ言語（XML）の使用に関するガイドライン」、BCP 70、RFC 3470、2003年1月。
[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月。
[RFC5126] Pinkas, D., Pope, N., and J. Ross, "CMS Advanced Electronic Signatures (CAdES)", RFC 5126, March 2008.
[RFC5126] Pinkas、D.、Pope、N。、およびJ. Ross、「CMS Advanced Electronic Signatures（Cades）」、RFC 5126、2008年3月。
[TS-ENTRUST] The Slovenian Time Stamping Authority, Entrust XML Schema for Time-Stamp, http://www.si-tsa.gov.si/ dokumenti/timestamp-protocol-20020207.xsd.
[TS-ENTRUST] The Slovenian Time Stamping Authority, Entrust XML Schema for Time-Stamp, http://www.si-tsa.gov.si/ dokumenti/timestamp-protocol-20020207.xsd.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[XAdES] Cruellas, J. C., Karlinger, G., Pinkas, D., Ross, J., "XML Advanced Electronic Signatures", XAdES, W3C Note, February 2003.
[Xades] Cruellas、J。C.、Karlinger、G.、Pinkas、D.、Ross、J。、「XML Advanced Electronic Signatures」、Xades、W3c Note、2003年2月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)", RFC 5698, November 2009.
[RFC5698] Kunz、T.、Okunick、S。、およびU. Pordesch、「暗号化アルゴリズム（DSSC）のセキュリティ適合性のためのデータ構造」、RFC 5698、2009年11月。
To verify the validity of an Evidence Record start with the first ATS till the last ATS (ordered by attribute Order) and perform verification for each ATS, as follows:
証拠レコードの妥当性を確認するには、最初のATSから最後のATS（属性順序で順序付けられます）から始まり、次のように各ATSの検証を実行します。
1. Select corresponding archive object and its data object or a group of data objects.
1. 対応するアーカイブオブジェクトとそのデータオブジェクトまたはデータオブジェクトのグループを選択します。
2. Re-encrypt data object or data object group, if the <EncryptionInformation> field is used (see Section 5 for more details)
2. <encryptionInformation>フィールドを使用する場合、データオブジェクトまたはデータオブジェクトグループを再クリップするか、詳細についてはセクション5を参照）
3. Get a canonicalization method C and a digest method H from the <DigestMethod> element of the current chain.
3. 現在のチェーンの<DigestMethod>要素から標準化方法Cと消化法Hを取得します。
4. Make a new list L of digest values of (binary representation of) objects (data, ATS, or sequence) that MUST be protected with this ATS as follows:
4. 次のように、このATSで保護する必要があるオブジェクト（データ、ATS、またはシーケンス）の（バイナリ表現）のダイジェスト値の新しいリストを作成します。
a. If this ATS is the first in the Archive Time-Stamp Chain:
a. このATSがアーカイブタイムスタンプチェーンで最初の場合の場合：
i. If this is the first ATS of the first ATSC (the initial ATS) in the ATSSeq, calculate digest values of data objects with H and add each digest value to the list L.
i. これがATSSEQの最初のATSC（初期ATS）の最初のATSである場合、hでデータオブジェクトのダイジェスト値を計算し、各ダイジェスト値をリストlに追加します。
ii. If this ATS is not the initial ATS, calculate a digest value with H of ordered ATSSeq without this and successive chains. Add value H and digest values of data objects to the list L.
ii。このATSが初期ATSではない場合は、このチェーンと連続したチェーンなしで、順序付けられたATSSEQのHでダイジェスト値を計算します。データオブジェクトの値をリストlに追加するlに追加します。
b. If this ATS is not the first in the ATSC:
b. このATSがATSCで最初のものではない場合：
i. Calculate the digest value with H of the previous <TimeSatmp> element and add this digest value to the list L.
i. 以前の<timesAtmp>要素のhでダイジェスト値を計算し、このダイジェスト値をリストlに追加します。
5. Verify the ATS's Time-Stamped value as follows. Get the first sequence of the hash tree for this ATS.
5. 次のように、ATSのタイムスタンプ値を確認します。このATSのハッシュツリーの最初のシーケンスを取得します。
a. If this ATS has no hash tree elements then:
a. このATSにハッシュツリー要素がない場合：
ii. If this ATS is not the first in the ATSSeq (the initial ATS), then the Time-Stamped value must be equal to the digest value of previous Time-Stamp element. If not, exit with a negative result.
ii。このATSがATSSEQ（初期ATS）の最初のものではない場合、タイムスタンプの値は、以前のタイムスタンプ要素のダイジェスト値に等しくなければなりません。そうでない場合は、否定的な結果で終了します。
iii. If this ATS is the initial ATS in the ATSC, there must be only one data object of the archive object. The digest value of that data object must be the same as its Time-Stamped value. If not, exit with a negative result.
iii。このATSがATSCの初期ATSである場合、アーカイブオブジェクトのデータオブジェクトは1つだけでなければなりません。そのデータオブジェクトのダイジェスト値は、そのタイムスタンプ値と同じでなければなりません。そうでない場合は、否定的な結果で終了します。
b. If this ATS has a hash tree then: If there is a digest value in the list L of digest values of protected objects, which cannot be found in the first sequence of the hash tree or if there is a hash value in the first sequence of the hash tree which is not in the list L of digest values of protected objects, exit with a negative result.
b. このATSにハッシュツリーがある場合：保護されたオブジェクトのダイジェスト値のリストLのダイジェスト値がある場合、ハッシュツリーの最初のシーケンスには見られない場合、または最初のシーケンスのハッシュ値がある場合保護されたオブジェクトのダイジェスト値のリストLにないハッシュツリーは、負の結果で終了します。
i. Get the hash tree from the current ATS and use H to calculate the root hash value (see Sections 3.2.1 and 3.2.2).
i. 現在のATSからハッシュツリーを取得し、Hを使用してルートハッシュ値を計算します（セクション3.2.1および3.2.2を参照）。
ii. Get Time-Stamped value from the Time-Stamp Token. If calculated root hash value from the hash tree does not match the Time-Stamped value, exit with a negative result.
ii。タイムスタンプトークンからタイムスタンプの値を取得します。ハッシュツリーから計算されたルートハッシュ値がタイムスタンプの値と一致しない場合、負の結果で終了します。
6. Verify Time-Stamp cryptographically and formally (validate the used certificate and its chain, which may be available within the Time-Stamp Token itself or <CryptographicInformation> element).
6. タイムスタンプを暗号化および正式に検証します（使用済みの証明書とそのチェーンを検証します。これらは、タイムスタンプトークン自体または<暗号化>要素内で利用可能です）。
7. If this ATS is the last ATS, check formal validity for the current time (now), or get "valid from" time of the next ATS and verify formal validity at that specific time.
7. このATSが最後のATSである場合、現在の時刻（現在）の正式な妥当性を確認するか、次のATSの時間から「有効」を取得し、その特定の時間に正式な妥当性を確認してください。
8. If the needed information to verify formal validity is not found within the Time-Stamp or within its Cryptographic Information section of ATS, exit with a negative result.
8. 正式な妥当性を検証するために必要な情報が、タイムスタンプ内またはATSの暗号化情報セクション内で見つからない場合は、否定的な結果で終了します。
Authors' Addresses
著者のアドレス
Aleksej Jerman Blazic SETCCE Tehnoloski park 21 1000 Ljubljana Slovenia
Aleksej Jerman Blazic Setcce Tehnoloski Park 21 1000 Ljubljana Slovenia
Phone: +386 (0) 1 620 4500
Fax: +386 (0) 1 620 4509
EMail: aljosa@setcce.si
Svetlana Saljic SETCCE Tehnoloski park 21 1000 Ljubljana Slovenia
Svetlana Saljic Setcce Tehnoloski Park 21 1000 Ljubljana Slovenia
Phone: +386 (0) 1 620 4506
Fax: +386 (0) 1 620 4509
EMail: svetlana.saljic@setcce.si
Tobias Gondrom Kruegerstr. 5A 85716 Unterschleissheim Germany
Tobias Gondrom Kruegerstr。5A 85716 Unterschleissheimドイツ
Phone: +49 (0) 89 320 5330
EMail: tobias.gondrom@gondrom.org