Timestamp Authority Server | Ascertia | Blog

This article describes why RFC3161 compliant Time Stamp Authority (TSA) servers are needed and what to look for when choosing a TSA server. 

ETSI TS 101 861 and TS 102 023 also places important requirements for TSA services providers and these are also considered in this hot topic.

Why do you need a Timestamp Authority server?

With the move from paper to electronic records many public and private organisations are realising the importance of being able to prove that electronic records are trustworthy and have not changed since archiving.

Without adequate and provable security measures it’s just not possible to prove the data has not changed to an independent party, as required for dispute resolution.

An RFC3161 timestamp server provides an essential function in protecting data records for the long-term. It provides proof that the data existed at a particular moment in time and that it has not changed, even by a single binary bit, since it was notarised and time-stamped.

A timestamp authority achieves this by cryptographically binding the data’s unique fingerprint (typically a SHA-2 hash value) with the current date and time that is synchronised with a trusted time source.

This binding is achieved using strong digital signature algorithms and with a private signing key under the sole control of the timestamp authority. Using standard public key cryptographic techniques, this means only the timestamp authority can issue the secure timestamps whilst anyone who trusts the TSA certificate can verify these.

Example uses of a timestamp authority can be quite diverse. For example, Ascertia ADSS TSA Server is used in national infrastructure schemes, such as protecting the national digital archive maintained by the British Library for the long-term preservation of all digitally published material for future generations.

The British Library is a legal depository and required by law to retain published material in perpetuity, thus it needs to be able to provide assurance that an archived digital object is authentic.

Within a corporate context timestamp authorities are used to secure important business records such as financial reports & statements, invoices and receipts. Timestamps are also used to ensure digital signatures can be verifiable in the long-term as explained below.

Aren’t digital signatures enough by themselves?

We sometimes get asked – if I digitally sign a data record isn’t that enough to prove authenticity, why do I need a separate timestamp? The answer is that a basic digital signature is sufficient whilst the signer’s certificate is still valid, i.e. not expired or revoked.

Typically, certificates expire after one or two years, and any signatures already produced cannot be verified after this. The signer’s certificate may expire sooner than this after several months of use or even be revoked if they leave the organisation or lose control of their singing key.

To make digital signatures verifiable in the long-term, RFC3161 timestamps are essential – these are generally added to the signature at the time of signing or soon after (for instance once the details of the transaction are confirmed or after any grace period).

The embedded timestamps then prove when the signature was applied and any later expiry or revocation of the signer’s certificate is irrelevant, because at time of signing the certificate can be shown to be valid. To deliver these advanced long-term digital signature techniques have been standardised by ETSI, CEN and IETF (e.g. PAdES, XAdES and CAdES).

Examples of such long-term signatures includes signed and time-stamped PDF documents and time-stamping of software code signatures, i.e. drivers and executables are time-stamped to prove their authenticity and authorship and can be verified by operating systems even after the signer’s certificate expires.

Time source accuracy

Naturally, a timestamp server needs to reference an accurate and reliable time source, without which the trustworthiness of the entire system can come into question.

According to CWA 14167-1 the TSA’s trusted time source(s) must be synchronised to Co-ordinated Universal Time (UTC) within the tolerance dictated by policy e.g. to within 1 second.

It is further recommended that two independent sources of UTC are used to maintain a resilient time source. According to ETSI TS 102 023 , if the TSA's clock is detected as being out of the stated accuracy then time-stamp tokens must not be issued.

The Ascertia ADSS TSA Server implements these requirements in the following way:

The ADSS TSA Server admin GUI screenshot shows the relevant configuration detail:

Time monitoring & TSA service shut-down settings in ADSS TSA Serve

Note the general use of Part 3 to 5 of PAdES will be limited until these are also supported in the freely available Adobe® Reader. It’s currently uncertain when Adobe Inc will do this, possibly not until 2011 when ISO32000-2 is released.

Configuring PAdES part 2 signatures in PDF Sign&Seal

Step 1:Configuring PAdES part 2 signatures in ADSS Server 

Step 2: Configuring PAdES part 2 signatures in ADSS Server

Timestamp authority server summary

PAdES is quickly becoming a recognised acronym within the European signature industry. It will be an important future standard and various legislations may mandate this. PAdES consists of five different parts. Current PDF software supports PAdES Part 2 which is based on ISO 32000.

Later parts of PAdES allow the signature to be extended for long-term verification by allowing ability to embed a chain of timestamps. These later parts of PAdES will eventually become a part of ISO 32000-2 (possibly in 2011/12).

Ascertia products currently support PAdES Part 2 and enhancements are due later in 2010.

References to PAdES specifications

PAdES specifications consist of five parts: