| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2006.
Copyright © The Internet Society (2005).
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.
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].
1.
Introduction
1.1
Motivation
1.2
General Overview and Requirements
1.3
Terminology
2.
Evidence Record
2.1
Syntax
2.2
Generation
2.3
Verification
3.
Archive Time-Stamp
3.1
Syntax
3.2
Generation
3.3
Verification
4.
Archive Time-Stamp Chain and Archive Time-Stamp Sequence
4.1
Syntax
4.2
Generation
4.3
Verification
5.
Encryption
5.1
Syntax
5.2
Generation
5.3
Verification
6.
ASN.1-Module
7.
Security Considerations
8.
References
8.1
Normative References
8.2
Informative References
§
Authors' Addresses
A.
Evidence Record using CMS
§
Intellectual Property and Copyright Statements
| TOC |
In many application areas of electronic data exchange a non-repudiation proof of existence of digital data has to be possible over long periods of time. An important example 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 timely generating Time-Stamps for these data and by the renewal of these Time-Stamps during the archival period.
It is necessary to standardize data formats and processing procedures for such Time-Stamps in order to be able to verify and communicate archived data preserving evidence. A first approach was made by IETF within [RFC3126], where an optional Archive Time-Stamp Attribute was specified for integration in signatures according to the Cryptographic Messages Syntax (CMS) [RFC3852].
Evidence Record Syntax (ERS) broadens and generalizes this approach for data of any format and takes Long-term archive service requirements [REQ2004] into account, in particular, the handling of huge numbers of data objects. ERS specifies a syntax for an Evidence Record, which contains Archive Time-Stamps and some additional data. This Evidence Record can be stored as an additional file to signed data (ER as file format) or integrated in signed data (ER as part of another syntax specification). ERS also specifies processes for generation and verification of Evidence Records and as an appendix integration and use in context of signed and enveloped messages according to CMS. ERS does not specify a protocol, instead, this is done in a complementary LTANS specification.
ERS meets 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 referred 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 single data object or a data object group. These sets of hash values and the time-stamp yield the Archive Time-Stamp.
For the generation of the Initial Archive Time-Stamp the data objects to be time-stamped have to be determined - depending on the context of ERS use, e.g. this could be a file, or a data object group consisting of multiple files, such as a document and its associated digital signature.
Before cryptographic algorithms used within the Archive Time-Stamp become weak or time-stamp certificates become invalid, Archive Time-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 Time-Stamp Renewal the time-stamp of an Archive Time-Stamp has
to be hashed and time-stamped by a new Archive Time-Stamp. It is not
necessary to access the initially archived data objects itself. This
simple form of renewal is sufficient, if only the hash algorithm or
the public key-algorithm of the time-stamp of an Archive Time-Stamp is
going to lose its security suitability or the time-stamp certificates
get invalid. This is very efficient in particular, if Archive
Time-Stamping is done by an archiving system or service, which
implements a central management of Archive Time-Stamps.
Time-Stamp renewal is not sufficient if the hash algorithm 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 get the referred
data objects and other Archive Time-Stamps.
Archived data object: Data unit that is archived and has to be preserved for a long time by the Long-term Archive Service.
Archived data object group: A multitude of data objects, which for some reason belong together. E.g. a document file and a signature file could be a archived data object group, which represent signed data.
Archive Time-Stamp: Is a time-stamp and lists of hash values, which allows to verify the existence of several data objects at a certain time.
Evidence: Information that may be used to resolve a dispute about various aspects of authenticity of archived data objects.
Evidence record: Collection of evidence compiled for one or more given archived data objects over time. An evidence record include all Archive Time-Stamps and additional verification data, like certificates, revocation information, trust anchors, policy details, role information, etc.
Reduced hash-tree: The process of reducing a Merkle hash-tree [MER1980] to a list of lists of hash values. This is the basis of storing the evidence for a single data object.
Time-Stamp: A signed confirmation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. [RFC3161] specifies a good structure for time-stamps and a protocol for communicating with a Time-stamp Authority (TSA).
Trusted archive authority (TAA): A service responsible for preserving data for long periods of time, including generation and collection of evidence, storage of archived data objects and evidence, etc. A.K.A. Long-term archive service.
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 the hash algorithm used within the previous Archive Time-Stamps hash-tree became weak. Non-repudiation is preserved until the last Archive Time-Stamp of the last chain becomes invalid. The process of generating such an Archive Time-Stamp Sequence is called Hash-Tree Renewal.
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.
| TOC |
An Evidence Record is a unit of data, which is to be used to prove the existence of an archived data object or an archived data object group at a certain time. The Evidence Record contains Archive Time-Stamps, generated during a long period of archiving and possibly useful data for validation. It is possible to store this Evidence Record separately from the archived data objects or to integrate it into the data itself. For data types signed data and enveloped data of the CMS integration is specified in Appendix A.
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.
The generation of an EvidenceRecord overall can be described as follows:
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 a simple Archive Time-Stamp without building hash-trees and reducing them. Details of local generation procedure are not to be discussed in this specification.
The Verification of an EvidenceRecord overall can be described as follows:
| TOC |
An Archive Time-Stamp is a time-stamp and some lists of hash values, which allow verification of the existence of a data object or a data object group at a certain time. The lists of hash values can be generated by reduction of an ordered Merkle hash-tree [Mer1980]. The leaves of this hash-tree are the hash values of the data objects to be time-stamped. Every inner node of the tree contains one hash value, which is generated by hashing the concatenation of the children nodes. The root hash value, which represents unambiguously all data objects, is time-stamped.
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 must be used. If time-stamps according to [RFC3161] are used, the content of this field must be identical to hashAlgorithm of messageImprint-Field of timeStampToken.
reducedHashtree contains lists of hash values, which could be derived from a hash-tree by reduction to nodes necessary for verification of a single data object. Hash values are represented as octet strings. If the optional field reducedHashtree is not existent the Archive Time-Stamp is equal to the ordinary time-stamp.
timeStamp should contain the time-stamp 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.
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:
An example of a constructed hash tree for 3 data groups, where data group 1 and 3 only contain one document, and data group 2 contains 3 documents:
+------+
| h123 |
+------+
/ \
/ \
+----+ +----+
| h12| | h3 |
+----+ +----+
/ \
/ \
+----+ +-------+
| h1 | | h2abc |
+----+ +-------+
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
| h2a| | h2b| | h2c|
+----+ +----+ +----+
Figure 1: Hash-tree
h1 = H(d1) where d1 is the only data object in data group 1 h3 = H(d3) where d3 is the only data object in data group 3 h12 = H( binary sorted and concatenated (h1, h2abc)) h123 = H( binary sorted and concatenated (h12, h3)) h2a = H(first data object of data object group 2) h2b = H(second data object of data object group 2) h2c = H(third data object of data object group 2) h2abc = H( binary sorted and concatenated (h2a, h2b, h2c))
The hash-tree can be reduced to lists of hash values, necessary to have a proof of existence for a single data object:
Assuming that the sorted binary ordering of the hashes in Figure 1 is: h2abc < h1 then the reduced hash-tree for data group 1 (d1) is:
+--------------------------------+ | +----------------+ +--------+ | | | +------+ +----+ | | +----+ | | | | h2abc| | h1 | | | | h3 | | | | +------+ +----+ | | +----+ | | +----------------+ +--------+ | +--------------------------------+
Figure 2: Reduced hash-tree for data group 1
The pseudo ASN1 for this reduced hash-tree would look like:
rht1 = SEQ( SEQ (h2abc, h1), SEQ (h3))
Assuming the same hashtree as in figure 1 the reduced hash-tree for all data objects in data group 2 is identical.
+-------------------------------------------------+ | +----------------------+ +--------+ +--------+ | | | +----+ +----+ +----+ | | +----+ | | +----+ | | | | | h2b| | h2c| | h2a| | | | h1 | | | | h3 | | | | | +----+ +----+ +----+ | | +----+ | | +----+ | | | +----------------------+ +--------+ +--------+ | +-------------------------------------------------+
Figure 3: Reduced hash-tree for data object group 2
The pseudo ASN1 for this reduced hash-tree would look like:
rht2 = SEQ( SEQ (h2b, h2c, h2a), SEQ (h1), SEQ (h3))
Note, there are no restrictions to the quantity of hash value lists
and of their length. Also note, that it is profitable but not
required to build hash-trees and reduce them. An Archive Time-Stamp
may consist only of one list of hash-values and a time-stamp or
in the extreme case, only a time-stamp with no hash value lists.
The certificates, CRLS or OCSP-Responses needed to verify the
time-stamp SHOULD be stored in the time-stamp itself. A time-stamp
according to [RFC 3161] is a CMS-object in which certificates can be
stored in the certificates field and CRLs can be stored in the crls
field of signed data. OCSP responses can be stored as unsigned
attributes [RFC3126].
An Archive Time-Stamp shall prove that a data object existed at a certain time, given by time-stamp. This can be verified as follows:
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.
| TOC |
Archive Time-Stamps are used for archive time-stamping. An Archive
Time-Stamp proves the existence of single data objects or data
object group at a certain time. However, this first Archive
Time-Stamp in the first ArchiveTimeStampChain can become invalid, if hash algorithms or public key
algorithms used in its hash-tree or time-stamp become weak or if the
validity period of the time-stamp certificates expires or if the
time-stamp certificates are revoked.
If this is going to happen, the existence of the Archive Time-Stamp or
archive time-stamped data has to be reassured, which can be done by
creating new Archive Time-Stamps. Depending on whether the time-stamp
becomes invalid or the hash algorithm of the hash-tree becomes weak,
two kinds of Archive Time-Stamp renewals are possible:
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 hash-trees and reducedHashtrees of the contained ArchiveTimeStamps MUST use the same Hash-Algorithm.
A first Initial Archive Time-Stamp relates to a data object or a data object group. The application or the policy included in the LTANS Long term Archiving Protocol (to be specified) dictate when an Initial Archive Time-Stamp must be generated for each data object.
Before cryptographic algorithms used within the Archive Time-Stamp become weak or time-stamp certificates are invalidated, Archive Time-Stamps have to be renewed by generating a new Archive Time-Stamp.
In the case of Time-Stamp Renewal the content of the timeStamp field of the old Archive Time-Stamp has to be hashed and time-stamped by a new Archive Time-Stamp. The new Archive Time-Stamp must use the same hash algorithm within its hash-tree as the old 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:
+-------+
| h123' |
+-------+
/ \
/ \
+-----+ +----+
| h12'| | h3'|
+-----+ +----+
/ \
/ \
+----+ +--------+
| h1'| | h2abc' |
+----+ +--------+
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|h2a'| |h2b'| |h2c'|
+----+ +----+ +----+
Figure 4: Hash-tree from hash-tree renewal
Let H be the new secure hash algorithm
ha(1), ha(2), ha(3) are as defined in step 4 above
h1' = H( binary sorted and concatenated (H(d1), ha(1)))
d1 is the original document from data group 1
h3' = H( binary sorted and concatenated (H(d3), ha(3)))
d3 is the original document from data group 3
h2a = H(first data object of data object group 2)
...
h2c = H(third data object of data object group 2)
h2a' = H( binary sorted and concatenated (h2a, ha(2)))
...
h2c' = H( binary sorted and concatenated (h2c, ha(2)))
h2abc = H( binary sorted and concatenated (h2a', h2b', h2c'))
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 to be on the secure side. Nevertheless ArchiveTimeStamps, which are not necessary for verification, should not be added to ArchiveTimeStampChain or ArchiveTimeStampSequence.
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:
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.
| TOC |
If service providers are used to archive data and generate Archive Time-Stamps, it might be desirable or required that clients only send encrypted data to be archived. However, this means that evidence 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:
This specification defines an optional data field to store the needed parameters of the used encryption methods. One possible encryption method is specified. Further encryption methods may be defined in other specifications.
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 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 CMS-Standard using key transport technique with RSA public key encryption:
id-EncryptionCMS_encryptedmessage ::= {id-ATS-1}
CMS_encryption_params::= SEQUENCE {
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.
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 [RFC3852]. 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 verification 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.
If the EncryptionMethod field is used, verification of Archive-Time-Stamps requires two additional steps:
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:
| TOC |
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
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}
id-EncryptionCMS_encryptedmessage ::= {id-ATS-1}
CMS_encryption_params::= SEQUENCE {
encryptionCover ContentInfo,
publicKey BIT STRING OPTIONAL,
params CHOICE {
[0] privateKey BIT STRING,
[1] encryptionKeyRan 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
| TOC |
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 Time Stamping Authorities stated in security policies have to be met. Renewed Archive Time-Stamps should have the same or higher quality as the Initial Archive Time-Stamp. Archive Time-Stamps used for signature renewal of signed data, should have the same or higher quality than maximum quality of the signatures.
Secure Encryption
For non-repudiation proof it does not matter, whether encryption has been broken or not. Nevertheless, users should keep secret their private keys and randoms used for encryption and disclose them only if needed (e.g. in a lawsuit to a judge or expert). They should use encryption algorithms and parameters which are prospected to be unbreakable as long as confidentiality of the archived data is important.
| TOC |
| TOC |
| [RFC2026] | Bradner, S., “The Internet Standards Process -- Revision 3,” RFC 2026, 1996. |
| [RFC2119] | Bradner, S., “Key Words for Use in RFCs to Indicate Requirement Levels,” RFC 2119, 1997. |
| [RFC3126] | Adams, C., Pinkas, D., Ross, J., and N. Pope, “Electronic Signature Formats for long term electronic signatures,” RFC 3126, 2001. |
| [RFC3161] | Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),” RFC 3161, August 2001. |
| [RFC3852] | Housley, R., “Cryptographic Message Syntax (CMS),” RFC 3852, July 2004. |
| TOC |
| [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, March 2003. |
| [Mer1980] | Merkle, R., “Protocols for Public Key Cryptosystems, Proceedings of the 1980 IEEE Symposium on Security and Privacy (Oakland, CA, USA),” pages 122-134, April 1980. |
| [REQ2004] | Wallace, C., Brandner, R., and U. Pordesch, “Long-term Archive Service Requirements,” I-D ???, 2005. |
| TOC |
| Ralf Brandner | |
| InterComponentWare AG | |
| Otto-Hahn-Str. 3 | |
| Walldorf D-69119 | |
| Germany | |
| Email: | ralf.brandner@intercomponentware.com |
| Ulrich Pordesch | |
| Fraunhofer Gesellschaft | |
| Dolivostrasse 15 | |
| Darmstadt D-64293 | |
| Germany | |
| Email: | ulrich.pordesch@zv.fraunhofer.de |
| Tobias Gondrom | |
| Open Text Corporation | |
| Technopark 2 | |
| Werner-von-Siemens-Ring 20 | |
| Grasbrunn, Munich D-85630 | |
| Germany | |
| Phone: | +49 (0) 89 4629-1816 |
| Fax: | +49 (0) 89 4629-33-1816 |
| Email: | tobias.gondrom@opentext.com |
| TOC |
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:
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.
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:
| TOC |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright © The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.