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
<EvidenceRecord> element, which has the following structure (where
"+" denotes one or more occurrences; "*" denotes zero or more
occurrences):
<EvidenceRecord>
<Version />
<ArchiveTimeStamp Order>
<DigestMethod />
<HashTree> OPTIONAL
(<Transform />)*
<Content />
</HashTree>
<TimeStamp>
Jerman Blazic, et. al. Expires August 25, 2007 [Page 8]
Internet-Draft XMLERS February 2007
(<Transform />)*
<Content />
</TimeStamp>
<ComplementaryData> OPTIONAL
(<Transform />)*
<Content />
</ComplementaryData>)*
</ArchiveTimeStamp>) +
</EvidenceRecord>
The XML tags have the following meanings:
<Version> 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.
<DigestMethod> tag identifies the hash algorithms used to hash the
data object over the archival period.
<HashTree> tag holds a value or a structure of a reduced hash
tree(s) described in section 2.2.2.
<TimeStamp> tag holds a time stamp token provided by the Time-
Stamping Authority.
<ComplementaryData> 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 <CryptoInfos> 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 <ArchiveTimeStamp> element. The
first <ArchiveTimeStamp> 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 <Transform> elements indicate the transforms (e.g.
canonicalization algorithms) that must be applied to the node value
of <Content> 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 <Content>
element. This includes the entire text between the start and end tags
of the <Content> 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 <Content> 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.
<DigestMethod> 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).
<element name="DigestMethod" type="ds:DigestMethodType"/>
<complexType name="DigestMethodType" mixed="true">
<sequence>
<any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
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 <Object> element of a signature
(reference to a Entrust XML Schema for time-stamp).
<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>
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 <Content> element of the <HashTree>
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:
<Sequence>
<MessageImprint>5XQCAGgwJL2WZ6nv2OSGYlRFpK8=</MessageImprint>
<MessageImprint>wyFrW58ATzRch7VUPNY2P+75Q/I=</MessageImprint>
<MessageImprint>woCvx62tw0uc24v51xtNNxld5Kw=</MessageImprint>
<MessageImprint>7N2lphOrGx+/PCxtGwzbKIj+InQ=</MessageImprint>
<MessageImprint>zbCNhmQv+8kRo9W/0YedrpeZ1a8=</MessageImprint>
<MessageImprint>ThuhSOZhNj42vsIRg38epxj9qVo=</MessageImprint>
</Sequence>
<Sequence>
<MessageImprint>FX7AgSsZ0kaW8fHWi4BYDkAkZS0=</MessageImprint>
Jerman Blazic, et. al. Expires August 25, 2007 [Page 13]
Internet-Draft XMLERS February 2007
</Sequence>
<Sequence>
<MessageImprint>tWl/o/er7kGwIeip4g+xvzShMno=</MessageImprint>
</Sequence>
<Sequence>
<MessageImprint>+bY32LFVm/ynJj6TZss5J6BzYwI=</MessageImprint>
</Sequence>
<Sequence>
<MessageImprint>Eu05AI8VVqFkddHYyYXMs8cjXcU=</MessageImprint>
</Sequence>
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 <ComplementaryData> element
(as a node value of its <Content> element).
<ComplementaryData>
(<Transform>)*
<Content />
</ComplementaryData>
3. Generation of an Evidence Record
The generation of an <EvidenceRecord> 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 <ComplementaryData>.
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 <Content>
elements in <ComplementaryData> element (each data object into
separate <ComplementaryData>).
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 <Content> element. The
binary presentation of this node value is determined by UTF-8
encoding and if the <Transform> 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):
<Sequence>
<MessageImprint>h4</MessageImprint>
<MessageImprint>h5</MessageImprint>
<MessageImprint>h6</MessageImprint>
<MessageImprint>h7</MessageImprint>
</Sequence>
<Sequence>
<MessageImprint>h8</MessageImprint>
<MessageImprint>h9</MessageImprint>
</Sequence>
<Sequence>
<MessageImprint>h'1</MessageImprint>
<MessageImprint>h'3</MessageImprint>
Jerman Blazic, et. al. Expires August 25, 2007 [Page 21]
Internet-Draft XMLERS February 2007
</Sequence>
<Sequence>
<MessageImprint>h''2</MessageImprint>
</Sequence>
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 <DigestMethod> 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
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.setcce.org/schemas/ers"
targetNamespace="http://www.setcce.org/schemas/ers"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="EvidenceRecord">
<xs:complexType>
<xs:sequence>
<xs:element name="ArchiveTimeStamp" minOccurs="1"
maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="DigestMethod" type="xs:DigestMethodType"/>
<xs:element name="HashTree" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="Transform"
type="xs:TransformMethodType" minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="Content" minOccurs="1"
maxOccurs="1">
<xs:complexType>
<xs:sequence>
Jerman Blazic, et. al. Expires August 25, 2007 [Page 24]
Internet-Draft XMLERS February 2007
<xs:element name="Sequence"
maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="MessageImprint"
type="xs:hexBinary"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="TimeStamp" minOccurs="1" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="Transform"
type="xs:TransformMethodType" minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="Content" minOccurs="1"
maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ComplementaryData" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="Transform"
type="xs:TransformMethodType" minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="Content" minOccurs="1"
maxOccurs="1"/>
Jerman Blazic, et. al. Expires August 25, 2007 [Page 25]
Internet-Draft XMLERS February 2007
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:attribute name="version" type="xs:string" use="required" />
<!-- TYPE DEFINITIONS-->
<xs:complexType name="DigestMethodType" mixed="true">
<xs:sequence>
<xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required" />
</xs:complexType>
<xs:complexType name="TransformMethodType" mixed="true">
<xs:sequence>
<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required" />
</xs:complexType>
</xs:schema>
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]
