INTERNET-DRAFT R. Brandner 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]