rfc-4998

Evidence Record Syntax (ERS)

T. Gondrom, R. Brandner, U. Pordesch
date2007-08 streamIETF areaapp wgltans statusPROPOSED STANDARD pages32 canonicalhttps://www.rfc-editor.org/rfc/rfc4998 doi10.17487/RFC4998 errataview
In many scenarios, users must be able prove the existence and integrity of data, including 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, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK]

Extracted elements (28)

design-rationale §1.2

Merkle hash trees allow a single timestamp to cover many data objects while keeping proof size small. The tree is reduced to a few PartialHashtrees per data object, and deletion of one data object does not affect provability of others, enabling efficient large-scale archival with per-object verification paths.

crypto

design-rationale §3.1

The digestAlgorithms field at the EvidenceRecord level is explicitly defined as the union of all digestAlgorithm values from all contained ArchiveTimeStamps, providing a single lookup point for all hash algorithms used over the entire archival period without requiring traversal of the full structure.

crypto

design-rationale §6

The EncryptionInfo structure uses an OID-dispatched type/value pair rather than a fixed scheme because the specific re-encryption parameters are heavily mechanism-dependent and must be defined in separate specifications; the client inserts these values so the LTA never sees the private encryption parameters.

crypto, security

design-rationale §1.2

Two distinct renewal modes exist because they address different failure scenarios: Timestamp Renewal suffices when only the TSA's private key or the asymmetric algorithm is at risk (original data need not be accessed); Hash-Tree Renewal is mandatory when the Merkle tree's hash algorithm weakens, since forging a new tree sibling would then be feasible.

crypto, security

interoperability-note §2.1

Two alternative ASN.1 modules are provided — one for 1988 ASN.1 syntax and one for 1997 ASN.1 syntax — to accommodate compilers that only support the older version. In case of conflict between the two modules, the 1988 module takes precedence.

crypto

interoperability-note §A

When an EvidenceRecord is embedded in a CMS object as an unsigned/unprotected attribute, verification requires removing the EvidenceRecord attribute and adapting containing field lengths before computing the hash; for multiple embedded EvidenceRecords, verification of the nth record requires the first n-1 to remain present.

crypto, security

interoperability-note §4.1

While RFC 3161 is the primary timestamp format, the timeStamp field MAY contain other timestamp formats (e.g., ISO 18014, ANSI X9.95) provided they contain time data, timestamped data, and a cryptographically secure TSA confirmation. Non-certificate-based timestamps (ISO 18014-2, ISO 18014-3) require no CRL/OCSP preservation.

crypto, security

normative-requirement §3.1 SHOULD

An implementation conforming to this specification SHOULD reject an EvidenceRecord with a version field value below 1.

crypto, security

normative-requirement §5.1 MUST

ArchiveTimeStampChain and ArchiveTimeStampSequence MUST be ordered ascending by time of timestamp. Within an ArchiveTimeStampChain, all reducedHashtrees of contained ArchiveTimeStamps MUST use the same hash algorithm.

crypto, security

normative-requirement §4.2 MUST

Data needed to verify the timestamp (certificates, CRLs, OCSP responses) MUST be preserved and SHOULD be stored in the timestamp itself unless this causes unnecessary duplication.

crypto, pkix, security

normative-requirement §4.3 MUST

During Archive Timestamp verification, the computed intermediate hash h' MUST appear as a member of the next higher PartialHashtree list. The root hash value must correspond to hashedMessage (and digestAlgorithm to hashAlgorithm) in the messageImprint of the RFC 3161 TSTInfo.

crypto

normative-requirement §5.3 MUST

During chain verification, the first hash value list of each ArchiveTimeStamp MUST contain the hash value of the previous timestamp's content, each Archive Timestamp MUST be valid relative to the time of the following Archive Timestamp, and the chain's hash algorithm MUST be secure at the time of the first Archive Timestamp of the following chain.

crypto, security

normative-requirement §5.2 MUST

For Timestamp Renewal, the new Archive Timestamp MUST be added to the ArchiveTimeStampChain, and its hash tree MUST use the same hash algorithm as the old Archive Timestamp (taken from the digestAlgorithm field or, if absent, from within the timestamp itself).

crypto

normative-requirement §4.1 MUST

If the optional digestAlgorithm field is absent from an ArchiveTimeStamp, the digest algorithm of the embedded timestamp MUST be used for the reduced hash tree. For RFC 3161 timestamps this means the hashAlgorithm of the messageImprint field of TSTInfo.

crypto

normative-requirement §5.3 MUST

To complete a non-repudiation proof, the last Archive Timestamp in the ArchiveTimeStampSequence MUST be valid at the time verification is performed.

crypto, security

normative-requirement §4.2 MUST

When generating a hash tree, 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 to specify the hash tree algorithm.

crypto

protocol-element §4.1

ArchiveTimeStamp is an ASN.1 SEQUENCE with optional digestAlgorithm ([0] AlgorithmIdentifier), optional attributes ([1] Attributes SET), optional reducedHashtree ([2] SEQUENCE OF PartialHashtree), and mandatory timeStamp (ContentInfo). PartialHashtree is SEQUENCE OF OCTET STRING representing hash values sharing a common parent node.

crypto, security

protocol-element §5.1

ArchiveTimeStampChain is SEQUENCE OF ArchiveTimeStamp; ArchiveTimeStampSequence is SEQUENCE OF ArchiveTimeStampChain. The chain captures Timestamp Renewal (same hash algorithm, covers prior timestamp); the sequence captures Hash-Tree Renewal (new chain started, covers data objects and all prior chains).

crypto, security

protocol-element §3.1

CryptoInfos (optional in EvidenceRecord) is SEQUENCE SIZE(1..MAX) OF Attribute, storing validation-useful data such as trust anchors, certificates, revocation information, and cryptographic algorithm suitability declarations (e.g., 'RSA 1024-bit valid until 2008'). Data here is not protected by any timestamp and must be verified through external mechanisms.

crypto, pkix, security

protocol-element §6.1

EncryptionInfo is an ASN.1 SEQUENCE containing encryptionInfoType (OBJECT IDENTIFIER) and encryptionInfoValue (ANY DEFINED BY encryptionInfoType), storing parameters needed for unambiguous re-encryption of unencrypted data objects to exactly reproduce the archived encrypted form.

crypto, security

protocol-element §3.1

EvidenceRecord is an ASN.1 SEQUENCE containing: version (INTEGER v1), digestAlgorithms (SEQUENCE OF AlgorithmIdentifier, union of all hash algorithms used across the archival period), optional cryptoInfos ([0] CryptoInfos), optional encryptionInfo ([1] EncryptionInfo), and archiveTimeStampSequence (ArchiveTimeStampSequence).

crypto, security

registry §2.3

This document defines the LTANS OID tree root (ltans ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) }) and two CMS attribute OIDs for embedding Evidence Records: id-aa-er-internal (smime.id-aa.49) and id-aa-er-external (smime.id-aa.50).

crypto, registry

security-consideration §7

Cryptographic algorithms and parameters used within Archive Timestamps must be secure at the time of generation for both hash and public-key algorithms. Publications such as NIST 800-57 and ETSI TS 102176-1 must be consulted by verifying components; a generic automated interpretation mechanism is desirable but out of scope.

crypto, security

security-consideration §7

ERS directly protects the integrity of the encrypted bit-stream, freezing the bit structure at archiving time. If the encryption scheme later becomes insecure, re-encryption is impossible without breaking the integrity proof; only encryption methods that allow unambiguous proof of the encrypted-to-unencrypted mapping should be used, and encryption parameters must be analyzed for potential collision attacks.

crypto, security

security-consideration §7

Retrospective algorithm compromise can simultaneously invalidate many TSAs using the same algorithm. To counter this, it is recommended to maintain at least two redundant Evidence Records using different hash algorithms and different TSAs with different signature algorithms, preferably managed centrally by an LTA.

crypto, security

state-machine §1.2

EvidenceRecord lifecycle: (1) Initial — create Archive Timestamp over data object(s); (2) Timestamp Renewal — triggered when TSA certificate expires or asymmetric/hash algorithm used in timestamp weakens, covers only the old timestamp without accessing archived data; (3) Hash-Tree Renewal — triggered when hash algorithm used in the Merkle tree weakens, requires re-hashing all data objects and appending a new ArchiveTimeStampChain.

crypto, security

wire-format §5.2

For Hash-Tree Renewal, each renewed leaf hash is h(i)' = H(h(i) || ha(i)), where h(i) = H(data object) under new algorithm H and ha(i) = H(DER-encoded ArchiveTimeStampSequence of all previous chains for that data object). ArchiveTimeStampChains must be DER-encoded (including sequence and length tags) for this computation.

crypto

wire-format §4.2

Hash tree nodes are computed by binary-sorting children hash values in ascending order, concatenating them (leading zeros preserved, most-significant bit first), and hashing the concatenation. Hash values are full-length octet strings. The root hash value is submitted to the TSA for timestamping.

crypto