[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6283

Long-term Archive And Notary                           A. Jerman Blazic
Services (LTANS)                                                 SETCCE
Internet Draft                                                S. Saljic
Intended status: Standards Track                                 SETCCE
Expires: February 20, 2011                                   T. Gondrom
                                                        August 20, 2010

             Extensible Markup Language Evidence Record Syntax
                      draft-ietf-ltans-xmlers-07.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79. This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008. The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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.



Jerman Blazic, et. al. Expires February 20, 2011                [Page 1]


Internet-Draft                  XMLERS                      August 2010




   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 20, 2011.

Copyright Notice

   Copyright (c) 2010 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.

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.





Jerman Blazic, et. al. Expires January 26 2011                 [Page 2]


Internet-Draft                  XMLERS                      August 2010


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 January 26 2011                 [Page 3]


Internet-Draft                  XMLERS                      August 2010


Table of Contents


   1. Introduction...................................................6
      1.1. Motivation................................................6
      1.2. General Overview and Requirements.........................8
      1.3. Terminology...............................................9
      1.4. Conventions Used in This Document........................11
   2. Evidence Record...............................................11
      2.1. Structure................................................12
      2.2. Generation...............................................16
      2.3. Verification.............................................17
   3. Archive Time-Stamp............................................17
      3.1. Structure................................................18
         3.1.1. Hash Tree...........................................18
         3.1.2. Time-Stamp..........................................19
         3.1.3. Cryptographic Information List......................21
      3.2. Generation...............................................21
         3.2.1. Generation of Hash-Tree.............................22
         3.2.2. Reduction of Merkle Hash-Tree.......................26
      3.3. Verification.............................................28
   4. Archive Time-Stamp Sequence and Archive Time-Stamp Chain......29
      4.1. Structure................................................30
         4.1.1. Digest Method.......................................30
         4.1.2. Canonicalization Method.............................31
      4.2. Generation...............................................32
         4.2.1. Time-Stamp Renewal..................................32
         4.2.2. Hash Tree Renewal...................................33
      4.3. Verification.............................................36
   5. Encryption....................................................37
   6. XSD Schema for the Evidence Record............................38
   7. Security Considerations.......................................43
   8. IANA Considerations...........................................44
   9. References....................................................47
      9.1. Normative References.....................................47
      9.2. Informative References...................................48


Jerman Blazic, et. al. Expires January 26 2011                 [Page 4]


Internet-Draft                  XMLERS                      August 2010


   APPENDIX A: Detailed verification process of an Evidence Record..50
   Author's Addresses...............................................52




































Jerman Blazic, et. al. Expires January 26 2011                 [Page 5]


Internet-Draft                  XMLERS                      August 2010




1. Introduction

   The purpose of the document is to define XML Schema and processing
   rules for Evidence Record Syntax in XML format. Document is related
   to initial ASN.1 syntax for Evidence Record Syntax as defined in
   [RFC4998].

1.1. Motivation

   The evolution of electronic commerce and electronic data exchange in
   general requires introduction of non-repudiable proof of data
   existence as well as data integrity and authenticity. Such data and
   non-repudiable proof of existence must endure for long periods of
   time, even when information to prove data existence and integrity
   weakens or ceases to exist. Mechanisms such as digital signatures
   defined in [RFC5652] for example do not provide absolute reliability
   on a long term basis. Algorithms and cryptographic material used to
   create a signature can become weak in course of time and information
   needed to validate digital signatures may became compromised or
   simply cease to exist due to for example decomposing 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 related techniques used today suffer
   from the same problem of time related reliability degradation
   including techniques for Time-Stamping, which are generally
   recognized as data existence and integrity proofs mechanisms. Over
   long periods of time cryptographic algorithms used may become weak or
   encryption keys compromised. Some of the problems might not even be
   technically related like decomposing Time-Stamping authority. To
   create a stable environment where proof of existence and integrity



Jerman Blazic, et. al. Expires January 26 2011                 [Page 6]


Internet-Draft                  XMLERS                      August 2010


   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 [RFC5126]. Long term signature syntaxes
   and processing rules address mostly the long term endurance of
   digital signatures, while Evidence Record Syntax broadens this
   approach for data of any type or format including digital signatures.

   The XMLERS 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 language, XMLERS does not present a direct
   transformation of ERS in ASN.1 syntax. The XMLERS syntax is based on
   different processing rules as defined in [RFC4998] and it does not
   support for example import of ASN.1 values in XML tags. Creating
   Evidence Records in XML syntax must follow the steps as defined in
   this draft. XMLERS is a standalone draft and is based on [RFC4998]
   conceptually only.




Jerman Blazic, et. al. Expires January 26 2011                 [Page 7]


Internet-Draft                  XMLERS                      August 2010


   Evidence Record Syntax in XML format is based on long term archive
   service requirements as defined in [RFC4810]. XMLERS syntax delivers
   the same (level of) non-repudiable proof of data existence as ASN.1
   ERS. The XML syntax supports archive data grouping (and de-grouping)
   together with simple or complex Time-Stamp renewal process. Evidence
   Records can be embedded in the data itself or stored separately as a
   standalone XML file.

1.2. General Overview and Requirements

   XMLERS draft specifies XML syntax and processing rules for creating
   evidence for long-term non-repudiation of existence of data in a unit
   called "Evidence Record". The XMLERS syntax is defined to meet the
   requirements for data structures as set out in [RFC4810]. This
   document also refers to 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. 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 out of the scope of this draft.

   Evidence Record maintains a close relationship 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 hash-treeing, a technique first described by Merkle
   [MER1980], 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-treeing


Jerman Blazic, et. al. Expires January 26 2011                 [Page 8]


Internet-Draft                  XMLERS                      August 2010


   technique and acquiring only one Time-Stamp to protect all archive
   objects.

   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 included Time-Stamp(s).

   Due to the fact that digest algorithms or cryptographic methods used
   may become weak or that certificates used within a Time-Stamp (and
   signed data) may be revoked or expired, 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.

1.3. Terminology

   Archive data object: Data unit that is archived and has to be
   preserved for a long time by the Long-term Archive Service.

   Archive data object group: A multitude of (archive) data objects,
   which for some reason (logically) belong together, e.g. a group of
   document files or a document file and a signature file could
   represent an archive data object group.

   Archive object: an archive data object or an archive data object
   group.

   Archive Time-Stamp (ATS): An Archive Time-Stamp contains a Time-Stamp
   Token, useful data for validation and optionally a set of ordered
   lists of hash values (a hash tree). An Archive Time-Stamp relates to
   a data object, if the hash value of this data object is part of the
   first hash value list of the Archive Time-Stamp or its hash value
   matches the Time-Stamped value. An Archive Time-Stamp relates to a



Jerman Blazic, et. al. Expires January 26 2011                 [Page 9]


Internet-Draft                  XMLERS                      August 2010


   data object group, if it relates to every data object of the group
   and no other data object.

   Archive Time-Stamp Chain (ATSC): holds a sequence of Archive Time-
   Stamps generated during the preservation period.

   Archive Time-Stamp Sequence (ATSSeq): is a sequence of Archive Time-
   Stamp Chains.

   Canonicalization: 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: Data or part of data related to the
   validation process of signed data, e.g. digital certificates, digital
   certificate chains, certificate revocation lists, etc.

   Digest Method: Digest method is an identifier for 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.
   Digest algorithm transforms input data into a short value of fixed
   length. The output is called digest value, 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 a given archive
   object over time. An Evidence Record includes ordered collection of
   ATSs, which are grouped into ATSCs and ATSSeqs.




Jerman Blazic, et. al. Expires January 26 2011                [Page 10]


Internet-Draft                  XMLERS                      August 2010


   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, e.g.
   storage of archive data and associated evidences.

   Hash Tree: Collection of significant 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 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].

1.4. 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].

2. Evidence Record

   An Evidence Record is a unit of data, which is to be used to prove
   the existence of an archive object (a single archive data object or a
   archive data object group) at a certain time. Through the lifetime of
   an archive object, an Evidence Record also demonstrates data objects
   integrity and non-repudiability. To achieve this, cryptographic means
   are used, i.e. Time-Stamp Tokens obtained from the Time-Stamping
   Authority (TSA). It is possible to store Evidence Record separately
   from the archive object or to integrate it into the data itself.




Jerman Blazic, et. al. Expires January 26 2011                [Page 11]


Internet-Draft                  XMLERS                      August 2010


   As cryptographic means are used to support Evidence Records, such
   records may lose their value through time. Time-Stamps obtained from
   Time-Stamping Authorities may become invalid for a number of reasons,
   usually due to time constrains of Time-Stamp validity. Before Time-
   Stamp Tokens used become unstable, 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 Record 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).

2.1. Structure

   The Evidence Record contains one or several Archive Time-Stamps
   (ATS). An ATS contains a Time-Stamp Token and optionally other useful
   data for Time-Stamp validation, e.g. certificates, CRLs or OCSP
   responses and also specific attributes such as service policies.
   Initially, an ATS is acquired and later, before it expires or becomes
   invalid a new ATS is acquired, which prolongs the validity of the
   archived object (its data objects together with all previously
   generated Archive Time-Stamps). This process must continue during the
   desired archiving period of archive data object. A series of
   successive Archive Time-Stamps is collected in Archive Time-Stamp
   Chains and a series of chains in Archive Time-Stamp Sequence.

   In XML syntax the Evidence Record is represented by the
   <EvidenceRecord> root element, which has the following structure
   (where "?" denotes zero or one occurrences, "+" denotes one or more
   occurrences and "*" denotes zero or more occurrences):

   <EvidenceRecord Version>


Jerman Blazic, et. al. Expires January 26 2011                [Page 12]


Internet-Draft                  XMLERS                      August 2010



      <EncryptionInformation>
         <EncryptionInformationType>
         <EncryptionInformationValue>
      </EncryptionInformation> ?
      <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 6. The schema uses the following XML
   namespace [XMLName] urn:ietf:params:xml:ns:ers as default namespace
   and starts with following definition:

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema  xmlns:xs="http://www.w3.org/2001/XMLSchema"
               xmlns ="urn:ietf:params:xml:ns:ers"
               targetNamespace="urn:ietf:params:xml:ns:ers"
               elementFormDefault="qualified"
               attributeFormDefault="unqualified">


Jerman Blazic, et. al. Expires January 26 2011                [Page 13]


Internet-Draft                  XMLERS                      August 2010


  The XML tags have the following meanings:

     Version attribute 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 XMLERS.
     Current version of the XMLERS syntax is 1.0.

     <EncryptionInformation> tag 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.

     <ArchiveTimeStampSequence> is a sequence of
     <ArchiveTimeStampChain>.

     <ArchiveTimeStampChain> 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 are ordered and the order must be indicated with
     "Order" attribute of the <ArchiveTimeStampChain> and
     <ArchiveTimeStamp> element.

     <DigestMethod> is a required element and identifies the digest
     algorithm used within one Archive Time-Stamp chain to calculate
     digest values from: archive data object(s), previous Archive Time-
     Stamp sequence, Time-Stamps and within a Time-Stamp Token.

     <CanonicalizationMethod> is a required element that specifies the
     canonicalization algorithm applied over the archive data in case of



Jerman Blazic, et. al. Expires January 26 2011                [Page 14]


Internet-Draft                  XMLERS                      August 2010


     XML data objects, <ArchiveTimeStampSequence> or <TimeStamp> element
     prior to performing digest value calculations.

     <HashTree> tag holds a structure as described in section 3.1.1.

     <TimeStamp> tag holds a <TimeStampToken> element with a Time-Stamp
     Token provided by the Time-Stamping Authority and optional element
     <CryptographicInformationList>.

     <CryptographicInformationList> tag 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 separate child element <CryptographicInformation>, having
     mandatory Order attribute to indicate the order within 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
     Time-Stamps.

     <Attributes> tag contains additional information that may be
     provided by an LTA used for the renewal process. An example of
     additional information may be processing (renewal) policies, which
     are relevant for data object(s) preservation and evidence
     validation at a later stage. Each data object is put into separate
     child element <Attribute>, having mandatory Order attribute to
     indicate the order within parent element and optional Type
     attribute to indicate processing directions.

     Order attribute is mandatory in all cases when one or more XML
     elements with the same name occur on the same level in the XMLERS
     structure. Although most of the XML parsers will preserve order of
     the sibling elements having the same name, within XML structure
     there is no definition how to unambiguously define such order.



Jerman Blazic, et. al. Expires January 26 2011                [Page 15]


Internet-Draft                  XMLERS                      August 2010


     Preserving correct order in such cases is of significant importance
     for digest value calculations over XML structures.

2.2. Generation

   The generation of an <EvidenceRecord> element can be described as
   follows:

   1. Select an archive object (a data object or a data object group) to
      archive.

   2. Create the initial <ArchiveTimeStamp>. This is the first ATS
      within the initial <ArchiveTimeStampChain> element of the
      <ArchiveTimeStampSequence> element.

   3. Refresh the <ArchiveTimeStamp> when necessary by Time-Stamp
      Renewal or Hash-Tree Renewal (see Section 4.).

   The Time-Stamping service may be, for a large number of archived
   objects, expensive and time-demanding, so the LTA may profit 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 Merkle Hash Tree to generate a single value
   to be Time-Stamped, and respectively reduce that Merkle 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,
   hash-treeing (<HashTree> element) can be omitted. It is also possible
   to convert existing Time-Stamps into ATS for renewal.

   In the case that only essential parts of documents or objects shall
   be protected, the application not defined in this draft must ensure
   that the correct extraction of binary data is made for generation of
   Evidence Record.



Jerman Blazic, et. al. Expires January 26 2011                [Page 16]


Internet-Draft                  XMLERS                      August 2010


   Example: an application may provide also evidence such as
   certificates, revocation lists etc., needed to verify and validate
   signed data objects or data object group. This evidence may be added
   to the archived object data group and will be protected within
   initial (and successive) Time-Stamp(s).

   Note that <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 TS(s).

2.3. Verification

   The overall Verification of an Evidence Record can be described as
   follows:

   1. Select an archive object (a data object or a data object group)

   2. Re-encrypt data object or data object group, if encryption field
      is used (for details, see Section 5.).

   3. Verify Archive Timestamp Sequence (details in Section 3.3. and
      Section 4.3.).

3. Archive Time-Stamp

   An Archive Time-Stamp is a timestamp with additional artifacts that
   allow verification of the existence of several data objects at a
   certain time.

   The process of construction of an ATS must support evidence on a long
   term basis and prove that the archive object existed and was
   identical, at the time of the Time-Stamp, to the currently present
   archive object (at the time of verification). To achieve this, ATS
   must be renewed before it becomes invalid (which may happen for



Jerman Blazic, et. al. Expires January 26 2011                [Page 17]


Internet-Draft                  XMLERS                      August 2010


   several reasons such as invalid digital certificate or decomposing
   TSA).

3.1. Structure

   An Archive Time-Stamp contains a Time-Stamp Token, with useful data
   for its validation (cryptographic information), such as certificate
   chain or certificate revocation list, an optional ordered set of
   ordered lists of hash values (a hash tree) that were protected with
   the Time-Stamp Token and optional information describing renewal
   steps (<Attributes> element).  A hash tree may be used to store data
   needed to bind Time-Stamped value with protected objects by the
   Archive Time-Stamp. If a hash tree is not present, ATS simply refers
   to a single object; either input data object or a previous TS.



3.1.1. Hash Tree

   Hash tree structure is an optional container for significant values,
   needed to unambiguously relate a Time-Stamped value to protected data
   objects, and is represented by the <HashTree> element. The root hash
   value that is generated from the values of the hash tree MUST be the
   same as the Time-Stamped value.

   <HashTree>
      <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: content of each <DigestValue>
   element within the first <Sequence> element is base64 decoded to
   obtain a binary value (hash value). Collected hash values are ordered
   in binary ascending order, concatenated and a new hash value is


Jerman Blazic, et. al. Expires January 26 2011                [Page 18]


Internet-Draft                  XMLERS                      August 2010


   generated from that string (there is exception when the first
   <Sequence> element has one <DigestValue> element, then its binary
   value is added to the next list obtained from the next <Sequence>
   element). Newly generated 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 generated hash value
   is the root hash value. When an archive object is composed of more
   than one data object, the first hash list MUST contain hash values of
   all its data objects. When a single Time-Stamp is obtained for a
   group of archive objects, a Merkle Hash Tree MUST be constructed to
   generate a single hash value to bind all archive objects from that
   group and then a reduced hash tree MUST be extracted from a Merkle
   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. For example, the text value
   of a <DigestValue> element for the message digest A9993E36 4706816A
   BA3E2571 7850C26C 9CD0D89D would be:

   <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>

3.1.2. Time-Stamp

   Time-Stamp Token is an attestation generated by a TSA that a data
   item existed at a certain time. The Time-Stamp Token is a signed data
   object that contains the hash value, the identity of the TSA, and the
   exact time (obtained from trusted time source) of Time-Stamping. This
   proves that the given data existed before the time of Time-Stamping.
   For example, [RFC3161] specifies a structure for signed Time-Stamp
   Tokens in ASN.1 format. Since at the time being there is no standard
   for an XML Time-Stamp, the following structure example is provided
   (referring to the Entrust XML Schema for Time-Stamp
   http://www.entrust.com/schemas/timestamp19protocol-20020207), which
   is a digital signature compliant to [XMLDSig] specification


Jerman Blazic, et. al. Expires January 26 2011                [Page 19]


Internet-Draft                  XMLERS                      August 2010


   containing Time-Stamp specific data, such as Time-Stamped value and
   time within <Object> element of a signature.

   <element name="TimeStampInfo">
      <complexType>
         <sequence>
            <element ref="ts:Policy" />
            <element ref="ts:Digest" />
            <element ref="ts:SerialNumber" minOccurs="0" />
            <element ref="ts:CreationTime" />
            <element ref="ts:Accuracy" minOccurs="0" />
            <element ref="ts:Ordering" minOccurs="0" />
            <element ref="ts:Nonce" minOccurs="0" />
            <element ref="ts: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 come in XML or ASN.1
   format. Attribute Type must be used to indicate format for processing
   purposes, with values XMLENTRUST and RFC3161 respectively For RFC3161
   type of a Time-Stamp Token, <TimeStamp> element must contain base64
   encoding of a DER-encoded ASN1 data. These type values have been
   registered by IANA (see Section 8). It may be necessary to register
   further types not given in this section (in particular, for future
   XML standards).

   For example:

   <TimeStamp Type="RFC3161">MIAGCSqGSIb3DQEH...</TimeStamp>

   or

   <TimeStamp Type="XMLENTRUST"><dsig:Signature>...</dsig:Signature>
   </TimeStamp>.


Jerman Blazic, et. al. Expires January 26 2011                [Page 20]


Internet-Draft                  XMLERS                      August 2010


3.1.3. Cryptographic Information List

   Digital certificates, CRLs, SCVP or OCSP-Responses needed to verify
   the Time-Stamp Token should be stored in the Time-Stamp Token itself.
   When this is not possible, such data may be stored in
   <CryptographicInformationList> element, each data object into a
   separate <CryptographicInformation> element, using a mandatory Order
   attribute.

   The attribute Type is mandatory and is used to store processing
   information about type of stored cryptographic information. Following
   values SHOULD be used as identifiers for the Type attribute: 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];.

   These values have been registered by IANA (see Section 8). It may be
   necessary to register further types not given in this section (in
   particular, for future validation standards).

3.2. Generation

   Initial ATS relates to a data object or a data object group that
   represents an archive object. The generation of the initial ATS



Jerman Blazic, et. al. Expires January 26 2011                [Page 21]


Internet-Draft                  XMLERS                      August 2010


   element can be done in a single process pass for one or for many
   archived objects, described as follows:

   1. Collect one or more archive objects to be Time-Stamped.

   2. Select a canonicalization method C to be used for obtaining binary
      representation of archive data and for Archive Time-Stamp at a
      later stage in renewing process (see section 4). Note that
      selected canonicalization method MUST be used also for archive
      data when data is represented in XML format.

   3. Select a valid digest algorithm H. Selected secure hash algorithm
      MUST be the same as hash algorithm used in the Time-Stamp Token
      and for the hash tree computations.

   4. Generate a hash tree for selected archive object (see 3.2.1).

      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 3.1.1). If the Time-Stamp token is valid, the initial
      Archive Time-Stamp may be generated.

3.2.1. Generation of Hash-Tree

   The <DigestValue> elements within the <Sequence> element MUST be
   ordered in binary ascending order to ensure correct calculation of
   digest values at time of renewal and later for verification purposes.
   Note, that the text value of <DigestValue> element is base64 encoded,
   so it MUST be base64 decoded in order to obtain a binary
   representation of the hash value.

   Hash tree MUST be generated when the Time-Stamped value is not equal
   to the hash value of the input data object. This is the case:


Jerman Blazic, et. al. Expires January 26 2011                [Page 22]


Internet-Draft                  XMLERS                      August 2010


   1. When an archive object is having more than one data object, its
     digest value is the digest value of binary ascending ordered and
     concatenated digest values of all its containing data objects.
     Note that in this case the first list of the hash tree MUST
     contain hash values of all data objects and only those values.

   2. When for more than one archive object a single Time-Stamp Token is
     generated, then the hash-tree is a reduced hash tree extracted
     from Merkle Hash-Tree for that archive object (see Section 3.2.2).

   The Merkle Hash-Tree for a group of archive objects is built from
   bottom to the root. First are collected the leaves of the tree. The
   leaves represent digest values of archive objects:

   1. Collect archive objects and for each archive object its
      corresponding data objects.

   2. Chose a secure hash algorithm H and calculate digest values for
      the data objects and put them into the input list for the Merkle
      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;
      for more than one data object a digest value is the digest value
      of binary sorted, concatenated digest values of all its containing
      data objects.

      Note that for archive objects 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
      became members of the first hash list.

   3. Group together items in the input list by N (e.g. to make binary
      tree group in pairs) and for each group: binary ascending sort,
      concatenate and calculate hash values. The result is a new input
      list.




Jerman Blazic, et. al. Expires January 26 2011                [Page 23]


Internet-Draft                  XMLERS                      August 2010


   4. Repeat step 3, until only one digest value is left; this is the
      root value of the Merkle Hash-Tree, which is Time-Stamped.

   Note that 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...). It is
   also possible to extend the tree with "dummy" values; to make every
   node have the same number of children.



























Jerman Blazic, et. al. Expires January 26 2011                [Page 24]


Internet-Draft                  XMLERS                      August 2010


                    ----------
                    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/
                    ----------

               Figure 1 Generation of the Merkle Hash-Tree.





Jerman Blazic, et. al. Expires January 26 2011                [Page 25]


Internet-Draft                  XMLERS                      August 2010


   Note that there are no restrictions on the quantity of hash value
   lists and of their length. Also note that it is profitable but not
   required to build Merkle Hash-tree and reduce hash-trees. 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.

3.2.2. Reduction of Merkle Hash-Tree

   The generated Merkle Hash-Tree can be reduced to lists of hash
   values, necessary as a proof of existence for a single archive object
   as follows:

   1. For a selected archive object (AO) select its hash value h within
      the leaves of the Merkle Hash-Tree.

   2. Put h as base64 encoded text value of a new <DigestValue> element
      within a first <Sequence> element. If selected AO is having more
      than one data object, the first <Sequence> element MUST be in this
      case formed from the hash values of all AO's data objects, each
      within separate <DigestValue> element.

   3. Select all hash values, which 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).




Jerman Blazic, et. al. Expires January 26 2011                [Page 26]


Internet-Draft                  XMLERS                      August 2010


   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>


Jerman Blazic, et. al. Expires January 26 2011                [Page 27]


Internet-Draft                  XMLERS                      August 2010


         <DigestValue>base64 encoded h''3</DigestValue>
     </Sequence>
     <Sequence Order=4>
         <DigestValue>base64 encoded h'''2</DigestValue>
     </Sequence>
   </HashTree>


3.3. Verification

   The initial Archive Timestamp shall prove that an archive object
   existed at a certain time, indicated by its Time-Stamp token.
   Verification procedure is as follows:

   1. Identify hash algorithm H (from <DigestMethod> element) and
     calculate hash value for each data object of the archive object.

   2. If the hash-tree is present, search for hash values in the first
     <Sequence> element. If hash values are not present, terminate
     verification process with negative result. If an additional proof
     is necessary that the Archive Time-Stamp relates to a data object
     group (e.g. a document and all its digital signatures), it can
     also be verified that only the hash values of the given data
     objects are in the first hash-value list.

   3. If the hash-tree is present, calculate its root hash value.
     Compare the root hash value with the Time-Stamped value. If not
     equal, terminate verification process with negative result.

   4. If the hash-tree is omitted, compare the hash value of the single
     data object with the Time-Stamped value. If not equal, terminate
     verification process with negative result. If an archive object is
     having more data objects and the hash tree is omitted, also exit
     with negative result.




Jerman Blazic, et. al. Expires January 26 2011                [Page 28]


Internet-Draft                  XMLERS                      August 2010


   5. Check the validity of the Time-Stamp token. If the needed
     information to verify formal validity of the Time-Stamp token is
     not found within the <TimeStampToken> element or within
     <CryptographicInformationList> element, exit with a negative
     result.

4. Archive Time-Stamp Sequence and Archive Time-Stamp Chain

   An Archive Time-Stamp proves the existence of single data objects or
   data object group at a certain time. However, the initial Evidence
   Record created can become invalid due to decomposing validity of
   Time-Stamp Token for a number of reasons: hash algorithms or public
   key algorithms used in its hash tree or the Time-Stamp may become
   weak or the validity period of the timestamp authority certificate
   expires or is revoked.

   To preserve the validity of Evidence Record before such events occur,
   Evidence Record has to be renewed. This can be done by creating a new
   ATS. Depending on the reason for renewing Evidence Record (the Time-
   Stamp becomes invalid or the hash algorithm of the hash tree becomes
   weak) two types of renewal processes are possible:

   o  Time-Stamp renewal: For this process a new Archive Time-Stamp is
      generated, which is applied over last Time-Stamp created. The
      process results in a series of Archive Time-Stamps which are
      contained within a single Archive Time-Stamp Chain (ATSC).

   o  Hash-tree renewal: For this process a new Archive Time-Stamp is
      generated, which is applied over all existing Time-Stamps and data
      objects. Newly generated Archive Time-Stamp is placed in a new
      Archive Time-Stamp Chain. The process results in a series of
      Archive Time-Stamps Chains which are contained within a single
      Archive Time-Stamp Sequence (ATSS).





Jerman Blazic, et. al. Expires January 26 2011                [Page 29]


Internet-Draft                  XMLERS                      August 2010


   After renewal process, only the most recent (i.e. the last generated)
   Archive Time-Stamp has to be monitored for expiration or decomposing
   validity.

4.1. Structure

   Archive Time-Stamp Chain and Archive Time-Stamp Sequence are
   containers for sequences of archive Time-Stamp(s) which are generated
   through renewal processes. Renewal process results in a series of
   Evidence Record elements: <ArchiveTimeStampSequence> element contains
   an ordered sequence of <ArchiveTimeStampChain> elements and
   <ArchiveTimeStampChain> element contains an ordered sequence of
   <ArchiveTimeStamp> elements. Both elements MUST be sorted by time of
   the Time-Stamp in ascending order. Order is indicated by the Order
   attribute.

   When Archive Time-Stamp must be renewed, a new <ArchiveTimeStamp>
   element is generated and depending on the generation process, it is
   either placed:

   o  as the last <ArchiveTimeStamp> child element in a sequence of the
      last <ArchiveTimeStampChain> element in case of Time-Stamp renewal
      or

   o  as the first <ArchiveTimeStamp> child element in a sequence of the
      newly created <ArchiveTimeStampChain> element in case of hash-tree
      renewal.

   The ATS with the largest Order attribute value within the ATSC with
   the largest Order attribute value is the latest ATS and must be valid
   at the present time.

4.1.1. Digest Method

   Digest method is a required element that identifies the digest
   algorithm used to calculate hash values of archive data (and node


Jerman Blazic, et. al. Expires January 26 2011                [Page 30]


Internet-Draft                  XMLERS                      August 2010


   values of hash tree). Digest method is specified in the
   <ArchiveTimeStampChain> element by required <DigestMethod> element
   and indicates the digest algorithm that MUST be used for all hash
   value calculations related to the Archive Time-Stamps within Archive
   Time-Stamp chain.

   The Algorithm attribute contains URIs for identifiers and those must
   be used as defined in [RFC3275] and [RFC4051]. For example when SHA-1
   algorithm is used, algorithm identifier is:

   <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

   Digest algorithms used for Evidence Record must be equal to the
   algorithms used for Time-Stamp Token(s) within a single ATSC. When
   algorithms used by TSA are changed (e.g. upgraded) a new ATSC must be
   started using equal or stronger digest algorithm.

4.1.2. Canonicalization Method

   Prior to hash value calculations of an XML element, a proper binary
   representation must be extracted from its (abstract) XML data
   presentation. The binary representation is determined by UTF-8
   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(s). 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"/>.



Jerman Blazic, et. al. Expires January 26 2011                [Page 31]


Internet-Draft                  XMLERS                      August 2010


   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).

   Canonicalization method is specified in the <Algorithm> attribute of
   the <CanonicalizationMethod> element within <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 calculation of digest value of preceding ATSC. Note that
   canonicalization method is unlikely to change over time as it does
   not impose the same constrains as digest method. In theory, the same
   canonicalization method can be used for a single Archive Time-Stamp
   Sequence. Although alternative canonicalization methods may be used,
   it is recommended to use the c14n-20010315.

4.2. Generation

   Before the cryptographic algorithms used within the most recent
   Archive Time-Stamp become weak or the Time-Stamp certificates are
   invalidated, Archive Time-Stamps have to be renewed by generating a
   new Archive Time-Stamp.

4.2.1. Time-Stamp Renewal

   In case of Time-Stamp renewal, i.e. if the digest algorithm (H) to be
   used in the renewal process is the same as digest algorithm (H') used
   in the last Archive Time-Stamp, the complete content of the last
   <TimeStamp> element MUST be Time-Stamped and new <ArchiveTimeStamp>
   element created as follows:







Jerman Blazic, et. al. Expires January 26 2011                [Page 32]


Internet-Draft                  XMLERS                      August 2010


   1. If the current <ArchiveTimeStamp> element does not contain needed
      proof for long-term formal validation of its Time-Stamp Token
      within the <TimeStamp> element, collect needed data such as root
      certificates, certificate revocation lists, etc., and include them
      in <CryptographicInformationList> element of the last Archive
      Time-Stamp (each data object into a separate
      <CryptographicInformation> element).

   2. Select canonicalization method from <CanonicalizationMethod>
      element and select digest algorithm from <DigestMethod> element.
      Calculate hash value from binary representation of the <TimeStamp>
      element of the last <ArchiveTimeStamp> element including added
      cryptographic information. Acquire the Time-Stamp for the
      calculated hash value. If the Time-Stamp is valid, the new Archive
      Time-Stamp may be generated.

   3. Increase the value order of the new ATS by one and place the new
      ATS into the last <ArchiveTimeStampChain> element.

   The new ATS and its hash tree MUST use the same digest algorithm as
   the preceding one, which is specified in the <DigestMethod> element
   within <ArchiveTimeStampChain> element. Note that the new ATS MAY not
   contain hash-tree. However, Time-Stamp Renewal process may be
   optimized to acquire one Time-Stamp for many Archive Time-Stamps
   using the Merkle Hash Tree. Note that each hash of the <TimeStamp>
   element is treated as the document hash in Section 3.2.1.

4.2.2. Hash Tree Renewal

   The process of hash tree renewal occurs when the new digest algorithm
   is different to the one used in the last Archive Time-Stamp (H <>
   H'). In this case the complete Archive Time-Stamp Sequence and the
   archive data objects covered by existing Archive Time-stamp must be
   Time-Stamped as follows:




Jerman Blazic, et. al. Expires January 26 2011                [Page 33]


Internet-Draft                  XMLERS                      August 2010


   1. Select one or more archive objects to be renewed and theirs
      current <ArchiveTimeStamp> elements.

   2. For each archive object check the current <ArchiveTimeStamp>
      element. If it 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, etc., and include them in
      <CryptographicInformationList> element of the last Archive Time-
      Stamp (each data object into a separate <CryptographicInformation>
      element).

   3. Select a canonicalization method C and select a new secure hash
      algorithm H.

   4. For each archive object select its data objects d(i). Generate
      hash values h(i) = H(d(i)), for example: h(1), h(2).., h(n).

   5. For each archive object calculate a hash hseq=H(ATSSeq) from
      binary representation of the <ArchiveTimeStampSequence> element,
      corresponding to that archive object. Note that Archive Time-Stamp
      Chains and Archive Time-Stamps MUST be chronologically ordered,
      each respectively to its Order attribute, and that the
      canonicalization method C MUST be applied.

   6. For each archive object sort in binary ascending order and
      concatenate all h(i) and the hseq. Generate a new digest value
      h(j)=H(h(1)..h(n),hseq).

   7. Build a new Archive Time-Stamp for each h(j) (hash tree generation
      and reduction is defined in sections 3.2.1. and 3.2.2.). Note that
      each h(j) is treated as the document hash in section 3.2.1. The
      first hash value list in the reduced hash tree should only contain
      h(i) and hseq.




Jerman Blazic, et. al. Expires January 26 2011                [Page 34]


Internet-Draft                  XMLERS                      August 2010


   8. Create 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>


Jerman Blazic, et. al. Expires January 26 2011                [Page 35]


Internet-Draft                  XMLERS                      August 2010


            <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 Merkle Hash Tree.

4.3. Verification

   An Evidence Record shall prove that an archive object existed and has
   not been changed from the time of the initial Time-Stamp Token within
   the first ATS. In order to complete the non-repudiation proof for an
   archive object, the last ATS has to be valid and ATSCs and their
   relations to each other have to be proved:

   1. Select archive object and re-encrypt its data object or data
      object group, if <EncryptionInformation> field is used. Select the
      initial digest algorithm specified within the first Archive Time-
      Stamp Chain and calculate 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 Hash-tree is omitted, calculated AO's value
      MUST match the Time-Stamped value.











Jerman Blazic, et. al. Expires January 26 2011                [Page 36]


Internet-Draft                  XMLERS                      August 2010


   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 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.

5. Encryption

   In some archive services scenarios it may be required that clients
   send encrypted data only, preventing information disclosure to third
   parties, such as archive service providers. In such scenarios it must
   be clear that Evidence Records generated refer to encrypted data
   objects. Evidence Records in general protect the bit-stream (or
   binary representation of XML data) which freezes the bit structure at
   the time of archiving. Encryption schemes in such scenarios cannot be
   changed afterwards without losing the integrity proof. Therefore, an


Jerman Blazic, et. al. Expires January 26 2011                [Page 37]


Internet-Draft                  XMLERS                      August 2010


   ERS record must hold and preserve encryption information in a
   consistent manner.

   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. When different cryptographic material is used, the results
   may not be the same, i.e. decrypted data does not match the original
   (unencrypted) data. 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.

   Cryptographic material may also be used in scenarios when a local
   copy of encrypted data submitted to the archive service provider for
   preservation is kept in an unencrypted form by a client. In such
   scenarios cryptographic material is used to re-encrypt unencrypted
   data kept by a client for the purpose of performing validation of
   Evidence Record, which is related to the encrypted form of client's
   data.

   The attribute Type within <EncrytionInformation> element is optional
   and is used to store processing information about type of stored
   encryption information, e.g. encryption algorithm or encryption key.
   The use of encryption elements heavily depends on the cryptographic
   mechanism and has to be defined by other specification.

6. XSD Schema for the Evidence Record

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema  xmlns:xs="http://www.w3.org/2001/XMLSchema"
               xmlns="urn:ietf:params:xml:ns:ers"
               targetNamespace="urn:ietf:params:xml:ns:ers"
               elementFormDefault="qualified"


Jerman Blazic, et. al. Expires January 26 2011                [Page 38]


Internet-Draft                  XMLERS                      August 2010


               attributeFormDefault="unqualified">
   <xs:element name="EvidenceRecord" type="EvidenceRecordType"/>

   <!-- TYPE DEFINITIONS-->

   <xs:complexType name="EvidenceRecordType">
      <xs:sequence>
         <xs:element name="EncryptionInformation"
                     type="EncryptionInfo" minOccurs="0"/>
         <xs:element name="ArchiveTimeStampSequence"
                     type="ArchiveTimeStampSequenceType"/>
      </xs:sequence>
      <xs:attribute name="Version" type="xs:string" use="required"
                                                       fixed="1"/>
   </xs:complexType>

   <xs:complexType name="EncryptionInfo">
      <xs:sequence>
         <xs:element name="EncryptionInfoType" type="ObjectIdentifier"/>
         <xs:element name="EncryptionInfoValue">
            <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"/>


Jerman Blazic, et. al. Expires January 26 2011                [Page 39]


Internet-Draft                  XMLERS                      August 2010


                  <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>



Jerman Blazic, et. al. Expires January 26 2011                [Page 40]


Internet-Draft                  XMLERS                      August 2010


   <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="skip" minOccurs="0"
                                 maxOccurs="unbounded"/>
                     </xs:sequence>
                     <xs:attribute  name="Type" type="xs:string"
                                    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>



Jerman Blazic, et. al. Expires January 26 2011                [Page 41]


Internet-Draft                  XMLERS                      August 2010


   <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="skip" 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="skip" minOccurs="0"
                                 maxOccurs="unbounded"/>
                     </xs:sequence>
                     <xs:attribute  name="Order" type="OrderType"
                                    use="required"/>
                     <xs:attribute  name="Type" type="xs:string"
                                    use="required"/>


Jerman Blazic, et. al. Expires January 26 2011                [Page 42]


Internet-Draft                  XMLERS                      August 2010


                  </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>

7. Security Considerations

   Secure Algorithms

   Cryptographic algorithms and parameters that are used within Archive
   Time-Stamps must always be secure at the time of generation. This
   concerns the hash algorithm used in the hash lists of Archive
   Timestamp as well as hash algorithms and public key algorithms of the
   timestamps. Publications regarding security suitability of
   cryptographic algorithms ([NIST.800-57-Part1.2006] and [ETSI TS 102
   176-1 V2.0.0]) have to be considered by verifying components. A
   generic solution for automatic interpretation of security suitability
   policies in electronic form is not the subject of this specification.

   Redundancy



Jerman Blazic, et. al. Expires January 26 2011                [Page 43]


Internet-Draft                  XMLERS                      August 2010


   Evidence Records may become affected by weakening cryptographic
   algorithms even before this is publicly known. Retrospectively this
   has an impact on Archive Time-Stamps generated and renewed during
   the archival period. In this case the validity of Evidence Records
   created may end without any options for retroactive action.

   Many TSAs are using the same cryptographic algorithms. While
   compromise of a private key of a TSA may compromise the security of
   only one TSA (and only on Archive Time-Stamp for example), weakening
   cryptographic algorithms used to generate Time-Stamp Tokens would
   affect many TSAs at the same time.

   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 must use different hash algorithms within Archive
   Time-Stamp Sequences and different TSAs using different
   cryptographic algorithms for Time-Stamp Tokens.

   Secure Time-Stamps

   Archive Time-Stamps depend upon the security of normal Time-Stamping
   provided by TSA and stated in security policies. Renewed Archive
   Time-Stamps should have the same or higher quality as the initial
   Archive Time-Stamp of archive data. Archive Time-Stamps used for
   signed archive data should have the same or higher quality than the
   maximum quality of the signatures.

8. IANA Considerations

   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.




Jerman Blazic, et. al. Expires January 26 2011                [Page 44]


Internet-Draft                  XMLERS                      August 2010


   This document defines an XML schema (see Section 6) 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 creates a new IANA registry entitled "XML Evidence
   Record Syntax (ERSXML)".  This registry contains two sub-registries
   entitled "Time-Stamp Token Type" and "Cryptographic Information
   Type".  The policy for future assignments to the both sub-registries
   is "RFC Required".

   The sub-registry "Time-Stamp Token Type" contains textual names and
   description, which should refer to 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)

   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

               Token

   XMLENTRUST EnTrust XML Schema   http://www.entrust.com



Jerman Blazic, et. al. Expires January 26 2011                [Page 45]


Internet-Draft                  XMLERS                      August 2010


                                   /schemas/timestamp

                                   19protocol-20020207

   The sub-registry "Cryptographic Information Type" contains textual
   names and description, which should refer to 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)

   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)


Jerman Blazic, et. al. Expires January 26 2011                [Page 46]


Internet-Draft                  XMLERS                      August 2010


9. References

9.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BPC 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, D., Reagle, J., Solo, D., "XML-Signature Syntax
             and Processing", RFC 3275, March 2002.

   [RFC4051] Eastlake, D., "Additional XML Security Uniform Resource
             Identifiers", RFC 4051, April 2005.

   [RFC4998] Gondrom, T., Brandner, R., Pordesch, U., "Evidence Record
             Syntax (ERS)", RFC 4998, August 2007.

   [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D. and Polk,
             W., "Server-Based Certificate Validation Protocol (SCVP)",
             RFC 5055, December 2007

   [RFC5280] Cooper, D., Santesson, S., Farell, S., Boyen, S., Housley,
             R.,Polk, W., "Internet X.509 Public Key Infrastructure
             Certificate and Certificate Revocation List (CRL) Profile",
             RFC 5280, May 2008.



Jerman Blazic, et. al. Expires January 26 2011                [Page 47]


Internet-Draft                  XMLERS                      August 2010


   [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.

9.2. Informative References

   [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.

   [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.

   [RFC3470] Hollenbeck, S., Rose, M., Masinter, L., "Guidelines for the
             Use of Extensible Markup Language (XML) within IETF
             Protocols", RFC 3470, January 2003.

   [RFC4810] Wallace, C., Pordesch, U., Brandner, R., "Long-Term Archive
             Service Requirements", RFC 4810, March 2007.

   [RFC5126] Pinkas, D., Popoe, N., Ross, J., "CMS Advanced Electronic
             Signatures (CAdES)", RFC 5126, February 2008.



Jerman Blazic, et. al. Expires January 26 2011                [Page 48]


Internet-Draft                  XMLERS                      August 2010


   [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)", RFC
             5652, September 2009.
































Jerman Blazic, et. al. Expires January 26 2011                [Page 49]


Internet-Draft                  XMLERS                      August 2010


APPENDIX A: Detailed verification process of an Evidence Record

   To verify the validity of an Evidence Record start with the first ATS
   till the last ATS (ordered by attribute Order) and perform
   verification for each ATS, as follows:

   1. Select corresponding archive object and its data object or a group
      of data objects.

   2. Re-encrypt data object or data object group, if
      <EncryptionInformation> field is used (see 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.


Jerman Blazic, et. al. Expires January 26 2011                [Page 50]


Internet-Draft                  XMLERS                      August 2010


   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 digest
               value of previous Time-Stamp element. If not, exit with a
               negative result.

         iii. If this ATS is the initial ATS in 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> tag).




Jerman Blazic, et. al. Expires January 26 2011                [Page 51]


Internet-Draft                  XMLERS                      August 2010


   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.



Author's Addresses

   Aleksej Jerman Blazic
   SETCCE
   Tehnoloski park 21
   1000 Ljubljana
   Slovenia

   Phone: +386 (0) 1 620 4500
   Fax:   +386 (0) 1 620 4509
   Email: aljosa@setcce.si


   Svetlana Saljic
   SETCCE
   Tehnoloski park 21
   1000 Ljubljana
   Slovenia

   Phone: +386 (0) 1 620 4506
   Fax:   +386 (0) 1 620 4509
   Email: svetlana.saljic@setcce.si






Jerman Blazic, et. al. Expires January 26 2011                [Page 52]


Internet-Draft                  XMLERS                      August 2010


   Tobias Gondrom
   Waisenhausstr. 67C
   80637 Munich
   Germany

   Phone: +49 (0) 89 3205 330
   Fax:   /
   Email: tobias.gondrom@gondrom.org






























Jerman Blazic, et. al. Expires January 26 2011                [Page 53]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/