Evidence record
An Evidence Record (ER) defined by Evidence Record Syntax (ERS, RFC4998) is essentially a timestamp wrapped in a specific data structure and proves that the protected document existed before the generation time of the timestamp. It solves two problems:
- High cost of qualified timestamps. ERS allows one to mark practically unlimited number of documents with a single timestamp.
- Expiration of timestamps and weakening of cryptographic algorithms. ERS defines methods for appending new timestamps and re-hashing data.
Visual explanation
To create an ER, we collect a set of documents (d1, d2, ..., dn). The more documents we have, the lower will be the price of a timestamp per document. Then a tree is constructed from the set and its root is timestamped.
Evidence Record: is a path (called "ReducedHashtree") from protected document (d3) to the root together with all the timestamps. Size of the ER is given by the depth of the tree and grows logarithmically with the number of documents. Even for billions of documents the size of ER is in a range of KBs.
Timestamp renewal: before the timestamp expires, it's timestamped by another timestamp with later expiry date. This mechanism (together with hashtree renewal) allows for long-term archival.
Lifecycle of an evidence record
- Submit hashes of data objects. Before submitting, include suitable certificates, OCSP responses and certificate revocation lists as needed for long-term archival. Note that single ER can protect only a single hash (technically ER protects N hashes, where N is the arity of used tree). If you require a single ER to protect multiple hashes (e.g. all files in ASiC-E container), you must submit them as a group.
- A tree is constructed from the submitted hashes (and groups of hashes) and its root is timestamped.
- Collect ER for your hashes or groups of hashes.
- Optional: Associate the ER with the data it protects. There are currently two options according to ETSI:
- CAdES-E-ERS: ER is included as an unsigned attribute in a CMS signature.
- ASiC: ER is included as a file in a ZIP archive together with related data objects. ASiC-E allows for association of single ER with multiple data objects. Such an ER must be created for a group of hashes.
- Periodic timestamp renewal. ER's timestamp must be renewed before it expires. This is done automatically by the
ER service, user just needs to
collect the updated ER.
- ER on the server is re-stamped automatically before it expires. User collects updated ER.
- If ER is not stored on a server, user must submit it for re-stamping. User collects updated ER from the server.
- Periodic hashtree renewal. The whole ER and data it protects must be re-hashed when current hash algorithm used
in the ER becomes weak.
- Since the original data are needed, user must submit stronger hash of data and optionally ER, if it isn't stored on a server.
- User collects updated ER from the server.
Long-term archival
When storing a signed document for long-term archival, the document must be augmeneted with a proof that its signing certificate was not revoked at the time of signing. The time of signing is effectivelly the time of the first timestamp in the ER, which protects the document. But since the document cannot be modified once protected by the ER, the validation data can be added to the document only before the ER is generated. However, an ER can be generated long after the validation data were obtained and thus they might not be fresh. Consider a case, when attacker obtains validation data, then revokes the cert and then signs the document.
The solution is to obtain the validation data (e.g. OCSP response) after the ER is generated and then insert the data not into the document, but into the ER's timestamp token. Now it can be proven that the signing certificate was valid after the document was signed.
Alternative solution is to augment the original signature with required validation data just before the ER is timestamped. However this requires the PDF document to be stored on the server, since modification of PDF's signature changes hash of the document and it must be computed after the signature is augmented. Also please note that this approach will never satisfy Signature applicability rules for the validation of EU qualified electronic signatures/seals (..."the revocation information is only accepted if it has been issued after the best signature time").