LTANS
Internet Draft R. Brandner
Document: draft-ietf-ltans-ers-01.txt InterComponentWare AG
Expires: January 2005 B. Hunter
Fraunhofer Gesellschaft
Institute for Secure
Telecooperation
July 2004
Evidence Record Syntax (ERS)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
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 existence of data, which particularly can be used
for conservation of evidence of digitally signed data.
Brandner & Hunter Expires - January 2005 [Page 1]
Evidence Record Syntax (ERS) July 2004
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...................................................2
1.1 Motivation.................................................2
1.2 General Overview and Requirements..........................3
1.3 Terminology................................................4
2. Evidence Record................................................5
2.1 Syntax.....................................................6
2.2 Generation.................................................7
2.3 Verification...............................................7
3. Archive Time-Stamp.............................................7
3.1 Syntax.....................................................8
3.2 Generation.................................................8
3.3 Verification..............................................11
4. Archive Time-Stamp Chain and Archive Time-Stamp Sequence......11
4.1 Syntax....................................................12
4.2 Generation................................................12
4.3 Verification..............................................14
5. Encryption....................................................15
5.1 Syntax....................................................16
5.2 Generation................................................17
5.3 Verification..............................................17
6. ASN.1-Module..................................................18
Security Considerations..........................................20
References.......................................................23
Author's Addresses...............................................23
Appendix A: Evidence Record using CMS............................24
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. Important examples are digitally signed
data, which sometimes have to be archived conclusively 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 that digitally signatures
lose their probative force it has to be provable that the data
already existed before such a critical event. This can be done by
Brandner & Hunter Expires - January 2005 [Page 2]
Evidence Record Syntax (ERS) July 2004
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) [RFC3369].
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 the 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 (ERS as file format) or integrated
in signed data (ERS 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 [LTAP to be published].
1.2 General Overview and Requirements
ERS meets the requirements for data structures set forth in
[REQ2004].
The basis of the ERS are Archive Time-Stamps, which can refer to a
single data object (same as ordinary time-stamps) or to 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 data objects, referred to in the hash-tree,
does not affect the provability of other data objects. The hash-
tree can be reduced to a few small sets of hash values, necessary
to prove the 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
Brandner & Hunter Expires - January 2005 [Page 3]
Evidence Record Syntax (ERS) July 2004
Time- Stamp 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 simple 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 will be
invalidated. This is very efficient in particular, when Archive
Time-Stamping is done by an archiving system or service that
implements a central management of Archive Time-Stamps.
The simple Time-Stamp renewal is not sufficient if the hash
algorithm of 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 access the referred data
objects and other Archive Time-Stamps.
1.3 Terminology
Archived data object: Data unit to be preserved by a long-term
archive service.
Archived data object group: A multitude of archived 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.
Archive Time-Stamp Chain: 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: 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
Brandner & Hunter Expires - January 2005 [Page 4]
Evidence Record Syntax (ERS) July 2004
the hash algorithm used within the previous Archive Time-Stamp's
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 demonstrate the validity
archived data objects or related attestations.
Evidence record: Collection of evidence compiled for one or more
archived data objects. An evidence record may include
acknowledgements of TAA, timestamps and verification data, such as
public-key certificates, revocation information, trust anchors,
policy details and role information.
Long-term archive service: See Trusted Archive Authority.
Reduce 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 signed attestation generated by a Time Stamping
Authority (TSA) that a data item existed at a certain time.
[RFC3161] specifies a structure for timestamps and a protocol for
communicating with a TSA.
Trusted archive authority (TAA): A service that is responsible for
preserving data for long periods.
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 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 the CMS data types signed-data and
enveloped-data, the CMS integration is specified in Appendix A.
Brandner & Hunter Expires - January 2005 [Page 5]
Evidence Record Syntax (ERS) July 2004
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,
encryption [1] EncryptionMethod OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF CryptoInfo
CryptoInfo ::= SEQUENCE
{
cryptoInfoType OBJECT IDENTIFIER
cryptoInfoValue ANY DEFINED BY cryptoInfoType
}
The fields have the following meanings:
version is the syntax version number, for compatibility with future
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.
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.
Brandner & Hunter Expires - January 2005 [Page 6]
Evidence Record Syntax (ERS) July 2004
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.
2. Create Initial Archive Time-Stamp (see Archive Time-Stamp
chapter 3).
3. Renew this Archive Time-Stamp if necessary, via 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. 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 an Archive Time-Stamp without including a
reduced hash-tree and putting the data object hash directly in the
timestamp. Details of local generation procedures 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 to verify 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 unambiguously
represents all data objects, is time-stamped.
Brandner & Hunter Expires - January 2005 [Page 7]
Evidence Record Syntax (ERS) July 2004
3.1 Syntax
An Archive Time-Stamp has the following ASN.1 Syntax:
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier OPTIONAL,
reducedHashtree [0] 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 is 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 are the nodes
(of a hash-tree) necessary for the verification of a single data
object. Hash values are represented as octet strings. If the
optional field reducedHashtree is not present the Archive Time-
Stamp is equivalent to the ordinary time-stamp and contains the
hash of the document, instead of the root hash of the
reducedHashTree. timeStamp should contain the time-stamp which is
defined as timeStampToken in [RFC 3161]. Other types of time-stamp
might be used, provided that they contain time data, time-stamped
data and a signature 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 object 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.
Brandner & Hunter Expires - January 2005 [Page 8]
Evidence Record Syntax (ERS) July 2004
(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 object groups,
where data object group 1 and 3 only contain one document, and data
object group 2 contains 3 documents:
+------+
| h123 |
+------+
/ \
/ \
+----+ +----+
| h12| | h3 |
+----+ +----+
/ \
/ \
+----+ +-------+
| h1 | | h2abc |
+----+ +-------+
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
| h2a| | h2b| | h2c|
+----+ +----+ +----+
Figure 1: Hash-tree
h1 = H(d1) where d1 is the only data object in data object group 1
h3 = H(d3) where d3 is the only data object in data object 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:
Brandner & Hunter Expires - January 2005 [Page 9]
Evidence Record Syntax (ERS) July 2004
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.
Assuming that the sorted binary ordering of the hashes in Figure 1
is:
h2abc < h1 then the reduced hash-tree for data object group 1
(d1) is:
+----------------------------------+
| +------------------+ +--------+ |
| | +------+ +----+ | | +----+ | |
| | | h2abc| | h1 | | | | h3 | | |
| | +------+ +----+ | | +----+ | |
| +------------------+ +--------+ |
+----------------------------------+
Figure 2: Reduced hash-tree for data object group 1
The pseudo ASN1 for this reduced hash-tree would look like:
rht1 = SEQ( SEQ (h2abc, h1), SEQ (h3))
Assuming the same hashtree as in figure 1 the reduced hash-tree for
all data objects in data object 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 on the number of hash value lists
or of their length. Also note, that it is profitable but not
Brandner & Hunter Expires - January 2005 [Page 10]
Evidence Record Syntax (ERS) July 2004
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 (directly including the hash of
the data object) 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].
3.3 Verification
An Archive Time-Stamp shall prove that a data object existed at a
certain time, given within the 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 or from
the messageImprint-Field of timeStampToken if digestAlgorithm is
not present.
2. Search for hash value h in the first list of reducedHashtree. If
not present, terminate verification process with negative result.
3. Concatenate hash values of the actual list of hash values 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 [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 groups at a certain time. However, this first Initial
Brandner & Hunter Expires - January 2005 [Page 11]
Evidence Record Syntax (ERS) July 2004
Archive Time-Stamp can become invalid, if hash algorithms or public
key algorithms used in its hash-tree or time-stamp become weak or
if the time-stamp certificates expire or are revoked. If this is
going to happen, the existence of the Archive Time-Stamp and
archive time-stamped data has to be reassured. This is 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 types of Archive Time-Stamp renewals are
possible:
- Time-Stamp Renewal: A new Archive Time-Stamp is generated, which
refers to the time-stamp of the old one. One or more Archive Time-
Stamps generated by Time-Stamp Renewal yield an Archive Time-Stamp
Chain for a data object or data object group.
- Hash-Tree Renewal: A new Archive Time-Stamp is generated, which
refers to all the old Archive Time-Stamps as well as the data
objects initially archive time-stamped. A new Archive Time-Stamp
Chain is created. 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 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
[LTAP to be published] 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. The new Archive Time-Stamp
must use the same hash algorithm within its hash-tree as the old
Brandner & Hunter Expires - January 2005 [Page 12]
Evidence Record Syntax (ERS) July 2004
one, which is specified in the hash algorithm field of the Archive
Time-Stamp or 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.
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 object 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 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 ASN1 encoded, i.e. they contain
sequence and length tags.
4. Binary sort and 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 & Hunter Expires - January 2005 [Page 13]
Evidence Record Syntax (ERS) July 2004
+------+
| 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 3 above
h1' = H( binary sorted and concatenated (H(d1), ha(1)))
d1 is the original document from data object group 1
h3' = H( binary sorted and concatenated (H(d3), ha(3)))
d3 is the original document from data object 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'))
If 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.
4.3 Verification
Brandner & Hunter Expires - January 2005 [Page 14]
Evidence Record Syntax (ERS) July 2004
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 to be
valid at the time of the following Archive Time-Stamp. All Archive
Time-Stamps within the 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.
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 TAA 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 records
refer to encrypted data objects and not to the unencrypted ones. To
avoid problems when using the evidence records in the future,
additional special precautions have to be taken:
- 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 allow to prove that archive time-stamped encrypted data
Brandner & Hunter Expires - January 2005 [Page 15]
Evidence Record Syntax (ERS) July 2004
objects unambiguously represent unencrypted data objects. All data
necessary to prove unambiguous representation have to be part of
the archived data objects.
- 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 encrypted 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).
This specification defines an optional data field to store the
needed parameters of the used encryption methods. One possible
encryption method is specified [Fis2004]. Further encryption
methods may be defined in other specifications.
5.1 Syntax
The encryption field within EvidenceRecord has the following
syntax:
EncryptionMethod ::= SEQUENCE {
encryptionAlgorithm OBJECT IDENTIFIER,
encryptionParameters ANY DEFINED BY encryptionAlgorithm
OPTIONAL}
encryptionMethod refers to the algorithm used to encrypt the data
objects if used before Archive Time-Stamping.
encryptionParameters contains specific parameters for the
encryption algorithm and are necessary for verification and re-
encryption.
encryptionMethod is open for encryption methods, which fulfill the
above mentioned requirements. Instead of using a traditional
encryption method it might be reasonable to define and use a
surjective one-way function, if the service provider manages
Archive Time-Stamping, but not document management.
ERS specifies one EncryptionMethod on the basis of enveloped data
of the CMS-Standard using key transport technique with RSA public
key encryption:
id-EncryptionCMS_encryptedmessage ::= {id-ATS-1}
CMS_encryption_params::= SEQUENCE {
Brandner & Hunter Expires - January 2005 [Page 16]
Evidence Record Syntax (ERS) July 2004
encryptionCover ContentInfo,
publicKey BIT STRING OPTIONAL,
params CHOICE {
[0] privateKey BIT STRING,
[1] encryptionKeyRan EncryptionKeyRandom}}
EncryptionKeyRandom::= SEQUENCE {
encryptionKey OCTET STRING,
randomValue BIT STRING}}
encryptionCover is a CMS-message of type enveloped message, without
encrypted content (external content).
publicKey is the public key used to encrypt encryptKey. This value
must be present if the corresponding certificate is not included in
the CMS structure, or if more than one certificate is included.
privateKey is the private key corresponding to the public key given
by the recipientInfo field. The private key can decrypt the
encrypted document encryption key.
encryptionKeyRan contains encryptionKey, the clear text of content-
encryption Key (used to encrypt the content (data objects)), and
randomValue, the random value used in the encryption of the
content-encryption key. Thus, one can re-encrypt encryptionKey
using the randomValue using the public key in the recipientInfo.
This encrypted result is compared with the encryptedKey of
recipient info of Encryption-Cover. If it is the same, then
encryptionKey can be used to re-encrypt the data objects.
5.2 Generation
When the client encrypts to-be-archived data objects, it must
ensure that the needed encryption info is included in the archived
data.
In the case of CMS encryption, a CMS encrypted message has to be
generated using the key transport technique, as described in
[RFC3369], and the RSA encryption algorithm. Encrypted content must
be part of the message. At least one certificate must be added,
which contains the public key used to encrypt the encryption key.
The private key or randomValue used to encrypt the content
encryption key has to be stored by the client for verifications in
the future. The client adds CMS_encryption_params to the Archive
Time-Stamps Element, when a proof is necessary that this
EvidenceRecord refers to the given unencrypted data.
5.3 Verification
Brandner & Hunter Expires - January 2005 [Page 17]
Evidence Record Syntax (ERS) July 2004
If the EncryptionMethod field is used, verification of Archive-
Time- Stamps requires two additional steps:
1. Apply encryption method to reconstruct the encrypted data
objects.
2. Check whether the encryption key was applied before Archive
Time- Stamping.
In case of CMS-Encryption this means:
Time-stamped data objects can be reconstructed by encrypting
selected data objects with encryptionKey and inserting result in
Encryption-Cover. In order to get the identical Bitstream, that
originally was archive time-stamped, the encoding of the encrypted
message must not be changed, with the exception of adapting the
(preceding) length fields.
To verify that the encryptionKey is the right one, it has to be
verified that the encrypted key field contains the encrypted
content encryption key. This can be done in two ways:
- Re-encrypting: encryptionKey and randomValue must be provided.
encryptionKey is re-encrypted using randomValue and the public key
in recipient Info, which is contained in the certificate. The
result must be compared with encrypted key.
- Decrypting: privateKey must be provided. privateKey is used to
decrypt encryptedKey, which provides the content-encryption key.
6. ASN.1-Module
ERS
-- {iso(1) identified-organization(3) dod(6) internet(1)
-- security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ers(TBD) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
TimeStampToken
FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13) }
ContentInfo
Brandner & Hunter Expires - January 2005 [Page 18]
Evidence Record Syntax (ERS) July 2004
FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)};
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
reducedHashtree [0] SEQUENCE OF SEQUENCE OF OCTET STRING
OPTIONAL,
timeStamp ContentInfo}
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain
EncryptionMethod ::= SEQUENCE {
encryptionAlgorithm OBJECT IDENTIFIER,
encryptionParameters ANY DEFINED BY encryptionAlgorithm
OPTIONAL}
CMS-encryption-params::= SEQUENCE {
encryptionCover ContentInfo,
publicKey BIT STRING OPTIONAL,
params CHOICE {
privateKey [0] BIT STRING,
encryptionKeyRan [1] EncryptionKeyRandom}}
EncryptionKeyRandom::= SEQUENCE {
encryptionKey OCTET STRING,
randomValue BIT STRING}
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) },
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryption [1] EncryptionMethod OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF CryptoInfo
CryptoInfo ::= SEQUENCE
{
cryptoInfoType OBJECT IDENTIFIER,
cryptoInfoValue ANY DEFINED BY cryptoInfoType
}
END
Brandner & Hunter Expires - January 2005 [Page 19]
Evidence Record Syntax (ERS) July 2004
Security Considerations
Secure Algorithms
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 TSAs 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.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
Brandner & Hunter Expires - January 2005 [Page 20]
Evidence Record Syntax (ERS) July 2004
has made any effort to identify any such rights. Information on
the IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF
Executive Director.
ERS uses time-stamps and the Time-Stamp Protocol [RFC3161] might be
used to get necessary time-stamps. ERS does not define a new kind
of trusted time-stamping or non-repudiation service. Nevertheless,
especially if a service is created, which uses ERS, patents
regarding time-stamping services might be relevant and have to be
considered (see [RFC3161]).
There are no other patents known, which affect this specification.
Nevertheless implementers of this specification SHOULD perform
their own patent search and determine whether or not any
encumbrances exist on their implementation. Users of this
specification SHOULD perform their own patent search and determine
whether or not any encumbrances exist on the use of this
specification.
Disclaimer of Validity
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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 (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
Brandner & Hunter Expires - January 2005 [Page 21]
Evidence Record Syntax (ERS) July 2004
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Brandner & Hunter Expires - January 2005 [Page 22]
Evidence Record Syntax (ERS) July 2004
References
[ETS2003] European Telecommunication Standards Institute (ETSI),
Electronic Signatures and Infrastructures (ESI); Algorithms and
Parameters for Secure Electronic Signatures, ETSI SR 002 176 V1.1.1
(2003-03).
[Fis2004] Fischlin, M., Pordesch, B., Non-repudiation Despite
Encryption, First published as Nichtabstreitbarkeit trotz
Verschlusselung, Datenschutz und Datensicherung 3 / 2004, pp 163-
168. English translation http://ltans.edelweb.fr/.
[Mer1980] Merkle, R. Protocols for Public Key Cryptosystems,
Proceedings of the 1980 IEEE Symposium on Security and Privacy
(Oakland, CA, USA, April 1980): pages 122-134.
[REQ2004] Wallace, C., Pordesch, U., Brandner, R. Long-term Archive
Service Requirements, 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. Pope, N. Electronic
Signature Formats for long term electronic signatures, RFC 3126,
2001.
[RFC3161] Cain, P. Pinkas, D. Zuccherato, R. Time-Stamp Protocol
(TSP), RFC 3161, 2001.
[RFC3369] Housley, R., Cryptographic Message Syntax (CMS), RFC 3369,
2002.
Author's Addresses
Ralf Brandner
InterComponentWare AG
Otto-Hahn-Str. 3
D-69119 Walldorf, Germany
E-Mail: ralf.brandner@intercomponentware.com
Brian Hunter
Fraunhofer Gesellschaft
Institute Secure Telecooperation
Dolivostrasse 15
Brandner & Hunter Expires - January 2005 [Page 23]
Evidence Record Syntax (ERS) July 2004
D-64293 Darmstadt, Germany
E-Mail: brian.hunter@sit.fraunhofer.de
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 have 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-ATS-Attribute 1}
External signature:
id-EvidenceRecord ::= {id-ATS-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.
Brandner & Hunter Expires - January 2005 [Page 24]
Evidence Record Syntax (ERS) July 2004
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 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:
- During verification of the first (in a chronological order)
EvidenceRecord, all EvidenceRecord have to be removed in order to
generate the data object.
- During verification of the nth one EvidenceRecord, the first n-1
attributes should remain within the CMS object.
- 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 & Hunter Expires - January 2005 [Page 25]
