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)
AbstractIn 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. 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. 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. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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.
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
RFC4998]. 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. 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.
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. 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]. 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. Evidence Record Syntax in XML format is based on long-term archive service requirements as defined in [RFC4810]. XMLERS delivers the same (level of) non-repudiable proof of data existence as ASN.1 ERS [RFC4998]. The XML syntax supports archive data grouping (and de- grouping) together with simple or complex Time-Stamp renewal processes. Evidence Records can be embedded in the data itself or stored separately as a standalone XML file. RFC4810]. This document also refers to the ASN.1 ERS specification as defined in [RFC4998].
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. 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.
Section 3). Archive Time-Stamp Chain (ATSC): An ATSC holds a sequence of Archive Time-Stamps generated during the preservation period. Archive Time-Stamp Sequence (ATSSeq): AN ATSSeq is a sequence of Archive Time-Stamp Chains. 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]. 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. 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. 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]. RFC2119].
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). Section 8 (where "?" denotes zero or one occurrences, "+" denotes one or more occurrences, and "*" denotes zero or more occurrences):
<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> 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. The XML elements and attributes have the following meanings: The "Version" attribute MUST be included and indicates the syntax version, for compatibility with future revisions of this specification and to distinguish it from earlier non-conformant or proprietary versions of XMLERS. Current version of XMLERS is 1.0. The used versioning scheme is described in detail in Section 6. <EncryptionInformation> element is OPTIONAL and holds information on cryptographic algorithms and cryptographic material used to encrypt archive data (in case archive data is encrypted, e.g., for privacy purposes). This optional information is needed to unambiguously re-encrypt data objects when processing Evidence Records. When omitted, data objects are not encrypted or
non-repudiation proof is not needed for the unencrypted data. Details on how to process encrypted archive data and generate Evidence Record(s) are described in Section 5. <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. <ArchiveTimeStampSequence> is REQUIRED and contains a sequence of one or more <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. <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.
<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. <HashTree> is an OPTIONAL element that holds a structure as described in Section 3.1.1. <TimeStamp> is REQUIRED and holds a <TimeStampToken> element with a Time-Stamp Token (as defined in Section 3.1.2) provided by the Time-Stamping Authority and an OPTIONAL element <CryptographicInformationList>. <CryptographicInformationList> 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. <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]. 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.
Section 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). 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. 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).
<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. 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. 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). 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>. RFC3161] specifies a structure for signed Time-Stamp Tokens in ASN.1 format. Since at the time being
there is no standard for an XML Time-Stamp, the following structure example is provided [TS-ENTRUST], which is a digital signature compliant to [XMLDSig] specification containing Time-Stamp specific data, such as Time-Stamped value and time within the <Object> element of a signature. <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. For example: <TimeStamp Type="RFC3161">MIAGCSqGSIb3DQEH...</TimeStamp> or <TimeStamp Type="XMLENTRUST"><dsig:Signature>...</dsig:Signature> </TimeStamp>
<CryptographicInformationList> element; each data object is stored into a separate <CryptographicInformation> element, with a REQUIRED Order attribute. 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: o for type CRL, a base64 encoding of a DER-encoded X.509 CRL [RFC5280] o for type OCSP, a base64 encoding of a DER-encoded OCSPResponse [RFC2560] o for type SCVP, a base64 encoding of a DER-encoded CVResponse; [RFC5055] o for type CERT, a base64 encoding of a DER-encoded X.509 certificate [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). Section 4). Note that the selected canonicalization method MUST be used also for archive data when data is represented in XML format. 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. 4. Generate a hash tree for selected archive object (see Section 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. 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. Section 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. 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.
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. 4. Repeat step 3, until only one digest value is left; this is the root value of the hash tree, which is Time-Stamped. Note that the selected secure hash algorithm MUST be the same as the one defined in the <DigestMethod> element of the ATSChain. 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.
---------- 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 Note that there are no restrictions on the quantity of hash value lists and of their length. Also note that it is beneficial but not required to build hash trees and reduce hash trees. An Archive Time- Stamp may consist only of one list of hash values and a Time-Stamp or in an extreme case only a Time-Stamp with no hash value lists.
1. For a selected archive object (AO) select its hash value h within the leaves of the hash tree. 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. 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. 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. The order of <DigestValue> elements within each <Sequence> element MUST be binary ascending (by base64 decoded values). Reduced hash tree for data object d4 (from the previous example, presented in Figure 1): <HashTree> <Sequence Order='1'> <DigestValue>base64 encoded h4</DigestValue> <DigestValue>base64 encoded h5</DigestValue> <DigestValue>base64 encoded h6</DigestValue> <DigestValue>base64 encoded h7</DigestValue> </Sequence> <Sequence Order='2'> <DigestValue>base64 encoded h8</DigestValue> <DigestValue>base64 encoded h9</DigestValue> </Sequence> <Sequence Order='3'> <DigestValue>base64 encoded h''1</DigestValue> <DigestValue>base64 encoded h''3</DigestValue> </Sequence> <Sequence Order='4'> <DigestValue>base64 encoded h'''2</DigestValue> </Sequence> </HashTree> Reduced hash tree for data object d2 (from the previous example, presented in Figure 1):
<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>
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. 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.
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). 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.
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: <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. 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. <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 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). 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].
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. 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.
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. AO / | \ d1 d2 d3 ATSSeq ATSChain1: ATS0, ATS1 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. 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. <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.
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. 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. 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. 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. For non-repudiation proof for the data object, the last Archive Time- Stamp MUST be valid at the time of verification process.
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.
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). 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.
<xs:complexType mixed="true"> <xs:sequence> <xs:any minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="ArchiveTimeStampSequenceType"> <xs:sequence> <xs:element name="ArchiveTimeStampChain" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="DigestMethod" type="DigestMethodType"/> <xs:element name="CanonicalizationMethod" type="CanonicalizationMethodType"/> <xs:element name="ArchiveTimeStamp" type="ArchiveTimeStampType" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="Order" type="OrderType" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="ArchiveTimeStampType"> <xs:sequence> <xs:element name="HashTree" type="HashTreeType" minOccurs="0"/> <xs:element name="TimeStamp" type="TimeStampType"/> <xs:element name="Attributes" type="Attributes" minOccurs="0"/> </xs:sequence> <xs:attribute name="Order" type="OrderType" use="required"/> </xs:complexType> <xs:complexType name="DigestMethodType" mixed="true"> <xs:sequence> <xs:any namespace="##other" minOccurs="0"/> </xs:sequence> <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/> </xs:complexType> <xs:complexType name="CanonicalizationMethodType" mixed="true"> <xs:sequence minOccurs="0"> <xs:any namespace="##any" minOccurs="0"/>
</xs:sequence> <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/> </xs:complexType> <xs:complexType name="TimeStampType"> <xs:sequence> <xs:element name="TimeStampToken"> <xs:complexType mixed="true"> <xs:complexContent mixed="true"> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Type" type="xs:NMTOKEN" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="CryptographicInformationList" type="CryptographicInformationType" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="HashTreeType"> <xs:sequence> <xs:element name="Sequence" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="DigestValue" type="xs:base64Binary" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Order" type="OrderType" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="Attributes"> <xs:sequence> <xs:element name="Attribute" maxOccurs="unbounded"> <xs:complexType mixed="true"> <xs:complexContent mixed="true"> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> <xs:attribute name="Order" type="OrderType" use="required"/> <xs:attribute name="Type" type="xs:string" use="optional"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="CryptographicInformationType"> <xs:sequence> <xs:element name="CryptographicInformation" maxOccurs="unbounded"> <xs:complexType mixed="true"> <xs:complexContent mixed="true"> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Order" type="OrderType" use="required"/> <xs:attribute name="Type" type="xs:NMTOKEN" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="SupportingInformationType"> <xs:sequence> <xs:element name="SupportingInformation" maxOccurs="unbounded"> <xs:complexType mixed="true"> <xs:complexContent mixed="true"> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="Type" type="xs:string" use="required"/> </xs:restriction> </xs:complexContent>
</xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:simpleType name="ObjectIdentifier"> <xs:restriction base="xs:token"> <xs:pattern value="[0-2](\.[1-3]?[0-9]?(\.\d+)*)?"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="OrderType"> <xs:restriction base="xs:int"> <xs:minInclusive value="1"/> </xs:restriction> </xs:simpleType> </xs:schema> 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.
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. 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).
RFC5226] allocation policies MUST be used. 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. 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". 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". 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 A reference to a publicly available specification that defines the Time-Stamp Token type (description). The initial values for the "Time-Stamp Token Type" sub-registry are: Value Description Reference ------------- RFC3161 RFC3161 Time-Stamp RFC 3161 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. When registering a new cryptographic information type, the following information MUST be provided: o The textual name of the cryptographic information type (value). The value MUST conform to the XML datatype "xs:NMTOKEN". o A reference to a publicly available specification that defines the cryptographic information type (description). The initial values for the "Cryptographic Information Type" sub- registry are: Value Description Reference ----- ------------------ ----------------- CERT DER-encoded X.509 Certificate RFC 5280 CRL DER-encoded X.509 RFC 5280 Certificate Revocation List OCSP DER-encoded OCSPResponse RFC 2560 SCVP DER-encoded SCVP response RFC 5055 (CVResponse) [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. [RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007. [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007. [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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [XMLC14N] Boyer, J., "Canonical XML", W3C Recommendation, March 2001. [XMLDSig] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Roessler, T., "XML-Signature Syntax and Processing", XMLDSig, W3C Recommendation, July 2006. [XMLName] Layman, A., Hollander, D., Tobin, R., and T. Bray, "Namespaces in XML 1.0 (Second Edition)", W3C Recommendation, August 2006. [XMLSchema] Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004.
[ANSI.X9-95.2005] American National Standard for Financial Services, "Trusted Timestamp Management and Security", ANSI X9.95, June 2005. [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. [ISO-18014-1.2002] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1: Framework", ISO ISO-18014-1, February 2002. [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-3.2004] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3: Mechanisms producing linked tokens", ISO ISO-18014-3, February 2004. [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. [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. [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. [RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term Archive Service Requirements", RFC 4810, March 2007. [RFC5126] Pinkas, D., Pope, N., and J. Ross, "CMS Advanced Electronic Signatures (CAdES)", RFC 5126, March 2008.
[TS-ENTRUST] The Slovenian Time Stamping Authority, Entrust XML Schema for Time-Stamp, http://www.si-tsa.gov.si/ dokumenti/timestamp-protocol-20020207.xsd. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [XAdES] Cruellas, J. C., Karlinger, G., Pinkas, D., Ross, J., "XML Advanced Electronic Signatures", XAdES, W3C Note, February 2003. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)", RFC 5698, November 2009.
Section 5 for more details) 3. Get a canonicalization method C and a digest method H from the <DigestMethod> element of the current chain. 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: a. If this ATS is the first in the Archive Time-Stamp Chain: 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. 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. b. If this ATS is not the first in the ATSC: i. Calculate the digest value with H of the previous <TimeSatmp> element and add this digest value to the list L. 5. Verify the ATS's Time-Stamped value as follows. Get the first sequence of the hash tree for this ATS. a. If this ATS has no hash tree elements then: 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.
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. 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. 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). 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). 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. 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.