Long-term Archive And Notary A. Jerman Blazic Services (LTANS) SETCCE Internet Draft S. Saljic Intended status: Standards Track SETCCE Expires: August 26, 2007 T. Gondrom Open Text Corporation February 26, 2007 Extensible Markup Language Evidence Record Syntax draft-ietf-ltans-xmlers-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 20, 2007. Copyright Notice Jerman Blazic, et. al. Expires August 25, 2007 [Page 1] Internet-Draft XMLERS February 2007 Copyright (C) The IETF Trust (2007). Abstract In many scenarios, users must be able to demonstrate the (time) existence, integrity and validity of data including signed data for long or undetermined period of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence of data. ERS-XML incorporates alternative syntax and processing rules to ASN.1 ERS syntax by using XML language. Conventions used in this document 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]. Jerman Blazic, et. al. Expires August 25, 2007 [Page 2] Internet-Draft XMLERS February 2007 Table of Contents 1. Introduction...................................................4 1.1. Motivation................................................4 1.2. General Overview and Requirements.........................4 1.3. Terminology...............................................5 2. Evidence Record................................................7 2.1. Evidence Record Structure.................................8 2.2. Archive Time-Stamp Structure.............................10 2.2.1. Time-Stamp Token....................................11 2.2.2. Hash Tree...........................................12 2.2.3. Hash Tree...........................................14 3. Generation of an Evidence Record..............................14 3.1. Initial Archive Time-Stamp...............................15 3.2. Renewal Process..........................................16 4. Merkle Hash-Tree..............................................18 4.1. Generation of a Merkle Hash-Tree for a Group of Archive Objects.......................................................18 4.2. Generation of the Reduced Hash Tree for an Archive Object21 4.3. Calculation of the root hash value from a reduced hash tree22 5. Verification of an Evidence Record............................22 6. XSD Schema for the Evidence Record............................24 7. Security Considerations.......................................26 8. IANA Considerations...........................................27 9. Conclusions...................................................27 10. Acknowledgments..............................................27 APPENDIX A: First Appendix.......................................28 A.1. XSD Schema for ERS.......................................28 11. References...................................................29 11.1. Normative References....................................29 11.2. Informative References..................................30 Author's Addresses...............................................30 Intellectual Property Statement..................................31 Disclaimer of Validity...........................................32 Jerman Blazic, et. al. Expires August 25, 2007 [Page 3] Internet-Draft XMLERS February 2007 1. Introduction Comment [AJB]: This document is initial draft. The purpose of the document is to define XML Schema for Evidence Record Syntax. The following text needs rework. 1.1. Motivation TBA 1.2. General Overview and Requirements ERSXML draft (draft-ietf-ltans-ers-xml) specifies XML syntax and processing rules for creating evidence for long-term non-repudiation of existence of data in a unit called "Evidence Record". This document refers to ERS specification as defined in draft-ietf-ltans- ers-11. An Evidence Record may be generated and maintained for a single data object or a group of data objects that form an archive object. 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 relation than "a data object is a part of particular archived object" are out of the scope of this draft. Evidence for an archive object is created by acquiring a timestamp from a trustworthy authority for a specific value that is unambiguously related to all data objects within an archive object. Besides a time-stamp other artifacts MUST be preserved as well: data necessary to verify relation of the time-stamped value with a specific data object, which is packed into a structure called "hash- tree"; and long term proofs for the formal verification of the time- stamp. Jerman Blazic, et. al. Expires August 25, 2007 [Page 4] Internet-Draft XMLERS February 2007 The Evidence Record syntax enables processing of several archive objects within a single processing pass and by acquiring only one timestamp to protect all archive objects. Due to the fact that digest algorithms or cryptographic methods used may become weak or that certificates used within timestamp (and signed data) may be revoked or expired, the collected evidence data must be monitored and renewed before such event occurs. Procedures for generation of such evidence are already specified within the ERS draft (draft-ietf-ltans-ers), but they depend on defined ASN.1 data structures. For a purpose of renewal of the evidence, digest values of ASN.1 formatted data must be calculated and used in further processing. Besides replacing an ASN.1 scheme with an XML scheme, this document modifies underlying procedures to use XML data structure. 1.3. Terminology Archived data object: Data unit that is archived and has to be preserved for a long time by the Long-term Archive Service. Archived data object group: A multitude of data objects, which for some reason belong together. E.g. a document file and a signature file could be an archived data object group, which represent signed data. Archive Timestamp: Is a timestamp and lists of hash values, which allows verifying the existence of several data objects at a certain time. Archive Timestamp Chain: Part of a Archive Timestamp Sequence, it is a time-ordered sequence of Archive Timestamps, where each Archive Timestamp preserves non-repudiation of the previous Archive Timestamp, even after the previous Archive Timestamp becomes invalid. Overall non-repudiation is maintained until the new Jerman Blazic, et. al. Expires August 25, 2007 [Page 5] Internet-Draft XMLERS February 2007 Archive Timestamp itself becomes invalid. The process of generating such an Archive Timestamp Chain is called Timestamp Renewal. Archive Timestamp Sequence: Part of the Evidence Record, it is a sequence of Archive Timestamp Chains, where each Archive Timestamp Chain preserves non-repudiation of the previous Archive Timestamp Chains, even after the hash algorithm used within the previous Archive Timestamps hash-tree became weak. Non-repudiation is preserved until the last Archive Timestamp of the last chain becomes invalid. The process of generating such an Archive Timestamp Sequence is called Hash-Tree Renewal. Complementary Data: Data or part of data related to the validation process of signed data, e.g. digital certificates, digital certificate chains, certificate revocation list, etc. Digest Method: Processing rules for one way transformation of data or pieces of data into short value of fixed length. The result of processing is a hash value or data fingerprint. Evidence: Information that may be used to resolve a dispute about various aspects of authenticity, validity and existence of archived data objects. Evidence record: Collection of evidence compiled for one or more given archived data objects over time. An evidence record includes all Archive Timestamps (within structures of Archive Timestamp Chains and Archive Timestamp Sequences) and additional verification data, like certificates, revocation information, trust anchors, policy details, role information, etc. Long-term Archive Service (LTA): A service responsible for generation, collection and maintenance (renewal) of evidence data. A LTA service may also preserve data for long periods of time, i.e. storage of archived data objects and evidence, etc. Jerman Blazic, et. al. Expires August 25, 2007 [Page 6] Internet-Draft XMLERS February 2007 Reduced hash-tree: The process of reducing a Merkle hash-tree [MER1980] to a list of lists of hash values. This is the basis of storing the evidence for a single data object. Timestamp: A cryptographically secure confirmation generated by a Time Stamping Authority (TSA) [RFC3161] specifies a structure for timestamps and a protocol for communicating with a Timestamp Authority (TSA). 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]. Transforms: Processing rules for transforming an input XML document into an output XML document. The result of XML transformation may be an XML document or a byte stream. An Archive Timestamp relates to a data object, if the hash value of this data object is part of the first hash value list of the Archive Timestamp. An Archive Timestamp relates to a data object group, if it relates to every data object of the group and no other data objects. An Archive Timestamp Chain relates to a data object / data object group, if its first Archive Timestamp relates to this data object/data object group. An Archive Timestamp Sequence relates to a data object / data object group, if its first Archive Timestamp Chain relates to this data object/data object group. 2. Evidence Record An Evidence Record is a unit of data, which is to be used to prove the existence of an archived object (a single data object or a group of data objects) at a certain time. It is possible to store Evidence Record separately from the archived object or to integrate it into the data itself. Evidence Record syntax enables processing of several archive objects (group processing) with a single process and by acquiring only one timestamp to protect many archive objects, without a need to access Jerman Blazic, et. al. Expires August 25, 2007 [Page 7] Internet-Draft XMLERS February 2007 any other archive object or their evidence records while demonstrating the validity for a particular archive object from the group. The Evidence Record contains one or several archive time-stamps (ATS). An ATS contains a time-stamp token and possibly useful data for validation. The basic idea is to time-stamp a specific value, constructed from significant values, which are unambiguously related to protected data objects. Initially, an archive time-stamp is acquired and later, before it expires or becomes invalid, a new archive time-stamp is generated, which prolongs the validity of archived object (of its data objects together with all previously generated archive time-stamps). This process must continue during the desired archiving period. For additional reference see draft-ietf-ltans-ers-11 (current XML ERS syntax does not include information to support encrypted content to be handled). 2.1. Evidence Record Structure In XML syntax an Evidence Record is represented by the element, which has the following structure (where "+" denotes one or more occurrences; "*" denotes zero or more occurrences): OPTIONAL ()* Jerman Blazic, et. al. Expires August 25, 2007 [Page 8] Internet-Draft XMLERS February 2007 ()* OPTIONAL ()* )* ) + The XML tags have the following meanings: tag indicates the syntax version, for compatibility with future revisions of this specification and to distinguish it from earlier non-conformant or proprietary versions of the XML ERS. Current version of the XML ERS syntax is 00. tag identifies the hash algorithms used to hash the data object over the archival period. tag holds a value or a structure of a reduced hash tree(s) described in section 2.2.2. tag holds a time stamp token provided by the Time- Stamping Authority. tag allows the storage of data useful in the process of time stamp or data signature validation. This could include possible Trust Anchors, certificates, revocation information or the current definition of the suitability of cryptographic algorithms, past and present. These items may be added based on the policy used. Comment [AJB]: The naming could be replaced with as used in draft-ietf-ltans-ers-11. Jerman Blazic, et. al. Expires August 25, 2007 [Page 9] Internet-Draft XMLERS February 2007 The sequence of archive time-stamps is ordered and the order must be indicated in "Order" attribute of the element. The first element (initial time-stamp) is generated at the beginning of the archival period and the value of the "Order" is 1. The next archive time-stamp prolongs initial time-stamp and its "Order" attribute value is increased by one, etc. The archive time- stamp with largest "Order" attribute value is the last and must be valid at the present time. 2.2. Archive Time-Stamp Structure The process of construction of an ATS must unambiguously bind data objects and time-stamped value and thus prove that data objects existed and were identical, at the time of the time-stamp, to the currently present objects (at the time of verification). Therefore an ATS is a collection of the time-stamp token, an identifier of used digest algorithm, an optional structure (a hash tree) for digest values of objects that were protected with that time-stamp token and optional structures (complementary data) to store additional data needed for formal verification of the time- stamp token, such as certificate chain or certificate revocation list. For the initial ATS the value to be time-stamped must be unambiguously related to the archive object (to all of its data objects). When at the renewal time the same digest algorithm is used as the last time, it is enough that time-stamped value is related only to the digest value of the last ATS. When we use a different digest algorithm, the time-stamped value must be unambiguously related to the archive object and all previous ATSs (those digest values must be calculated with this new digest algorithm). Jerman Blazic, et. al. Expires August 25, 2007 [Page 10] Internet-Draft XMLERS February 2007 Before performing digest value calculation for a specific object, the proper octet-string must be extracted from its (abstract) XML data presentation. The elements indicate the transforms (e.g. canonicalization algorithms) that must be applied to the node value of element before being digested. Such digest values are needed in process of renewal, where digest values of previous archive time-stamps are required. The resource for a specific object is a node value of its element. This includes the entire text between the start and end tags of the element, including all descendant markup and character data. Such node value may be a base64 encoded string representing any binary content or it may be any markup data (XML). When the node value of the element represents a binary content, the node value must be base64 decoded into octet-string. When the node value represents markup data, it must be canonicalized and encoded into UTF-8 octet-string. is a required element that identifies the digest algorithm to be used within an ATS for creating significant values of data objects, time-stamped value and values within time-stamp token (digest value of the signature element). 2.2.1. Time-Stamp Token Time-Stamp is an attestation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. For example, Jerman Blazic, et. al. Expires August 25, 2007 [Page 11] Internet-Draft XMLERS February 2007 [RFC3161] specifies a structure for signed time-stamp tokens. Following structure example is a digital signature compliant to XMLDsig specification containing time-stamp specific data, such as time-stamped value and time within element of a signature (reference to a Entrust XML Schema for time-stamp). 2.2.2. Hash Tree Hash tree structure is a container for significant values, needed to unambiguously relate time-stamped value to protected data objects, and is represented by the element of the element. For the purpose of creating significant value for the group of data objects the following procedure can be used: sort (binary ascending) digest values of all data objects to be protected with this time- stamp, concatenate them and calculate the final digest value to be time-stamped. The time-stamping service may be, for a large number of archived objects, expensive and time-demanding, so the TAA may profit from Jerman Blazic, et. al. Expires August 25, 2007 [Page 12] Internet-Draft XMLERS February 2007 acquiring one time-stamp for many archived objects, which are not otherwise related to each other. For that purpose a Merkle Hash Tree [MER1980] may be constructed and reduced for each archive object. Note that there are no restrictions to the quantity of hash value lists and of their length. Also note that it is profitable but not required to build hash-trees and reduce them. An Archive Time-Stamp may consist only of one list of hash-values and a time-stamp or in the extreme case, only a time-stamp with no hash value lists. The lists of digest values can be generated by reduction of an ordered Merkle hash-tree [Mer1980]. The leaves of this hash-tree are the digest values of the data objects to be time-stamped. Every inner node of the tree contains one digest value, which is generated by digesting the binary sorted concatenation of the children nodes. The root digest value, which represents unambiguously all data objects, is time-stamped. Comment [AJB]: Is there a need to define the structure of a hash tree in XML format? Comment [AJB]: Graphical interpretation needs to be added as in draft-ietf-ltans-ers-11. A sample of lists of hash values within Content node value: 5XQCAGgwJL2WZ6nv2OSGYlRFpK8= wyFrW58ATzRch7VUPNY2P+75Q/I= woCvx62tw0uc24v51xtNNxld5Kw= 7N2lphOrGx+/PCxtGwzbKIj+InQ= zbCNhmQv+8kRo9W/0YedrpeZ1a8= ThuhSOZhNj42vsIRg38epxj9qVo= FX7AgSsZ0kaW8fHWi4BYDkAkZS0= Jerman Blazic, et. al. Expires August 25, 2007 [Page 13] Internet-Draft XMLERS February 2007 tWl/o/er7kGwIeip4g+xvzShMno= +bY32LFVm/ynJj6TZss5J6BzYwI= Eu05AI8VVqFkddHYyYXMs8cjXcU= This sample represents a reduced hash tree. The first sequence (input list) contains 6 digest values, which indicate 6 fingerprints of data objects to be archived with archive time-stamp element. Sequences that follow input list are used to calculate a final digest value to be (has already been) time-stamped. The reduced tree is result of reducing a Merkle hash-tree as described in chapter 4. The digest value is always represented as encoded base64 character data. 2.2.3. Hash Tree Digital certificates, CRLs or OCSP-Responses needed to verify the time-stamp should be stored in the time-stamp itself. When this is not possible, such data may be stored in element (as a node value of its element). ()* 3. Generation of an Evidence Record The generation of an element can be described as follows: Jerman Blazic, et. al. Expires August 25, 2007 [Page 14] Internet-Draft XMLERS February 2007 1. Select archived data object (a data object or a data object group), which are documents or essential parts of it - depending on application. 2. Create the initial ATS. 3. Refresh the ArchiveTimeStamp when necessary, by TimeStamp Renewal or Hash-TreeRenewal. In the case that only essential parts of documents or objects shall be protected the application not defined in this draft must take care of the right extraction of binary data to be covered for generation of evidence record. For example: an application may provide also evidence such as certificates, revocation lists etc., needed to verify and validate signed data objects. This evidence may be added to the archived group of data object and will be protected within initial time-stamp. 3.1. Initial Archive Time-Stamp Initial Archive Time-Stamp relates to a data object or a data object group that represent an archive data object. The generation of the initial Archive Time-Stamp element can be described as follows: 1. Select a valid digest algorithm H (a strong one-way hash function, for which it is computationally infeasible to find any message that corresponds to a given digest or any two messages that correspond to the same digest). It is recommended to use the same digest algorithm to create the time-stamped value and the time- stamp. Jerman Blazic, et. al. Expires August 25, 2007 [Page 15] Internet-Draft XMLERS February 2007 2. Create an input list of digest values calculated with H (one digest value for each separate data object). This list must be part of the first sequence in the hash tree. Hash tree may be omitted in the initial archive time-stamp, when a single data object is being archived and then the time-stamped value must match the digest value of that single data object. 3. Sort binary ascending the input list and calculate digest value to be time-stamped. 4. Acquire time-stamp for that value. If the time-stamp is valid, the initial archive time-stamp may be generated. 3.2. Renewal Process Before the cryptographic algorithm used within the last Archive Time- Stamp becomes weak or the time-stamp certificates are invalidated, the last Archive Time-Stamp must be renewed by generating a new Archive Time-Stamp. If the digest algorithm to be used (H) is the same as one used in the last Archive Time-Stamp (H'), the digest value of that Archive Time- Stamp is calculated and a new Archive Time-Stamp must time-stamp that specific value. If the new digest algorithm is different than one used in the last Archive Time-Stamp (H <> H'), then a new Archive Time-Stamp must time-stamp a specific value digested with new digest algorithm from: o digest values for archive object calculated with the new digest algorithm and o digest values of all previous Archive Time-Stamps, all calculated with the new digest algorithm. Jerman Blazic, et. al. Expires August 25, 2007 [Page 16] Internet-Draft XMLERS February 2007 The first list of the hash-tree for the new Archive Time-Stamp must contain digest values of: o the archived object and o all previous Archive Time-Stamps, all digested with the new digest algorithm. A digest value for an Archive Time-Stamp is digested from binary ascending sorted and concatenated digest values of: o the hash tree, o timestamp and o objects within . A digest value of an Archive Time-Stamp (ATS) is calculated as follows: 5. If the current ATS does not contain needed proof for long-term formal validation of its time-stamp token within the time-stamp token, collect needed data such as root certificates, certificate revocation lists and include them as node values of elements in element (each data object into separate ). 6. Make a list of digest values of all ATS's sub-elements, which are: the hash tree, the time-stamp token and complementary data. Digest value of the ATS's sub-elements are calculated from binary presentation of the node value of its element. The binary presentation of this node value is determined by UTF-8 encoding and if the elements are stated, identified transforms must be previously subsequently applied. Expected transforms are canonicalization in case of XML data structure or base64 decoding for binary data. Jerman Blazic, et. al. Expires August 25, 2007 [Page 17] Internet-Draft XMLERS February 2007 7. Sort binary ascending all acquired digest values, concatenate them and digest with the chosen digest algorithm. 4. Merkle Hash-Tree A hash tree is a tree of digest values in which the leaves are hashes of data blocks in, for instance, a file or set of files. Nodes further up in the tree are the hashes of their respective children. In the top of a hash tree there is a root hash value or master hash. From Merkle Hash-Tree for each leaf a very small sub tree may be extracted (a reduced tree), that holds enough information to unambiguously bind the leaf value with the root hash. After the group processing of several archive objects (the root hash, that unambiguously bound together all archive objects, was time-stamped), for each archive object reduced tree is saved within its evidence record (a hash tree within the last ATS). 4.1. Generation of a Merkle Hash-Tree for a Group of Archive Objects The Merkle Hash-Tree for a group of archive objects is built from bottom to the root. First are collected leaves of the tree. The leaves are digest values of archive objects: 8. Collect archive objects and for each archive object corresponding data objects. 9. Calculate hash values of the archive objects and put them into input list as follows: a digest value of an archive objects is a digest value of its data object, if there is only one data object; for more than one data objects a digest value is a digest value of binary sorted, concatenated digest values of all containing data objects. Note that for some hash values on the input list also lists of their sub-hash values are stored (for archive objects having more than one data object) Jerman Blazic, et. al. Expires August 25, 2007 [Page 18] Internet-Draft XMLERS February 2007 10.Group items in the input list by N (to make binary tree in pairs) and for each group: binary ascending sort, concatenate and calculate hash values with algorithm H. The result is a new input list. 11.Repeat step 3, until only one hash is left; this is the master hash to be time-stamped. Example: The input list with 18 hashes, where the h47 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...). It is also possible to extend the tree with "dummy" values; to make every node having the same number of children. Jerman Blazic, et. al. Expires August 25, 2007 [Page 19] Internet-Draft XMLERS February 2007 d1 -> h1 \ \ d2 -> h2 |-> h'1 G1 / \ +--------+ d3 -> h3 / \ |D4 -> h4|\ \ | | \ -------- | |d5 -> h5| \ | | | | -> h47 \ | |d6 -> h6| / \ | | | / d8 -> h8 -> h'2 |--|-> h''1 |d7 -> h7|/ / | \ +--------+ d9 -> h9 / | \ | | -------- | | / | d10 -> h10\ / | \ / | d11 -> h11 |-> h'3 | / | d12 -> h12/ | |-> master hash -------- | | d13 -> h13\ | \ | d14 -> h14 |-> h'4 | / \ | d15 -> h15/ \ / \ / --------- |-> h'2 / d16 -> h16\ / \ / d17 -> h17 |-> h'5 / Jerman Blazic, et. al. Expires August 25, 2007 [Page 20] Internet-Draft XMLERS February 2007 d18 -> h18/ Figure 1 Generation of the Reduced Hash Tree. 4.2. Generation of the Reduced Hash Tree for an Archive Object The following procedure describes generation of the reduced hash tree for an archive object: 12.For selected archive object generate the first sequence of the reduced tree, which contains the list of hash values of the data objects contained in the archive object (one or more). Select node with a hash value of the archive object. 13.Select all neighboring nodes, which have the same parent as currently selected node and add their hash values as a new sequence to the reduced tree. Select parent node. 14.Repeat step 2 until the root is reached. Note that parent nodes are not saved in the list, they are computable. Reduced Hash tree for data group (from the previous example): h4 h5 h6 h7 h8 h9 h'1 h'3 Jerman Blazic, et. al. Expires August 25, 2007 [Page 21] Internet-Draft XMLERS February 2007 h''2 4.3. Calculation of the root hash value from a reduced hash tree The following procedure describes generation of the root hash value from a reduced hash tree: 15.Take the first sequence from a reduced hash tree, sort hash items, concatenate them and calculate a hash value with algorithm H (the one used for creation of the hash tree). 16.Remove this sequence from the reduced hash tree. 17.If a reduced hash tree is not empty, add previously calculated hash value to the first sequence and go to step 1. If a reduced hash tree is empty, than the last calculated hash value is the master hash. 5. Verification of an Evidence Record An Evidence Record shall prove that an archive object existed and has not been changed from the time of a time-stamp token within the first ATS. Every ATS, but the last, must be valid at the time of the next ATS. In order to complete the non-repudiation proof for the data objects, the last ATS has to be valid at the time the verification is performed. This can be verified as follows: 1. Start with the first ATS till the last ATS (ordered by attribute "Order") and perform ATS verification, as follows: Jerman Blazic, et. al. Expires August 25, 2007 [Page 22] Internet-Draft XMLERS February 2007 2. Get a digest method identifier H from the element of current ATS. 3. Get all objects that have to be protected with this ATS and calculate their digest values with H (list of digest values of protected objects). Objects, which have to be protected with an ATS are: the archive object and all previous ATSs. When H is the same as a digest algorithm of the previous ATS, only the preceding ATS must be protected. For the archive object collect digest values for all of its data objects; generally that could be: documents or parts of documents, metadata, complementary data for signed documents (certificates, CRLs...), etc. For ATS collect digest values of: the timestamp, the hash tree and complementary data. If there is only one data object in the archive object, the hash tree may be omitted for the first ATS and digest value of that data object must be the same as a time-stamped value. Note that this also implies individual processing. If there is a digest value on a list of digest values of protected objects, which can not be found on a first sequence of the hash tree, exit with a negative result. 4. Get the hash tree for the current ATS and use H to calculate the master hash. (Reference to the chapter 4.3) 5. Get time stamped value from the time stamp token. If calculated master hash from the hash tree does not match time stamped value, exit with a negative result. Jerman Blazic, et. al. Expires August 25, 2007 [Page 23] Internet-Draft XMLERS February 2007 6. Verify timestamp cryptographically and formally (validate used certificate and its chain). 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. If the needed information to verify formal validity is not found within the timestamp or within its complementary data section of ATS, exit with a negative result. 6. XSD Schema for the Evidence Record Jerman Blazic, et. al. Expires August 25, 2007 [Page 24] Internet-Draft XMLERS February 2007 Jerman Blazic, et. al. Expires August 25, 2007 [Page 25] Internet-Draft XMLERS February 2007 7. Security Considerations TBA Jerman Blazic, et. al. Expires August 25, 2007 [Page 26] Internet-Draft XMLERS February 2007 8. IANA Considerations TBA 9. Conclusions TBA 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Jerman Blazic, et. al. Expires August 25, 2007 [Page 27] Internet-Draft XMLERS February 2007 APPENDIX A: First Appendix TBA A.1. XSD Schema for ERS XML ERS Schema to be added. Jerman Blazic, et. al. Expires August 25, 2007 [Page 28] Internet-Draft XMLERS February 2007 11. References [I-D.ietf-ltans-ers] Brandner, R., "Evidence Record Syntax (ERS)", draft-ietf-ltans-ers-11 (work in progress), February 2007 [I-D.ietf-ltans-ltap] Jerman-Blazic, A., "Long-term Archive Protocol (LTAP)", draft-ietf-ltans-ltap-03 (work in progress), October 2006. [I-D.ietf-ltans-reqs] Wallace, C., "Long-Term Archive Service Requirements", draft-ietf-ltans-reqs-10 (work in progress), December 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BPC 14, RFC 2119, March 1997. [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [XMLDsig] Eastlake, D. "XML-Signature Syntax and Processing", XMLDsig, July 2006. 11.1. Normative References TBA Jerman Blazic, et. al. Expires August 25, 2007 [Page 29] Internet-Draft XMLERS February 2007 11.2. Informative References [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. [MIME] Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Author's Addresses Aleksej Jerman Blazic SETCCE Jamova 39 1000 Ljubljana Slovenia Phone: +386 (0) 1 477 3505 Fax: +386 (0) 1 477 3911 Email: aljosa@setcce.si Svetlana Saljic SETCCE Jamova 39 1000 Ljubljana Slovenia Phone: +386 (0) 1 477 3505 Fax: +386 (0) 1 477 3911 Email: svetlana.saljic@setcce.si Jerman Blazic, et. al. Expires August 25, 2007 [Page 30] Internet-Draft XMLERS February 2007 Tobias Gondrom Open Text Corporation Werner-von-Siemens-Ring 20 Grasbrunn, Munich D-85630 Germany Phone: +49 (0) 89 4629-1816 Fax: +49 (0) 89 4629-33-1816 Email: tobias.gondrom@opentext.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Jerman Blazic, et. al. Expires August 25, 2007 [Page 31] Internet-Draft XMLERS February 2007 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jerman Blazic, et. al. Expires August 25, 2007 [Page 32]