Internet DRAFT - draft-brandner-etal-ats
draft-brandner-etal-ats
INTERNET-DRAFT R. Brandner
<draft-brandner-etal-ats-00.txt> University of Heidelberg
Expiration date: 15.1.2004 Tobias Gondrom
IXOS Software AG
U. Pordesch
Fraunhofer Gesellschaft
M. Tielemann
DATEV eG
July 2003
Archive Time-Stamps Syntax (ATS)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [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 made obsolete 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 (2003). All Rights Reserved.
Abstract
This specification describes the syntax and processing of an Archive
Time-Stamps Element, designed for long-term non-repudiation of
existence of data, which particularly can be used for
conservation of evidence of 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..................................................2
1.1 Motivation................................................2
1.2 Requirements..............................................3
1.3 General Overview..........................................3
1.4 Terminology...............................................4
2. Archive Time-Stamps Element...................................5
2.1 Syntax....................................................5
2.2 Generation................................................6
2.3 Verification..............................................7
Brandner et al. [Page 1]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
3. Enhanced Time Stamp...........................................7
3.1 Syntax....................................................7
3.2 Generation................................................8
3.3 Verification..............................................9
4. Archive Time-Stamp Chain and Archive Time-Stamp Sequence......9
4.1 Syntax...................................................10
4.2 Generation...............................................10
4.3 Verification.............................................11
5. Encryption ..................................................12
5.1 Syntax...................................................12
5.2 Generation...............................................13
5.3 Verification.............................................13
6. ASN.1-Module.................................................14
7. Security Considerations......................................15
8. Intellectual Property Rights.................................16
References......................................................16
Authors' Addresses..............................................17
Appendix A - Archive Time-Stamps Element Attribute using CMS....18
Appendix B - Enhanced Time-Stamp Attribute for multiple signature
verification using CMS.............................20
1 Introduction
1.1 Motivation
In many application areas of electronic data exchange a non-
repudiation proof of existence of data has to be possible over long
periods of time. An important example are signed documents, 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 get weak or certificates can
become invalid. To avoid that 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 timely generating Archive Time-Stamps for these
data and by renewal of these Archive Time-Stamps during archiving
period.
It is necessary to standardize data formats and processing
procedures for such Archive Time-Stamps in order to be able to
verify and communicate 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].
Archive Time-Stamps Syntax (ATS) broadens and generalizes this
approach for data of any format and takes requirements of practical
use into account, especially handling a huge amount of data objects.
ATS specifies a syntax for Archive Time-Stamps Element, which
contains Enhanced Time-Stamps and some additional data. This Archive
Time-Stamps Element can be stored as an additional file to signed
Brandner et al. [Page 2]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
data (ATS as file format) or integrated in signed data (ATS as part
of another syntax specification).
ATS also specifies processes for generation and verification of
Archive Time-Stamps Element and as an appendix integration and use
in context of signed and enveloped messages according to CMS.
ATS does not specify a protocol for an archive service yet. Existing
and established archive protocols like SAP ArchiveLink can be
augmented to handle Archive Time-Stamping using ATS as an service.
1.2 Requirements
ATS was designed to fulfill the following requirements:
- Non-repudiation of existence of data must be conserved, even if
hash algorithms or public key algorithms get weak or validity of
certificates expires or certificates are revoked.
- ATS has to be low priced even for a huge amount of data objects
and possibly frequent renewal of time-stamps. The number of time-
stamps should be minimized even for a high quantity of
documents, e.g. stored in archive systems of business companies
or administration departments.
- In case of renewal of Archive-Time Stamps, access to the archived
data objects, which might be stored scattered on external and
write once media, should be avoided as far as possible.
- It should be possible to time-stamp groups of data objects
like a document file and a signature file together, so that they
get the same Archive Time-Stamps. Non-repudiation proof should
still be possible for each single data object separately.
- If it is necessary to delete individual data objects for reasons of
data or secret protection, this must not put at risk the
provability of other data objects.
- It should be possible to encrypt data before transfering to service
providers and generate Archive Time-Stamps to encrypted data. This
should be done in such a way, that these Archive Time-Stamps are a
non-repudiation proof for the unencrypted data as well.
1.3 General Overview
The basis of the ATS are Enhanced Time-Stamps, which refers not
only to a single data object as ordinary time-stamps do, but also to
many data objects. An Enhanced 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 refered data objects does not
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
Brandner et al. [Page 3]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
single data object or a data object group. These sets of hash values
and the time-stamp yield the Enhanced Time-Stamp. In this context of
long-term archiving Enhanced Time-Stamp is called Archive Time-Stamp,
but there are other application areas for Enhanced Time-Stamps, e.g.
used for multiple signature verification (see Appendix B).
For the generation of the Initial Archive Time-Stamp the data objects
to be time-stamped have to be determined - depending of the context
of ATS use. E.G. this can be a file, a pair document file and
signature file as a data object group.
Before cryptographic algorithms used within the Archive Time-Stamp
get weak or time-stamp certificates get invalid Archive Time-Stamp
have to be renewed by generating a new Archive Time-Stamp. ATS
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. It is very effective 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 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 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.4 Terminology
Long-term non-repudiation of existence of data means the ability to
prove existence of data over an undetermined period of time.
A Data Object is an unit of data, provided for (archive) time-
stamping.
A Data object group is a multitude of data objects, which for some
reason belong together. E.g. a document file and a signature file
could be a data object group, which represent signed data.
A Time-stamp is a signed confirmation of a Time Stamping Authority
(TSA) that a data object existed before a certain time. One syntax
specification of time-stamps used here is specified in [RFC3161].
Brandner et al. [Page 4]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
An Enhanced 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.
An Archive Time-Stamp is an Enhanced Time-Stamp used for long-term
non-repudiation of data.
An Archive Time-Stamp Chain is a timely ordered sequence of
Enhanced Time-Stamps, where each Enhanced Time-Stamp preserves non-
repudiation of the Enhanced Time-Stamp before, although if it got
invalid and until itself gets invalid. The process of generating such
an Archive Time-Stamp Chain is called Time-Stamp Renewal.
An Archive Time-Stamp Sequence is a sequence of Archive Time-
Stamp Chains, where each Archive Time-Stamp Chain preserves non-
repudiation of Archive Time-Stamp Chains before, although the hash
algorithm used within Enhanced Time-Stamps hash-tree got weak. Non-
repudiation is preserved until the last Enhanced Time-Stamp of the
last chain gets invalid. The process of generating such an Archive
Time-Stamp Sequence is called Hash-Tree Renewal.
Archive Time-Stamps Element are all Archive Time-Stamps and other
data, which are to be used to prove the existence of a data object or
a data object group.
An Enhanced 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
Enhanced Time-Stamp. An Enhanced 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 Enhanced 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 Archive Time-Stamps Element
An Archive Time-Stamps Element is a unit of data, which is to be used
to prove the existence of a data object or a data object group at a
certain time. The Archive Time-Stamps Element contains Enhanced Time-
Stamps, generated during a long period of archiving and some
necessary or useful data. It is possible to store this Archive Time-
Stamps Element separately from the archived data 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
Archive Time-Stamps Element has the following ASN.1 Syntax:
Brandner et al. [Page 5]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
ArchiveTimeStampsElement ::= SEQUENCE {
version INTEGER { v1(1) },
usefulinformation [1] OCTET STRING OPTIONAL,
encryption [2] EncryptionMethod OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence}
The fields have the following meanings:
version is the syntax version number, for compatibility
with future revisions of this specification.
ArchiveTimeStampSequence is a sequence of ArchiveTimeStampChain,
described in chapter 4.
usefulinformation is an optional field, which can be used by an
application to store additional useful data, like names of files,
which contain the documents.
If the 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 ArchiveTimeStampsElement overall can be
described as follows:
1. Select data object or a group of data objects, which are
documents or essential parts of it - depending on
application.
2. Create Initial Archive Time-Stamp (see Enhanced Time-Stamp chapter
3).
3. Renew this Archive Time-Stamp if necessary, by Time-Stamp Renewal
or Hash-Tree Renewal (see chapter 4).
Process of generation depends in details on the question, whether
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 a simple Archive Time-Stamp without
building hash-trees and reducing them. Details of that generation
procedure are not to be discussed in this specification.
Brandner et al. [Page 6]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
2.3 Verification
The Verification of an ArchiveTimeStampsElement overall can be
described as follows:
1. Select data object or a group of data objects, which where
originally Archive Time-Stamped. Verify that this selection
is adequate (out of scope of this specification).
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 Enhanced Time-Stamp
An Enhanced 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 represents unambiguously all data objects, is
time-stamped.
3.1 Syntax
An Enhanced Time-Stamp has the following ASN.1 Syntax:
EnhancedTimeStamp ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier OPTIONAL,
reducedHashtree [0] SEQUENCE OF {SEQUENCE OF OCTET STRING}
OPTIONAL,
timeStamp ContentInfo}
The fields of type EnhancedTimeStamp 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 existent the digest algorithm of the time-
stamp must be used. If time-stamps according to [RFC3161] are used,
the content of this field must be identically 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 Enhanced Time-Stamp is equal to the ordinary time-stamp.
Brandner et al. [Page 7]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
timeStamp should contain the time-stamp which is defined as
timeStampToken in [RFC 3161]. Other types of time-stamp might be
used, if 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 Enhanced 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 and group them.
2. Choose secure hash algorithm H and generate hash values for the
data objects, which will be the leaves of the hash-tree.
3. If there is more than one hash value, then put together groups of
hash values and arrange in binary ascending order. Concatenate
these values and generate hash values, which are inner nodes of
this tree. Repeat this step until there is only one hash value,
which is the root node of the hash-tree.
4. Order a time-stamp for this root hash value. The hash algorithm in
the time-stamp request must the same as the hash algorithm of the
hash-tree.
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 in binary
ascending order. Repeat this step for the father node of these
hash until you reach root hash. 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 Enhanced Time-Stamp.
Degenerated hash-trees, where father node exist, which only have one
son node should be avoided, because this causes empty lists, when the
hash-tree is reduced.
But note, that there are no restrictions to the quantity of hash
value lists and of there length. Also note, that it is profitable but
not required to build hash-trees and reduce them. An Enhanced Time-
Stamp may consist only of one list of hash-values and a time-stamp or
in extreme only a time-stamp with no hash value lists.
Brandner et al. [Page 8]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
The certificates, CRLS or OCSP-Responses to verify the time-stamp
should be stored in the time-stamp itself. A time-stamp according to
[RFC 3161] is a CMS-object 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 attribute [RFC3126].
3.3 Verification
An Enhanced 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 Enhanced Time-Stamp.
2. Search 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 Enhanced Time-Stamp relates to a data
object group - e.g. a document and all its signatures - it can be
verified additionally, that there are no other hash values in first
hash value list as hash values of the given data objects.
4 Archive Time-Stamp Chain and Archive Time-Stamp Sequence
Enhanced 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. But it has to be considered that this
first Initial Archive Time-Stamp can get invalid, if hash algorithms
or public key algorithms used in its hash-tree or time-stamp get weak
or if validity period of time-stamp certificates expires or if time-
stamp certificates were revoked.
If this happened, the existence of Archive Time-Stamp or archive
time-stamped data has to be proved, which can be done by new Archive
Time-Stamps. Depending on whether time-stamp gets invalid or hash
algorithm of hash-tree gets weak, two kinds of Archive Time-Stamp
renewal are distinguished:
- 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.
Brandner et al. [Page 9]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
- Hash-Tree Renewal: A new Archive Time-Stamp is generated, which
refers to all old Archive Time-Stamps and the data objects
initially archive time-stamped. This opens a new
Archive Time-Stamp Chain. 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 EnhancedTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF ArchiveTimeStampChain
ArchiveTimeStampChain and ArchiveTimeStampSequence must be
ordered ascending by time of time-stamp. Within an
ArchiveTimeStampChain all EnhancedTimestamps 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. It depends on the application, which data objects have
to be time-stamped and when Initial Archive Time-Stamp must be
generated.
Before cryptographic algorithms used within the Archive Time-Stamp
get weak or time-stamp certificates get invalid, Archive Time-Stamp
have to be renewed by generating a new Enhanced 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 one,
specified in the field hash algorithm of the Enhanced 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 by the initial Archive Time-Stamp
have to be regarded, hashed and time-stamped again:
1. Select secure hash algorithm H.
2. Select data objects d(i) refered by initial Archive Time-Stamp
(which are still present and not deleted). Generate hash values
h(i) = H((d(i)) of them using H.
3. Concatenate Archive Time-Stamp Chains before and generate hash
value ha of this concatenation using H.
Brandner et al. [Page 10]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
4. Concatenate each h(i) with ha and generate hash values
h(i)' = H (h(i))+ ha).
5. Build new Archive Time Stamp having each h(i)' (and no other
hash values in first hash value list)
6. Open new ArchiveTimeStampChain and add new Archive Time-Stamp.
If the Time-Stamp of an Archive Time-Stamp gets invalid, the simple
time-stamp renewal should be done. Only if the hash algorithm used
within the hash-tree gets 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 get
invalid to be on the secure side. Nevertheless ArchiveTimeStamps,
which are not necessary for verification, should not be added to
ArchiveTimeStampChain or ArchiveTimeStampSequence.
4.3 Verification
To get an non-repudiation proof that a data object existed at acertain
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 Archive Time-Stamp of all other
ArchiveTimeStampChains contains a hash value of the concatenation
of hash values of all older ArchiveTimeStampChain and a hash value
of the data object. Verify that this Archive Time-Stamp was
generated before the last Archive Time-Stamp of the
ArchiveTimeStampchain got invalid.
In order to complete 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 Enhanced Time-Stamp of each
ArchiveTimeStampChain does not contain other hash values in his first
hash value list.
Brandner et al. [Page 11]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
5 Encryption
If service providers take care of archiving data and generating
Archive Time-Stamps, it might be desirable or required to encrypt
data before transfer. In this case Archive Service Provider
generate time-stamps for encrypted data objects not for the unencrypted
ones. Unfortunately this can affect proof of existence of the unencrypted
data. It could be possible to choose an algorithm or a key for
decryption which is not the algorithm or key used for encryption.
If this case, Archive Time-Stamps would not be a non-
repudiation proof for the unencrypted data. So special care has to
be taken into account using encryption in context of Archive Time-
Stamping: It must be provable, that encrypted data objects
unambiguously represent unencrypted data objects, which are archive
time-stamped. All data necessary to prove this representation must
be part of the archive time-stamped data. Encryption field is a
container for data, which are necessary for this to prove and to
verify that Archive time-Stamps which generated for encrypted data
objects relate to given unencrypted data.
5.1 Syntax
Encryption-Field in ArchiveTimeStampsDocument has following Syntax:
EncryptionMethod ::= SEQUENCE {
encryptionAlgorithm OBJECT IDENTIFIER,
encryptionParameters ANY DEFINED BY encryptionAlgorithm OPTIONAL}
encryptionMethod refers to the algorithm used to encrypt data objects
if used before Archive Time-Stamping.
encryptionParameters contains specific parameters to the encryption
algorithm and necessary for verification. 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.
ATS specifies one EncryptionMethod on the basis of enveloped data
of CMS-Standard using key transport technique with RSA public
key encryption:
id-EncryptionCMS_encryptedmessage ::= {id-ATS-1}
CMS_encryption_params::= SEQUENCE {
encryptionCover ContentInfo,
encryptionKey OCTET STRING,
additional_data CHOICE {
[0] privateKey BIT STRING,
[1] randomValue BIT STRING}}
Brandner et al. [Page 12]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
encryptionCover is a CMS-message of type enveloped message, without
encrypted content (external content).
encryptionKey is the clear text of content-encryption Key, used to
encrypt the content (data objects).
Additional data are necessary to verify, that encryptionKey, which is
not archive time-stamped but added later to Archive Time-Stamp Element
in fact was used, to encrypt the data objects before Archive Time-
Stamps were generated. Two alternatives are given to prove this:
- privateKey, the private key corresponding to the public key given
by the recipientInfo field and usable to decrypt the encrypted
document encryption key and to compare the result with the
encryptionKey.
- randomValue, the random which was used to encrypt the
content-encryption key, which makes it possible to re-encrypt the
encryptionKey and to compare the result with encryptedKey of
recipient info of Encryption-Cover.
5.2 Generation
If encryption method is used, it has to be applied to the data object
or every data object of a data object group before generating Archive
Time-Stamps.
In case of CMS-encryption a CMS-encrypted message has to be generated
using key transport technique as described in [RFC3369] and 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. Private key or
randomValue used to encrypt the content encryption key has to be
stored for verification in future. Later it has to be added to
Archive Time-Stamps Element, if a prove is necessary that this
element in fact refers to unencrypted data.
5.3 Verification
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
Brandner et al. [Page 13]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
selected data objects with encryptionKey and inserting result in
Encryption-Cover. In order to get the identical Bitstream, which originally
was archive time-stamped encoding of encrypted message must not be
changed, with exception of adapting length fields.
To verify that the encryptionKey is the right one, it has to
be verified that the field encrypted key contains the encrypted
content encryption key. This can be done in two ways:
- Re-encrypting: Additionally given encryptionKey is re-encrypted
with the public key of recipient Info, layed down in the
certificate and the additionally given randomValue. The result
must be compared with encrypted key.
- Decrypting: Additionally given privateKey is used to decrypt
encryptedKey. The result has to be compared with encryptionKey.
6 ASN.1-Module
ATS
-- {iso(1) identified-organization(3) dod(6) internet(1)
-- security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ats(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
FROM
CryptographicMessageSyntax {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
EnhancedTimeStamp ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
reducedHashtree [0] SEQUENCE OF {SEQUENCE OF OCTET STRING }
OPTIONAL,
timeStamp ContentInfo}
ArchiveTimeStampChain::= SEQUENCE OF EnhancedTimeStamp
ArchiveTimeStampSequence::= SEQUENCE OF ArchiveTimeStampChain
Brandner et al. [Page 14]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
EncryptionMethod ::= SEQUENCE {
encryptionAlgorithm OBJECT IDENTIFIER,
encryptionParameters::= ANY DEFINED BY encryptionAlgorithm OPTIONAL}
CMS_encryption_params::= SEQUENCE {
encryptionCover ContentInfo,
encryptionKey OCTET STRING
additional_data CHOICE {
[0] privateKey BIT STRING,
[1] randomValue BIT STRING}}
id-EncryptionCMS_encryptedmessage ::= {id-ATS 1}
ArchiveTimeStampsElement::= SEQUENCE {
version INTEGER,
usefulinformation [1] OCTET STRING OPTIONAL,
encryption [2] EncryptionMethod OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence }
END
7 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 Enhanced 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.
Brandner et al. [Page 15]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
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 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
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 [RFC2028]. 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.
ATS uses time-stamps and the Time-Stamp Protocol [RFC3161] might be
used to get necessary time-stamps. ATS does not define a new kind of
trusted time-stamping or non-repudiation service. Nevertheless,
especially if a service is created, which uses ATS, 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 implementors 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.
References
[ETS2003] European Telecommunication Standards Institute (ETSI),
Electronic Signatures and Infrastructures (ESI);
Brandner et al. [Page 16]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
Algorithms and Parameters for Secure Electronic Signatures
ETSI SR 002 176 V1.1.1 (2003-03).
[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.
[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.
Authors' Addresses
Ralf Brandner
University of Heidelberg
Department of Medical Informatics
Im Neuenheimer Feld 400
D-69120 Heidelberg, Germany
E-Mail: ralf_brandner@med.uni-heideberg.de
Tobias Gondrom
IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/M’nchen
E-Mail: tobias.gondrom@ixos.de
Ulrich Pordesch
Fraunhofer Gesellschaft
Institute Secure Telecooperation
Dolivostrasse 15
D-64293 Darmstadt, Germany
E-Mail: ulrich.pordesch@sit.fraunhofer.de
Michael Tielemann
DATEV eG
Paumgartnerstraže 6-14
D-90329 N’rnberg, Germany
E-Mail: michael.tielemann@datev.de
Brandner et al. [Page 17]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
Appendix A - Archive Time-Stamps Element Attribute using CMS
An Archive Time-Stamps Element 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 Archive Time-Stamps Element
is an unsigned attribute (signed message) or an unprotected attribute
(enveloped message).
The Archive Time-Stamps Element Attribute 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 Enhanced 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 Archive
Time-Stamps Element Attribute 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 Archive
Time-Stamp Element Attribute:
Internal signature:
id-ArchiveTimeStampElement ::= {id-ATS-Attribute 1}
External signature:
id-ArchiveTimeStampElement ::= {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 Archive Time-Stamps Element
Attributes - which indicates that the Archive Time-Stamps Element has
been provided externally - the archive time-stamped data object has
to be generated over the complete CMS object within the existing
coding.
Brandner et al. [Page 18]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
In case of verification, if only one Archive Time-Stamps Element
Attribute is contained in the CMS object, the hash value must be
generated over the CMS object without the one Archive Time-Stamps
Element Attribute. 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) Archive
Time-Stamps Element Attribute, all Archive Time-Stamps Element
Attributes have to be removed in order to generate the data object.
- During verification of the nth one Archive Time-Stamps Element
Attribute, the first n-1 attributes should remain within the CMS
object.
- The verification of the nth one Archive Time-Stamps Element
Attribute 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. [Page 19]
DRAFT Archive Time-Stamps Syntax (ATS) July 2003
Appendix B - Enhanced Time Stamp Attribute for multiple signature
verification using CMS
Apart from the use in Archive Time-Stamps, Enhanced Time-Stamps can
also be used for securing the verification time of signed data with
several signatures. A single Enhanced Time-Stamp offers the
possibility to prove that the certificates on which the signatures
rely were not revoked at the moment of verification. It is not
necessary to request several ordinary time-stamps, which can cause a
huge amount of expenses, the same Enhanced Time-Stamp, added to all
signatures is sufficient.
For CMS a sensible place to store such an Enhanced Time-Stamp is an
unsigned attribute. In this case the Enhanced Time-Stamp is added to
each signature as an unsigned attribute.
The following OBJECT INDENTIFIER identifies the verification time-
stamp attribute:
OBJECT IDENTIFIER ::= {id-ATS-Attribute 3}
The attribute value of the verification time stamp has the ASN.1 type
VerificationTimeStampToken:
VerificationTimeStampToken ::= EnhancedTimeStamp
The hash values of the SignatureValue fields in the SignerInfo
structures are stored in the first hash value list of the reduced
hash-tree.
Expiration date of this draft: 15.1.2004
Brandner et al. [Page 20]
