RFC 4998
Evidence Record Syntax (ERS)
RFC 4998: Evidence Record Syntax (ERS) 🦋
Okay bestie, here's the paperwork ✨ This is RFC 4998, called Evidence Record Syntax (ERS). It was published in August 2007 through the Network Working Group, and it's on the Standards Track. The authors are T. Gondrom from Open Text Corporation, R. Brandner from InterComponentWare AG, and U. Pordesch from Fraunhofer Gesellschaft. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🎀
Status of This Memo
Okay so this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Copyright Notice
Copyright (C) The IETF Trust (2007). 🔥
Abstract
Lots of situations need people to prove that data exists and hasn't been messed with, including digitally signed data, in a common and reproducible way, over a long and maybe unknowable stretch of time 💅 This document defines the syntax and processing of an Evidence Record, a structure built to support long-term non-repudiation of existence of data. It's giving reliability over the long haul ✨
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. General Overview and Requirements . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Conventions Used in This Document . . . . . . . . . . . . 6
2. Identification and References . . . . . . . . . . . . . . . . 7
2.1. ASN.1 Module Definition . . . . . . . . . . . . . . . . . 7
2.1.1. ASN.1 Module Definition for 1988 ASN.1 Syntax . . . . 7
2.1.2. ASN.1 Module Definition for 1997-ASN.1 Syntax . . . . 7
2.2. ASN.1 Imports and Exports . . . . . . . . . . . . . . . . 7
2.2.1. Imports and Exports Conform with 1988 ASN.1 . . . . . 8
2.2.2. Imports and Exports Conform with 1997-ASN.1 . . . . . 8
2.3. LTANS Identification . . . . . . . . . . . . . . . . . . . 9
3. Evidence Record . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 11
4. Archive Timestamp . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 15
5. Archive Timestamp Chain and Archive Timestamp Sequence . . . . 16
5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Generation . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Verification . . . . . . . . . . . . . . . . . . . . . . . 19
6. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1. EncryptionInfo in 1988 ASN.1 . . . . . . . . . . . . . 21
6.1.2. EncryptionInfo in 1997-ASN.1 . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Evidence Record Using CMS . . . . . . . . . . . . . . 26
Appendix B. ASN.1-Module with 1988 Syntax . . . . . . . . . . . . 27
Appendix C. ASN.1-Module with 1997 Syntax . . . . . . . . . . . . 291. Introduction ✨
1.1. Motivation 💭
So in tons of electronic data exchange situations, a non-repudiable proof that digital data exists must be possible 🙈 Sometimes that proof has to survive really long periods of time. A big example is digitally signed data. Digital signatures can show data integrity and do source authentication. Sometimes digitally signed data has to be archived for 30 years or more, and that's a long time, bestie 😭 Reliability of digital signatures over long periods is not absolute. During the archival period, hash algorithms and public key algorithms can get weak, or certificates can become invalid. Those events make it harder to rely on digitally signed data after many years, because forgeries become more likely to be created. To keep the security properties that digital signatures give you, it's necessary to prove the digitally signed data already existed before that critical event. A timestamp can do this. The catch is that some timestamps rely on mechanisms that will hit the same problems 💀 So to counter that, timestamps get renewed by simply grabbing a new timestamp that covers the original data and its timestamps, done before the mechanisms used to make the timestamps get compromised. This document gives you a syntax that supports that periodic renewal of timestamps 🦋
Okay, second part. To verify and communicate preservation evidence, it's necessary to standardize the data formats and processing procedures for these timestamps. The IETF made a first try in [RFC3126], where an optional Archive Timestamp Attribute was specified for integration into signatures under the Cryptographic Messages Syntax (CMS) [RFC3852]. ERS takes that idea and broadens and generalizes it for data of any format 🌸 It also takes long-term archive service requirements [RFC4810] into account, especially handling large sets of data objects. ERS specifies a syntax for an EvidenceRecord, which holds a set of Archive Timestamps plus some additional data. This Evidence Record can be stored separately from the archived data, as a file, or it can be integrated into the archived data, meaning as an attribute. ERS also specifies processes for generating and verifying Evidence Records. Appendix A describes how to integrate and use an EvidenceRecord with signed and enveloped messages under the Cryptographic Message Syntax (CMS). Heads up, though: ERS does not specify a protocol for interacting with a long-term archive system. The Long-term Archive Protocol specification, being developed by the IETF LTANS WG, covers that interface 🧚
1.2. General Overview and Requirements 🧚
ERS is designed to meet the requirements for data structures set forth in [RFC4810]. It's giving intentional design 👑
The basis of ERS is Archive Timestamps. An Archive Timestamp can cover a single data object, like an RFC3161 compliant timestamp does, or it can cover a group of data objects. Groups of data objects are handled using hash trees, first described by Merkle [MER1980], combined with a timestamp. The leaves of the hash tree are hash values of the data objects in a group. Only the root hash of the hash tree gets a timestamp requested. Deleting a data object from the tree does not affect the provability of the others, which is so iconic 💖 For any particular data object, the hash tree can be reduced to a few sets of hash values, and those are enough to prove the existence of that single data object. Similarly, the hash tree can be reduced to prove the existence of a data group, as long as all members of the data group have the same parent node in the hash tree. Archive Timestamps are made up of an optional reduced hash tree and a timestamp 🍓
An EvidenceRecord may contain many Archive Timestamps. To generate the initial Archive Timestamp, you first have to figure out which data objects get timestamped. Depending on context, that could be a file, or a data object group made of multiple files, like a document and its associated digital signature 📄
Before the cryptographic algorithms used in the Archive Timestamp become weak, or the timestamp certificates become invalid, Archive Timestamps have to be renewed by generating a new Archive Timestamp. (Note: Info about the weakening of the security properties of public key and hash algorithms, plus the risk of compromise of private keys of Time Stamping Units, has to be closely watched by the Long-Term Archive provider or the owner of the data objects themselves. This info should be gathered by "out-of-band" means and is out of scope of this document.) ERS distinguishes two ways to renew an Archive Timestamp: Timestamp Renewal and Hash-Tree Renewal 🔥
Which kind of renewal you need depends on the conditions. The timestamp renewal is necessary if the private key of a Timestamping Unit has been compromised, or if an asymmetric algorithm or a hash algorithm used to generate the timestamps is no longer secure for the given key size. If the hash algorithm used to build the hash trees in the Archive Timestamp loses its security properties, then Hash-Tree Renewal is required. ⚠️
In the case of Timestamp Renewal, the timestamp of an Archive Timestamp has to be hashed and timestamped by a new Archive Timestamp. This mode of renewal can only be used when it's not necessary to access the archived data objects covered by the timestamp. For example, this simple form of renewal is enough if the public key algorithm of the timestamp is going to lose its security, or if the timestamp authority certificate is about to expire. It's very efficient, especially if Archive Timestamping is done by an archiving system or service that does central management of Archive Timestamps 🌈
Timestamp renewal is not enough if the hash algorithm used to build the hash tree of an Archive Timestamp becomes insecure. In the case of Hash-Tree Renewal, all evidence data must be accessed and timestamped. That includes not only the timestamps but also the complete Archive Timestamps and the archived data objects covered by the timestamps, which must be hashed and timestamped again by a new Archive Timestamp 💅
(part 1 of 6, more coming bestie 🫶)
1.3. Terminology ✨
Okay, glossary time, bestie 📚💅 These are the words the rest of the spec leans on, so let's get them straight.
Archived data object: a data unit that gets archived and has to be preserved for a long time by the Long-term Archive Service 🗃️
Archived data object group: two or more data objects that belong together for some reason. For example, a document file and a signature file could form an archived data object group, since together they represent signed data ✍️
Archive Timestamp: a timestamp plus, typically, lists of hash values, which let you verify that several data objects existed at a certain time ⏰ (In its simplest form, when it covers only one object, it may consist of just the timestamp.)
Archive Timestamp Chain: part of an Archive Timestamp Sequence. It's a time-ordered sequence of Archive Timestamps, and each one preserves non-repudiation of the previous Archive Timestamp, even after that previous one becomes invalid 🔗 Overall non-repudiation holds until the new Archive Timestamp itself becomes invalid. Generating one of these chains is called Timestamp Renewal 🔄
Archive Timestamp Sequence: part of the Evidence Record. It's a sequence of Archive Timestamp Chains, where each chain preserves non-repudiation of the previous chains, even after the hash algorithm used within the previous Archive Timestamp's hash tree has become weak 🫶 Non-repudiation holds until the last Archive Timestamp of the last chain becomes invalid. Generating one of these sequences is called Hash-Tree Renewal 🌳
Evidence: information that may be used to resolve a dispute about various aspects of the authenticity of archived data objects 🕵️♀️
Evidence record: a collection of evidence compiled for one or more given archived data objects over time 📦 An evidence record includes all Archive Timestamps (within the structures of Archive Timestamp Chains and Archive Timestamp Sequences) plus additional verification data, like certificates, revocation information, trust anchors, policy details, role information, etc. 🎀
Long-term Archive (LTA) Service: a service responsible for preserving data for long periods of time, including generating and collecting evidence, storing archived data objects and evidence, and so on 🏛️
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 🌸
Timestamp: a cryptographically secure confirmation generated by a Time Stamping Authority (TSA). [RFC3161] specifies a structure for timestamps and a protocol for communicating with a TSA 💌 Besides this, other data structures and protocols may also be appropriate, e.g., such as those defined in [ISO-18014-1.2002], [ISO-18014-2.2002], [ISO-18014-3.2004], and [ANSI.X9-95.2005] 🧚
Now for the relationship rules, which are the fiddly bit, so read slowly 👀
An Archive Timestamp relates to a data object if the hash value of that data object is part of the first hash value list of the Archive Timestamp. An Archive Timestamp relates to a data object group if it relates to every data object of the group and no other data objects 🧩 An Archive Timestamp Chain relates to a data object or data object group if its first Archive Timestamp relates to that data object or group. An Archive Timestamp Sequence relates to a data object or data object group if its first Archive Timestamp Chain relates to that data object or group 💜
1.4. Conventions Used in This Document 🎀
Here's the important bit: 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] 📜 They're capitalised on purpose, so keep an eye out for them 👑
2. Identification and References 🪪
2.1. ASN.1 Module Definition 🧾
Many open ASN.1 compilers still support the 1988 syntax, so this standard offers support for two versions of ASN.1: 1997-ASN.1 and 1988-ASN.1 🕰️ (For the specification of ASN.1, refer to [CCITT.X208.1988], [CCITT.X209.1988], [CCITT.X680.2002] and [CCITT.X690.2002].) This specification defines two ASN.1 modules: one for 1988-conformant ASN.1 and another in 1997-ASN.1 syntax. Depending on the syntax version your compiler uses, you can use the imports for the 1988-conformant syntax or the imports for the 1997-ASN.1 syntax. The appendix of this document lists the two complete alternative ASN.1 modules. If there is a conflict between both modules, the 1988-ASN.1 module takes precedence 🥇
2.1.1. ASN.1 Module Definition for 1988 ASN.1 Syntax 🌙
1988 ASN.1 Module start
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers88(2) id-mod-ers88-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN2.1.2. ASN.1 Module Definition for 1997-ASN.1 Syntax ☀️
ASN.1 Module start
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers(1) id-mod-ers-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN2.2. ASN.1 Imports and Exports 📥📤
The specification exports all definitions and imports various definitions 🎁 Depending on the ASN.1 syntax version your implementation uses, you can use the imports for 1988-conformant ASN.1 syntax below, or the imports for the 1997-ASN.1 syntax in Section 2.2.2 💅
2.2.1. Imports and Exports Conform with 1988 ASN.1 🫧
-- EXPORTS ALL --
IMPORTS
-- Imports from RFC 3852 Cryptographic Message Syntax
ContentInfo, Attribute
FROM CryptographicMessageSyntax2004 -- FROM [RFC3852]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
-- Imports from RFC 3280 [RFC3280], Appendix A.1
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
;2.2.2. Imports and Exports Conform with 1997-ASN.1 🌷
-- EXPORTS ALL --
IMPORTS
-- Imports from PKCS-7
ContentInfo
FROM PKCS7
{iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-7(7) modules(0)}
-- Imports from AuthenticationFramework
AlgorithmIdentifier
FROM AuthenticationFramework
{joint-iso-itu-t ds(5) module(1)
authenticationFramework(7) 4}
-- Imports from InformationFramework
Attribute
FROM InformationFramework
{joint-iso-itu-t ds(5) module(1)
informationFramework(1) 4}
;2.3. LTANS Identification 🆔
This document defines the LTANS object identifier tree root 🌳
LTANS Object Identifier tree root
ltans OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) }3. Evidence Record 🦋
An Evidence Record is a unit of data that can be used to prove the existence of an archived data object or an archived data object group at a certain time ⏳ It contains Archive Timestamps, generated during a long archival period, plus possibly useful data for validation 🧠 You can store this Evidence Record separately from the archived data objects, or integrate it into the data itself 🗂️ For data types, signed data and enveloped data of the CMS integration are specified in Appendix A 💖
3.1. Syntax 🍓
The Evidence Record has the following ASN.1 syntax:
ASN.1 Evidence Record
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) } ,
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryptionInfo [1] EncryptionInfo OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence
}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF AttributeHere's what each field means 👀
The 'version' field indicates the syntax version. It's there for compatibility with future revisions of this specification, and to tell it apart from earlier non-conformant or proprietary versions of the ERS 🔖 The value 1 indicates this specification. Lower values indicate that an earlier version of the ERS has been used. An implementation conforming to this specification SHOULD reject a version value below 1 🚫
'digestAlgorithms' is a sequence of all the hash algorithms used to hash the data object over the archival period. It's the union of all digestAlgorithm values from the ArchiveTimestamps contained in the EvidenceRecord. The ordering of the values is not relevant 🔀
'cryptoInfos' allows the storage of data useful in validating the archiveTimeStampSequence. This could include possible Trust Anchors, certificates, revocation information, or the current definition of the suitability of cryptographic algorithms, past and present (e.g., RSA 768-bit valid until 1998, RSA 1024-bit 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 timestamp, the data should be verifiable through other mechanisms. Such verification is out of scope of this document 🙈
'encryptionInfo' contains the necessary information to support encrypted content being handled. For discussion of syntax, please refer to Section 6.1 🔐
'ArchiveTimeStampSequence' is a sequence of ArchiveTimeStampChain, described in Section 5 🔗
If the archive data objects were encrypted before Archive Timestamps were generated, but a non-repudiation proof is needed for the unencrypted data objects, the optional encryptionInfos field contains the data necessary to unambiguously re-encrypt the data objects 🪄 If it's omitted, the data objects are either not encrypted, or a non-repudiation proof for the unencrypted data isn't required. For further details, see Section 6 💫
3.2. Generation 🛠️
The generation of an EvidenceRecord can be described as follows:
- Select a data object or group of data objects to archive.
- Create the initial Archive Timestamp (see Section 4, "Archive Timestamp").
- Refresh the Archive Timestamp when necessary, by Timestamp Renewal or Hash-Tree Renewal (see Section 5).
The process of generation depends on whether the Archive Timestamps are generated, stored, and managed by a centralised instance 🏢 With central management, it's possible to collect many data objects, build hash trees, store them, and reduce them later 🌲 With local generation, it might be easier to generate a simple Archive Timestamp without building hash trees. You can do this by omitting the reducedHashtree field from the ArchiveTimestamp. In this case, the ArchiveTimestamp covers a single data object. Using this approach, it's possible to "convert" existing timestamps into ArchiveTimestamps for renewal 🔁
3.3. Verification ✅
The verification of an EvidenceRecord overall can be described as follows:
- Select an archived data object or group of data objects
- Re-encrypt the data object or data object group, if the encryption field is used (for details, see Section 6).
- Verify the Archive Timestamp Sequence (details in Section 4 and Section 5).
4. Archive Timestamp ✨
Okay bestie, an Archive Timestamp is a timestamp AND a set of lists of hash values 🦋 Those lists come from reducing an ordered Merkle hash tree [MER1980]. The leaves are the hash values of the data objects you want to timestamp. Every inner node holds one hash value, made by hashing the concatenation of its children nodes. The root hash value represents all the data objects unambiguously, and that root is what gets timestamped. It's giving tree energy 🌳💅
4.1. Syntax
An Archive Timestamp has the following ASN.1 Syntax 📝
ASN.1 Archive Timestamp
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
attributes [1] Attributes OPTIONAL,
reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
timeStamp ContentInfo}
PartialHashtree ::= SEQUENCE OF OCTET STRING
Attributes ::= SET SIZE (1..MAX) OF AttributeThe fields of type ArchiveTimeStamp have these meanings, so pay attention 👀
digestAlgorithm tells you 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 timestamp MUST be used. Which means, if timestamps according to [RFC3161] are used in this case, the content of this field is identical to hashAlgorithm of messageImprint field of TSTInfo 🎀
attributes holds info an LTA might want to provide to document individual renewal steps and the creation of the individual ArchiveTimeStamps, e.g., applied policies 📋 Since the structure of the ArchiveTimeStamp may be protected by hash and timestamps, the ordering matters. That's why a SET is used instead of a SEQUENCE. Main character ordering energy 👑
reducedHashtree contains lists of hash values, organized in PartialHashtrees so they're easier to understand 🧚 They can be derived by reducing a hash tree down to the nodes you need to verify a single data object. Hash values are represented as octet strings. If the optional field reducedHashtree is not present, the ArchiveTimestamp simply contains an ordinary timestamp 🍓
timeStamp should contain the timestamp as defined in Section 1.3. (e.g., as defined with TimeStampToken in [RFC3161]). Other types of timestamp MAY be used, as long as they contain time data, timestamped data, and a cryptographically secure confirmation from the TSA of these data 🌈
4.2. Generation
The lists of hash values of an Archive Timestamp can be generated by building and reducing a Merkle hash tree [MER1980] 🌸
Here's how you build one, step by step 🫶
- Collect the data objects to be timestamped.
- Choose a secure hash algorithm H and generate hash values for the data objects. These values become the leaves of the hash tree.
- For each data group containing more than one document, its respective document hashes are binary sorted in ascending order, concatenated, and hashed. The hash values are the complete output from the hash algorithm, i.e., leading zeros are not removed, with the most significant bit first.
- If there is more than one hash value, place them in groups and sort each group in binary ascending order. Concatenate these values and generate new hash values, which are inner nodes of this tree. (If additional hash values are needed, e.g., so that all nodes have the same number of children, any data may be hashed using H and used.) Repeat this step until there is only one hash value, which is the root node of the hash tree.
- Obtain a timestamp for this root hash value. The hash algorithm in the timestamp request MUST be the same as the hash algorithm of the hash tree, or the digestAlgorithm field of the ArchiveTimeStamp MUST be present and specify the hash algorithm of the hash tree. 🔥
Here's an example hash tree for 3 data groups, where data groups 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, which are what you need to prove a single data object exists 🕵️♀️
- Generate hash value h of the data object, using hash algorithm H of the hash tree.
- Select all hash values which have the same father node as h. Generate the first list of hash values by arranging these hashes in binary ascending order. This gets stored in the structure of the PartialHashtree. Repeat this step for the father node of all hashes until the root hash is reached. The father nodes themselves are not saved in the hash lists -- they are computable. 🧠
- The list of all partialHashtrees finally is the reducedHashtree. (All of the specified hash values under the same father node, except the father node of the nodes below, are grouped in a PartialHashtree. The sequence list of all Partialhashtrees is the reducedHashtree.) 💖
- Finally, add the timestamp and the info about the hash algorithm to get an Archive Timestamp. ✨
Assuming the sorted binary ordering of the hashes in Figure 1 is: h2abc < h1, 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 rht1 would look like:
rht1 = SEQ(pht1, pht2)
with the PartialHashtrees pht1 and pht2
pht1 = SEQ (h2abc, h1)
pht2 = SEQ (h3)Assuming the same hash tree as in Figure 1, the reduced hash tree for all data objects in data group 2 is identical. 👯♀️
+-------------------------------------------------+
| +----------------------+ +--------+ +--------+ |
| | +----+ +----+ +----+ | | +----+ | | +----+ | |
| | | h2b| | h2c| | h2a| | | | h1 | | | | h3 | | |
| | +----+ +----+ +----+ | | +----+ | | +----+ | |
| +----------------------+ +--------+ +--------+ |
+-------------------------------------------------+Figure 3: Reduced hash tree for data object group 2
The pseudo ASN1 for this reduced hash tree would look like:
rht2 = SEQ(pht3, pht4, pht5)
with the PartialHashtrees pht3, pht4, and pht5
pht3 = SEQ (h2b, h2c, h2a)
pht4 = SEQ (h1)
pht5 = SEQ (h3)Note there are no restrictions on the quantity or length of hash-value lists. Also note that it is profitable but not required to build hash trees and reduce them. An Archive Timestamp may consist only of one list of hash values and a timestamp, or only a timestamp with no hash value lists 🦋
The data (e.g. certificates, Certificate Revocation Lists (CRLs), or Online Certificate Status Protocol (OCSP) responses) needed to verify the timestamp MUST be preserved, and SHOULD be stored in the timestamp itself unless this causes unnecessary duplication. A timestamp according to [RFC3161] is a CMS object in which certificates can be stored in the certificates field and CRLs can be stored in the crls field of signed data. OCSP responses can be stored as unsigned attributes [RFC3126]. Note [ANSI.X9-95.2005], [ISO-18014-2.2002], and [ISO-18014-3.2004], which specify verifiable timestamps that do not depend on certificates, CRLs, or OCSP responses 📜🌷
4.3. Verification
An Archive Timestamp shall prove that a data object existed at a certain time, given by timestamp. Here's how you check it 🔍
- Calculate hash value h of the data object with hash algorithm H given in field digestAlgorithm of the Archive Timestamp.
- Search for hash value h in the first list (partialHashtree) of reducedHashtree. If it's not present, terminate verification process with negative result. 🙅♀️
- Concatenate the hash values of the actual list (partialHashtree) of hash values in binary ascending order and calculate the hash value h' with algorithm H. This hash value h' MUST become a member of the next higher list of hash values (from the next partialHashtree). Continue step 3 until a root hash value is calculated. 🌀
- Check timestamp. In case of a timestamp according to [RFC3161], the root hash value must correspond to hashedMessage, and digestAlgorithm must correspond to hashAlgorithm field, both in messageImprint field of timeStampToken. In case of other timestamp formats, the hash value and digestAlgorithm must also correspond to their equivalent fields if they exist. ✅
If a 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 Timestamp 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. 🫶
5. Archive Timestamp Chain and Archive Timestamp Sequence
An Archive Timestamp proves the existence of single data objects or data object groups at a certain time. However, this first Archive Timestamp in the first ArchiveTimeStampChain can become invalid, if hash algorithms or public key algorithms used in its hash tree or timestamp become weak, or if the validity period of the timestamp authority certificate expires or is revoked 😱
Before that happens, the existence of the Archive Timestamp or archive timestamped data has to be reassured. This can be done by creating a new Archive Timestamp. Depending on whether the timestamp becomes invalid or the hash algorithm of the hash tree becomes weak, two kinds of Archive Timestamp renewal are possible 🔄
- Timestamp Renewal: A new Archive Timestamp is generated, which covers the timestamp of the old one. One or more Archive Timestamps generated by Timestamp Renewal yield an Archive Timestamp Chain for a data object or data object group. 🎀
- Hash-Tree Renewal: A new Archive Timestamp is generated, which covers all the old Archive Timestamps as well as the data objects. A new Archive Timestamp Chain is started. One or more Archive Timestamp Chains for a data object or data object group yield an Archive Timestamp Sequence. 🌈
After the renewal, always only the last (i.e., most recent) ArchiveTimeStamp and the algorithms and timestamps used by it must be watched regarding expiration and loss of security. Keep an eye on that one, bestie 👀💜
5.1. Syntax
okay bestie, the syntax is actually giving simple 💅 An ArchiveTimeStampChain is a SEQUENCE OF ArchiveTimeStamp, and an ArchiveTimeStampSequence is a SEQUENCE OF those chains. Here's the ASN.1:
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF
ArchiveTimeStampChainTwo rules you cannot skip 🫶 Chains and sequences MUST be ordered ascending by time of timestamp. And inside one ArchiveTimeStampChain, every reducedHashtree in the contained ArchiveTimeStamps MUST use the same Hash-Algorithm. no cap, order and algorithm consistency is non-negotiable 😭
5.2. Generation
The initial Archive Timestamp is the one that covers a data object or a data object group 🦋 Then, before the crypto algorithms used in the most recent Archive Timestamp (which is the initial one at the start) become weak, or their timestamp certificates become invalid, you have to renew the Archive Timestamps by generating a new one. Renewal is a whole thing, so let's break it down.
Timestamp Renewal: the content of the timeStamp field of the old Archive Timestamp has to be hashed and timestamped by a new Archive Timestamp. The new one MAY not contain a reducedHashtree field, if the timestamp only simply covers the previous timestamp 🌸 Generally though, you can collect a bunch of old Archive Timestamps and build the new hash tree with the hash values of their timeStamp field contents, which is lowkey the move.
The new Archive Timestamp MUST be added to the ArchiveTimestampChain. Its hash tree MUST use the same hash algorithm as the old one, which is specified in the digestAlgorithm field of the Archive Timestamp or, if that value isn't set (it's optional), within the timestamp itself ✨
Hash-Tree Renewal: here the Archive Timestamp and the archived data objects it covers have to be hashed and timestamped again. Follow these steps, bestie 🧚
- Select a secure hash algorithm H.
- Select the data objects d(i) referred to by the initial Archive Timestamp (objects that are still present and not deleted). Generate hash values
h(i) = H((d(i)). If data groups with more than one document are present, then one group has more than one hash, i.e.,h(i_a),h(i_b)..h(i_n). atsc(i)is the encoded ArchiveTimeStampSequence, which is the concatenation of all previous Archive Timestamp Chains (in chronological order) related to data objectd(i). Generate the hash valueha(i) = H(atsc(i)). Note: The ArchiveTimeStampChains used are DER encoded, i.e., they contain sequence and length tags 🎀- Concatenate each
h(i)withha(i)and generate the hash valuesh(i)' = H (h(i)+ ha(i)). For multi-document groups, this ish(i_a)' = H (h(i_a)+ ha(i))andh(i_b)' = H (h(i_b)+ ha(i)), etc. - Build a new Archive Time Stamp for each
h(i)'. Hash-tree generation and reduction is defined in Section 4.2, and eachh(i)'gets treated there as the document hash 👑 The first hash value list in the reduced hash tree should only containh(i)'. For a multi-document group, the first hash value list contains the new hashes for all the documents in that group, i.e.,h(i_a)',h(i_b)'..h(i_n)'. - Create a new ArchiveTimeStampChain containing the new Archive Timestamp, and append this ArchiveTimeStampChain to the ArchiveTimeStampSequence.
Here's the hash tree, it's giving art 🌈
+-------+
| h123' |
+-------+
/ \
/ \
+-----+ +----+
| h12'| | h3'|
+-----+ +----+
/ \
/ \
+----+ +--------+
| h1'| | h2abc' |
+----+ +--------+
/ | \
/ | \
/ | \
/ | \
+----+ +----+ +----+
|h2a'| |h2b'| |h2c'|
+----+ +----+ +----+Figure 4: Hash tree from Hash-Tree Renewal
And here are the actual calculations for that tree 🔥
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'))ArchiveTimeStamps that are not necessary for verification should not be added to an ArchiveTimeStampChain or ArchiveTimeStampSequence. Keep your chains lean, bestie 🍓
5.3. Verification
So you want a non-repudiation proof that a data object existed at a certain time? 🧐 Then the Archive Timestamp Chains, and how they relate to each other and to the data objects, have to be proved:
- Verify that the first Archive Timestamp of the first ArchiveTimestampChain (the initial Archive Timestamp) contains the hash value of the data object.
- Verify each ArchiveTimestampChain. The first hash value list of each ArchiveTimeStamp MUST contain the hash value of the timestamp of the Archive Timestamp before it. Each Archive Timestamp MUST be valid relative to the time of the following Archive Timestamp. All Archive Timestamps within a chain MUST use the same hash algorithm, and this algorithm MUST be secure at the time of the first Archive Timestamp of the following ArchiveTimeStampChain 💜
- Verify that the first hash value list (partialHashtree) of the first Archive Timestamp of all other ArchiveTimeStampChains contains a hash value of the concatenation of the data object hash and the hash value of all older ArchiveTimeStampChains. Verify that this Archive Timestamp was generated before the last Archive Timestamp of the ArchiveTimeStampChain became invalid ⭐
To finish the non-repudiation proof for the data objects, the last Archive Timestamp has to be valid at the time the verification is performed 🦋
If the proof is needed for more than one data object, steps 1 and 3 have to be done for all of them. To prove that the Archive Timestamp Sequence relates to a data object group, verify that the first Archive Timestamp of the first ArchiveTimeStampChain of the ArchiveTimeStampSequence of each data object does not contain other hash values in its first hash value list (other than the hash values of the other data objects) ✨
6. Encryption ✨
Okay, this one's a bit spicy 🌶️ If service providers are used to archive data and generate Archive Timestamps, it might be desirable or even required that clients only send encrypted data to be archived. But that means evidence records refer to encrypted data objects. ERS directly protects the integrity of the bit-stream, and that freezes the bit structure at the time of archiving. So you can't change the encryption scheme during the archival period. If the encryption scheme stops being secure, a change isn't possible without losing the integrity proof of the EvidenceRecord 😭 In those cases, a data transformation (and so possibly re-encryption) done by a notary service might be a possible solution. To keep things smooth when you use evidence records in the future, a few extra precautions have to be taken:
- Evidence generated to prove the existence of encrypted data cannot always be relied upon to prove the existence of unencrypted data. It may be possible to choose an algorithm or a key for decryption that is not the algorithm or key used for encryption. In that case, the evidence record would not be a non-repudiation proof for the unencrypted data. Therefore, only encryption methods should be used that make it possible to prove that archive-timestamped encrypted data objects unambiguously represent unencrypted data objects. All data necessary to prove unambiguous representation should be included in the archived data objects. (Note: In addition, the long-term security of the encryption schemes should be analyzed to determine if it could be used to create collision attacks.) 🙈
- When a relying party uses an evidence record to prove the existence of encrypted data objects, it may be desirable for clients to only store the unencrypted data objects and to delete the encrypted copy. To use the evidence record, it must then be possible to unambiguously re-encrypt the unencrypted data to get exactly the data that was originally archived. Therefore, additional data necessary to re-encrypt data objects should be inserted into the evidence record by the client, i.e., the LTA never sees these values 🔐
An extensible structure is defined to store the necessary parameters of the encryption methods. The use of the specified encryptionInfoType and encryptionInfoValue may be heavily dependent on the mechanisms and has to be defined in other specifications 🧚
6.1. Syntax
The EncryptionInfo field in EvidenceRecord has the following syntax, depending on the version of ASN.1 🎀
6.1.1. EncryptionInfo in 1988 ASN.1
1988 ASN.1 EncryptionInfo
EncryptionInfo ::= SEQUENCE {
encryptionInfoType OBJECT IDENTIFIER,
encryptionInfoValue ANY DEFINED BY encryptionInfoType
}6.1.2. EncryptionInfo in 1997-ASN.1
1997-ASN.1 EncryptionInfo
EncryptionInfo ::= SEQUENCE {
encryptionInfoType ENCINFO-TYPE.&id
({SupportedEncryptionAlgorithms}),
encryptionInfoValue ENCINFO-TYPE.&Type
({SupportedEncryptionAlgorithms}{@encryptionInfoType})
}
ENCINFO-TYPE ::= TYPE-IDENTIFIER
SupportedEncryptionAlgorithms ENCINFO-TYPE ::= {...}encryptionInfo contains information necessary for the unambiguous re-encryption of unencrypted content, so that it exactly matches the encrypted data objects protected by the EvidenceRecord 💖
7. Security Considerations 🔐
Secure Algorithms
Okay bestie, the crypto stuff inside Archive Timestamps has to be secure at the moment it's generated 🔒. That covers the hash algorithm used in the hash lists of the Archive Timestamp, plus the hash and public key algorithms of the timestamps themselves. Verifying components need to look at the security suitability publications ([NIST.800-57-Part1.2006] and [ETSI-TS102176-1-2005]). A generic way to automatically read security suitability policies in electronic form would be iconic, but that's not what this spec is about 💅.
Redundancy
Okay, plot twist 😭. Looking back later, certain parts of an Archive Timestamp might have already lost their security suitability before anyone publicly knew. For example, it could turn out that algorithms lost their security suitability, and that even TSAs can't be trusted. That can make Archive Timestamps that rely on those things lose their probative force 💀.
Here's the scary part: many TSAs use the same signature algorithms. A compromised private key only hurts one specific TSA, but when a signature algorithm loses its security, it can hit a potentially huge number of TSAs all at once 🌪️. So to counter these risks, it is recommended to generate and manage at least two redundant Evidence Records with ArchiveTimeStampSequences, using different hash algorithms and different TSAs that use different signature algorithms. Main character redundancy energy 👑.
To best achieve and manage this redundancy, it is recommended to manage the Archive Timestamps in a central LTA 🧚.
Secure Timestamps
Archive Timestamping depends on the security of normal time stamping, so it's giving "everything is connected" ✨. Security requirements for Time Stamping Authorities stated in security policies have to be met. Renewed Archive Timestamps should have the same or higher quality as the initial Archive Timestamp. And Archive Timestamps used for signature renewal of signed data should have the same or higher quality than the maximum quality of the signatures 🎀.
Secure Encryption
Lowkey important: for non-repudiation proof, it does not matter whether encryption has been broken or not 🙈. Still, users should keep their private keys and randoms used for encryption secret, and only disclose them if needed, e.g., in a lawsuit to a judge or expert. They should use encryption algorithms and parameters that are prospected to be unbreakable for as long as the confidentiality of the archived data matters 🫶.
8. References 📚
8.1. Normative References
[CCITT.X208.1988] International Telephone and Telegraph Consultative Committee, "Specification of Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.208, November 1988.
[CCITT.X209.1988] International Telephone and Telegraph Consultative Committee, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.209, 1988.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
8.2. Informative References
[ANSI.X9-95.2005] American National Standard for Financial Services, "Trusted Timestamp Management and Security", ANSI X9.95, June 2005.
[CCITT.X680.2002] International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", CCITT Recommendation X.680, July 2002.
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[ETSI-TS102176-1-2005] European Telecommunication Standards Institute (ETSI), Electronic Signatures and Infrastructures (ESI);, "Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms", ETSI TS 102 176-1 V1.2.1, July 2005.
[ISO-18014-1.2002] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1: Framework", ISO ISO-18014-1, February 2002.
[ISO-18014-2.2002] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2: Mechanisms producing independent tokens", ISO ISO-18014-2, December 2002.
[ISO-18014-3.2004] ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3: Mechanisms producing linked tokens", ISO ISO-18014-3, February 2004.
[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.
[NIST.800-57-Part1.2006] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revised)", NIST 800-57 Part1, May 2006.
[RFC3126] Pinkas, D., Ross, J., and N. Pope, "Electronic Signature Formats for long term electronic signatures", RFC 3126, September 2001.
[RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term Archive Service Requirements", RFC 4810, March 2007.
Appendix A. Evidence Record Using CMS 🦋
An Evidence Record can be added to signed data or enveloped data so that they can be transferred 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).
One advantage of storing the Evidence Record inside the CMS structure is that all the data travels in one conclusive file and stays directly connected 🍓. The documents, the signatures, and their Evidence Records can be bundled and managed together. The description in this appendix contains the normative specification of how to integrate ERS in CMS structures.
The Evidence Record also contains information about the selection method that was used to generate the data objects to be timestamped. For CMS, two selection methods can be distinguished:
- The CMS Object as a whole, including contentInfo, is selected as data object and archive timestamped. This means that a hash value of the CMS object MUST be located in the first list of hash values of Archive Timestamps.
- The CMS Object and the signed or encrypted content are included in the Archive Timestamp 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, for instance, as 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 Identifiers are defined for the Evidence Record 🌈:
ASN.1 Internal EvidenceRecord Attribute
id-aa-er-internal OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 49 }ASN.1 External EvidenceRecord Attribute
id-aa-er-external OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 50 }The attributes SHOULD only occur once. If they appear several times, they have to be stored within the first signature in chronological order 🕰️.
If the CMS object doesn't have the EvidenceRecord Attributes (which indicates that the EvidenceRecord has been provided externally), the archive timestamped 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 that one EvidenceRecord. This means 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 Timestamps occur, the data object has to be generated as follows:
- During verification of the first (in chronological order) EvidenceRecord, all EvidenceRecord have to be removed in order to generate the data object.
- During verification of the nth one EvidenceRecord, the first n-1 attributes should remain within the CMS object.
- The verification of the nth one EvidenceRecord must result in a point of time when the document must have existed with the first n attributes. The verification of the n+1th attribute must prove that this requirement has been met 💅.
Appendix B. ASN.1-Module with 1988 Syntax 🧚
okay so this is the 1988 version of the ASN.1 module, and it's giving a clean, tidy little package 💅 Here's the whole thing, verbatim, because the bits have to match exactly ✨
ASN.1-Module
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers88(2) id-mod-ers88-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
-- Imports from RFC 3852 Cryptographic Message Syntax
ContentInfo, Attribute
FROM CryptographicMessageSyntax2004 -- FROM [RFC3852]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }
-- Imports from RFC 3280 [RFC3280], Appendix A.1
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
;
ltans OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) }
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) } ,
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryptionInfo [1] EncryptionInfo OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence
}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
attributes [1] Attributes OPTIONAL,
reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
timeStamp ContentInfo}
PartialHashtree ::= SEQUENCE OF OCTET STRING
Attributes ::= SET SIZE (1..MAX) OF Attribute
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF
ArchiveTimeStampChain
EncryptionInfo ::= SEQUENCE {
encryptionInfoType OBJECT IDENTIFIER,
encryptionInfoValue ANY DEFINED BY encryptionInfoType}
id-aa-er-internal OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 49 }
id-aa-er-external OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 50 }
ENDAppendix C. ASN.1-Module with 1997 Syntax 🎀
and now the 1997 version, which is the newer glow-up 🦋 same vibe, but with some extra WITH COMPONENTS and ENCINFO-TYPE stuff so the encryption info can be typed properly. Still verbatim, obviously ✨
ASN.1-Module
ERS {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ers(1) id-mod-ers-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
-- Imports from PKCS-7
ContentInfo
FROM PKCS7
{iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-7(7) modules(0)}
-- Imports from AuthenticationFramework
AlgorithmIdentifier
FROM AuthenticationFramework
{joint-iso-itu-t ds(5) module(1)
authenticationFramework(7) 4}
-- Imports from InformationFramework
Attribute
FROM InformationFramework
{joint-iso-itu-t ds(5) module(1)
informationFramework(1) 4}
;
ltans OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) }
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) } ,
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryptionInfo [1] EncryptionInfo OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence
}
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF Attribute
(WITH COMPONENTS {
...,
valuesWithContext ABSENT
})
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
attributes [1] Attributes OPTIONAL,
reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL,
timeStamp ContentInfo}
PartialHashtree ::= SEQUENCE OF OCTET STRING
Attributes ::= SET SIZE (1..MAX) OF Attribute
(WITH COMPONENTS {
...,
valuesWithContext ABSENT
})
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
ArchiveTimeStampSequence ::= SEQUENCE OF
ArchiveTimeStampChain
EncryptionInfo ::= SEQUENCE {
encryptionInfoType ENCINFO-TYPE.&id
({SupportedEncryptionAlgorithms}),
encryptionInfoValue ENCINFO-TYPE.&Type
({SupportedEncryptionAlgorithms}{@encryptionInfoType})
}
ENCINFO-TYPE ::= TYPE-IDENTIFIER
SupportedEncryptionAlgorithms ENCINFO-TYPE ::= {...}
id-aa-er-internal OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 49 }
id-aa-er-external OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 50 }
ENDAuthors' Addresses 🌸
these are the humans who wrote this, and they deserve a shoutout 🫶
Tobias Gondrom
Open Text Corporation
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
Ralf Brandner
InterComponentWare AG
Industriestra?e 41
Walldorf D-69119
Germany
EMail: ralf.brandner@intercomponentware.com
Ulrich Pordesch
Fraunhofer Gesellschaft
Rheinstra?e 75
Darmstadt D-64295
Germany
EMail: ulrich.pordesch@zv.fraunhofer.deFull Copyright Statement 🌈
okay, legal time, but make it cute 💅 The IETF Trust owns the copyright here (2007), and the whole thing is covered by the rights, licenses and restrictions in BCP 78. Apart from what BCP 78 says, the authors keep all their rights.
The disclaimer is in all caps in the original, so I'm keeping it exactly like that so nobody can say I changed the legal vibes 🙈
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, THE IETF TRUST 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.
Intellectual Property 🦋
the IETF doesn't take a position on whether any IP rights claimed for this tech are valid or how far they reach, and it's not saying any licenses are or aren't available. It also hasn't done its own digging to find any such rights. If you want the details on rights for RFC documents, check out BCP 78 and BCP 79 🔍
if you've told the IETF Secretariat about any IPR, or there are assurances of licenses, or someone tried to get a general license for implementers or users, that info lives in the IETF online IPR repository at http://www.ietf.org/ipr.
the IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that to ietf-ipr@ietf.org 💜
Acknowledgement 🍓
funding for the RFC Editor function is currently provided by the Internet Society, so a big thank you to them 👑
📦 where this page comes from
- ietf: rfc4998 2007-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms