Long-term Archive And Notary R. Brandner
Services (LTANS) InterComponentWare AG
Internet-Draft T. Gondrom
Expires: November 13, 2006 Open Text Corporation
U. Pordesch
Fraunhofer Gesellschaft
May 12, 2006
Evidence Record Syntax (ERS)
draft-ietf-ltans-ers-07
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 November 13, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In many scenarios, users need to be able to ensure and prove the
existence and integrity of data, especially digitally signed data, in
a common and reproducible way over a long and possibly undetermined
period of time. This document specifies the syntax and processing of
an Evidence Record, designed for long-term non-repudiation of
Brandner, et al. Expires November 13, 2006 [Page 1]
Internet-Draft ERS May 2006
existence of data, which particularly can be used for conservation of
evidence of digitally signed data.
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. General Overview and Requirements . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Evidence Record . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 8
3. Archive Time-Stamp . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 12
4. Archive Time-Stamp Chain and Archive Time-Stamp Sequence . . . 12
4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 16
5. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. ASN.1-Module . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Evidence Record using CMS . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Brandner, et al. Expires November 13, 2006 [Page 2]
Internet-Draft ERS May 2006
1. Introduction
1.1. Motivation
In many application areas of electronic data exchange a non-
repudiation proof of existence of digital data has to be possible
over long periods of time. An important example is digitally signed
data, which sometimes has to be archived with digital signatures
being verifiable over 30 years or more. During the archiving period
hash algorithms and public key algorithms or their parameters can
become weak or certificates can become invalid. To avoid the loss of
probative value of a digital signature, it has to be provable that
the digitally signed data already existed before such a critical
event. This can be done by timely generating Time-Stamps for these
data and by the renewal of these Time-Stamps during the archival
period.
It is necessary to standardize data formats and processing procedures
for such Time-Stamps in order to be able to verify and communicate
archived data preserving evidence. A first approach was made by IETF
within [RFC3126], where an optional Archive Time-Stamp Attribute was
specified for integration in signatures according to the
Cryptographic Messages Syntax (CMS) [RFC3852].
Evidence Record Syntax (ERS) broadens and generalizes this approach
for data of any format and takes Long-term archive service
requirements [REQ2004] into account, in particular, the handling of
huge numbers of data objects. ERS specifies a syntax for an Evidence
Record, which contains Archive Time-Stamps and some additional data.
This Evidence Record can be stored as an additional file to signed
data (ER as file format) or integrated in signed data (ER as part of
another syntax specification). ERS also specifies processes for
generation and verification of Evidence Records and as an appendix
integration and use in context of signed and enveloped messages
according to CMS. ERS does not specify a protocol, instead, this is
done in a complementary LTANS specification.
1.2. General Overview and Requirements
ERS meets requirements for data structures set forth in [REQ2004].
The basis of the ERS are Archive Time-Stamps, which can cover a
single data object (as an RFC3161 compliant time-stamp does) or can
cover a group of data objects. An Archive Time-Stamp can be derived
from hash-trees, first described by Merkle [Mer1980], combined with a
time-stamp. The leaves of the hash-tree are hash values of the data
objects. A time-stamp is requested only for the root hash of the
hash-tree. The deletion of any referred data objects does not
Brandner, et al. Expires November 13, 2006 [Page 3]
Internet-Draft ERS May 2006
influence the provability of others. The hash-tree can be reduced to
a few little sets of hash values, necessary to prove existence of a
single data object or a data object group. These sets of hash values
and the time-stamp yield the Archive Time-Stamp.
For the generation of the Initial Archive Time-Stamp the data objects
to be time-stamped have to be determined - depending on the context
of ERS use, e.g. this could be a file, or a data object group
consisting of multiple files, such as a document and its associated
digital signature.
Before cryptographic algorithms used within the Archive Time-Stamp
become weak or time-stamp certificates become invalid, Archive Time-
Stamps have to be renewed by generating a new Archive Time-Stamp.
ERS distinguishes two ways for renewal of an Archive Time-Stamp, the
simple Time-Stamp Renewal and the complex Hash-Tree Renewal.
In the case of Time-Stamp Renewal the time-stamp of an Archive Time-
Stamp has to be hashed and time-stamped by a new Archive Time-Stamp.
It is not necessary to access the initially archived data objects
itself. This simple form of renewal is sufficient, if only the hash
algorithm or the public key-algorithm of the time-stamp of an Archive
Time-Stamp is going to lose its security suitability or the time-
stamp certificates get invalid. This is very efficient in
particular, if Archive Time-Stamping is done by an archiving system
or service, which implements a central management of Archive Time-
Stamps.
Time-Stamp renewal is not sufficient if the hash algorithm used to
build the hash-tree of an Archive Time-Stamp becomes insecure. In
the case of Hash-Tree Renewal not only the time-stamps but also the
complete Archive Time-Stamps and the referred archived data objects
have to be hashed and time-stamped again by a new Archive Time-Stamp.
It is necessary to get the referred data objects and other Archive
Time-Stamps.
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 a archived data object group, which
represent signed data.
Archive Time-Stamp: Is a time-stamp and lists of hash values,
which allows to verify the existence of several data objects at a
certain time.
Brandner, et al. Expires November 13, 2006 [Page 4]
Internet-Draft ERS May 2006
Archive Time-Stamp Chain: Part of a Archive Time-Stamp Sequence,
it is a time-ordered sequence of Archive Time-Stamps, where each
Archive Time-Stamp preserves non-repudiation of the previous
Archive Time-Stamp, even after the previous Archive Time-Stamp
becomes invalid. Overall non-repudiation is maintained until the
new Archive Time-Stamp itself becomes invalid. The process of
generating such an Archive Time-Stamp Chain is called Time-Stamp
Renewal.
Archive Time-Stamp Sequence: Part of the Evidence Record, it is a
sequence of Archive Time-Stamp Chains, where each Archive Time-
Stamp Chain preserves non-repudiation of the previous Archive
Time-Stamp Chains, even after the hash algorithm used within the
previous Archive Time-Stamps hash-tree became weak. Non-
repudiation is preserved until the last Archive Time-Stamp of the
last chain becomes invalid. The process of generating such an
Archive Time-Stamp Sequence is called Hash-Tree Renewal.
Evidence: Information that may be used to resolve a dispute about
various aspects of authenticity 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 Time-Stamps (within structures of Archive
Time-Stamp Chains and Archive Time-Stamp Sequences) and additional
verification data, like certificates, revocation information,
trust anchors, policy details, role information, etc.
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.
Time-Stamp: A cryptographically secure confirmation generated by a
Time Stamping Authority (TSA) [RFC3161] specifies a good structure
for time-stamps and a protocol for communicating with a Time-stamp
Authority (TSA). Further good structures and protocols for
communicating with a Time-stamp Authority (TSA) may also, but not
exclusively, be [I180141], [I180142], [I180143], and [ANSX995].
Trusted archive authority (TAA): A service responsible for
preserving data for long periods of time, including generation and
collection of evidence, storage of archived data objects and
evidence, etc. A.K.A. Long-term archive service.
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. An Archive Time-Stamp relates to a data object group, if
it relates to every data object of the group and no other data
Brandner, et al. Expires November 13, 2006 [Page 5]
Internet-Draft ERS May 2006
objects. An Archive Time-Stamp Chain relates to a data object / data
object group, if its first Archive Time-Stamp relates to this data
object/data object group. An Archive Time-Stamp Sequence relates to
a data object / data object group, if its first Archive Time-Stamp
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 data object or an archived data object
group at a certain time. The Evidence Record contains Archive Time-
Stamps, generated during a long period of archiving and possibly
useful data for validation. It is possible to store this Evidence
Record separately from the archived data objects or to integrate it
into the data itself. For data types signed data and enveloped data
of the CMS integration is specified in Appendix A.
2.1. Syntax
Evidence Record has the following ASN.1 Syntax:
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) },
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryptionInfo [1] EncryptionInfo OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF CryptoInfo
CryptoInfo ::= SEQUENCE
{
cryptoInfoType OBJECT IDENTIFIER
cryptoInfoValue ANY DEFINED BY cryptoInfoType
}
EncryptionInfo ::= SEQUENCE
{
encryptionInfoType OBJECT IDENTIFIER,
encryptionInfoValue [0] EXPLICIT ANY DEFINED BY encryptionInfoType
}
The fields have the following meanings:
version is the syntax version number, for compatibility with future
Brandner, et al. Expires November 13, 2006 [Page 6]
Internet-Draft ERS May 2006
revisions of this specification.
digestAlgorithms is a sequence of all the hash algorithms used to
hash the data object over the archival period.
cryptoInfos allows the storage of data useful in the validation of
the archiveTimeStampSequence. This could include possible
TrustAnchors, certificates, revocation information or the current
definition of the suitability of cryptographic algorithms, past and
present (e.g. RSA 768bit valid until 1998, RSA 1024bit valid until
2008, SHA1 valid until 2010). These items may be added based on the
policy used. Since this data is not protected within any time-stamp,
the data should be current and somehow verifiable. Such verification
is out-of-scope of this document.
encryptionInfo contains the necessary information in case encrypted
content shall be handled. For discussion of syntax please refer to
chapter 5.1
ArchiveTimeStampSequence is a sequence of ArchiveTimeStampChain,
described in chapter 4.
If the archive data objects were encrypted before generating Archive
Time-stamps but a non-repudiation proof is needed for unencrypted
data objects, the optional field encryption contains data necessary
to re-encrypt data objects. If left out, it means that data objects
are not encrypted. For further details see chapter 5.
2.2. Generation
The generation of an EvidenceRecord overall can be described as
follows:
1. Select archived data object or an archived group of data objects,
which are documents or essential parts of it - depending on
application. In the case that only essential parts of documents
or objects shall be covered the application not defined in this
draft MUST take care of the right extraction of binary data to be
covered for generation EvidenceRecord and their verification.
2. Create Initial Archive Time-Stamp (see Archive Time-Stamp chapter
3).
3. Renew this Archive Time-Stamp when necessary, by Time-Stamp
Renewal or Hash-Tree Renewal (see chapter 4).
The process of generation depends on whether the Archive Time-Stamps
are generated, stored and managed by a centralized instance or not.
Brandner, et al. Expires November 13, 2006 [Page 7]
Internet-Draft ERS May 2006
In case of central management it is possible to collect data objects
from many documents, to build hash-trees, store them and reduce them
later. In case of local generation it might be easier to generate a
simple Archive Time-Stamp without building hash-trees and reducing
them. Details of local generation procedure are not to be discussed
in this specification.
2.3. Verification
The Verification of an EvidenceRecord overall can be described as
follows:
1. Select archived data object or a group of data objects, which
were originally Archive Time-Stamped.
2. Re-encrypt data object/data object group, if encryption field is
used (details see chapter 5)
3. Verify Archive Time-Stamp Sequence (details in chapter 3 and 4).
3. Archive Time-Stamp
An Archive Time-Stamp is a time-stamp and some lists of hash values,
which allow verification of the existence of a data object or a data
object group at a certain time. The lists of hash values can be
generated by reduction of an ordered Merkle hash-tree [Mer1980]. The
leaves of this hash-tree are the hash values of the data objects to
be time-stamped. Every inner node of the tree contains one hash
value, which is generated by hashing the concatenation of the
children nodes. The root hash value, which represents unambiguously
all data objects, is time-stamped.
3.1. Syntax
An Archive Time-Stamp has the following ASN.1 Syntax:
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier OPTIONAL,
reducedHashtree [0] EXPLICIT SEQUENCE OF {SEQUENCE OF OCTET STRING}
OPTIONAL,
timeStamp ContentInfo}
The fields of type ArchiveTimeStamp have the following meaning:
digestAlgorithm identifies the digest algorithm and any associated
parameters used within the reduced hash-tree. If the optional field
digestAlgorithm is not present the digest algorithm of the time-stamp
Brandner, et al. Expires November 13, 2006 [Page 8]
Internet-Draft ERS May 2006
must be used. If time-stamps according to [RFC3161] are used, the
content of this field must be identical to hashAlgorithm of
messageImprint-Field of timeStampToken.
reducedHashtree contains lists of hash values, which could be derived
from a hash-tree by reduction to nodes necessary for verification of
a single data object. Hash values are represented as octet strings.
If the optional field reducedHashtree is not existent the Archive
Time-Stamp is equal to the ordinary time-stamp.
timeStamp should contain the time-stamp as defined in section 1.3
"Terminology". (e.g. as defined with timeStampToken in [RFC 3161]).
Other types of time-stamp might be used, if they contain time data,
time-stamped data and a cryptographically secure confirmation from
the TSA of these data.
3.2. Generation
The lists of hash values of an Archive Time-Stamp can be generated by
the way of building and reducing a Merkle hash-tree [Mer1980].
Such a hash-tree can be built as follows:
1. Collect data objects to be time-stamped.
2. Choose secure hash algorithm H and generate hash values for the
data objects, which will be the leaves of the hash-tree.
3. For each data group containing more than one document, its
respective document hashes are binary sorted in ascending order,
concatenated and hashed.
4. If there is more than one hash value, place them in groups and
sort each group in binary ascending order. Concatenate these
values and generate new hash values, which are inner nodes of
this tree. (If additional hash values are needed, e.g. so that
all nodes have the same number of children, any data may be
hashed using H and used.) Repeat this step until there is only
one hash value, which is the root node of the hash-tree.
5. Order a time-stamp for this root hash value. The hash algorithm
in the time-stamp request must be the same as the hash algorithm
of the hash-tree.
An example of a constructed hash-tree for 3 data groups, where data
group 1 and 3 only contain one document, and data group 2 contains 3
documents:
Brandner, et al. Expires November 13, 2006 [Page 9]
Internet-Draft ERS May 2006
+------+
| h123 |
+------+
/ \
/ \
+----+ +----+
| h12| | h3 |
+----+ +----+
/ \
/ \
+----+ +-------+
| h1 | | h2abc |
+----+ +-------+
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
| h2a| | h2b| | h2c|
+----+ +----+ +----+
Figure 1: Hash-tree
h1 = H(d1) where d1 is the only data object in data group 1
h3 = H(d3) where d3 is the only data object in data group 3
h12 = H( binary sorted and concatenated (h1, h2abc))
h123 = H( binary sorted and concatenated (h12, h3))
h2a = H(first data object of data object group 2)
h2b = H(second data object of data object group 2)
h2c = H(third data object of data object group 2)
h2abc = H( binary sorted and concatenated (h2a, h2b, h2c))
The hash-tree can be reduced to lists of hash values, necessary to
have a proof of existence for a single data object:
1. Generate hash value h of the data object, using hash algorithm H
of the hash-tree.
2. Select all hash values, which have the same father node as h.
Generate the first list of hash values by arranging these hashes,
in binary ascending order. Repeat this step for the father node
of these hashes until the root hash is reached. The father nodes
are not saved in the hash lists - they are computable.
3. Generate a reduced hash-tree by building the sequence of these
hash value lists. Then add the time-stamp and the hash algorithm
to get an Archive Time-Stamp.
Brandner, et al. Expires November 13, 2006 [Page 10]
Internet-Draft ERS May 2006
Assuming that the sorted binary ordering of the hashes in Figure 1
is: h2abc < h1 then the reduced hash-tree for data group 1 (d1) is:
+--------------------------------+
| +----------------+ +--------+ |
| | +------+ +----+ | | +----+ |
| | | h2abc| | h1 | | | | h3 | |
| | +------+ +----+ | | +----+ |
| +----------------+ +--------+ |
+--------------------------------+
Figure 2: Reduced hash-tree for data group 1
The pseudo ASN1 for this reduced hash-tree would look like:
rht1 = SEQ( SEQ (h2abc, h1), SEQ (h3))
Assuming the same hash-tree as in figure 1 the reduced hash-tree for
all data objects in data group 2 is identical.
+-------------------------------------------------+
| +----------------------+ +--------+ +--------+ |
| | +----+ +----+ +----+ | | +----+ | | +----+ | |
| | | h2b| | h2c| | h2a| | | | h1 | | | | h3 | | |
| | +----+ +----+ +----+ | | +----+ | | +----+ | |
| +----------------------+ +--------+ +--------+ |
+-------------------------------------------------+
Figure 3: Reduced hash-tree for data object group 2
The pseudo ASN1 for this reduced hash-tree would look like:
rht2 = SEQ( SEQ (h2b, h2c, h2a), SEQ (h1), SEQ (h3))
Note, 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 certificates, CRLS or OCSP-Responses needed to verify the time-
stamp SHOULD be stored in the time-stamp itself. A time-stamp
according to [RFC 3161] is a CMS-object in which certificates can be
stored in the certificates field and CRLs can be stored in the crls
field of signed data. OCSP responses can be stored as unsigned
attributes [RFC3126]. Note [ANSX995], [I180142] and [I180143]
specify irrefutably verifiable time-stamps which do not depend on
certificates, CRLS, or OCSP-Responses.
Brandner, et al. Expires November 13, 2006 [Page 11]
Internet-Draft ERS May 2006
3.3. Verification
An Archive Time-Stamp shall prove that a data object existed at a
certain time, given by time-stamp. This can be verified as follows:
1. Calculate hash value h of the data object with hash algorithm H
given in field digestAlgorithm of the Archive Time-Stamp.
2. Search for hash value h in the first list of reducedHashtree. If
not present, terminate verification process with negative result.
3. Concatenate the hash values of the actual list of hash values in
binary ascending order and calculate the hash value h' with
algorithm H. This hash value h' must become member of the next
higher list of hash values. Continue step 3 until a root hash
value is calculated.
4. Check time-stamp. In case of time-stamp according to [RFC 3161]
the root hash value must correspond to hashedMessage and
digestAlgorithm must correspond to hashAlgorithm field, both in
messageImprint field of timeStampToken.
If the proof is necessary for more than one data object, steps 1 and
2 have to be done for all data objects to be proved. If an
additional proof is necessary that the Archive Time-Stamp relates to
a data object group (e.g. a document and all its signatures) it can
be verified additionally, that only the hash values of the given data
objects are in the first hash value list.
4. Archive Time-Stamp Chain and Archive Time-Stamp Sequence
Archive Time-Stamps are used for archive time-stamping. An Archive
Time-Stamp proves the existence of single data objects or data object
group at a certain time. However, this first Archive Time-Stamp in
the first ArchiveTimeStampChain can become invalid, if hash
algorithms or public key algorithms used in its hash-tree or time-
stamp become weak or if the validity period of the time-stamp
certificates expires or if the time-stamp certificates are revoked.
If this is going to happen, the existence of the Archive Time-Stamp
or archive time-stamped data has to be reassured, which can be done
by creating new Archive Time-Stamps. Depending on whether the time-
stamp becomes invalid or the hash algorithm of the hash-tree becomes
weak, two kinds of Archive Time-Stamp renewals are possible:
o Time-Stamp Renewal: A new Archive Time-Stamp is generated, which
covers the time-stamp of the old one. One or more Archive Time-
Stamps generated by Time-Stamp Renewal yield an Archive Time-Stamp
Brandner, et al. Expires November 13, 2006 [Page 12]
Internet-Draft ERS May 2006
Chain for a data object or data object group.
o Hash-Tree Renewal: A new Archive Time-Stamp is generated, which
covers all the old Archive Time-Stamps as well as the data
objects. A new Archive Time-Stamp Chain is started. One or more
Archive Time-Stamp Chains for a data object or data object group
yield an Archive Time-Stamp Sequence.
4.1. Syntax
ArchiveTimeStampChain and ArchiveTimeStampSequence have the following
ASN.1 Syntax:
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain
ArchiveTimeStampChain and ArchiveTimeStampSequence MUST be ordered
ascending by time of time-stamp. Within an ArchiveTimeStampChain all
reducedHashtrees of the contained ArchiveTimeStamps MUST use the same
Hash-Algorithm.
4.2. Generation
A first Initial Archive Time-Stamp relates to a data object or a data
object group. The application or the policy included in the LTANS
Long term Archiving Protocol (to be specified) dictate when an
Initial Archive Time-Stamp must be generated for each data object.
Before cryptographic algorithms used within the Archive Time-Stamp
become weak or time-stamp certificates are invalidated, Archive Time-
Stamps have to be renewed by generating a new Archive Time-Stamp.
In the case of Time-Stamp Renewal the content of the timeStamp field
of the old Archive Time-Stamp has to be hashed and time-stamped by a
new Archive Time-Stamp. For this procedure one could of course e.g.
collect a number of old Archive Time-Stamps and build the new hash-
tree with the hash values of the content of their timeStamp fields.
This hash-tree of the new Archive Time-Stamp MUST use the same hash
algorithm as the old one, which is specified in the digestAlgorithm
field of the Archive Time-Stamp or if this value is not set (as it is
optional) within the time-stamp itself.
In the case of Hash-Tree Renewal not only the Archive Time-Stamp but
also the data objects referred to by the initial Archive Time-Stamp
have to be hashed and time-stamped again:
1. Select secure hash algorithm H.
Brandner, et al. Expires November 13, 2006 [Page 13]
Internet-Draft ERS May 2006
2. Select data objects d(i) referred to by initial Archive Time-
Stamp (objects which are still present and not deleted).
Generate hash values h(i) = H((d(i)). If data groups with more
than one document are present, then one will have more than one
hash for a group, i.e. h(i_a), h(i_b).., h(i_n)
3. atsc(i) is the encoded ArchiveTimeStampSequence, the
concatenation of all previous Archive Time-Stamp Chains (in
chronological order) related to data object d(i).
Generate hash value ha(i) = H(atsc(i)).
Note: The ArchiveTimeStampChains used are DER encoded, i.e. they
contain sequence and length tags.
4. Concatenate each h(i) with ha(i) and generate hash values
h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is:
h(i_a)' = H (h(i_a)+ ha(i))
h(i_b)' = H (h(i_b)+ ha(i)) etc.
5. Build a new Archive Time Stamp for each h(i)'. (hash-tree
generation and reduction is defined in 3.2, note that each h(i)'
will be treated in 3.2 as the document hash. The first hash
value list in the reduced hash-tree should only contain h(i)'.
For a multi-document group, the first hash value list will
contain the new hashes for all the documents in this group, i.e.
h(i_a)', h(i_b)'.., h(i_n)')
6. Create new ArchiveTimeStampChain and add this new Archive Time-
Stamp.
Brandner, et al. Expires November 13, 2006 [Page 14]
Internet-Draft ERS May 2006
+-------+
| h123' |
+-------+
/ \
/ \
+-----+ +----+
| h12'| | h3'|
+-----+ +----+
/ \
/ \
+----+ +--------+
| h1'| | h2abc' |
+----+ +--------+
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|h2a'| |h2b'| |h2c'|
+----+ +----+ +----+
Figure 4: Hash-tree from hash-tree renewal
Let H be the new secure hash algorithm
ha(1), ha(2), ha(3) are as defined in step 4 above
h1' = H( binary sorted and concatenated (H(d1), ha(1)))
d1 is the original document from data group 1
h3' = H( binary sorted and concatenated (H(d3), ha(3)))
d3 is the original document from data group 3
h2a = H(first data object of data object group 2)
...
h2c = H(third data object of data object group 2)
h2a' = H( binary sorted and concatenated (h2a, ha(2)))
...
h2c' = H( binary sorted and concatenated (h2c, ha(2)))
h2abc = H( binary sorted and concatenated (h2a', h2b', h2c'))
Before the Time-Stamp of an Archive Time-Stamp becomes invalid, the
simple time-stamp renewal should be done. Only if the hash algorithm
used within the hash-tree becomes weak, Hash-Tree Renewal must be
done. In case of centralized Archive Time-Stamping, Archive Time-
Stamps might be generated a long-time before other Archive Time-
Stamps become invalid to be on the secure side. Nevertheless
ArchiveTimeStamps, which are not necessary for verification, should
Brandner, et al. Expires November 13, 2006 [Page 15]
Internet-Draft ERS May 2006
not be added to ArchiveTimeStampChain or ArchiveTimeStampSequence.
4.3. Verification
To get an non-repudiation proof that a data object existed at a
certain time, the Archive Time-Stamp Chains and their relations to
each other and to the data objects have to be proved:
1. Verify that the first Archive Time-Stamp of the first
ArchiveTimestampChain (the Initial Archive Time-Stamp) contains
the hash value of the data object.
2. Verify each ArchiveTimestampChain. The first hash value list of
each ArchiveTimeStamp must contain the hash value of the time-
stamp of the Archive Time-Stamp before. The Archive Time-Stamp
has had to be valid at the time of the following Archive Time-
Stamp (especially the time-stamp refer to section 3.3
verification step 4 has to be valid and secure at the moment the
next Archive time-stamp has been applied. All Archive Time-
Stamps within a chain MUST use the same hash algorithm and this
algorithm MUST be secure at the time of the first Archive Time-
Stamp of the following ArchiveTimeStampChain.
3. Verify that the first hash value list of the first Archive Time-
Stamp of all other ArchiveTimeStampChains contains a hash value
of the concatenation of the data object hash and the hash value
of all older ArchiveTimeStampChain. Verify that this Archive
Time-Stamp was generated before the last Archive Time-Stamp of
the ArchiveTimeStampChain became invalid.
In order to complete the non-repudiation proof for the data objects,
the last Archive Time-Stamp has to be valid at the time the
verification is performed.
If the proof is necessary for more than one data object, steps 1 and
3 have to be done for all these data objects. If an additional proof
is necessary that the Archive Time-Stamp Sequence relates to a data
object group (e.g. a document and all its signatures) it can be
verified additionally, that each first Archive Time-Stamp of each
ArchiveTimeStampChain does not contain other hash values in its first
hash value list.
5. Encryption
If service providers are used to archive data and generate Archive
Time-Stamps, it might be desirable or required that clients only send
encrypted data to be archived. However, this means that evidence
Brandner, et al. Expires November 13, 2006 [Page 16]
Internet-Draft ERS May 2006
records refer to encrypted data objects and not to the unencrypted
ones. ERS directly protects the integrity of the bit-stream and this
some kind of freezes the bit structure at the time of archiving and
later renewal or change of the encryption scheme, e.g. because the
encryption is no longer secure is not possible without loosing the
integrity proof of the ERS. In such cases the services of a data
transformation (and by this also possible re-encryption) done by a
notary service might be a possible solution. To avoid problems when
using the evidence records in the future, additional special
precautions have to be taken:
o Encryption can affect the proof of existence of the unencrypted
data. E.g. it could be possible to choose an algorithm or a key
for decryption that is not the algorithm or key used for
encryption. In this case, the evidence record would not be a non-
repudiation proof for the unencrypted data. Therefore, only
encryption methods may be used, which make it possible to prove
that archive time-stamped encrypted data objects unambiguously
represent unencrypted data objects. All data necessary to prove
unambiguous representation has to be part of the archived data
objects. (Note: Additionally the long term security of the used
encryption schemes has to be analyzed on how it could be used to
create collision attacks.)
o When encrypted data objects and the evidence record are sent back,
it may be desirable for clients to only store the unencrypted data
objects and to delete the decrypted ones, in order to avoid
duplicate storage. In order to use the evidence record, it must
be then possible to re-encrypt the unencrypted data to get exactly
the data that was originally archived. Therefore, additional data
necessary to re-encrypt data objects should be inserted into the
evidence record by the client (i.e. archive provider never sees
these values).
The syntax specifies an open structure to store the needed parameters
of the used encryption methods and further information dependent on
the used encryption methods. The use of the specified
encryptionInfoType and encryptionInfoValue may be heavily dependent
on the used mechanisms and has to be defined in other specifications.
5.1. Syntax
EncryptionInfo-Field in EvidenceRecord has the following Syntax:
EncryptionInfo ::= SEQUENCE
{
encryptionInfoType OBJECT IDENTIFIER,
encryptionInfoValue [0] EXPLICIT ANY DEFINED BY encryptionInfoType
Brandner, et al. Expires November 13, 2006 [Page 17]
Internet-Draft ERS May 2006
}
encryptionInfoType defines the type of information or structure that
will be in the encryptionInfoValue field.
encryptionInfoValue contains the specific information that is
necessary to provide the proof that the unencrypted data is
unambiguously represented by the encrypted data protected by the
EvidenceRecord.
6. ASN.1-Module
ERS
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) ltans(11) id-mod(1) id-mod-ers(0) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
TimeStampToken
FROM PKIXTSP -- [RFC3161]
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13) }
ContentInfo
FROM CryptographicMessageSyntax2004 -- FROM [RFC3852]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
-- Imports from RFC 3280 [RFC3280], Appendix A.1
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- LTANS specific idnetifiers
id-ltans OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) }
Brandner, et al. Expires November 13, 2006 [Page 18]
Internet-Draft ERS May 2006
id-em OBJECT IDENTIFIER ::= { id-ltans 2 }
-- ERS encryption methods
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier OPTIONAL,
reducedHashtree [0] EXPLICIT SEQUENCE OF SEQUENCE OF OCTET STRING
OPTIONAL,
timeStamp ContentInfo}
ArchiveTimeStampChain::= SEQUENCE SIZE (1..MAX) OF ArchiveTimeStamp
ArchiveTimeStampSequence::= SEQUENCE SIZE (1..MAX) OF
ArchiveTimeStampChain
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) },
digestAlgorithms SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryptionInfo [1] EncryptionInfo OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF CryptoInfo
-- dynamically extensible information object set --
CryptoInfo ::= SEQUENCE {
cryptoInfoType OBJECT IDENTIFIER
cryptoInfoValue ANY DEFINED BY cryptoInfoType
}
EncryptionInfo ::= SEQUENCE {
encryptionInfoType OBJECT IDENTIFIER,
encryptionInfoValue [0] EXPLICIT ANY DEFINED BY encryptionInfoType
}
END
7. Security Considerations
Secure Algorithms
Brandner, et al. Expires November 13, 2006 [Page 19]
Internet-Draft ERS May 2006
Cryptographic algorithms and parameters which are used within Archive
Time-Stamps must be secure at the time of generation. This concerns
the hash algorithm used in the hash lists of Archive Time-Stamp as
well as hash algorithms and public key algorithms of the time-stamps.
Publications regarding security suitability of cryptographic
algorithms ([ETSI2003]) have to be considered by verifying
components. A generic solution for automatic interpretation of
security suitability policies in electronic form is desirable but not
subject of this specification.
Redundancy
Algorithms can loose there security suitability untimely or Time
Stamping Authorities may be considered as untrustworthy
retrospectively. Therefore Archive Time-Stamps can lose their
probative force. If Archive Time-Stamps are managed centrally
several redundant ArchiveTimeStampSequences can be generated using
different hash algorithms and different Time Stamping Authorities.
Secure Time-Stamps
Archive Time-Stamping is as secure as normal time stamping. Security
requirements for Time Stamping Authorities stated in security
policies have to be met. Renewed Archive Time-Stamps should have the
same or higher quality as the Initial Archive Time-Stamp. Archive
Time-Stamps used for signature renewal of signed data, should have
the same or higher quality than maximum quality of the signatures.
Secure Encryption
For non-repudiation proof it does not matter, whether encryption has
been broken or not. Nevertheless, users should keep secret their
private keys and randoms used for encryption and disclose them only
if needed (e.g. in a lawsuit to a judge or expert). They should use
encryption algorithms and parameters which are prospected to be
unbreakable as long as confidentiality of the archived data is
important.
8. References
8.1. Normative References
[ANSX995] American National Standard for Financial Services,
"Trusted Timestamp Management and Security", ANSX X9.95-
2005, June 2005.
[I180141] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1:
Brandner, et al. Expires November 13, 2006 [Page 20]
Internet-Draft ERS May 2006
Framework", ISO ISO-18014-1, February 2002.
[I180142] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2:
Mechanisms producing independent tokens", ISO ISO-18014-2,
December 2002.
[I180143] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3:
Mechanisms producing linked tokens", ISO ISO-18014-3,
February 2004.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, 1996.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, 1997.
[RFC3126] Adams, C., Pinkas, D., Ross, J., and N. Pope, "Electronic
Signature Formats for long term electronic signatures",
RFC 3126, 2001.
[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,
August 2001.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
8.2. Informative References
[ETSI2003]
European Telecommunication Standards Institute (ETSI),
Electronic Signatures and Infrastructures (ESI);,
"Algorithms and Parameters for Secure Electronic
Signatures", ETSI SR 002 176 V1.1.1, March 2003.
[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.
[REQ2004] Wallace, C., Brandner, R., and U. Pordesch, "Long-term
Archive Service Requirements", I-D ???, 2005.
Brandner, et al. Expires November 13, 2006 [Page 21]
Internet-Draft ERS May 2006
Appendix A. Evidence Record using CMS
An Evidence Record can be added to signed data or enveloped data in
order to transfer them in a conclusive way. For CMS a sensible place
to store such an Evidence Record is an unsigned attribute (signed
message) or an unprotected attribute (enveloped message).
The Evidence Record also contains information about the selection
method which was used for the generation of the data objects to be
time-stamped. In the case of CMS, two selection methods can be
distinguished:
1. The CMS Object as a whole including contentInfo is selected as
data object and archive time-stamped. This means that a hash
value of the CMS object must be located in the first list of hash
values of Archive Time-Stamps.
2. The CMS Object and the signed or encrypted content are included
in the Archive Time-Stamp as separated objects. In this case the
hash value of the CMS Object as well as the hash value of the
content has to be stored in the first list of hash values as a
group of data objects.
However, other selection methods could also be applied like for
instance in [RFC3126].
In the case of the two selection methods defined above, the Evidence
Record has to be added to the first signature of the CMS Object of
signed data. Depending on the selection method, the following Object
Identifier is defined for the Evidence Record:
Internal signature:
id-EvidenceRecord ::= {id-em-env-data-Attribute 1}
External signature:
id-EvidenceRecord ::= {id-em-env-data-Attribute 2}
The attributes should only occur once. If they appear several times,
they have to be stored within the first signature in a chronological
order.
If the CMS object doesn't have the EvidenceRecord Attributes - which
indicates that the EvidenceRecord has been provided externally - the
archive time-stamped data object has to be generated over the
complete CMS object within the existing coding.
In case of verification, if only one EvidenceRecord is contained in
the CMS object, the hash value must be generated over the CMS object
without the one EvidenceRecord. This means that the attribute has to
Brandner, et al. Expires November 13, 2006 [Page 22]
Internet-Draft ERS May 2006
be removed before verification. The length of fields containing tags
has to be adapted. Apart from that, the existing coding must not be
modified.
If several Archive Time-Stamps occur, the data object has to be
generated as follows:
o During verification of the first (in a chronological order)
EvidenceRecord, all EvidenceRecord have to be removed in order to
generate the data object.
o During verification of the nth one EvidenceRecord, the first n-1
attributes should remain within the CMS object.
o The verification of the nth one EvidenceRecord must result in a
point of time when the document must have existed with the first n
attributes. The verification of the n+1th attribute must prove
that this requirement has been met.
Brandner, et al. Expires November 13, 2006 [Page 23]
Internet-Draft ERS May 2006
Authors' Addresses
Ralf Brandner
InterComponentWare AG
Otto-Hahn-Str. 3
Walldorf D-69119
Germany
Email: ralf.brandner@intercomponentware.com
Tobias Gondrom
Open Text Corporation
Technopark 2
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
Ulrich Pordesch
Fraunhofer Gesellschaft
Dolivostrasse 15
Darmstadt D-64293
Germany
Email: ulrich.pordesch@zv.fraunhofer.de
Brandner, et al. Expires November 13, 2006 [Page 24]
Internet-Draft ERS May 2006
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.
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 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 Internet Society (2006). 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.
Brandner, et al. Expires November 13, 2006 [Page 25]
