Trusted Timestamp (RFC 3161)

A trusted timestamp is produced through the Time-Stamp Protocol (TSP) defined in IETF RFC 3161. The requester sends the time-stamping authority (TSA) only the cryptographic hash (e.g. SHA-256) of the document or log file. The TSA combines that hash with the time from a trusted clock source, a serial number and a policy identifier. It signs the result with its private key and returns a TimeStampToken.

The token is signed data in CMS (Cryptographic Message Syntax) format. Its TSTInfo structure holds the hash, the generation time (genTime), accuracy and the TSA policy. A verifier recomputes the file's hash, compares it with the one in the token and checks the validity of the TSA certificate. If even a single bit of the file changes, the hashes no longer match and tampering is revealed. Since the content is never sent to the TSA, confidentiality is preserved.

In Türkiye, Electronic Signature Law No. 5070 defines a timestamp as a record, verified with an electronic signature by an electronic certificate service provider (ESHS), that establishes when electronic data was created, modified, sent, received or stored. The service is offered by ESHSs authorised by BTK. Typical uses include proving the integrity of access records under Law No. 5651, long-term-valid electronic signatures (the timestamped levels of PAdES, CAdES and XAdES), e-archiving and contract workflows, and proof of date for creative works.

In practice, log files are closed at fixed intervals (hourly or daily, for example), hashed and timestamped. Chaining each file's hash into the next makes deletion of a file from the archive detectable too. For long-term archives, re-timestamping (archive timestamps) should be planned before the algorithms or the TSA certificate lose their strength. Weakened hash algorithms such as SHA-1 should be avoided in favour of the SHA-2 family.