Timestamping

Timestamping services provide cryptographic proof that a document, signature, or certificate existed at a specific point in time. In regulated industries like fintech, digital identity, and payment services, this matters because it determines whether a digital signature was valid at the moment of signing, not just today. Without trusted timestamps, signatures tied to expired or revoked certificates become legally and technically unverifiable.

What Is a Trusted Timestamp

A trusted timestamp is a cryptographically signed token issued by a Time Stamping Authority (TSA). The token binds a hash of your data to a specific date and time, sealed by the TSA's private key. No one, including the issuer, can retroactively alter the recorded time without invalidating the token.

The process is defined in RFC 3161 (Internet X.509 Public Key Infrastructure Time-Stamp Protocol). Here is how it works step by step:

1. Your system generates a hash of the document or signature.
2. The hash is sent to the TSA in a TimeStampRequest.
3. The TSA signs the request with its own certificate and returns a TimeStampToken.
4. The token is stored alongside the original document.
5. Any verifier can independently confirm the token using the TSA's public certificate.

No raw document content ever leaves your system. Only the hash is transmitted.

RFC 3161 vs Proprietary Timestamping

Not all timestamping is equal. RFC 3161 is the standard used in legal and compliance contexts. Some platforms implement internal or proprietary timestamps, which are unsuitable for regulated use cases.

For PSD2 compliance, eIDAS qualified signatures, or Canadian federal procurement, RFC 3161 from an accredited TSA is the only acceptable option.

Timestamping in eIDAS and PSD2 Compliance

Under eIDAS Regulation (EU) 910/2014, a qualified electronic timestamp must be issued by a Qualified Trust Service Provider (QTSP). It serves as a legal presumption that the data existed at the stated time. Canadian organizations operating in cross-border EU transactions must understand this requirement directly.

PSD2, enforced under the EBA's Regulatory Technical Standards, requires strong customer authentication and non-repudiation for payment transactions. Timestamping plays a role in audit log integrity, ensuring transaction records are tamper-evident and time-bound.

Key compliance checkpoints where timestamping applies:

• Signing of contracts and agreements in digital banking
• Audit logs for payment authorization flows
• Certificate lifecycle events (issuance, revocation, renewal)
• Timestamping of qualified electronic signatures (QES) before certificate expiry

In the Canadian context, PIPEDA and provincial privacy legislation require demonstrable data integrity for financial and personal records. RFC 3161 timestamps support this by creating an immutable timeline.

How Long-Term Validation (LTV) Depends on Timestamps

Long-Term Validation is the mechanism that keeps a digitally signed document verifiable beyond the lifetime of the signing certificate. Without LTV, once the certificate expires or is revoked, the signature becomes unverifiable.

LTV works by embedding:

• The signed document
• The signing certificate chain
• The OCSP response or CRL at the time of signing
• An RFC 3161 timestamp over all of the above

The timestamp proves the signature was applied when the certificate was still valid. This is the foundation of PDF Advanced Electronic Signatures (PAdES) and CAdES formats, both referenced in eIDAS technical standards.

An example: A fintech company signs a loan agreement using a certificate valid through March 2026. The certificate is revoked in July 2026. Without an LTV timestamp from before July 2026, the agreement's signature is unverifiable. With a valid RFC 3161 timestamp from the signing date, the signature remains legally sound indefinitely.

TSA Certificate Requirements

A TSA must operate under its own certificate, specifically issued for timestamping with the Extended Key Usage (EKU) value of id-kp-timeStamping (OID 1.3.6.1.5.5.7.3.8). This certificate must be issued by a trusted CA and should not be used for any other purpose.

Technical requirements for a TSA certificate:

If you are evaluating a TSA for enterprise deployment, ask specifically for their time synchronization audit logs and clock accuracy specifications. Accuracy matters in legal disputes where the precise minute of signing is contested.

Integrating Timestamping Services: Technical Approaches

There are three primary integration patterns depending on your architecture:

1. HTTP-Based TSA Query (RFC 3161 over HTTP)

The most common method. Your application sends a DER-encoded TimeStampRequest via HTTP POST to the TSA endpoint. The response is a TimeStampResponse containing the signed token.

Libraries that support this natively:

• OpenSSL (command line and API)
• Bouncy Castle (Java, C#)
• Python rfc3161ng and pyhanko
• Java BouncyCastle TSP

Example OpenSSL command:

openssl ts -query -data document.pdf -no_nonce -sha256 -out request.tsq
openssl ts -reply -queryfile request.tsq -out response.tsr

2. Embedded Timestamping in PDF Signing Workflows

Adobe Acrobat and most enterprise signing platforms support Document Timestamp (DST) as a separate signature field. This is distinct from a signature-level timestamp and covers the entire signed document state.

3. API-Based Timestamping for High-Volume Pipelines

For fintech platforms processing thousands of transactions per hour, REST or SOAP TSA APIs provide batch timestamping with SLA guarantees. Response times under 200ms are typical for commercial TSAs. Evaluate:

• Uptime SLA (99.9% is baseline, 99.99% for payment-critical infrastructure)
• Timestamp volume limits per subscription tier
• Token format: binary DER vs base64-encoded
• Webhook support for asynchronous workflows

Timestamping and TLS Certificate Lifecycle Management

Timestamping intersects with TLS certificate management in less obvious ways. When a TLS certificate is used to sign OCSP responses, those responses should also be timestamped for archival purposes. Certificate Transparency logs are themselves timestamped via Signed Certificate Timestamps (SCT), defined in RFC 6962.

For organizations managing internal PKI, timestamps on certificate issuance and revocation events create an auditable chain of custody. This is especially relevant for:

• Root CA key ceremony records
• Intermediate CA certificate issuance
• Hardware Security Module (HSM) audit logs

Canadian federal government PKI guidelines under the Government of Canada's Trust Framework reference time integrity as a foundational element for identity assurance levels 2 and above.

Choosing a TSA: What to Verify

When selecting a timestamping service, do not rely on marketing claims. Verify the following directly:

For cross-border use between Canada and EU jurisdictions, a QTSP-issued timestamp that meets ETSI EN 319 421 (Policy and Security Requirements for Trust Service Providers issuing Time-Stamps) provides the strongest legal standing.

Common Errors in Timestamping Implementations

Teams frequently encounter these specific issues:

• Clock skew between the signing system and TSA exceeds the TSA's declared accuracy, causing timestamp rejection
• Using SHA-1 in the TimeStampRequest hash when the TSA has deprecated it; use SHA-256 minimum
• Not renewing TSA certificates before embedding them in archive timestamps, causing chain validation failure
• Assuming that a document-level timestamp covers signatures applied after it, it does not
• Embedding timestamps in PDF XMP metadata instead of in the PDF signature structure, which has no legal standing