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
Internet Engineering Task Force (IETF) A. Jerman Blazic
Request for Comments: 6283 S. Saljic
Category: Standards Track SETCCE
ISSN: 2070-1721 T. Gondrom
July 2011
Extensible Markup Language Evidence Record Syntax (XMLERS)
可扩展标记语言证据记录语法（XMLERS）
Abstract
摘要
In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non-repudiation of existence and integrity of data. The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML.
在许多场景中，用户必须能够证明数据（存在时间）、完整性和有效性，包括长时间或不确定时间段内的签名数据。本文档指定了XML语法和处理规则，用于为数据的存在性和完整性的长期不可否认性创建证据。可扩展标记语言证据记录语法XMLERS通过使用XML为ASN.1（抽象语法表示法1）ERS（证据记录语法）（RFC 4998）语法提供了替代语法和处理规则。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6283.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. General Overview and Requirements ..........................4
1.3. Terminology ................................................6
1.4. Conventions Used in This Document ..........................7
2. Evidence Record .................................................7
2.1. Structure ..................................................8
2.2. Generation ................................................12
2.3. Verification ..............................................13
3. Archive Time-Stamp .............................................13
3.1. Structure .................................................13
3.1.1. Hash Tree ..........................................13
3.1.2. Time-Stamp .........................................14
3.1.3. Cryptographic Information List .....................15
3.2. Generation ................................................16
3.2.1. Generation of Hash Tree ............................17
3.2.2. Reduction of Hash Tree .............................19
3.3. Verification ..............................................21
4. Archive Time-Stamp Sequence and Archive Time-Stamp Chain .......22
4.1. Structure .................................................23
4.1.1. Digest Method ......................................23
4.1.2. Canonicalization Method ............................24
4.2. Generation ................................................25
4.2.1. Time-Stamp Renewal .................................25
4.2.2. Hash Tree Renewal ..................................26
4.3. Verification ..............................................27
5. Encryption .....................................................28
6. Version ........................................................29
7. Storage of Policies ............................................30
8. XSD Schema for the Evidence Record .............................30
9. Security Considerations ........................................34
9.1. Secure Algorithms .........................................34
9.2. Redundancy ................................................34
9.3. Secure Time-Stamps ........................................35
9.4. Time-Stamp Verification ...................................35
10. IANA Considerations ...........................................36
11. References ....................................................37
11.1. Normative References .....................................37
11.2. Informative References ...................................39
Appendix A. Detailed Verification Process of an Evidence Record ...41
The purpose of the document is to define XML schema and processing rules for Evidence Record Syntax in XML (Extensible Markup Language) format. The document is related to initial ASN.1 (Abstract Syntax Notation One) syntax for Evidence Record Syntax as defined in [RFC4998].
本文档的目的是为XML（可扩展标记语言）格式的证据记录语法定义XML模式和处理规则。本文档与[RFC4998]中定义的证据记录语法的初始ASN.1（抽象语法符号1）语法相关。
The evolution of electronic commerce and electronic data exchange in general requires introduction of non-repudiable proof of data existence as well as data integrity and authenticity. Such data and non-repudiable proof of existence must endure for long periods of time, even when the initial information to prove its existence and integrity weakens or ceases to exist. Mechanisms such as digital signatures defined in [RFC5652], for example, do not provide absolute reliability on a long-term basis. Algorithms and cryptographic material used to create a signature can become weak in the course of time, and information needed to validate digital signatures may become compromised or simply cease to exist, for example, due to the disbanding of a certificate service provider. Providing a stable environment for electronic data on a long-term basis requires the introduction of additional means to continually provide an appropriate level of trust in evidence on data existence, integrity, and authenticity.
一般而言，电子商务和电子数据交换的发展要求引入不可否认的数据存在证明以及数据完整性和真实性。这种数据和不可否认的存在证明必须持续很长时间，即使证明其存在和完整性的初始信息减弱或不再存在。例如，[RFC5652]中定义的数字签名等机制不能长期提供绝对可靠性。用于创建签名的算法和加密材料随着时间的推移可能会变得薄弱，验证数字签名所需的信息可能会受到损害，或者干脆不存在，例如，由于证书服务提供商的解散。为长期的电子数据提供稳定的环境需要引入额外的手段，以持续提供对数据存在性、完整性和真实性证据的适当信任。
All integrity and authenticity protecting techniques used today suffer from the problem of degrading reliability over time, including techniques for Time-Stamping, which are generally recognized as data existence and integrity proof mechanisms. Over long periods of time cryptographic algorithms used may become weak or encryption keys compromised. Some of the problems might not even be of technical nature like a Time-Stamping Authority going out of business and ceasing its service. To create a stable environment where proof of existence and integrity can endure well into the future a new technical approach must be used.
目前使用的所有完整性和真实性保护技术都存在可靠性随时间而降低的问题，包括时间戳技术，通常被认为是数据存在和完整性证明机制。在很长一段时间内，使用的加密算法可能会变弱或加密密钥受损。有些问题甚至可能不是技术性的，比如一个加盖时间戳的机构倒闭并停止服务。为了创造一个稳定的环境，在这个环境中，存在和完整性的证明可以持续到未来，必须使用一种新的技术方法。
Long-term non-repudiation of data existence and demonstration of data integrity techniques have been already introduced, for example, by long-term signature syntaxes like those defined in [RFC5126]. Long-term signature syntaxes and processing rules address only the long-term endurance of the digital signatures themselves, while Evidence Record Syntax broadens this approach for data of any type or format including digital signatures.
例如，通过[RFC5126]中定义的长期签名语法，已经引入了数据存在的长期不可否认性和数据完整性演示技术。长期签名语法和处理规则仅涉及数字签名本身的长期耐久性，而证据记录语法将此方法扩展到包括数字签名在内的任何类型或格式的数据。
XMLERS (Extensible Markup Language Evidence Record Syntax) is based on Evidence Record Syntax as defined in [RFC4998] and is addressing the same problem of long-term non-repudiable proof of data existence and demonstration of data integrity on a long-term basis. XMLERS does not supplement the [RFC4998] specification. Following extensible markup language standards and [RFC3470] guidelines it introduces the same approach but in a different format and with adapted processing rules.
XMLERS（可扩展标记语言证据记录语法）基于[RFC4998]中定义的证据记录语法，解决了长期不可否认的数据存在性证明和数据完整性证明的相同问题。XMLERS不补充[RFC4998]规范。遵循可扩展标记语言标准和[RFC3470]指南，它引入了相同的方法，但采用了不同的格式和经过调整的处理规则。
The use of Extensible Markup Language (XML) format is already recognized by a wide range of applications and services and is being selected as the de facto standard for many applications based on data exchange. The introduction of Evidence Record Syntax in XML format broadens the horizon of XML use and presents a harmonized syntax with a growing community of XML-based standards including those related to security services such as [XMLDSig] or [XAdES].
可扩展标记语言（XML）格式的使用已经被广泛的应用程序和服务所认可，并被选为许多基于数据交换的应用程序的事实标准。XML格式的证据记录语法的引入拓宽了XML的使用范围，并与越来越多的基于XML的标准（包括与[XMLDSig]或[XAdES]等安全服务相关的标准）一起提供了一种统一的语法。
Due to the differences in XML processing rules and other characteristics of XML, XMLERS does not present a direct transformation of ERS in ASN.1 syntax. XMLERS is based on different processing rules as defined in [RFC4998] and it does not support, for example, the import of ASN.1 values in XML tags. Creating Evidence Records in XML syntax must follow the steps as defined in this document. XMLERS is a standalone document and is based on [RFC4998] conceptually only. The content of this document provides enough information for implementation of Evidence Record Syntax (represented in XML format). References to [RFC4998] are for informative purposes only.
由于XML处理规则和XML的其他特性的差异，XMLERS在ASN.1语法中不提供ERS的直接转换。XMLERS基于[RFC4998]中定义的不同处理规则，不支持在XML标记中导入ASN.1值。以XML语法创建证据记录必须遵循本文档中定义的步骤。XMLERS是一个独立的文档，仅在概念上基于[RFC4998]。本文档的内容为证据记录语法（以XML格式表示）的实现提供了足够的信息。[RFC4998]仅供参考。
Evidence Record Syntax in XML format is based on long-term archive service requirements as defined in [RFC4810]. XMLERS delivers the same (level of) non-repudiable proof of data existence as ASN.1 ERS [RFC4998]. The XML syntax supports archive data grouping (and de-grouping) together with simple or complex Time-Stamp renewal processes. Evidence Records can be embedded in the data itself or stored separately as a standalone XML file.
XML格式的证据记录语法基于[RFC4810]中定义的长期存档服务要求。XMLERS提供了与ASN.1 ERS[RFC4998]相同的（级别）不可否认的数据存在证明。XML语法支持归档数据分组（和取消分组）以及简单或复杂的时间戳更新过程。证据记录可以嵌入数据本身，也可以作为独立的XML文件单独存储。
XMLERS specifies the XML syntax and processing rules for creating evidence for the long-term non-repudiation of existence and integrity of data in a unit called the "Evidence Record". XMLERS is defined to meet the requirements for data structures as set out in [RFC4810]. This document also refers to the ASN.1 ERS specification as defined in [RFC4998].
XMLERS指定了XML语法和处理规则，用于在一个称为“证据记录”的单元中为数据的存在和完整性的长期不可否认性创建证据。XMLERS的定义是为了满足[RFC4810]中规定的数据结构要求。本文件还参考了[RFC4998]中定义的ASN.1 ERS规范。
An Evidence Record may be generated and maintained for a single data object or a group of data objects that form an archive object. A data object (binary chunk or a file) may represent any kind of document or part of it. Dependencies among data objects, their validation, or any other relationship than "a data object is a part of particular archived object" are outside the scope of this document.
可以为构成存档对象的单个数据对象或一组数据对象生成和维护证据记录。数据对象（二进制块或文件）可以表示任何类型的文档或其中的一部分。数据对象之间的依赖关系、它们的验证或除“数据对象是特定存档对象的一部分”以外的任何其他关系不在本文档的范围内。
Evidence Record is closely related to Time-Stamping techniques. However, Time-Stamps as defined in [RFC3161] can cover only a single unit of data and do not provide processing rules for maintaining a long-term stability of Time-Stamps applied over a data object. Evidence for an archive object is created by acquiring a Time-Stamp from a trustworthy authority for a specific value that is unambiguously related to a single or more data objects. Relationship between several data objects and a single Time-Stamped value is addressed using a hash tree, a technique first described by Merkle [MER1980] and later in [RFC4998], with data structures and procedures as specified in this document. The Evidence Record Syntax enables processing of several archive objects within a single processing pass using a hash tree technique and acquiring only one Time-Stamp to protect all archive objects. The leaves of the hash tree are hash values of the data objects in a group. A Time-Stamp is requested only for the root hash of the hash tree. The deletion of a data object in the tree does not influence the provability of others. For any particular data object, the hash tree can be reduced to a few sets of hash values, which are sufficient to prove the existence of a single data object. Similarly, the hash tree can be reduced to prove existence of a data group, provided all members of the data group have the same parent node in the hash tree. Archive Time-Stamps are comprised of an optional reduced hash tree and a Time-Stamp.
证据记录与时间戳技术密切相关。然而，[RFC3161]中定义的时间戳只能覆盖单个数据单元，并且不提供用于维持应用于数据对象的时间戳的长期稳定性的处理规则。存档对象的证据是通过从可信机构获取与单个或多个数据对象明确相关的特定值的时间戳来创建的。多个数据对象和单个时间戳值之间的关系使用散列树解决，该技术首先由Merkle[MER1980]描述，随后在[RFC4998]中描述，数据结构和过程如本文档所述。证据记录语法支持使用哈希树技术在单个处理过程中处理多个存档对象，并仅获取一个时间戳以保护所有存档对象。哈希树的叶子是组中数据对象的哈希值。仅为哈希树的根哈希请求时间戳。删除树中的数据对象不会影响其他对象的可证明性。对于任何特定的数据对象，哈希树可以简化为几组哈希值，这些值足以证明单个数据对象的存在。类似地，如果数据组的所有成员在哈希树中具有相同的父节点，则可以简化哈希树以证明数据组的存在。存档时间戳由可选的简化哈希树和时间戳组成。
Besides a Time-Stamp other artifacts are also preserved in Evidence Record: data necessary to verify the relationship between a time-stamped value and a specific data object, packed into a structure called a "hash tree", and long-term proofs for the formal verification of the included Time-Stamp(s).
除了时间戳，其他工件也保存在证据记录中：验证时间戳值和特定数据对象之间关系所需的数据，打包到称为“哈希树”的结构中，以及对所包含时间戳的正式验证的长期证据。
Because digest algorithms or cryptographic methods used may become weak or certificates used within a Time-Stamp (and signed data) may be revoked or expire, the collected evidence data must be monitored and renewed before such events occur. This document introduces XML-based syntax and processing rules for the creation and continuous renewal of evidence data.
由于使用的摘要算法或加密方法可能会变弱，或者在时间戳内使用的证书（和签名数据）可能会被吊销或过期，因此必须在此类事件发生之前监视和更新收集的证据数据。本文档介绍了用于创建和持续更新证据数据的基于XML的语法和处理规则。
Archive Data Object: An archive data object is a data unit that is archived and has to be preserved for a long time by the long-term archive service.
归档数据对象：归档数据对象是归档的数据单元，必须由长期归档服务长期保存。
Archive Data Object Group: An archive data object group is a set of archive data objects that, for some reason, (logically) belong together; e.g., a group of document files or a document file and a signature file could represent an archive data object group.
归档数据对象组：归档数据对象组是由于某种原因，（逻辑上）属于一起的一组归档数据对象；e、 例如，一组文档文件或一个文档文件和一个签名文件可以表示归档数据对象组。
Archive Object (AO): An AO is an archive data object or an archive data object group.
存档对象（AO）：AO是存档数据对象或存档数据对象组。
Archive Time-Stamp (ATS): An ATS contains a Time-Stamp Token, useful data for validation, and optionally a set of ordered lists of hash values (a hash tree). An Archive Time-Stamp relates to a data object if the hash value of this data object is part of the first hash value list of the Archive Time-Stamp or its hash value matches the Time-Stamped value. An Archive Time-Stamp relates to a data object group if it relates to every data object of the group and no other data object (i.e., the hash values of all but no other data objects of the group are part of the first hash value list of the Archive Time-Stamp) (see Section 3).
存档时间戳（ATS）：ATS包含一个时间戳令牌、用于验证的有用数据，以及可选的一组有序哈希值列表（哈希树）。如果数据对象的哈希值是归档时间戳的第一个哈希值列表的一部分，或者其哈希值与时间戳值匹配，则归档时间戳与数据对象相关。如果存档时间戳与数据对象组的每个数据对象相关，而不与其他数据对象相关，则存档时间戳与该数据对象组相关（即，该组的所有但无其他数据对象的散列值都是存档时间戳的第一个散列值列表的一部分）（参见第3节）。
Archive Time-Stamp Chain (ATSC): An ATSC holds a sequence of Archive Time-Stamps generated during the preservation period.
存档时间戳链（ATSC）：ATSC保存保存期间生成的存档时间戳序列。
Archive Time-Stamp Sequence (ATSSeq): AN ATSSeq is a sequence of Archive Time-Stamp Chains.
归档时间戳序列（ATSSeq）：ATSSeq是归档时间戳链的序列。
Canonicalization: Canonicalization refers to processing rules for transforming an XML document into its canonical form. Two XML documents may have different physical representations, but they may have the same canonical form. For example, a sort order of attributes does not change the meaning of the document as defined in [XMLC14N].
规范化：规范化是指将XML文档转换为其规范形式的处理规则。两个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.
对应于相同输出的输入值。摘要算法将输入数据转换为固定长度的短值。输出称为摘要值、哈希值或数据指纹。
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.
证据记录：证据记录是一段时间内为给定存档对象编译的证据集合。证据记录包括有序收集的ATS，这些ATS分为ATSC和ATSSEQ。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An Evidence Record is a unit of data that is to be used to prove the existence of an archive object (a single archive data object or a archive data object group) at a certain time. Through the lifetime of an archive object, an Evidence Record also demonstrates the data objects' integrity and non-repudiability. To achieve this, cryptographic means are used, i.e., the LTA obtains Time-Stamp Tokens from the Time-Stamping Authority (TSA). It is possible to store the Evidence Record separately from the archive object or to integrate it into the data itself.
证据记录是用于证明某个归档对象（单个归档数据对象或归档数据对象组）在特定时间存在的数据单元。在存档对象的整个生命周期中，证据记录还可以证明数据对象的完整性和不可否认性。为此，使用加密手段，即LTA从时间戳授权机构（TSA）获得时间戳令牌。可以将证据记录与存档对象分开存储，或将其集成到数据本身中。
As cryptographic means are used to support Evidence Records, such records may lose their value over time. Time-Stamps obtained from Time-Stamping Authorities may become invalid for a number of reasons, usually due to time constraints of Time-Stamp validity or when cryptographic algorithms lose their security properties. Before the used Time-Stamp Tokens become unreliable, the Evidence Record has to be renewed. This may result in a series of Time-Stamp Tokens, which are linked between themselves according to the cryptographic methods and algorithms used.
由于使用加密手段来支持证据记录，随着时间的推移，这些记录可能会失去价值。从时间戳管理机构获得的时间戳可能因多种原因而无效，通常是由于时间戳有效性的时间限制或密码算法失去其安全属性。在使用的时间戳令牌变得不可靠之前，必须更新证据记录。这可能导致一系列时间戳令牌，它们根据所使用的加密方法和算法在它们之间链接。
Evidence Records can be supported with additional information, which can be used to ease the processes of Evidence Record validation and renewal. Information such as digital certificates and Certificate Revocation Lists as defined in [RFC5280] or other cryptographic material can be collected, enclosed, and processed together with archive object data (i.e., Time-Stamped).
证据记录可由其他信息支持，这些信息可用于简化证据记录验证和更新过程。[RFC5280]中定义的数字证书和证书撤销列表等信息或其他加密材料可以与归档对象数据（即时间戳）一起收集、封装和处理。
The Evidence Record contains one or several Archive Time-Stamps (ATSs). An ATS contains a Time-Stamp Token and optionally other useful data for Time-Stamp validation, e.g., certificates, CRLs (Certificate Revocation Lists), or OCSP (Online Certificate Status Protocol) responses and also specific attributes such as service policies.
证据记录包含一个或多个存档时间戳（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语法中，证据记录由<取证记录>根元素表示，该元素具有伪XML中描述的以下结构以及第8节中定义的完整XML模式（其中“？”表示零或一次出现，“+”表示一次或多次出现，“*”表示零或多次出现）：
<EvidenceRecord Version>
<证据记录版本>
<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 Type /> +
</SupportingInformationList> ?
<ArchiveTimeStampSequence>
<ArchiveTimeStampChain Order>
<DigestMethod Algorithm />
<CanonicalizationMethod Algorithm />
<ArchiveTimeStamp Order>
<HashTree /> ?
<TimeStamp>
<TimeStampToken Type />
<CryptographicInformationList>
<CryptographicInformation Order Type /> +
</CryptographicInformationList> ?
</TimeStamp>
<Attributes>
<Attribute Order Type /> +
</Attributes> ?
</ArchiveTimeStamp> +
</ArchiveTimeStampChain> +
</ArchiveTimeStampSequence>
</EvidenceRecord>
The syntax of an Evidence Record is defined as an XML schema [XMLSchema], see Section 8. The schema uses the following XML namespace [XMLName] urn:ietf:params:xml:ns:ers as default namespace with a detailed xml schema header listed in Section 8.
证据记录的语法定义为XML模式[XMLSchema]，参见第8节。模式使用以下XML名称空间[XMLName]urn:ietf:params:XML:ns:ers作为默认名称空间，第8节列出了详细的XML模式头。
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
必须包括“Version”属性，并指明语法版本，以便与本规范的未来版本兼容，并将其与XMLERS的早期不一致或专有版本区分开来。XMLERS的当前版本是1.0。第6节详细描述了使用的版本控制方案<EncryptionInformation>元素是可选的，它保存用于加密存档数据的加密算法和加密材料的信息（如果存档数据是加密的，例如出于隐私目的）。在处理证据记录时，需要此可选信息来明确地重新加密数据对象。省略时，数据对象不会被加密或删除
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.
未加密的数据不需要防抵赖证明。有关如何处理加密档案数据和生成证据记录的详细信息，请参见第5节。
<SupportingInformationList> element is OPTIONAL and can hold information to support processing of Evidence Records. An example of this supporting information may be a processing policy, like a cryptographic policy (e.g., [RFC5698]) or archiving policies, which can provide input about preservation and evidence validation. Each data object is put into a separate child element <SupportingInformation>, with an OPTIONAL Type attribute to indicate its type for processing directions. As outlined, Types to be used must be defined in the specification of the information structure to be stored or in this standard. As outlined in Section 9.4, cryptographic information may also be stored in the SupportingInformation element, in which case its Section 3.1.3 defined type MUST be used. Or as defined in Section 7 cryptographic policies [RFC5698] MAY be stored, in which case the used type is defined in the relevant RFC. Note that if supporting information and policies are relevant for and already available at or before the time of individual renewal steps (e.g., to indicate the DSSC crypto policy [RFC5698]) that was used at the time of the individual renewal) they SHOULD be stored in the <Attributes> element of the individual Archive Time-Stamp (see below) as this is integrity protected by the Archive Time-Stamps. Supporting information that is relevant for the whole Evidence Record (like the LTA's current Cryptographic Algorithms Security Suitability policy (DSSC, [RFC5698]) or that was not available at the time of renewal (and therefore could not later be stored in the protected <Attributes> element) can be stored in this <SupportingInformation> element.
<SupportingInformationList>元素是可选的，可以保存支持证据记录处理的信息。该支持信息的一个示例可以是处理策略，如加密策略（例如，[RFC5698]）或归档策略，其可以提供有关保存和证据验证的输入。每个数据对象都被放入一个单独的子元素<SupportingInformation>，并带有一个可选的Type属性来指示其处理方向的类型。如上所述，必须在待存储的信息结构规范或本标准中定义要使用的类型。如第9.4节所述，加密信息也可存储在SupportingInformation元素中，在这种情况下，必须使用第3.1.3节定义的类型。或如第7节所定义，可存储加密策略[RFC5698]，在这种情况下，使用的类型在相关RFC中定义。请注意，如果支持信息和策略与单个续订步骤相关，并且在单个续订步骤时或之前已经可用（例如，指示单个续订时使用的DSSC加密策略[RFC5698]），则应将其存储在单个存档时间戳的<Attributes>元素中（见下文）因为这是由存档时间戳保护的完整性。与整个证据记录相关的支持信息（如LTA当前的加密算法安全适用性策略（DSSC，[RFC5698]）或在更新时不可用的支持信息（因此以后无法存储在受保护的<Attributes>元素中）可存储在此<SupportingInformation>元素中。
<ArchiveTimeStampSequence> is REQUIRED and contains a sequence of one or more <ArchiveTimeStampChain>.
<ArchiveTimeStampSequence>是必需的，它包含一个或多个<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>和<ArchiveTimeStampChain>元素的“order”属性指示顺序。
<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>是必需的元素，它包含一个属性“Algorithm”，该属性标识一个存档时间戳链中使用的摘要算法，用于从存档数据对象、以前的存档时间戳序列、时间戳和时间戳令牌中计算摘要值。
<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>或<TimeStamp>元素的存档数据。
<HashTree> is an OPTIONAL element that holds a structure as described in Section 3.1.1.
<HashTree>是一个可选元素，包含第3.1.1节所述的结构。
<TimeStamp> is REQUIRED and holds a <TimeStampToken> element with a Time-Stamp Token (as defined in Section 3.1.2) provided by the Time-Stamping Authority and an OPTIONAL element <CryptographicInformationList>.
<TimeStamp>是必需的，它包含一个<TimeStampToken>元素，该元素带有时间戳机构提供的时间戳令牌（如第3.1.2节所定义）和一个可选元素<CryptographicInformationList>。
<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>，并具有一个必需的Order属性来指示其父元素中的顺序。可以根据使用的策略添加这些项。此数据由存档时间戳序列中的连续时间戳保护。
<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].
<Attributes>元素是可选的，包含LTA可能提供的用于支持证据记录处理的附加信息。该支持信息的一个示例可以是处理策略，如续订、加密（例如[RFC5698]）或归档策略。此类策略可以提供与数据对象保存和后期证据验证相关的输入。每个数据对象都被放入一个单独的子元素<Attribute>，其中一个必需的Order属性表示父元素中的顺序，另一个可选的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.
当一个或多个具有相同名称的XML元素出现在XMLERS结构的同一级别上时，在所有情况下都需要Order属性。尽管大多数XML解析器将保留同名同级元素的顺序，但在XML结构中没有定义如何明确定义这种顺序。在这种情况下，保持正确的顺序对于XML结构上的摘要值计算非常重要。
The generation of an <EvidenceRecord> element MUST be as follows:
<证据记录>元素的生成必须如下所示：
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可以从为许多存档对象获取一个时间戳令牌中获益，这些存档对象在其他方面互不相关。可以收集多个存档对象，构建一个哈希树以生成一个要加时间戳的值，并分别将该哈希树缩减为小子集，以便为每个存档对象提供与加时间戳的哈希值的必要绑定（参见第3.2.1节）。
For performance reasons or in case of local Time-Stamp generation, building a hash tree (<HashTree> element) can be omitted. It is also possible to convert existing Time-Stamps into an ATS for renewal.
出于性能原因或在生成本地时间戳的情况下，可以省略构建哈希树（<HashTree>元素）。也可以将现有时间戳转换为ATS进行更新。
The case when only essential parts of documents or objects shall be protected is out of scope for this standard, and an application that is not defined in this document must ensure that the correct unambiguous extraction of binary data is made for the generation of Evidence Record.
仅保护文件或对象的重要部分的情况不在本标准的范围内，本文件中未定义的应用程序必须确保正确无误地提取二进制数据以生成证据记录。
An application may also provide evidence such as certificates, revocation lists, etc. needed to verify and validate signed data objects or a data object group. This evidence may be added to the archive data object group and will be protected within the initial (and successive) Time-Stamp(s).
应用程序还可以提供验证和验证签名数据对象或数据对象组所需的证据，如证书、吊销列表等。此证据可添加到存档数据对象组，并将在初始（和连续）时间戳内受到保护。
Note that the <CryptographicInformationList> element of Evidence Record is not to be used to store and protect cryptographic material related to signed archive data. The use of this element is limited to cryptographic material related to the Time-Stamp(s).
请注意，证据记录的<CryptographicInformationList>元素不用于存储和保护与签名存档数据相关的加密材料。此元素的使用仅限于与时间戳相关的加密材料。
The overall verification of an Evidence Record MUST be as follows:
证据记录的总体验证必须如下所示：
1. Select an archive object (a data object or a data object group).
1. 选择存档对象（数据对象或数据对象组）。
2. Re-encrypt data object or data object group, if encryption field is used (for details, see Section 5).
2. 如果使用加密字段，则重新加密数据对象或数据对象组（有关详细信息，请参阅第5节）。
3. Verify Archive Time-Stamp Sequence (details in Sections 3.3 and 4.3).
3. 验证存档时间戳序列（详情见第3.3节和第4.3节）。
An Archive Time-Stamp is a Time-Stamp with additional artifacts that allow the verification of the existence of several data objects at a certain time.
存档时间戳是一个带有附加工件的时间戳，它允许在特定时间验证多个数据对象的存在性。
The process of construction of an ATS must support evidence on a long-term basis and prove that the archive object existed and was identical, at the time of the Time-Stamp, to the currently present archive object (at the time of verification). To achieve this, an ATS MUST be renewed before it becomes invalid (which may happen for several reasons such as, e.g., weakening used cryptographic algorithms, invalidation of digital certificate, or a TSA terminating its business or ceasing its service).
ATS的构建过程必须长期支持证据，并证明存档对象存在，且在时间戳时与当前存档对象（在验证时）相同。为此，必须在ATS失效之前对其进行更新（这可能是由于多种原因造成的，例如，削弱使用的加密算法、数字证书失效或TSA终止其业务或停止其服务）。
An Archive Time-Stamp contains a Time-Stamp Token, with useful data for its validation (cryptographic information), such as the certificate chain or Certificate Revocation Lists, an optional ordered set of ordered lists of hash values (a hash tree) that were protected with the Time-Stamp Token and optional information describing the renewal steps (<Attributes> element). A hash tree may be used to store data needed to bind the Time-Stamped value with protected objects by the Archive Time-Stamp. If a hash tree is not present, the ATS simply refers to a single object, either input data object or a previous TS.
存档时间戳包含一个时间戳令牌，其中包含用于验证的有用数据（加密信息），例如证书链或证书吊销列表、一组可选的有序哈希值列表（哈希树），这些哈希值受时间戳令牌的保护，以及描述续订步骤的可选信息（<Attributes>元素）。哈希树可用于存储通过存档时间戳将时间戳值与受保护对象绑定所需的数据。如果哈希树不存在，则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>
<Sequence Order>
<DigestValue>base64 encoded hash value</DigestValue> +
</Sequence> +
</HashTree>
The algorithm by which a root hash value is generated from the <HashTree> element is as follows: the content of each <DigestValue> element within the first <Sequence> element is base64 ([RFC4648], using the base64 alphabet not the base64url alphabet) decoded to obtain a binary value (representing the hash value). All collected hash values from the sequence are ordered in binary ascending order, concatenated and a new hash value is generated from that string. With one exception to this rule: when the first <Sequence> element has only one <DigestValue> element, then its binary value is added to the next list obtained from the next <Sequence> element.
从<HashTree>元素生成根哈希值的算法如下：第一个<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>元素获得的下一个散列列表中，并且重复上一步骤，直到只剩下一个散列值，即，当没有<Sequence>元素时。最后计算的哈希值是根哈希值。当存档对象是一个组且由多个数据对象组成时，第一个哈希列表必须包含其所有数据对象的哈希值。
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>元素的文本值应为该位字符串的base64编码，视为20个八位字节流。为了继续该示例，使用示例消息摘要值A9993E364706816ABA3E25717850C26C9CD0D89D（注意，这是160位消息摘要的十六进制编码值），其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
时间戳令牌是TSA生成的数据项在特定时间存在的证明。时间戳令牌是一个有符号的数据对象，它包含哈希值、TSA的标识以及时间戳的确切时间（从可信时间源获得）。这证明了给定的数据在时间戳之前存在。例如，[RFC3161]指定ASN.1格式的签名时间戳令牌的结构。因为当时
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.
XML时间戳没有标准，提供了以下结构示例[TS-TRUST]，它是符合[XMLDSig]规范的数字签名，包含特定于时间戳的数据，例如签名的<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>
<element name="TimeStampInfo">
<complexType>
<sequence>
<element ref="Policy" />
<element ref="Digest" />
<element ref="SerialNumber" minOccurs="0" />
<element ref="CreationTime" />
<element ref="Accuracy" minOccurs="0" />
<element ref="Ordering" minOccurs="0" />
<element ref="Nonce" minOccurs="0" />
<element ref="Extensions" minOccurs="0" />
</sequence>
</complexType>
</element>
A <TimeStamp> element of ATS holds a complete structure of Time-Stamp Token as provided by a TSA. Time-Stamp Token may be in XML or ASN.1 format. The Attribute type MUST be used to indicate the format for processing purposes, with values "XMLENTRUST" or "RFC3161" respectively. For an RFC3161 type Time-Stamp Token, the <TimeStamp> element MUST contain base64 encoding of a DER-encoded ASN1 data. These type values are registered by IANA (see Section 10). For support of future types of Time-Stamps (in particular for future XML Time-Stamp standards), these need to be registered there as well.
ATS的<TimeStamp>元素包含TSA提供的时间戳令牌的完整结构。时间戳令牌可以是XML或ASN.1格式。属性类型必须用于指示用于处理目的的格式，其值分别为“XmlTrust”或“RFC3161”。对于RFC3161类型的时间戳令牌，<TimeStamp>元素必须包含DER编码ASN1数据的base64编码。这些类型值由IANA注册（见第10节）。为了支持未来类型的时间戳（特别是未来的XML时间戳标准），还需要在那里注册这些时间戳。
For example:
例如：
<TimeStamp Type="RFC3161">MIAGCSqGSIb3DQEH...</TimeStamp>
<TimeStamp Type="RFC3161">MIAGCSqGSIb3DQEH...</TimeStamp>
or
或
<TimeStamp Type="XMLENTRUST"><dsig:Signature>...</dsig:Signature>
</TimeStamp>
<TimeStamp Type="XMLENTRUST"><dsig:Signature>...</dsig:Signature>
</TimeStamp>
Digital certificates, CRLs (Certificate Revocation Lists), SCVP (Server-Based Certificate Validation Protocol), or OCSP-Responses (Online Certificate Status Protocol) needed to verify the Time-Stamp Token SHOULD be stored in the Time-Stamp Token itself. When this is not possible, such data MAY be stored in the
验证时间戳令牌所需的数字证书、CRL（证书吊销列表）、SCVP（基于服务器的证书验证协议）或OCSP响应（在线证书状态协议）应存储在时间戳令牌本身中。当这不可能时，这些数据可以存储在
<CryptographicInformationList> element; each data object is stored into a separate <CryptographicInformation> element, with a REQUIRED Order attribute.
<CryptographicInformationList>元素；每个数据对象都存储在一个单独的<CryptographicInformation>元素中，并具有所需的Order属性。
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的base64编码[RFC5280]
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编码的CVR响应的base64编码；[RFC5055]
o for type CERT, a base64 encoding of a DER-encoded X.509 certificate [RFC5280]
o 对于类型证书，DER编码的X.509证书的base64编码[RFC5280]
The supported type identifiers are registered by IANA (see Section 10). Future supported types can be registered there (for example, to support future validation standards).
支持的类型标识符由IANA注册（见第10节）。可以在那里注册将来支持的类型（例如，为了支持将来的验证标准）。
An initial ATS relates to a data object or a data object group that represents an archive object. The generation of the initial ATS element can be done in a single process pass for one or for many archived objects. It MUST be done as described in the following steps:
初始ATS与表示存档对象的数据对象或数据对象组相关。对于一个或多个存档对象，初始ATS元素的生成可以在单个过程中完成。必须按照以下步骤进行：
1. Collect one or more archive objects to be Time-Stamped.
1. 收集一个或多个要加盖时间戳的存档对象。
2. Select a canonicalization method C to be used for obtaining binary representation of archive data and for Archive Time-Stamp at a later stage in the renewing process (see Section 4). Note that the selected canonicalization method MUST be used also for archive data when data is represented in XML format.
2. 选择一种规范化方法C，用于获取归档数据的二进制表示形式，并在更新过程的后期用于归档时间戳（参见第4节）。请注意，当数据以XML格式表示时，选定的规范化方法也必须用于存档数据。
3. Select a valid digest algorithm H. The selected secure hash algorithm MUST be the same as the hash algorithm used in the Time-Stamp Token and for the hash tree computations.
3. 选择有效的摘要算法H。所选安全哈希算法必须与时间戳令牌和哈希树计算中使用的哈希算法相同。
4. Generate a hash tree for selected archive object (see Section 3.2.1).
4. 为所选存档对象生成哈希树（见第3.2.1节）。
The hash tree may be omitted in the initial ATS, when an archive object has a single data object; then the Time-Stamped value MUST match the digest value of that single data object.
当存档对象具有单个数据对象时，可在初始ATS中省略哈希树；然后，时间戳值必须与单个数据对象的摘要值匹配。
5. Acquire Time-Stamp token from TSA for root hash value of a hash tree (see Section 3.1.1). If the Time-Stamp token is valid, the initial Archive Time-Stamp may be generated.
5. 从TSA获取哈希树根哈希值的时间戳令牌（见第3.1.1节）。如果时间戳令牌有效，则可以生成初始存档时间戳。
The <DigestValue> elements within the <Sequence> element MUST be ordered in binary ascending order to ensure the correct calculation of digest values at the time of renewal and later for verification purposes. Note that the text value of the <DigestValue> element is base64 encoded, so it MUST be base64 decoded in order to obtain a binary representation of the hash value.
<Sequence>元素中的<DigestValue>元素必须按二进制升序排序，以确保更新时以及以后出于验证目的正确计算摘要值。请注意，<DigestValue>元素的文本值是base64编码的，因此必须对其进行base64解码才能获得哈希值的二进制表示。
A hash tree MUST be generated when the Time-Stamped value is not equal to the hash value of the input data object. This is the case when either of the following is true:
当时间戳值不等于输入数据对象的哈希值时，必须生成哈希树。当以下任一情况为真时，即为这种情况：
1. When an archive object has more than one data object (i.e., is an archive data object group), its digest value is the digest value of binary ascending ordered and concatenated digest values of all its containing data objects. Note that in this case the first list of the hash tree MUST contain hash values of all data objects and only those values.
1. 当存档对象具有多个数据对象（即存档数据对象组）时，其摘要值是其包含的所有数据对象的二进制升序和串联摘要值的摘要值。请注意，在这种情况下，哈希树的第一个列表必须包含所有数据对象的哈希值，并且仅包含这些值。
2. When for more than one archive object a single Time-Stamp Token is generated, then the hash tree is a reduced hash tree extracted from the hash tree for that archive object (see Section 3.2.2).
2. 当为多个存档对象生成单个时间戳令牌时，则哈希树是从该存档对象的哈希树中提取的简化哈希树（参见第3.2.2节）。
The hash tree for a set of archive objects is built from the leaves to the root. First the leaves of the tree are collected, each leaf representing the digest value of an archive object. You MUST use the following procedure to calculate the hash tree:
一组存档对象的哈希树是从叶子到根构建的。首先收集树的叶子，每个叶子代表存档对象的摘要值。必须使用以下过程计算哈希树：
1. Collect archive objects and for each archive object its corresponding data objects.
1. 收集归档对象，并为每个归档对象收集其相应的数据对象。
2. Choose a secure hash algorithm H and calculate the digest values for the data objects and put them into the input list for the hash tree as follows: a digest value of an archive object is the digest value of its data object, if there is only one data object in the archive object; if there is more than one data object in the archive object (i.e., it is an archive data object group) the digest value is the digest value of binary sorted, concatenated digest values of all its containing data objects.
2. 选择安全哈希算法H，计算数据对象的摘要值，并将其放入哈希树的输入列表中，如下所示：如果存档对象中只有一个数据对象，则存档对象的摘要值就是其数据对象的摘要值；如果存档对象中有多个数据对象（即，它是存档数据对象组），则摘要值是其包含的所有数据对象的二进制排序、串联摘要值的摘要值。
Note that for an archive object group (having more than one data object), lists of their sub-digest values are stored and later, when creating a reduced hash tree for that archive object, they will become members of the first hash list.
请注意，对于存档对象组（具有多个数据对象），将存储其子摘要值的列表，稍后，当为该存档对象创建精简哈希树时，它们将成为第一个哈希列表的成员。
3. Group together items in the input list by the order of N (e.g., for a binary tree group in pairs, for a tertiary tree group in triplets, and so forth) and for each group: binary ascending sort, concatenate, and calculate the hash value. The result is a new input for the next list. For improved processing it is RECOMMENDED to have the same number of children for each node. For this purpose you MAY extend the tree with arbitrary values to make every node have the same number of children.
3. 按N的顺序将输入列表中的项目分组（例如，对于成对的二叉树组，对于三叉树组，等等），对于每个组：二进制升序排序、串联和计算哈希值。结果是下一个列表的新输入。为了改进处理，建议每个节点具有相同数量的子节点。为此，可以使用任意值扩展树，以使每个节点具有相同数量的子节点。
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.
示例：具有18个散列值的输入列表，其中h'1是为一组数据对象（d4、d5、d6和d7）生成的，并已按3分组。该组可以是任何大小（2，3…）。注意，任意值h''6和h''3的添加是可选的，可用于改进处理，如上面步骤3所述。
----------
d1 -> h1 \
\
G1 d2 -> h2 |-> h''1
+--------+ / \
|d4 -> h4|\ d3 -> h3 / \
|d5 -> h5| \ ---------- |
| | | -> h'1\ |
|d6 -> h6| / \ |
|d7 -> h7|/ d8 -> h8 |-> h''2 |-> h'''1
+--------+ / | \
d9 -> h9 / | \
---------- | |
d10 -> h10\ / |
\ / |
d11 -> h11 |-> h''3 |
/ |
d12 -> h12/ |-> root hash value
---------- |
d13 -> h13\ |
\ |
d14 -> h14 |-> h''4 |
/ \ |
d15 -> h15/ \ |
---------- |-> h'''2 |
d16 -> h16\ | |
\ | |
d17 -> h17 |-> h''5 | |
/ | |
d18 -> h18/ | |
---------- / |
/ /
(any arbitrary) h''6 /
(any arbitrary) h'''3
----------
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。Merkle散列树的生成
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.
请注意，哈希值列表的数量及其长度没有限制。还要注意，构建哈希树和减少哈希树是有益的，但不是必需的。存档时间戳可能只包含一个哈希值列表和一个时间戳，或者在极端情况下，只包含一个没有哈希值列表的时间戳。
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:
生成的Merkle散列树可以简化为散列值列表，作为单个归档对象存在的必要证明，如下所示：
1. For a selected archive object (AO) select its hash value h within the leaves of the hash tree.
1. 对于选定的存档对象（AO），在哈希树的叶子中选择其哈希值h。
2. Put h as base64 encoded text value of a new <DigestValue> element within a first <Sequence> element. If the selected AO is a data object group (i.e., has more than one data object), the first <Sequence> element MUST in this case be formed from the hash values of all AOs data objects, each within a separate <DigestValue> element.
2. 将h作为第一个<Sequence>元素中新<DigestValue>元素的base64编码文本值。如果所选AO是数据对象组（即，具有多个数据对象），则在这种情况下，第一个<Sequence>元素必须由所有AOs数据对象的哈希值形成，每个AOs数据对象位于单独的<DigestValue>元素内。
3. Select all hash values that have the same father node as hash value h. Place these hash values each as a base64 encoded text value of a new <DigestValue> element within a new <Sequence> element, increasing its Order attribute value by 1.
3. 选择与哈希值h具有相同父节点的所有哈希值。将这些散列值分别作为新<Sequence>元素中新<DigestValue>元素的base64编码文本值，将其Order属性值增加1。
4. Repeat step 3 for the parent node until the root hash value is reached, with each step create a new <Sequence> element and increase its Order attribute by one. Note that node values are not saved as they are computable.
4. 对父节点重复步骤3，直到达到根哈希值，每一步创建一个新的<Sequence>元素并将其Order属性增加一。请注意，节点值不保存为可计算值。
The order of <DigestValue> elements within each <Sequence> element MUST be binary ascending (by base64 decoded values).
每个<Sequence>元素中<DigestValue>元素的顺序必须是二进制升序（按base64解码值）。
Reduced hash tree for data object d4 (from the previous example, presented in Figure 1):
数据对象d4的简化哈希树（来自上一个示例，如图1所示）：
<HashTree>
<Sequence Order='1'>
<DigestValue>base64 encoded h4</DigestValue>
<DigestValue>base64 encoded h5</DigestValue>
<DigestValue>base64 encoded h6</DigestValue>
<DigestValue>base64 encoded h7</DigestValue>
</Sequence>
<Sequence Order='2'>
<DigestValue>base64 encoded h8</DigestValue>
<DigestValue>base64 encoded h9</DigestValue>
</Sequence>
<Sequence Order='3'>
<DigestValue>base64 encoded h''1</DigestValue>
<DigestValue>base64 encoded h''3</DigestValue>
</Sequence>
<Sequence Order='4'>
<DigestValue>base64 encoded h'''2</DigestValue>
</Sequence>
</HashTree>
<HashTree>
<Sequence Order='1'>
<DigestValue>base64 encoded h4</DigestValue>
<DigestValue>base64 encoded h5</DigestValue>
<DigestValue>base64 encoded h6</DigestValue>
<DigestValue>base64 encoded h7</DigestValue>
</Sequence>
<Sequence Order='2'>
<DigestValue>base64 encoded h8</DigestValue>
<DigestValue>base64 encoded h9</DigestValue>
</Sequence>
<Sequence Order='3'>
<DigestValue>base64 encoded h''1</DigestValue>
<DigestValue>base64 encoded h''3</DigestValue>
</Sequence>
<Sequence Order='4'>
<DigestValue>base64 encoded h'''2</DigestValue>
</Sequence>
</HashTree>
Reduced hash tree for data object d2 (from the previous example, presented in Figure 1):
数据对象d2的简化哈希树（来自上一个示例，如图1所示）：
<HashTree>
<Sequence Order='1'>
<DigestValue>base64 encoded h2</DigestValue>
</Sequence>
<Sequence Order='2'>
<DigestValue>base64 encoded h1</DigestValue>
<DigestValue>base64 encoded h3</DigestValue>
</Sequence>
<Sequence Order='3'>
<DigestValue>base64 encoded h''2</DigestValue>
<DigestValue>base64 encoded h''3</DigestValue>
</Sequence>
<Sequence Order='4'>
<DigestValue>base64 encoded h'''2</DigestValue>
</Sequence>
</HashTree>
<HashTree>
<Sequence Order='1'>
<DigestValue>base64 encoded h2</DigestValue>
</Sequence>
<Sequence Order='2'>
<DigestValue>base64 encoded h1</DigestValue>
<DigestValue>base64 encoded h3</DigestValue>
</Sequence>
<Sequence Order='3'>
<DigestValue>base64 encoded h''2</DigestValue>
<DigestValue>base64 encoded h''3</DigestValue>
</Sequence>
<Sequence Order='4'>
<DigestValue>base64 encoded h'''2</DigestValue>
</Sequence>
</HashTree>
The initial Archive Time-Stamp shall prove that an archive object existed at a certain time, indicated by its Time-Stamp Token. The verification procedure MUST be as follows:
初始存档时间戳应证明存档对象在特定时间存在，由其时间戳令牌表示。验证程序必须如下所示：
1. Identify hash algorithm H (from <DigestMethod> element) and calculate the hash value for each data object of the archive object.
1. 识别哈希算法H（来自<DigestMethod>元素），并计算存档对象的每个数据对象的哈希值。
2. If the hash tree is present, search for hash values in the first <Sequence> element. If hash values are not present, terminate verification process with negative result. If the verifying party also seeks additional proof that the Archive Time-Stamp relates to a data object group (e.g., a document and all its digital signatures), it SHOULD also be verified that only the hash values of the data objects that are members of the given data object group are in the first hash value list.
2. 如果存在哈希树，则在第一个<Sequence>元素中搜索哈希值。如果不存在散列值，则终止验证过程，结果为负。如果验证方还寻求存档时间戳与数据对象组（例如，文档及其所有数字签名）相关的额外证据，则还应验证只有作为给定数据对象组成员的数据对象的散列值在第一散列值列表中。
3. If the hash tree is present, calculate its root hash value. Compare the root hash value with the Time-Stamped value. If they are not equal, terminate the verification process with negative result.
3. 如果存在哈希树，则计算其根哈希值。将根哈希值与时间戳值进行比较。如果它们不相等，则终止验证过程，结果为负。
4. If the hash tree is omitted, compare the hash value of the single data object with the Time-Stamped value. If they are not equal, terminate the verification process with negative result. If an archive object is having more data objects and the hash tree is omitted, also exit with negative result.
4. 如果忽略哈希树，请将单个数据对象的哈希值与时间戳值进行比较。如果它们不相等，则终止验证过程，结果为负。如果存档对象有更多的数据对象，并且忽略了哈希树，则也会以负结果退出。
5. Check the validity of the Time-Stamp Token. If the needed information to verify formal validity of the Time-Stamp Token is not available or found within the <TimeStampToken> element or within the <CryptographicInformationList> element or in <SupportingInformationList> (see Section 9.4), exit with a negative result.
5. 检查时间戳令牌的有效性。如果在<TimeStampToken>元素或<CryptographicInformationList>元素或<SupportingInformationList>中（参见第9.4节）没有或找不到验证时间戳令牌正式有效性所需的信息，请以否定结果退出。
Information for formal verification of the Time-Stamp Token includes digital certificates, Certificate Revocation Lists, Online Certificate Status Protocol responses, etc. This information needs to be collected prior to the Time-Stamp renewal process and protected with the succeeding Time-Stamp, i.e., included in the <TimeStampToken> or <CryptographicInformation> element (see Section 9.4 for additional information and Section 4.2.1 for details on the Time-Stamp renewal process). For the current (latest) Time-Stamp), information for formal verification of the (latest) Time-Stamp should be provided by the Time-Stamping Authority. This information can also be provided with the Evidence Record within the <SupportingInformation> element, which is not protected by any Time-Stamp.
时间戳令牌的正式验证信息包括数字证书、证书撤销列表、在线证书状态协议响应等。这些信息需要在时间戳更新过程之前收集，并使用后续时间戳进行保护，即。，包含在<TimeStampToken>或<CryptographicInformation>元素中（更多信息请参见第9.4节，时间戳更新过程的详细信息请参见第4.2.1节）。对于当前（最新）时间戳，时间戳机构应提供正式验证（最新）时间戳的信息。此信息还可以与<SupportingInformation>元素中的证据记录一起提供，该元素不受任何时间戳的保护。
An Archive Time-Stamp proves the existence of single data objects or a data object group at a certain time. However, the initial Evidence Record created can become invalid due to losing the validity of the Time-Stamp Token for a number of reasons: hash algorithms or public key algorithms used in its hash tree or the Time-Stamp may become weak or the validity period of the Time-Stamp authority certificate expires or is revoked.
存档时间戳证明在特定时间存在单个数据对象或数据对象组。但是，创建的初始证据记录可能会由于以下原因而变得无效：哈希树中使用的哈希算法或公钥算法，或者时间戳可能变弱，或者时间戳颁发机构证书的有效期到期或被撤销。
To preserve the validity of an Evidence Record before such events occur, the Evidence Record has to be renewed. This can be done by creating a new ATS. Depending on the reason for renewing the Evidence Record (the Time-Stamp becomes invalid or the hash algorithm of the hash tree becomes weak) two types of renewal processes are possible:
为了在此类事件发生前保持证据记录的有效性，必须更新证据记录。这可以通过创建新的ATS来实现。根据更新证据记录的原因（时间戳无效或哈希树的哈希算法变弱），可能有两种类型的更新过程：
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
o 哈希树更新：对于此过程，将生成一个新的存档时间戳，该时间戳将应用于所有现有的时间戳和数据对象。新生成的存档时间戳放置在
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).
新的存档时间戳链。该过程产生一系列存档时间戳链，这些链包含在单个存档时间戳序列（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.
存档时间戳链和存档时间戳序列是通过续订过程生成的存档时间戳序列的容器。更新过程产生一系列证据记录元素：<ArchiveTimeStampSequence>元素包含<ArchiveTimeStampChain>元素的有序序列，<ArchiveTimeStampChain>元素包含<ArchiveTimeStampChain>元素的有序序列。这两个元素必须按时间戳的时间按升序排序。顺序由Order属性表示。
When an Archive Time-Stamp must be renewed, a new <ArchiveTimeStamp> element is generated and depending on the generation process, it is either placed:
当必须续订存档时间戳时，将生成一个新的<ArchiveTimeStamp>元素，并根据生成过程将其放置在以下位置：
o as the last <ArchiveTimeStamp> child element in a sequence of the last <ArchiveTimeStampChain> element in case of Time-Stamp renewal or
o 作为最后一个<ArchiveTimeStampChain>元素序列中的最后一个<ArchiveTimeStampChain>子元素，以防时间戳更新或
o as the first <ArchiveTimeStamp> child element in a sequence of the newly created <ArchiveTimeStampChain> element in case of hash tree renewal.
o 在哈希树更新的情况下，作为新创建的<ArchiveTimeStampChain>元素序列中的第一个子元素。
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.
Digest method是一个必需元素，它标识用于计算存档数据的哈希值（以及哈希树的节点值）的摘要算法。摘要方法由必需的<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:
算法属性包含标识符的URI[RFC3986]，这些标识符必须按照[RFC3275]和[RFC4051]中的定义使用。例如，当使用SHA-1算法时，算法标识符为：
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
Within a single ATSC, the digest algorithms used for the hash trees of its Archive Time-Stamps and the Time-Stamp Tokens MUST be the same. When algorithms used by a TSA are changed (e.g., upgraded) a new ATSC MUST be started using an equal or stronger digest algorithm.
在单个ATSC中，用于存档时间戳和时间戳令牌的哈希树的摘要算法必须相同。当TSA使用的算法发生变化（例如升级）时，必须使用同等或更强的摘要算法启动新的ATSC。
Prior to hash value calculations of an XML element, a proper binary representation must be extracted from its (abstract) XML data presentation. The binary representation is determined by UTF-8 [RFC3629] encoding and canonicalization of the XML element. The XML element includes the entire text of the start and end tags as well as all descendant markup and character data (i.e., the text and sub-elements) between those tags.
在计算XML元素的散列值之前，必须从其（抽象）XML数据表示中提取适当的二进制表示。二进制表示由XML元素的UTF-8[RFC3629]编码和规范化决定。XML元素包括开始和结束标记的整个文本以及这些标记之间的所有子体标记和字符数据（即文本和子元素）。
<CanonicalizationMethod> is a required element that identifies the canonicalization algorithm used to obtain binary representation of an XML element or elements. Algorithm identifiers (URIs) MUST be used as defined in [RFC3275] and [RFC4051]. For example, when Canonical XML 1.0 (omits comments) is used, algorithm identifier is
<CanonicalizationMethod>是一个必需的元素，用于标识用于获取XML元素的二进制表示形式的规范化算法。必须按照[RFC3275]和[RFC4051]中的定义使用算法标识符（URI）。例如，当使用规范XML 1.0（省略注释）时，算法标识符为
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-
xml-c14n-20010315"/>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-
xml-c14n-20010315"/>
Canonicalization MUST be applied over XML structured archive data and MUST be applied over elements of Evidence Record (namely, ATS and ATSC in the renewing process).
规范化必须应用于XML结构化归档数据，并且必须应用于证据记录的元素（即更新过程中的ATS和ATSC）。
The canonicalization method is specified in the <Algorithm> attribute of the <CanonicalizationMethod> element within the <ArchiveTimeStampChain> element and indicates the canonicalization method that MUST be used for all binary representations of the Archive Time-Stamps within that Archive Time-Stamp Chain. In case of succeeding ATSC the canonicalization method indicated within the ATSC must also be used for the calculation of the digest value of the preceding ATSC. Note that the canonicalization method is unlikely to change over time as it does not impose the same constraints as the digest method. In theory, the same canonicalization method can be used for a whole Archive Time-Stamp Sequence. Although alternative canonicalization methods may be used, it is recommended to use c14n-20010315 [XMLC14N].
规范化方法在<ArchiveTimeStampChain>元素中<canonicalization method>元素的<Algorithm>属性中指定，并指示必须用于该归档时间戳链中归档时间戳的所有二进制表示形式的规范化方法。在后续ATSC的情况下，ATSC中指定的规范化方法也必须用于计算先前ATSC的摘要值。请注意，规范化方法不太可能随时间而改变，因为它不会施加与摘要方法相同的约束。理论上，相同的规范化方法可用于整个归档时间戳序列。尽管可以使用其他规范化方法，但建议使用c14n-20010315[XMLC14N]。
Before the cryptographic algorithms used within the most recent Archive Time-Stamp become weak or the Time-Stamp certificates are invalidated, the LTA has to renew the Archive Time-Stamps by generating a new Archive Time-Stamp using one of two procedures: Time-Stamp renewal or hash tree renewal.
在最近的存档时间戳内使用的加密算法变弱或时间戳证书失效之前，LTA必须通过使用以下两个过程之一生成新的存档时间戳来更新存档时间戳：时间戳更新或哈希树更新。
In case of Time-Stamp renewal, i.e., if the digest algorithm (H) to be used in the renewal process is the same as digest algorithm (H') used in the last Archive Time-Stamp, the complete content of the last <TimeStamp> element MUST be Time-Stamped and a new <ArchiveTimeStamp> element created as follows:
在时间戳更新的情况下，即，如果更新过程中使用的摘要算法（H）与上次存档时间戳中使用的摘要算法（H'）相同，则最后一个<TimeStamp>元素的完整内容必须是时间戳，并创建一个新的<ArchiveTimeStamp>元素，如下所示：
1. If the current <ArchiveTimeStamp> element does not contain needed proof for long-term formal validation of its Time-Stamp Token within the <TimeStamp> element, collect needed data such as root certificates, Certificate Revocation Lists, etc., and include them in the <CryptographicInformationList> element of the last Archive Time-Stamp (each data object into a separate <CryptographicInformation> element).
1. 如果当前<ArchiveTimeStamp>元素在<TimeStamp>元素中不包含对其时间戳令牌进行长期正式验证所需的证据，请收集所需的数据，如根证书、证书吊销列表等，并将其包含在最后一个存档时间戳的<CryptographicInformationList>元素中（将每个数据对象放入一个单独的<CryptographicInformation>元素中）。
2. Select the canonicalization method from the <CanonicalizationMethod> element and select the digest algorithm from the <DigestMethod> element. Calculate hash value from binary representation of the <TimeStamp> element of the last <ArchiveTimeStamp> element including added cryptographic information. Acquire the Time-Stamp for the calculated hash value. If the Time-Stamp is valid, the new Archive Time-Stamp may be generated.
2. 从<CanonicalizationMethod>元素中选择规范化方法，并从<DigestMethod>元素中选择摘要算法。从最后一个<ArchiveTimeStamp>元素的<TimeStamp>元素的二进制表示（包括添加的加密信息）计算哈希值。获取计算出的哈希值的时间戳。如果时间戳有效，则可能会生成新的存档时间戳。
3. Increase the value order of the new ATS by one and place the new ATS into the last <ArchiveTimeStampChain> element.
3. 将新ATS的值顺序增加1，并将新ATS放入最后一个<ArchiveTimeStampChain>元素中。
The new ATS and its hash tree MUST use the same digest algorithm as the preceding one, which is specified in the <DigestMethod> element within the <ArchiveTimeStampChain> element. Note that the new ATS MAY not contain a hash tree. However, the Time-Stamp renewal process may be optimized to acquire one Time-Stamp for many Archive Time-Stamps using a hash tree. Note that each hash of the <TimeStamp> element is treated as the document hash in Section 3.2.1.
新的ATS及其哈希树必须使用与前一个相同的摘要算法，该算法在<ArchiveTimeStampChain>元素中的<DigestMethod>元素中指定。请注意，新ATS可能不包含哈希树。然而，可以优化时间戳更新过程以使用散列树为多个存档时间戳获取一个时间戳。注意，<TimeStamp>元素的每个散列在第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>元素的二进制表示，计算hash hseq=H（ATSSeq）。请注意，存档时间戳链和存档时间戳必须按时间顺序排列，每个都对应于其顺序属性，并且必须应用规范化方法C。
6. For each archive object sort in binary ascending order and concatenate all h(i) and the hseq. Generate a new digest value h(j)=H(h(1)..h(n),hseq).
6. 对于每个归档对象，按二进制升序排序，并连接所有h（i）和hseq。生成一个新的摘要值h（j）=h（h（1）…h（n），hseq）。
7. Build a new Archive Time-Stamp for each h(j) (hash tree generation and reduction is defined in Sections 3.2.1 and 3.2.2). Note that each h(j) is treated as the document hash in Section 3.2.1. The first hash value list in the reduced hash tree should only contain h(i) and hseq.
7. 为每个h（j）构建一个新的归档时间戳（散列树的生成和减少在第3.2.1节和第3.2.2节中定义）。注意，在第3.2.1节中，每个h（j）都被视为文档散列。缩减哈希树中的第一个哈希值列表应仅包含h（i）和hseq。
8. Create the new <ArchiveTimeStampChain> containing the new <ArchiveTimeStamp> element (with order number 1), and place it into the existing <ArchiveTimeStampSequence> as a last child with the order number increased by one.
8. 创建包含新<ArchiveTimeStampChain>元素（订单号为1）的新<ArchiveTimeStampChain>，并将其作为订单号增加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
敖
/ | \
/ | \
d1 d2 d3
d1 d2 d3
ATSSeq ATSChain1: ATS0, ATS1
ATSSeq ATSChain1:ATS0，ATS1
ATSChain2: ATS0, ATS1, ATS2
ATSChain2:ATS0、ATS1、ATS2
The hash values MUST be calculated with the new hash algorithm H for all data objects and for the whole ATSSeq. Note that ATSSeq MUST be chronologically ordered and canonicalized before retrieving its binary representation.
对于所有数据对象和整个ATSSeq，必须使用新的哈希算法H计算哈希值。请注意，在检索其二进制表示之前，ATSSeq必须按时间顺序排列并规范化。
When generating the hash tree for the new ATS, the first sequence become values: H(d1), H(d2),..., H(dn), H(ATSSeq). Note: hash values MUST be sorted in binary ascending order.
为新ATS生成哈希树时，第一个序列变为值：H（d1）、H（d2）、…、H（dn）、H（ATSSeq）。注意：哈希值必须按二进制升序排序。
<HashTree>
<Sequence Order='1'>
<DigestValue>H(d1)</DigestValue>
<DigestValue>H(d2)</DigestValue>
<DigestValue>H(d3)</DigestValue>
<DigestValue>H(ATSSeq)</DigestValue>
</Sequence>
</HashTree>
<HashTree>
<Sequence Order='1'>
<DigestValue>H(d1)</DigestValue>
<DigestValue>H(d2)</DigestValue>
<DigestValue>H(d3)</DigestValue>
<DigestValue>H(ATSSeq)</DigestValue>
</Sequence>
</HashTree>
Note that if the group processing is being performed, the hash value of the concatenation of the first sequence is an input hash value into the hash tree.
注意，如果正在执行组处理，则第一序列的串联的散列值是散列树中的输入散列值。
An Evidence Record shall prove that an archive object existed and has not been changed from the time of the initial Time-Stamp Token within the first ATS. In order to complete the non-repudiation proof for an archive object, the last ATS has to be valid and ATSCs and their relations to each other have to be proved:
证据记录应证明存档对象存在，且自第一次ATS内的初始时间戳令牌时间起未发生变化。为了完成档案对象的不可否认性证明，最后的ATS必须有效，并且必须证明ATSC及其相互关系：
1. Select archive object and re-encrypt its data object or data object group, if <EncryptionInformation> field is used. Select the initial digest algorithm specified within the first Archive
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. 验证每个存档时间戳链和内的每个存档时间戳。如果哈希树存在于存档时间戳链的第二个和下一个存档时间戳内，则第一个<Sequence>必须包含之前<TimeStamp>元素的哈希值。每个存档时间戳必须相对于后续存档时间戳的时间有效。具有存档时间戳链的所有存档时间戳必须使用相同的哈希算法，该算法在后续存档时间戳链的第一个存档时间戳时是安全的。
3. Verify that the first hash value list of the first Archive Time-Stamp of all succeeding Archive Time-Stamp Chains contains hash values of data object and the hash value of Archive Time-Stamp Sequence of the preceding Archive Time-Stamp Chains. Verify that Archive Time-Stamp was created when the last Archive Time-Stamp of the preceding Archive Time-Stamp Chain was valid.
3. 验证所有后续存档时间戳链的第一个存档时间戳的第一个哈希值列表是否包含数据对象的哈希值和前一个存档时间戳链的存档时间戳序列的哈希值。验证是否在上一个存档时间戳链的最后一个存档时间戳有效时创建了存档时间戳。
4. To prove the Archive Time-Stamp Sequence relates to a data object group, verify that the first Archive Time-Stamp of the first Archive Time-Stamp Chain does not contain other hash values in its first hash value list than the hash values of those data objects.
4. 要证明存档时间戳序列与数据对象组相关，请验证第一存档时间戳链的第一存档时间戳在其第一哈希值列表中不包含除这些数据对象的哈希值以外的其他哈希值。
For non-repudiation proof for the data object, the last Archive Time-Stamp MUST be valid at the time of verification process.
对于数据对象的不可否认性证明，最后一个存档时间戳必须在验证过程时有效。
In some archive services scenarios it may be required that clients send encrypted data only, preventing information disclosure to third parties, such as archive service providers. In such scenarios it must be clear that Evidence Records generated refer to encrypted data objects. Evidence Records in general protect the bit-stream (or binary representation of XML data), which freezes the bit structure at the time of archiving. Encryption schemes in such scenarios cannot be changed afterwards without losing the integrity proof. Therefore, an ERS record must hold and preserve encryption information in a consistent manner. To avoid problems when using Evidence Records in the future, additional special precautions have to be taken.
在某些存档服务场景中，可能要求客户端仅发送加密数据，以防止信息泄露给第三方，如存档服务提供商。在这种情况下，必须明确生成的证据记录是指加密的数据对象。证据记录通常会保护位流（或XML数据的二进制表示），这会在存档时冻结位结构。在这种情况下，加密方案在不丢失完整性证明的情况下不能在事后更改。因此，ERS记录必须以一致的方式保存加密信息。为了避免将来使用证据记录时出现问题，必须采取额外的特别预防措施。
Encryption is a two-way process, whose result depends on the cryptographic material used, e.g., encryption keys and encryption algorithms. Encryption and decryption keys as well as algorithms must match in order to reconstruct the original message or data that was encrypted. Evidence generated to prove the existence of encrypted data cannot always be relied upon to prove the existence of unencrypted data. It may be possible to choose different cryptographic material, i.e., an algorithm or a key for decryption that is not the algorithm or key used for encryption. In this case, the evidence record would not be a non-repudiation proof for the unencrypted data. Therefore, only encryption methods should be used that make it possible to prove that archive Time-Stamped encrypted data objects unambiguously represent unencrypted data objects. In cases when evidence was generated to prove the existence of encrypted data the corresponding algorithm and decryption keys used for encryption must become a part of the Evidence Record and is used to unambiguously represent original (unencrypted) data that was encrypted. (Note: In addition, the long-term security of the encryption schemes should be analyzed to determine if it could be used to create collision attacks.) Cryptographic material may also be used in scenarios when a client submits encrypted data to the archive service provider for preservation but stores himself the data only in an unencrypted form. In such scenarios cryptographic material is used to re-encrypt the unencrypted data kept by a client for the purpose of performing validation of the Evidence Record, which is related to the encrypted form of client's data. An OPTIONAL extensible structure <EncryptionInformation> is defined to store the necessary parameters of the encryption methods. Its <EncryptionInformationType> element is used to store the type of stored encryption information, e.g., whether it is an encryption algorithm or encryption key. The <EncryptionInformationValue> element then contains the relevant encryption information itself. The use of encryption elements heavily depends on the cryptographic mechanism and has to be defined by other specifications.
加密是一个双向过程，其结果取决于所使用的加密材料，例如加密密钥和加密算法。加密和解密密钥以及算法必须匹配，以便重建加密的原始消息或数据。为证明加密数据的存在而生成的证据不能总是用来证明未加密数据的存在。可以选择不同的加密材料，即，用于解密的算法或密钥不是用于加密的算法或密钥。在这种情况下，证据记录不会是未加密数据的不可抵赖证据。因此，只应使用能够证明存档时间戳加密数据对象明确表示未加密数据对象的加密方法。在生成证据以证明加密数据存在的情况下，用于加密的相应算法和解密密钥必须成为证据记录的一部分，并用于明确表示加密的原始（未加密）数据。（注意：此外，应分析加密方案的长期安全性，以确定其是否可用于创建冲突攻击。）当客户端将加密数据提交给存档服务提供商保存，但仅以未加密的形式存储数据时，也可使用加密材料。在这种情况下，加密材料用于对客户保存的未加密数据进行重新加密，以验证与客户数据加密形式相关的证据记录。定义了可选的可扩展结构<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版本的编号方案为“<major><minor>”。主数字和次数字必须被视为独立的整数，每个数字的增量可以大于一个位数。因此，“2.4”的版本低于“2.13”，而“2.13”的版本又低于“12.3”。收件人必须忽略前导零（例如“6.01”），并且不得发送前导零。
The major version number will be incremented only if the data format has changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the elements and attributes it did not understand and took the actions defined in the older specification.
只有当数据格式发生了如此显著的变化，以至于旧版本实体无法与新版本实体进行互操作时（如果它忽略了它不理解的元素和属性，并采取了旧规范中定义的操作），主版本号才会增加。
The minor version number will be incremented if significant new capabilities have been added to the core format (e.g., new optional elements).
如果核心格式中添加了重要的新功能（例如，新的可选元素），则次要版本号将增加。
As explained above policies can be stored in the Evidence Record in the <Attribute> or the <SupportingInformation> element. In the case of storing DSSC policies [RFC5698], the types to be used in the <Attribute> or <SupportingInformation> element are defined in Appendix A.2 of [RFC5698] for both ASN.1 and XML representation.
如上所述，策略可以存储在<Attribute>或<SupportingInformation>元素中的证据记录中。在存储DSSC策略[RFC5698]的情况下，[RFC5698]的附录A.2为ASN.1和XML表示定义了<Attribute>或<SupportingInformation>元素中使用的类型。
<?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" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:ers"
targetNamespace="urn:ietf:params:xml:ns:ers"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="EvidenceRecord" type="EvidenceRecordType"/>
<!-- TYPE DEFINITIONS-->
<!-- TYPE DEFINITIONS-->
<xs:complexType name="EvidenceRecordType">
<xs:sequence>
<xs:element name="EncryptionInformation"
type="EncryptionInfo" minOccurs="0"/>
<xs:element name="SupportingInformationList"
type="SupportingInformationType" minOccurs="0"/>
<xs:element name="ArchiveTimeStampSequence"
type="ArchiveTimeStampSequenceType"/>
</xs:sequence>
<xs:attribute name="Version" type="xs:decimal" use="required"
fixed="1.0"/>
</xs:complexType>
<xs:complexType name="EvidenceRecordType">
<xs:sequence>
<xs:element name="EncryptionInformation"
type="EncryptionInfo" minOccurs="0"/>
<xs:element name="SupportingInformationList"
type="SupportingInformationType" minOccurs="0"/>
<xs:element name="ArchiveTimeStampSequence"
type="ArchiveTimeStampSequenceType"/>
</xs:sequence>
<xs:attribute name="Version" type="xs:decimal" use="required"
fixed="1.0"/>
</xs:complexType>
<xs:complexType name="EncryptionInfo">
<xs:sequence>
<xs:element name="EncryptionInformationType"
type="ObjectIdentifier"/>
<xs:element name="EncryptionInformationValue">
<xs:complexType name="EncryptionInfo">
<xs:sequence>
<xs:element name="EncryptionInformationType"
type="ObjectIdentifier"/>
<xs:element name="EncryptionInformationValue">
<xs:complexType mixed="true">
<xs:sequence>
<xs:any minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType mixed="true">
<xs:sequence>
<xs:any minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArchiveTimeStampSequenceType">
<xs:sequence>
<xs:element name="ArchiveTimeStampChain" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DigestMethod"
type="DigestMethodType"/>
<xs:element name="CanonicalizationMethod"
type="CanonicalizationMethodType"/>
<xs:element name="ArchiveTimeStamp"
type="ArchiveTimeStampType"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArchiveTimeStampSequenceType">
<xs:sequence>
<xs:element name="ArchiveTimeStampChain" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DigestMethod"
type="DigestMethodType"/>
<xs:element name="CanonicalizationMethod"
type="CanonicalizationMethodType"/>
<xs:element name="ArchiveTimeStamp"
type="ArchiveTimeStampType"
maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ArchiveTimeStampType">
<xs:sequence>
<xs:element name="HashTree" type="HashTreeType" minOccurs="0"/>
<xs:element name="TimeStamp" type="TimeStampType"/>
<xs:element name="Attributes" type="Attributes" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType" use="required"/>
</xs:complexType>
<xs:complexType name="ArchiveTimeStampType">
<xs:sequence>
<xs:element name="HashTree" type="HashTreeType" minOccurs="0"/>
<xs:element name="TimeStamp" type="TimeStampType"/>
<xs:element name="Attributes" type="Attributes" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType" use="required"/>
</xs:complexType>
<xs:complexType name="DigestMethodType" mixed="true">
<xs:sequence>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="DigestMethodType" mixed="true">
<xs:sequence>
<xs:any namespace="##other" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="CanonicalizationMethodType" mixed="true">
<xs:sequence minOccurs="0">
<xs:any namespace="##any" minOccurs="0"/>
<xs:complexType name="CanonicalizationMethodType" mixed="true">
<xs:sequence minOccurs="0">
<xs:any namespace="##any" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="TimeStampType">
<xs:sequence>
<xs:element name="TimeStampToken">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="CryptographicInformationList"
type="CryptographicInformationType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="HashTreeType">
<xs:sequence>
<xs:element name="Sequence" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DigestValue" type="xs:base64Binary"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="TimeStampType">
<xs:sequence>
<xs:element name="TimeStampToken">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="CryptographicInformationList"
type="CryptographicInformationType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="HashTreeType">
<xs:sequence>
<xs:element name="Sequence" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DigestValue" type="xs:base64Binary"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Attributes">
<xs:sequence>
<xs:element name="Attribute" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<xs:complexType name="Attributes">
<xs:sequence>
<xs:element name="Attribute" maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
<xs:attribute name="Type" type="xs:string"
use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CryptographicInformationType">
<xs:sequence>
<xs:element name="CryptographicInformation"
maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
<xs:attribute name="Type" type="xs:string"
use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="CryptographicInformationType">
<xs:sequence>
<xs:element name="CryptographicInformation"
maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Order" type="OrderType"
use="required"/>
<xs:attribute name="Type" type="xs:NMTOKEN"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="SupportingInformationType">
<xs:sequence>
<xs:element name="SupportingInformation"
maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Type" type="xs:string"
use="required"/>
</xs:restriction>
</xs:complexContent>
<xs:complexType name="SupportingInformationType">
<xs:sequence>
<xs:element name="SupportingInformation"
maxOccurs="unbounded">
<xs:complexType mixed="true">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Type" type="xs:string"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="ObjectIdentifier">
<xs:restriction base="xs:token">
<xs:pattern value="[0-2](\.[1-3]?[0-9]?(\.\d+)*)?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ObjectIdentifier">
<xs:restriction base="xs:token">
<xs:pattern value="[0-2](\.[1-3]?[0-9]?(\.\d+)*)?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="OrderType">
<xs:restriction base="xs:int">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
<xs:simpleType name="OrderType">
<xs:restriction base="xs:int">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Cryptographic algorithms and parameters that are used within Archive Time-Stamps must always be secure at the time of generation. This concerns the hash algorithm used in the hash lists of Archive Time-Stamp as well as hash algorithms and public key algorithms of the Time-Stamps. Publications regarding security suitability of cryptographic algorithms ([NIST.800-57-Part1.2006] and [ETSI-TS-102-176-1-V2.0.0]) have to be considered during the verification. A generic solution for automatic interpretation of security suitability policies in electronic form is not the subject of this specification.
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.translate error, please retry
Evidence Records may become affected by weakening cryptographic algorithms even before this is publicly known. Retrospectively this has an impact on Archive Time-Stamps generated and renewed during the archival period. In this case the validity of Evidence Records created may end without any options for retroactive action.
证据记录可能会受到加密算法减弱的影响，甚至在这一点被公开之前。回顾性地说，这会对归档期间生成和更新的归档时间戳产生影响。在这种情况下，创建的证据记录的有效性可能会在没有任何追溯行动选项的情况下终止。
Many TSAs are using the same cryptographic algorithms. While compromise of a private key of a TSA may compromise the security of only one TSA (and only one Archive Time-Stamp, for example), weakening cryptographic algorithms used to generate Time-Stamp Tokens would affect many TSAs at the same time.
许多TSA使用相同的加密算法。虽然泄露TSA的私钥可能只会泄露一个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.
为管理此类风险并避免由于使用的加密算法减弱而丢失证据记录的有效性，建议为单个数据对象生成和管理至少两个冗余证据记录。在这种情况下，冗余证据记录应在存档时间戳序列中使用不同的哈希算法，不同的TSA应使用不同的时间戳令牌加密算法。
Archive Time-Stamps depend upon the security of normal Time-Stamping provided by TSA and stated in security policies. Renewed Archive Time-Stamps MUST have the same or higher quality as the initial Archive Time-Stamp of archive data. Archive Time-Stamps used for signed archive data SHOULD have the same or higher quality than the maximum quality of the signatures.
存档时间戳取决于TSA提供并在安全策略中说明的正常时间戳的安全性。更新的存档时间戳必须与存档数据的初始存档时间戳具有相同或更高的质量。用于签名存档数据的存档时间戳的质量应与签名的最高质量相同或更高。
It is important to consider for renewal and verification that when a new Time-Stamp is applied, it MUST be ascertained that prior to the time of renewal (i.e., when the new Time-Stamp is applied) the certificate of the before current Time-Stamp was not revoked due to a key compromise. Otherwise, in the case of a key compromise, there is the risk that the authenticity of the used Time-Stamp and therefore its security in the chain of evidence cannot be guaranteed. Other revocation reasons like the revocation for cessation of activity do not necessarily pose this risk, as in that case the private key of the Time-Stamp unit would have been previously destroyed and thus cannot be used nor compromised.
重要的是考虑更新和验证，当应用新的时间戳时，必须确定在更新时间之前（即，当应用新的时间戳）时，由于密钥折衷而未撤销之前的当前时间戳的证书。否则，在关键泄露的情况下，使用的时间戳的真实性及其在证据链中的安全性可能无法得到保证。其他撤销原因，如为停止活动而撤销，不一定会造成这种风险，因为在这种情况下，时间戳单元的私钥先前会被销毁，因此无法使用或泄露。
Both elements <CryptographicInformationList> and <Attribute> are protected by future Archive Time_Stamp renewals and can store information as outlined in Section 2.1 that is available at or before the time of the renewal of the specific Archive Time-Stamp. At the time of renewal all previous Archive Time-Stamp data structures become protected by the new Archive Time-Stamp and frozen by it, i.e., no data MUST be added or modified in these elements afterwards. If, however, some supporting information is relevant for the overall Evidence Record or information that only becomes available later, this can be provided in the Evidence Record in the <SupportingInformationList> element. Data in the <SupportingInformatonList> can be added later to an Evidence Record, but it must rely on its own authenticity and integrity protection mechanism, like, for example, signed by current strong cryptographic means and/or provided by a trusted source (for example, this could be the LTA providing its current system DSSC policy, signed with current strong cryptographic means).
元素<CryptographicInformationList>和<Attribute>都受未来存档时间戳续订的保护，并且可以存储第2.1节中概述的在特定存档时间戳续订时或之前可用的信息。在续订时，所有以前的存档时间戳数据结构都将受到新存档时间戳的保护并被其冻结，即，以后不得在这些元素中添加或修改任何数据。但是，如果某些支持信息与整个证据记录相关，或者仅在以后可用，则可以在<SupportingInformationList>元素的证据记录中提供。<SupportingInformationList>中的数据可以稍后添加到证据记录中，但它必须依赖其自身的真实性和完整性保护机制，例如，由当前强大的加密手段签名和/或由可信来源提供（例如，这可能是LTA提供其当前系统DSSC策略，并使用当前强加密方式签名）。
For all IANA registrations related to this document, the "Specification Required" [RFC5226] allocation policies MUST be used.
对于与本文件相关的所有IANA注册，必须使用“所需规范”[RFC5226]分配策略。
This document defines the XML namespace "urn:ietf:params:xml:ns:ers" according to the guidelines in [RFC3688]. This namespace has been registered in the IANA XML Registry.
本文档根据[RFC3688]中的指南定义了XML名称空间“urn:ietf:params:XML:ns:ers”。此命名空间已在IANA XML注册表中注册。
This document defines an XML schema (see Section 8) according to the guidelines in [RFC3688]. This XML schema has been registered in the IANA XML Registry and can be identified with the URN "urn:ietf:params:xml:schema:ers".
本文档根据[RFC3688]中的指南定义了XML模式（参见第8节）。此XML模式已在IANA XML注册表中注册，可以通过URN“URN:ietf:params:XML:schema:ers”标识。
This specification defines a new IANA registry entitled "XML Evidence Record Syntax (XMLERS)". This registry contains two sub-registries entitled "Time-Stamp Token Type" and "Cryptographic Information Type". The policy for future assignments to both sub-registries is "RFC Required".
本规范定义了一个名为“XML证据记录语法（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数据类型“xs:NMTOKEN”。
o A reference to a publicly available specification that defines the Time-Stamp Token type (description).
o 对定义时间戳令牌类型（描述）的公共可用规范的引用。
The initial values for the "Time-Stamp Token Type" sub-registry are:
“时间戳令牌类型”子注册表的初始值为：
Value
Description
Reference
-------------
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
EnTrust XML Schema
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:
When registering a new cryptographic information type, the following information MUST be provided:translate error, please retry
o The textual name of the cryptographic information type (value). The value MUST conform to the XML datatype "xs:NMTOKEN".
o 加密信息类型（值）的文本名称。该值必须符合XML数据类型“xs:NMTOKEN”。
o A reference to a publicly available specification that defines the cryptographic information type (description).
o 对定义加密信息类型（描述）的公共可用规范的引用。
The initial values for the "Cryptographic Information Type" sub-registry are:
“加密信息类型”子注册表的初始值为：
Value Description Reference
----- ------------------ -----------------
Value Description Reference
----- ------------------ -----------------
CERT DER-encoded X.509 Certificate RFC 5280
证书编码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 DER编码OCSP响应RFC 2560
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]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[RFC3161]Adams，C.，Cain，P.，Pinkas，D.，和R.Zuccherato，“互联网X.509公钥基础设施时间戳协议（TSP）”，RFC3161，2001年8月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]Eastlake 3rd，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC 32752002年3月。
[RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005.
[RFC4051]Eastlake 3rd，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数据编码”，RFC4648，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 49982007年8月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055]Freeman，T.，Housley，R.，Malpani，A.，Cooper，D.，和W.Polk，“基于服务器的证书验证协议（SCVP）”，RFC 50552007年12月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[XMLC14N] Boyer, J., "Canonical XML", W3C Recommendation, March 2001.
[XMLC14N]Boyer，J.，“规范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.，雷格尔，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]Layman，A.，Hollander，D.，Tobin，R.，和T.Bray，“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.
[XMLSchema]Thompson，H.，Beech，D.，Mendelsohn，N.，和M.Maloney，“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.952005年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-12002年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.
[Merkle，R.，公钥密码系统协议，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 Part1，2006年5月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470]Hollenbeck，S.，Rose，M.，和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，2003年1月。
[RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term Archive Service Requirements", RFC 4810, March 2007.
[RFC4810]Wallace，C.，Pordesch，U.，和R.Brandner，“长期档案服务要求”，RFC 48102007年3月。
[RFC5126] Pinkas, D., Pope, N., and J. Ross, "CMS Advanced Electronic Signatures (CAdES)", RFC 5126, March 2008.
[RFC5126]Pinkas，D.，Pope，N.，和J.Ross，“CMS高级电子签名（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-TRUST]斯洛文尼亚时间戳管理局，委托XML模式进行时间戳，http://www.si-tsa.gov.si/ dokumenti/timestamp-protocol-20020207.xsd。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（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]Cruelas，J.C.，Karlinger，G.，Pinkas，D.，Ross，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 56522009年9月。
[RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)", RFC 5698, November 2009.
[RFC5698]Kunz，T.，Okunick，S.，和U.Pordesch，“加密算法（DSSC）安全适用性的数据结构”，RFC 5698，2009年11月。
To verify the validity of an Evidence Record start with the first ATS till the last ATS (ordered by attribute Order) and perform verification for each ATS, as follows:
为了验证证据记录的有效性，从第一个ATS开始直到最后一个ATS（按属性顺序排序），并对每个ATS进行验证，如下所示：
1. Select corresponding archive object and its data object or a group of data objects.
1. 选择相应的存档对象及其数据对象或一组数据对象。
2. Re-encrypt data object or data object group, if the <EncryptionInformation> field is used (see Section 5 for more details)
2. 如果使用<EncryptionInformation>字段，则重新加密数据对象或数据对象组（有关更多详细信息，请参阅第5节）
3. Get a canonicalization method C and a digest method H from the <DigestMethod> element of the current chain.
3. 从当前链的<DigestMethod>元素中获取规范化方法C和摘要方法H。
4. Make a new list L of digest values of (binary representation of) objects (data, ATS, or sequence) that MUST be protected with this ATS as follows:
4. 将必须使用该ATS保护的对象（数据、ATS或序列）的（二进制表示）摘要值列成一个新列表，如下所示：
a. If this ATS is the first in the Archive Time-Stamp Chain:
a. 如果此ATS是存档时间戳链中的第一个：
i. If this is the first ATS of the first ATSC (the initial ATS) in the ATSSeq, calculate digest values of data objects with H and add each digest value to the list L.
i. 如果这是ATSSeq中第一个ATSC（初始ATS）的第一个ATS，则使用H计算数据对象的摘要值，并将每个摘要值添加到列表L中。
ii. If this ATS is not the initial ATS, calculate a digest value with H of ordered ATSSeq without this and successive chains. Add value H and digest values of data objects to the list L.
二,。如果该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.
i. 使用上一个<TimeSatmp>元素的H计算摘要值，并将此摘要值添加到列表L中。
5. Verify the ATS's Time-Stamped value as follows. Get the first sequence of the hash tree for this ATS.
5. 验证ATS的时间戳值，如下所示。获取此ATS的哈希树的第一个序列。
a. If this ATS has no hash tree elements then:
a. 如果此ATS没有哈希树元素，则：
ii. If this ATS is not the first in the ATSSeq (the initial ATS), then the Time-Stamped value must be equal to the digest value of previous Time-Stamp element. If not, exit with a negative result.
二,。如果该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).
i. 从当前ATS获取哈希树，并使用H计算根哈希值（见第3.2.1和3.2.2节）。
ii. Get Time-Stamped value from the Time-Stamp Token. If calculated root hash value from the hash tree does not match the Time-Stamped value, exit with a negative result.
二,。从时间戳令牌获取时间戳值。如果从哈希树计算的根哈希值与时间戳值不匹配，则以负数结果退出。
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 Tehnoloski公园21 1000
Phone: +386 (0) 1 620 4500
Fax: +386 (0) 1 620 4509
EMail: aljosa@setcce.si
Phone: +386 (0) 1 620 4500
Fax: +386 (0) 1 620 4509
EMail: aljosa@setcce.si
Svetlana Saljic SETCCE Tehnoloski park 21 1000 Ljubljana Slovenia
斯洛文尼亚卢布尔雅那Svetlana Saljic SETCCE Tehnoloski公园21 1000
Phone: +386 (0) 1 620 4506
Fax: +386 (0) 1 620 4509
EMail: svetlana.saljic@setcce.si
Phone: +386 (0) 1 620 4506
Fax: +386 (0) 1 620 4509
EMail: svetlana.saljic@setcce.si
Tobias Gondrom Kruegerstr. 5A 85716 Unterschleissheim Germany
Tobias Gondrom Kruegerstr。5A 85716 Unterschleisheim德国
Phone: +49 (0) 89 320 5330
EMail: tobias.gondrom@gondrom.org
Phone: +49 (0) 89 320 5330
EMail: tobias.gondrom@gondrom.org