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)
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はASN.1（抽象構文記法1）ERS（証拠レコード構文）（RFC 4998）は、XMLを使用して構文に別の構文と処理ルールを提供します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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（Extensible Markup Language）形式で証拠レコード構文は、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.
電子商取引と、一般的に電子データ交換の進化は、データの存在の非repudiable証明の導入だけでなく、データの整合性と信頼性を必要とします。存在のようなデータと非repudiable証明はその存在と整合性を証明するために初期情報が弱まるか、または存在しなくなった場合でも、長時間耐えなければなりません。このような[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]で定義されるよう証拠レコード構文に基づいており、長期的にデータの有無とデータの整合性の実証の長期非repudiableプルーフの同じ問題に対処しています。 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の使用の地平線を広げると、そのような[XAdESの] [XMLDSIG]として、またはセキュリティ・サービスに関連するものを含む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.
[RFC4810]で定義されたXML形式の証拠を録音構文は、長期アーカイブサービス要件に基づいています。 XMLERSは同じ（のレベル）ASN.1 ERS [RFC4998]としてデータ有無の非repudiable証拠を提供します。 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]で定義されるようにタイムスタンプは、データの単一のユニットをカバーすることができ、タイムスタンプの長期安定性を維持するための処理ルールを提供するデータ・オブジェクトの上に適用されません。アーカイブオブジェクトの証拠は確実に1つ以上のデータ・オブジェクトに関連している特定の値のために信頼できる機関からタイムスタンプを取得することによって作成されます。この文書で指定されている複数のデータオブジェクトと単タイムスタンプ値との関係は、データ構造及び手順を用いて、ハッシュツリー、第マークル[MER1980]で以降、[RFC4998]に記載された技術を用いてアドレス指定されます。証拠録音構文は、ハッシュ木の技術を使用して、すべてのアーカイブオブジェクトを保護するための唯一のタイムスタンプを取得する単一の処理パスの中にいくつかのアーカイブオブジェクトの処理を可能にします。ハッシュツリーの葉は、グループ内のデータオブジェクトのハッシュ値です。タイムスタンプは唯一のハッシュツリーのルートハッシュのために要求されています。ツリー内のデータオブジェクトの削除は、他人の証明可能性に影響を与えません。任意の特定のデータオブジェクトに対して、ハッシュ木は、単一のデータ・オブジェクトの存在を証明するのに十分であるハッシュ値、数セットに低減することができます。同様に、ハッシュ木は、データグループのすべてのメンバーは、ハッシュツリーの同じ親ノードを有して設けられ、データ群の存在を証明するために低減することができます。アーカイブタイムスタンプは、オプションの減少ハッシュ木とタイムスタンプで構成されています。
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).
タイムスタンプのほかに他の成果物も証拠レコードに保存されています。必要なデータは、「ハッシュツリー」と呼ばれる構造に詰め込まタイムスタンプ値と特定のデータオブジェクト間の関係を、検証するために、との長期的な証明付属タイムスタンプ（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は、タイムスタンプトークン、検証のための有用なデータ、および必要に応じてハッシュ値の順序付けられたリストの集合（ハッシュ木）が含まれています。このデータ・オブジェクトのハッシュ値がアーカイブタイムスタンプの第1のハッシュ値のリストの一部であるか、またはそのハッシュ値をタイムスタンプ値と一致する場合、アーカイブタイムスタンプは、データ・オブジェクトに関する。それはグループのすべてのデータオブジェクトと他のデータ・オブジェクトに関連する場合のアーカイブタイムスタンプは、データオブジェクトのグループに関する（すなわち、すべてのハッシュ値が、グループの他のデータオブジェクトが第1のハッシュ値のリストの一部であります（セクション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.
証拠の録音：録音は、時間をかけて特定のアーカイブオブジェクト用にコンパイルされた証拠の収集である証拠。証拠の記録はATSCsとATSSeqsにグループ化されているのATS注文したコレクションを、含まれています。
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）：TSは、タイムスタンプ及びタイムスタンプと通信するためのプロトコルの構造を指定するタイムスタンプ局（TSA）、例えば、[RFC3161]、によって生成された暗号的に安全確認で権限。この他にも、他のデータ構造及びプロトコルはまた、[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
証拠レコードが特定の時間にアーカイブ・オブジェクト（単一のアーカイブ・データ・オブジェクト、またはアーカイブデータオブジェクト群）の存在を証明するために使用されるデータの単位です。アーカイブオブジェクトの有効期間を通じて、証拠の記録は、データオブジェクトの完全性と非repudiabilityを示しています。これを達成するために、暗号化手段が使用されている、すなわち、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構文で証拠は、レコードは、セクション8（「？」0または1の出現を示し、「+」意味で定義された完全なXMLスキーマによって擬似XMLで記述された以下の構造を有する<EvidenceRecord>ルート要素によって表され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>
<EncryptionInformation> <EncryptionInformationType> <EncryptionInformationValue> </ EncryptionInformation>？ <SupportingInformationList> <SupportingInformationタイプ/> + </ SupportingInformationList>？ <ArchiveTimeStampSequence> <ArchiveTimeStampChain注文> <DigestMethodアルゴリズム/> <CanonicalizationMethodにアルゴリズム/> <ArchiveTimeStamp注文> <HashTree />？ <タイムスタンプ> <TimeStampTokenの種類/> <CryptographicInformationList> <CryptographicInformation受注タイプ/> + </ CryptographicInformationList>？ </タイムスタンプ> <属性> + <受注タイプ/属性> </属性>？ </ 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スキーマ・ヘッダと、デフォルトの名前空間としてERS：IETF：paramsは：XML：NS証拠レコードの構文は、スキーマは、以下のXMLネームスペース[XMLNameの】URNを使用して、セクション8を参照して、XMLスキーマ[XMLスキーマ]のように定義されますセクション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]）または保存および証拠の検証に関する入力を提供することができるアーカイブポリシー、同様に、処理ポリシーであってもよいです。各データオブジェクトは、方向を処理するための、そのタイプを示すために、オプションのtype属性で、別の子要素<SupportingInformation>に入れています。概説したように、使用する種類記憶される情報構造の仕様またはこの規格で定義されなければなりません。 9.4節で概説したように、暗号化情報は、その3.1.3定義された型を使用しなければならない場合には、SupportingInformation要素に格納されてもよいです。またはセクション7暗号化ポリシー[RFC5698]で定義されるように、使用されるタイプは、関連するRFCに定義されている場合には、格納されてもよいです。サポート情報やポリシーがに関連するとのまたは個別の更新手順（例えば、DSSCの暗号化ポリシー[RFC5698]を示すために）個々の更新時に使用したこと）の時間の前に既に利用されている場合、彼らは保存しなければならないことに注意してくださいこのアーカイブタイムスタンプによって保護され整合性があるとして、<属性>に個々のアーカイブタイムスタンプの要素（下記参照）。全証拠LTAの現在の暗号化アルゴリズムのセキュリティ適合性ポリシー（DSSC、[RFC5698]のようなレコード（）に関連するか、それは更新時に利用できませんでした（そのため、後に保護された<属性に格納することができなかった情報をサポート>要素）は、この<SupportingInformation>要素に格納することができます。
<ArchiveTimeStampSequence> is REQUIRED and contains a sequence of one or more <ArchiveTimeStampChain>.
<ArchiveTimeStampSequence>必要とされ、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データオブジェクトまたは<ArchiveTimeStampSequence>又は<タイムスタンプ>値計算ダイジェスト行う前に要素にアーカイブデータに適用される正規化アルゴリズムを指定する必要な要素です。
<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>.
<タイムスタンプ>必要とされ、タイムスタンプ局と任意の要素<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>このようなデータはタイムスタンプトークン自体によって提供されない場合にはタイムスタンプトークンの検証の過程で必要なデータの記憶を可能にする任意の要素です。これは、可能なトラストアンカー、証明書、失効情報、または暗号化アルゴリズム、過去と現在の適性の現在の定義を含めることができます。各データオブジェクトは、その親要素内での順序を示すために必要な順序属性で、別の子要素<CryptographicInformation>に入れています。これらのアイテムは、使用されるポリシーに基づいて添加してもよいです。このデータはアーカイブタイムスタンプの順に連続したタイムスタンプにより保護されています。
<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]）、またはアーカイブポリシー、処理ポリシーであってもよいです。そのようなポリシーは、後の段階でデータオブジェクト（複数可）の保存及び証拠の検証に関連する入力を、提供することができます。各データオブジェクトは、要求された順序で処理する方向を示すために、親要素とオプションのtype属性内の順序を示すために、属性、別の子要素<属性>に入れています。使用されるタイプは、情報構造の仕様で定義されなければなりません。例えば、暗号化ポリシーを保存するときに使用するタイプ[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」<ArchiveTimeStampSequence>構造で同じレベルで発生したときの順序属性は、すべてのケースで必要とされます。 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>を作成します。これは、<ArchiveTimeStampSequence>要素の最初の<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).
アプリケーションはまた、等証明書失効リスト、確認及び署名されたデータオブジェクトまたはデータオブジェクトのグループを検証するために必要な証拠を提供してもよいです。この証拠は、アーカイブデータオブジェクトグループに追加することができ、初期の（連続する）タイムスタンプ（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>要素は、署名されたアーカイブ・データに関連する暗号化材料を保存及び保護するために使用されるべきではないことに留意されたいです。この要素の使用は、タイムスタンプ（S）に関連する暗号化材料に限定されます。
The overall verification of an Evidence Record MUST be as follows:
次のように証拠レコードの全体的な検証がなければなりません。
2. Re-encrypt data object or data object group, if encryption field is used (for details, see Section 5).
前記再暗号化データオブジェクトまたはデータオブジェクトのグループ、暗号化フィールドを使用する場合（詳細については、セクション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>
<HashTree> <シーケンス順序> <DigestValue> BASE64符号化されたハッシュ値</ DigestValue> + </シーケンス> + </ 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>要素から生成されるアルゴリズムである：最初の<sequence>要素内の各<DigestValue>要素の内容は、base64（[RFC4648]、BASE64のアルファベットを使用しないbase64urlアルファベットであります））ハッシュ値を表す（バイナリ値を取得するために復号されます。シーケンスから収集したすべてのハッシュ値は、バイナリの昇順に並べられ連結され、新しいハッシュ値がその文字列から生成されています。この規則の一つの例外を除いて第一の<sequence>要素が一つだけ<DigestValue>要素を有する場合、そのバイナリ値は、次の<sequence>要素から得られる次のリストに追加されます。
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.
新たに計算されたハッシュ値は、次の<sequence>要素と残された<シーケンス>要素が存在しない、すなわち、左側のみ1つのハッシュ値が存在するまで、前のステップが繰り返されるから得られたハッシュの次のリストに追加されます。最後に計算されたハッシュ値は、ルートハッシュ値です。アーカイブ・オブジェクトが基であり、複数のデータ・オブジェクトからなる場合、第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ビットのメッセージダイジェストのHEXエンコードされた値であることに注意）を使用して、例を続けるために、そのbase64で表現は次のようになり<DigestValue> qZk + NkcGgWq6PiVxeFDCbJzQ2J0 = </ DigestValue>。
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タイムスタンプのための標準が存在しないであり、以下の構造の例は、このような時間 - のようなタイムスタンプ特定データを含む[XMLDSIG]仕様に準拠したデジタル署名である、[TS-ENTRUST]設けられているので署名の<OBJECT>要素内の値と時間刻印。
<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>
<要素名= "TimeStampInfo"> <complexTypeの> <シーケンス> <要素REF = "ポリシー" /> <要素REF = "ダイジェスト" /> <要素REF = "のSerialNumber" のminOccurs = "0" /> <要素REF = "CREATIONTIME" /> <要素REF = "精度" のminOccurs = "0" /> <要素REF = "注文" のminOccurs = "0" /> <要素REF = "ノンス" のminOccurs = "0" /> <要素REF = "拡張" のminOccurs = "0" /> </配列> </ complexTypeの> </要素>
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.
TSAによって提供されるATSの<タイムスタンプ>要素は、タイムスタンプトークンの完全な構造を保持しています。タイムスタンプトークンは、XMLまたはASN.1形式であってもよいです。属性タイプは、それぞれ値「XMLENTRUST」または「RFC3161」で、処理目的のためのフォーマットを示すために使用されなければなりません。 RFC3161タイプタイムスタンプトークンは、<タイムスタンプ>要素は、DERエンコードASN1データのbase64エンコードを含まなければなりません。これらのタイプの値はIANAによって登録されている（セクション10を参照）。 （将来のXMLのタイムスタンプの標準のため特に）タイムスタンプの未来型のサポートについては、これらは、そこにも登録する必要があります。
For example:
例えば：
<TimeStamp Type="RFC3161">MIAGCSqGSIb3DQEH...</TimeStamp>
<タイムスタンプのタイプ= "RFC3161"> MIAGCSqGSIb3DQEH ... </タイムスタンプ>
or
または
<TimeStamp Type="XMLENTRUST"><dsig:Signature>...</dsig:Signature> </TimeStamp>
<タイムスタンプのタイプ= "XMLENTRUST"> <DSIG：署名> ... </ DSIG：署名> </タイムスタンプ>
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
デジタル証明書、CRLの（証明書失効リスト）は、SCVP（サーバーベースの証明書の検証議定書）、タイムスタンプトークンを検証するために必要に応じて、またはOCSP-応答（オンライン証明書状態プロトコル）は、タイムスタンプトークン自体に格納する必要があります。これができない場合は、そのようなデータをに保存することができます
<CryptographicInformationList> element; each data object is stored into a separate <CryptographicInformation> element, with a REQUIRED Order attribute.
<CryptographicInformationList>要素。各データオブジェクトは、必要な順序属性と、個別の<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:
属性タイプは必要とされ、格納された暗号化情報の種類に関する処理情報を格納するために使用されます。 type属性は、識別子として、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のbase64エンコーディング[RFC2560]
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]
型CERTのために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要素の生成は、いずれかの又は多くのアーカイブ・オブジェクトの単一の処理パスで行うことができます。次の手順で説明するようにそれを実行する必要があります。
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.
ハッシュツリーのルートハッシュ値のためのTSAから5.獲得タイムスタンプトークン（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.
<シーケンス>要素内の<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.
ある場合は、アーカイブオブジェクトのダイジェスト値は、そのデータオブジェクトのダイジェスト値である：セキュアハッシュアルゴリズムHを選択し、データ・オブジェクトのダイジェスト値を計算すると、以下のようにハッシュツリーの入力リストに入れて2。アーカイブオブジェクトで唯一のデータオブジェクト。アーカイブ・オブジェクトに複数のデータ・オブジェクトが存在する場合、ダイジェスト値がソートバイナリのダイジェスト値である（すなわち、それは、アーカイブデータオブジェクトグループである）、そのすべてを含むデータ・オブジェクトの値をダイジェスト連結。
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.
アーカイブ・オブジェクト・グループのために（複数のデータオブジェクトを有する）ことに注意し、リストのその部分のダイジェスト値が格納され、そのアーカイブ・オブジェクトの減少ハッシュツリーを作成する場合、後で、それらは第1のハッシュリストのメンバーになるであろう。
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の順序によって入力リスト内の項目と各グループのために：バイナリ昇順ソート、連結、および計算ハッシュ値。結果は次のリストのための新たな入力です。改良された処理のためには、各ノードの子の数が同じであることが推奨されます。この目的のためには、すべてのノードは、子どもの数が同じにするために、任意の値を使用してツリーを延長することができます。
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.ステップ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.
例：H'1は、データオブジェクトのグループのために生成された18個のハッシュ値、（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.
選択されたアーカイブ・オブジェクト（AO）について1.ハッシュツリーの葉内にそのハッシュ値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.
最初の<sequence>要素内の新しい<DigestValue>要素のBASE64符号化されたテキスト値として2プットH。選択されたAOは、データオブジェクトグループである場合、最初の<sequence>要素は、この場合には別個の<DigestValue>要素内のすべてのAOデータオブジェクトのハッシュ値を、各々から形成されなければならない、（すなわち、複数のデータオブジェクトを有します） 。
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.
ハッシュ値hと同じ父親のノードを持つすべてのハッシュ値を選択します。 1により、そのオーダー属性値を増加させる、新しい<シーケンス>要素内の新しい<DigestValue>要素のBASE64符号化されたテキスト値としてそれぞれを、これらのハッシュ値を置きます。
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).
各<シーケンス>要素内の<DigestValue>要素の順序は、（BASE64復号された値によって）バイナリ昇順でなければなりません。
Reduced hash tree for data object d4 (from the previous example, presented in Figure 1):
（図1に示す前の例からの）データオブジェクトD4用減少ハッシュツリー：
<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>
<HashTree> <配列順序= '1'> <DigestValue> base64で符号化されたH4 </ DigestValue> <DigestValue> base64で符号化されたH5 </ DigestValue> <DigestValue> base64で符号化されたH6 </ DigestValue> <DigestValue> base64で符号化されたH7 </ DigestValue > </シーケンス> <配列順序= '2'> <DigestValue> base64で符号化されたH8 </ DigestValue> <DigestValue> base64で符号化されたH9 </ DigestValue> </シーケンス> <配列順序= '3'> <DigestValue> Base64で符号化されましたh''1 </ DigestValue> <DigestValue> base64で符号化されたh''3 </ DigestValue> </シーケンス> <配列順序= '4'> <DigestValue> base64で符号化さH '' '2 </ DigestValue> </シーケンス> </ HashTree>
Reduced hash tree for data object d2 (from the previous example, presented in Figure 1):
（図1に示す前の例からの）データオブジェクトD2に対して減少ハッシュツリー：
<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>
<HashTree> <配列順序= '1'> <DigestValue> base64で符号化されたH2 </ DigestValue> </シーケンス> <配列順序= '2'> <DigestValue> base64で符号化されたH1 </ DigestValue> <DigestValue> base64で符号化されたH3 < / DigestValue> </シーケンス> <配列順序= '3'> <DigestValue> base64で符号化されたh''2 </ DigestValue> <DigestValue> base64で符号化されたh''3 </ DigestValue> </シーケンス> <配列順序=」 4 '> <DigestValue> base64で符号化さH' '' 2 </ DigestValue> </シーケンス> </ 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.（<DigestMethod>要素）から、ハッシュアルゴリズムHを特定し、アーカイブオブジェクトの各データオブジェクトのハッシュ値を計算します。
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.ハッシュツリーが存在する場合、最初の<sequence>要素内のハッシュ値の検索。ハッシュ値が存在しない場合は、否定的結果と照合処理を終了します。検証当事者は、（例えば、ドキュメントとそのすべてのデジタル署名が）、それはまたことを確認する必要がありますアーカイブタイムスタンプは、データオブジェクトグループに関連する追加の証拠を求めた場合のメンバーであるデータオブジェクトの唯一のハッシュ値所与のデータオブジェクトグループは、第1のハッシュ値のリストです。
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>要素に含まれる（付加情報及びタイムスタンプ更新処理の詳細については、セクション4.2.1、セクション9.4を参照）。現在（最新）のタイムスタンプ）については、（最新）のタイムスタンプのフォーマル検証のための情報は、タイムスタンプ局によって提供されるべきです。この情報はまた、任意のタイムスタンプによって保護されていない<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.
アーカイブタイムスタンプチェーンとアーカイブタイムスタンプのシーケンスは、更新プロセスを経て生成されたアーカイブタイムスタンプ（S）のシーケンスのためのコンテナです。証拠の記録素子の直列更新処理結果<ArchiveTimeStampSequence>要素は、<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
タイムスタンプの更新の場合、最後の<ArchiveTimeStampChain>要素のシーケンスの最後の<ArchiveTimeStamp>子要素として、またはO
o as the first <ArchiveTimeStamp> child element in a sequence of the newly created <ArchiveTimeStampChain> element in case of hash tree renewal.
ハッシュツリーの更新の場合は、新しく作成された<ArchiveTimeStampChain>要素のシーケンスの最初の<ArchiveTimeStamp>の子要素として、O。
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は、最新の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:
Algorithm属性は、[RFC3275]及び[RFC4051]で定義されるように使用されなければならない識別子のURI [RFC3986]を含んでいます。例えば、SHA-1アルゴリズムを使用した場合、アルゴリズム識別子です。
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestMethodアルゴリズム= "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要素または要素のバイナリ表現を得るために使用される正規化アルゴリズムを識別する必須要素です。 [RFC3275]及び[RFC4051]で定義されるようにアルゴリズム識別子（URIが）使用されなければなりません。例えば、カノニカルXML 1.0（コメントは省略）が使用される場合、アルゴリズム識別子であります
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<CanonicalizationMethodにアルゴリズム= "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>要素内の<CanonicalizationMethodに>要素の<アルゴリズム>属性で指定され、そのアーカイブタイムスタンプ鎖内のアーカイブタイムスタンプのすべてのバイナリ表現のために使用しなければならない正規化の方法を示しています。後続ATSCの場合にはATSC内に示さ正規化方法は、また、前述のATSCのダイジェスト値の算出に使用されなければなりません。正規化の方法は、それがダイジェストメソッドと同じ制約を課さないように時間とともに変化する可能性は低いであることに注意してください。理論的には、同じ正規化方法は、全体のアーカイブタイムスタンプのシーケンスのために使用することができます。別の正規化の方法を使用することができるが、[XMLC14N] C14N-20010315を使用することが推奨されます。
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 '）、最後の完全なコンテンツを<ダイジェストと同じですタイムスタンプ>要素は、タイムスタンプと、次のように作成した新しい<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>要素は、<タイムスタンプ>要素内でそのタイムスタンプトークンの長期的なフォーマルな検証のために必要な証拠が含まれているなどのルート証明書、証明書失効リスト、など必要なデータを収集し、含まれていない場合最後のアーカイブタイムスタンプの<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. <CanonicalizationMethodに>要素からの正規化方法を選択し、<DigestMethod>要素からダイジェストアルゴリズムを選択します。加え暗号化情報を含む最後の<ArchiveTimeStamp>要素の<タイムスタンプ>要素の二進表現からハッシュ値を計算します。計算されたハッシュ値のタイムスタンプを取得します。タイムスタンプが有効である場合は、新しいアーカイブタイムスタンプを生成することができます。
3. Increase the value order of the new ATS by one and place the new ATS into the last <ArchiveTimeStampChain> element.
3. 1で新しいATSの値の順序を増やし、最後の<ArchiveTimeStampChain>要素に新しいATSを配置します。
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.一個の以上のアーカイブオブジェクトに更新すると、現在の<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に含めます最後のアーカイブタイムスタンプの>要素（各データが別々の<CryptographicInformation>要素にオブジェクト）。
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は、アーカイブ・オブジェクトに対応する、<ArchiveTimeStampSequence>要素のバイナリ表現からハッシュ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.（ハッシュツリー生成および低減がセクション3.2.1と3.2.2で定義されている）各H（j）のための新しいアーカイブタイムスタンプを作成します。各H（j）は、セクション3.2.1の文書ハッシュとして扱われることに留意されたいです。縮小ハッシュツリーの第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.（注文番号1）新しい<ArchiveTimeStampChain>含む新しい<ArchiveTimeStamp>要素を作成し、1ずつ増加注文番号と最後の子として既存の<ArchiveTimeStampSequence>にそれを置きます。
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
TO
/ | \
／ ｜ ￥
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.
H（D1）、H（D2）、...、H（DN）、H（ATSSeq）：新たなATSのハッシュツリーを生成する際に、第一の配列の値になります。注意：ハッシュ値は、バイナリの昇順にソートされなければなりません。
<HashTree> <Sequence Order='1'> <DigestValue>H(d1)</DigestValue> <DigestValue>H(d2)</DigestValue> <DigestValue>H(d3)</DigestValue> <DigestValue>H(ATSSeq)</DigestValue> </Sequence> </HashTree>
<HashTree> <配列順序= '1'> <DigestValue> H（D1）</ DigestValue> <DigestValue> H（D2）</ DigestValue> <DigestValue> H（D3）</ DigestValue> <DigestValue> H（ATSSeq ）</ DigestValue> </シーケンス> </ 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は、互いに有効とATSCsとそれらの関係であることが証明されなければならい。
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
1. <EncryptionInformation>フィールドが使用されている場合は、アーカイブオブジェクトおよび再暗号化、データオブジェクトまたはデータオブジェクトのグループを選択します。最初のアーカイブ内で指定された初期のダイジェストアルゴリズムを選択します
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.
タイムスタンプチェーンおよびアーカイブオブジェクトのハッシュ値を計算します。最初のアーカイブタイムスタンプは（同じ）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.各アーカイブタイムスタンプチェーンと内の各アーカイブタイムスタンプを検証します。ハッシュツリーは第二およびアーカイブタイムスタンプチェーンの次のアーカイブタイムスタンプ、最初の内に存在する場合、<シーケンス>前<タイムスタンプ>要素のハッシュ値を含まなければなりません。各アーカイブタイムスタンプは、後続のアーカイブタイムスタンプの時間に対して有効でなければなりません。アーカイブタイムスタンプのチェーンを持つすべてのアーカイブタイムスタンプは、後続のアーカイブタイムスタンプチェーンの最初のアーカイブタイムスタンプの時点で、セキュアた同じハッシュアルゴリズムを使用する必要があります。
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.すべての後続のアーカイブタイムスタンプ鎖の最初のアーカイブタイムスタンプの第1のハッシュ値のリストは、データオブジェクトと前のアーカイブタイムスタンプ鎖のアーカイブタイムスタンプシーケンスのハッシュ値のハッシュ値が含まれていることを確認。前のアーカイブタイムスタンプチェーンの最後のアーカイブタイムスタンプが有効であったとき、アーカイブタイムスタンプが作成されたことを確認します。
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.
前記第1のアーカイブタイムスタンプ鎖の最初のアーカイブタイムスタンプはのハッシュ値よりも、その第1のハッシュ値リスト内の他のハッシュ値を含んでいないことを確認し、アーカイブタイムスタンプのシーケンスは、データオブジェクトグループに関する証明しますこれらのデータオブジェクト。
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.
暗号化は、その結果使用される暗号化材料、例えば、暗号化キーと暗号化アルゴリズムに依存する双方向のプロセスです。暗号化と復号化鍵だけでなく、アルゴリズムは、暗号化された元のメッセージやデータを再構成するために一致している必要があります。暗号化されたデータの存在を証明するために生成された証拠は、常に暗号化されていないデータが存在することを証明するために依拠することはできません。異なる暗号化物質、即ち、アルゴリズムまたは暗号化に使用されるアルゴリズム又は鍵はない復号化のための鍵を選択することも可能です。この場合、証拠の記録は暗号化されていないデータのための否認防止の証拠ではないでしょう。したがって、唯一の暗号化方式は、そのアーカイブのタイムスタンプを証明することを可能にすることに使用されなければならない明確に暗号化されていないデータ・オブジェクトを表すデータオブジェクトを暗号化。証拠は、暗号化に使用される対応するアルゴリズムと復号鍵証拠記録の一部にならなければならない暗号化データの存在を証明するために生成されたと明確に暗号化された元の（暗号化されていない）データを表すために使用されている場合には。 （注意：また、暗号化方式の長期的なセキュリティは、衝突攻撃を作成するために使用することができるかどうかを決定するために分析されなければならない）クライアントがアーカイブサービスプロバイダに暗号化されたデータを送信すると、暗号化材料はシナリオでも使用することができます保存のためしかし、店舗、自分自身だけで暗号化されていない形式のデータ。そのようなシナリオでは、暗号化材料は、クライアントのデータの暗号化された形式に関連している証拠レコードの検証を行う目的のために、クライアントによって保持暗号化されていないデータを再暗号化するために使用されます。 OPTIONAL拡張可能構造は、<EncryptionInformation>暗号化方法の必要なパラメータを格納するために定義されています。その<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バージョンの番号付けスキームは、「<主要な>。<マイナー>」です。メジャー番号とマイナー番号は、別々の整数として扱わなければならないと、それぞれ番号が一桁以上高い増分することができます。このように、「2.4」今度は「12.3」よりも低くなると思われる、「2.13」よりも低いバージョンになります。先頭のゼロ（例えば、「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"/>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのxmlns：XSの= "http://www.w3.org/2001/XMLSchema" のxmlns = "壷：IETF：のparams：XML ：NS：ERS」のtargetNamespace = "壷：IETF：のparams：XML：NS：ERS" のelementFormDefault = "資格" attributeFormDefault = "非修飾"> <XS：要素名= "EvidenceRecord" タイプ= "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の名前= "EvidenceRecordType"> <XS：配列> <XS：要素名= "EncryptionInformation" タイプ= "EncryptionInfo" のminOccurs = "0" /> <XS：要素名= "SupportingInformationList" タイプ= "SupportingInformationType" minOccurs = "0" /> <XS：要素名は= "ArchiveTimeStampSequence" タイプ= "ArchiveTimeStampSequenceType" /> </ XS：シーケンス> <XS：属性名= "バージョン" タイプ= "XS：小数点以下" 利用= "必要"固定= "1.0" /> </ XS：complexTypeの>
<xs:complexType name="EncryptionInfo"> <xs:sequence> <xs:element name="EncryptionInformationType" type="ObjectIdentifier"/> <xs:element name="EncryptionInformationValue">
<XS：complexTypeの名= "EncryptionInfo"> <XS：配列> <XS：要素名= "EncryptionInformationType" タイプ= "ObjectIdentifier" /> <XS：要素名= "EncryptionInformationValue">
<xs:complexType mixed="true"> <xs:sequence> <xs:any minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>
<XS：complexTypeの混合= "真"> <XS：配列> <XS：任意のminOccurs = "0" /> </ XS：配列> </ XS：complexTypeの> </ XS：要素> </ XS：配列> </ 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の名前= "ArchiveTimeStampSequenceType"> <XS：配列> <XS：要素名= "ArchiveTimeStampChain" のmaxOccurs = "無制限"> <XS：complexTypeの> <XS：配列> <XS：要素名= "DigestMethod" タイプ= "DigestMethodType" /> <XS：要素名= "CanonicalizationMethodに" TYPE = "CanonicalizationMethodType" /> <XS：要素名= "ArchiveTimeStamp" タイプ= "ArchiveTimeStampType" のmaxOccurs = "無制限" /> </ XS：配列> < XS：属性名は= "注文" タイプ= "OrderType" 使用= "必須" /> </ XS：complexTypeの> </ XS：要素> </ XS：シーケンス> </ 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の名前= "ArchiveTimeStampType"> <XS：配列> <XS：要素名= "HashTree" タイプ= "HashTreeType" のminOccurs = "0" /> <XS：要素名= "タイムスタンプ" タイプ= "TimeStampType" /> <XS：要素名= "属性" タイプ= "属性" のminOccurs = "0" /> </ XS：シーケンス> <XS：属性名= "注文" タイプ= "OrderType" 使用= "必要" /> </ 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の名= "DigestMethodType" 混合= "真の"> <XS：シーケンス> <XS：任意の名前空間= "##他" のminOccurs = "0" /> </ XS：シーケンス> <XS：属性名= "アルゴリズム" タイプ= "XS：anyURIの" 使用= "必須" /> </ XS：complexTypeの>
<xs:complexType name="CanonicalizationMethodType" mixed="true"> <xs:sequence minOccurs="0"> <xs:any namespace="##any" minOccurs="0"/>
<XS：complexTypeの名= "CanonicalizationMethodType" 混合= "真の"> <XS：シーケンスのminOccurs = "0"> <XS：任意の名前空間= "##あらゆる" のminOccurs = "0" />
</xs:sequence> <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/> </xs:complexType>
</ XS：シーケンス> <XS：属性名= "アルゴリズム" タイプ= "XS：anyURIの" 使用= "必須" /> </ 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の名前= "TimeStampType"> <XS：配列> <XS：要素名= "TimeStampTokenの"> <XS：complexTypeの混合= "真"> <XS：complexContentを混在= "真"> <XS：制限ベース= "XS：anyTypeの"> <XS：シーケンス> <XS：どんなのprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "タイプ" タイプ= "XS：NMTOKEN" 使用= "必須" /> </ XS：制限> </ XS：complexContentを> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "CryptographicInformationList" タイプ= "CryptographicInformationType" minOccurs = "0" /> </ XS：シーケンス> </ XS：complexTypeの> <XS：complexTypeの名は= "HashTreeType"> <XS：シーケンス> <XS：要素名= "シーケンス" のmaxOccurs = "無制限"> < XS：complexTypeの> <XS：シーケンス> <XS：要素名= "DigestValue" タイプ= "XS：base64Binaryの" maxOccursの= "無制限" /> </ XS：シーケンス> <XS：属性名= "注文" タイプ=」 OrderType」使用= "必須" /> </ XS：complexTypeの> </ XS：要素> </ XS：配列> </ 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：complexTypeの名前は= "属性"> <XS：シーケンス> <XS：要素名= "属性" のmaxOccurs = "無制限"> <XS：complexTypeの混合= "真の"> <XS：complexContentを混在= "true" を> <XS：制限ベース= "XS：anyType型"> <XS：配列> <XS：任意のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" />
</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：シーケンス> <XS：属性名= "注文" タイプ= "OrderType" 使用= "必要" /> <XS：属性名= "タイプ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：制限> </ XS：complexContentを> </ XS：complexTypeの> </ XS：要素> </ XS：配列> </ XS：complexTypeの> <XS：complexTypeの名= "CryptographicInformationType"> <XS：配列> <XS：要素名= "CryptographicInformation" のmaxOccurs = "無制限"> <XS：complexTypeの混合= "真"> <XS：complexContentを混在= "真"> <XS：制限ベース= "XS：anyType型"> <XS ：シーケンス> <XS：どんなのprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "注文" タイプ= "OrderType" 使用= "必要" / > <XS：属性名は= "タイプ" タイプ= "XS：NMTOKEN" 使用= "必須" /> </ XS：制限> </ XS：complexContentを> </ XS：complexTypeの> </ XS：要素> </ XS：シーケンス> </ 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の名前= "SupportingInformationType"> <XS：配列> <XS：要素名= "SupportingInformation" のmaxOccurs = "無制限"> <XS：complexTypeの混合= "真"> <XS：complexContentを混在= "TRUE"> <XS：制限ベース= "XS：anyTypeの"> <XS：シーケンス> <XS：どんなのprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "タイプ" タイプ= "XS：文字列" 使用= "必須" /> </ XS：制限> </ XS：complexContentを>
</xs:complexType> </xs:element> </xs:sequence> </xs:complexType>
</ XS：complexTypeの> </ XS：要素> </ XS：配列> </ 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：単純型名= "ObjectIdentifier"> <XS：制限ベース= "XS：トークン"> <XS：パターン値= "[0-2]（\ [1-3] [0-9]（。？ \ \ D +）*） "/> </ XS：。？制限> </ XS：単純>
<xs:simpleType name="OrderType"> <xs:restriction base="xs:int"> <xs:minInclusive value="1"/> </xs:restriction> </xs:simpleType> </xs:schema>
<XS：単純型名= "OrderType"> <XS：制限ベース= "XS：INT"> <XS：のminInclusive値= "1" /> </ XS：制限> </ XS：単純> </ XS：スキーマ>
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は、同じ暗号化アルゴリズムを使用しています。 （例えば、そして唯一のアーカイブタイムスタンプ）のみ1 TSAのセキュリティを損なう可能性がTSAの秘密鍵の妥協は、同時に多くの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によって提供されたセキュリティポリシーに記載依存します。リニューアルアーカイブタイムスタンプは、アーカイブデータの初期アーカイブタイムスタンプと同等以上の品質を持っていなければなりません。署名したアーカイブデータに使用されるアーカイブタイムスタンプは、署名の最高品質と同等以上の品質を持つべきである（SHOULD）。
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.
新しいタイムスタンプが適用されるとき、それは確認しなければならないことを更新し、検証のために考慮することが重要であるという更新時に先立って（すなわち、新しいタイムスタンプが適用される場合）は、現在の時間 - 前の証明書スタンプが原因鍵の危殆化に取り消されていませんでした。それ以外の場合は、鍵の危殆化の場合には、使用済みのタイムスタンプの真正性とは、したがって、証拠の連鎖でその安全性が保証されないおそれがあります。その場合にはタイムスタンプユニットの秘密鍵が以前に破壊されてしまうので、使用も妥協することはできませんとしての活動の中止の失効のような他の失効理由は、必ずしも、このリスクをもたらすことはありません。
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>と<属性>は、将来のアーカイブ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]のガイドラインに従って "ERS：IETF：のparams：XML：：NS壷" この文書は、XML名前空間を定義します。この名前空間は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]のガイドラインに従って（セクション8を参照）XMLスキーマを定義します。このXMLスキーマは、IANAのXMLレジストリに登録されているとURN「URN：IETF：のparams：XML：スキーマ：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の証拠録音構文（XMLERS）」と題した新しいIANAレジストリを定義します。このレジストリは、「タイムスタンプトークンの種類」と「暗号情報タイプ」と題する二つのサブレジストリが含まれています。両方のサブレジストリへの将来の割り当てのための政策は、「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データ型「：NMTOKEN XS」に従わなければなりません。
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スキーマhttp://www.si-tsa.gov.si/dokumenti/timestamp-protocol-20020207.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データ型「：NMTOKEN XS」に従わなければなりません。
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でエンコードされたX.509証明書のRFC 5280
CRL DER-encoded X.509 RFC 5280 Certificate Revocation List
CRL DERでエンコードされたX.509 RFC 5280証明書失効リスト
OCSP DER-encoded OCSPResponse RFC 2560
OCSP 2560 OCSPResponse RFC DERでエンコードされました
SCVP DER-encoded SCVP response RFC 5055 (CVResponse)
SCVP DER符号化されたSCVP応答RFC 5055（CVResponse）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、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]アダムス、C.、カイン、P.、ピンカス、D.、およびR. Zuccherato、 "インターネット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]イーストレーク3、D.、Reagle、J.、およびD.ソロ "（拡張マークアップ言語）、XML署名の構文および処理"、RFC 3275、2002年3月。
[RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005.
[RFC4051]イーストレーク第3、D.、 "追加のXMLセキュリティユニフォームリソース識別子（URI）"、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]フリーマン、T.、Housley氏、R.、Malpani、A.、クーパー、D.、およびW.ポーク、 "サーバーベースの証明書の検証プロトコル（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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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]ボイヤー、J.、 "正規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]イーストレーク、D.、Reagle、J.、ソロ、D.、ハーシュ、F.、レスラー、T.、 "XML-署名構文と処理"、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の]素人、A.、オランダ、D.、トービン、R.、およびT.ブレイ、 "XML 1.0での名前空間（第二版）"、W3C勧告、2006年8月。
[XMLSchema] Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004.
[XMLスキーマ]トンプソン、H.、ブナ、D.、メンデルゾーン、N.、およびM.マロニー、 "XMLスキーマパート1：構造第二版"、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-1 V2.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]マークル、R.、 "公開鍵暗号のプロトコル、セキュリティとプライバシー（オークランド、CA、USA）の1980 IEEEシンポジウム"、ページ122から134、1980年4月。
[NIST.800-57-Part1.2006] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revised)", NIST 800-57 Part1, May 2006.
[NIST.800-57-Part1.2006]米国国立標準技術研究所、 "キー管理のための提言 - パート1：一般（改訂）"、NIST 800-57パート1、2006年5月。
[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]ホレンベック、S.、ローズ、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]ウォレス、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]ピンカス、D.、法王、N.、およびJ.ロス、 "CMS高度な電子署名（な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]タイムスタンプ、http://www.si-tsa.gov.si/ dokumenti /タイムスタンプ・プロトコル20020207.xsdためスロベニアタイムスタンプ局、EntrustのXMLスキーマ。
[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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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.、ピンカス、D.、ロス、J.、 "XML高度な電子署名"、XAdESの、W3Cノート、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]クンツ、T.、Okunick、S.、およびU. Pordesch、 "暗号アルゴリズムのセキュリティ適性（DSSC）のためのデータ構造"、RFC 5698、2009年11月。
Appendix A. Detailed Verification Process of an Evidence Record
証拠レコードの付録A.詳細な検証プロセス
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)
<EncryptionInformation>フィールドが使用される場合2.再暗号化データオブジェクトまたはデータオブジェクトのグループは、（詳細については、セクション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で保護されなければならないのダイジェスト値の新しいリストL（のバイナリ表現）を行います。
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.
私。これは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でダイジェスト値を計算します。値Hを追加し、リスト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.
私。以前の<タイムスタンプ>要素の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がある場合は、アーカイブオブジェクトの一つだけのデータオブジェクトが存在しなければなりません。そのデータ・オブジェクトのダイジェスト値は、そのタイムスタンプ値と同じでなければなりません。そうでない場合は、否定的な結果で終了。
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).
私。現在の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.（タイムスタンプトークン自体又は<CryptographicInformation>要素内で利用可能なものが使用される証明書と、そのチェーンを検証する）暗号と正式にタイムスタンプを確認します。
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テクノロジーパーク21 1000年リュブリャナスロベニア
Phone: +386 (0) 1 620 4500 Fax: +386 (0) 1 620 4509 EMail: aljosa@setcce.si
電話番号：+386（0）1 620 4500ファックス：+386（0）1 620 4509 Eメール：aljosa@setcce.si
Svetlana Saljic SETCCE Tehnoloski park 21 1000 Ljubljana Slovenia
スヴェトラーナŠaljićSETCCEテクノロジーパーク21 1000年リュブリャナスロベニア
Phone: +386 (0) 1 620 4506 Fax: +386 (0) 1 620 4509 EMail: svetlana.saljic@setcce.si
電話番号：+386（0）1 620 4506ファックス：+386（0）1 620 4509 Eメール：svetlana.saljic@setcce.si
Tobias Gondrom Kruegerstr. 5A 85716 Unterschleissheim Germany
トビアスGondrom Kruegerstr。図5（a）85716 Unterschleissheimのドイツ
Phone: +49 (0) 89 320 5330 EMail: tobias.gondrom@gondrom.org
電話：+49（0）89 320 5330 Eメール：tobias.gondrom@gondrom.org