ANSI ASC X9.95 Standard

The ANS X9.95 standard for trusted timestamps expands on the widely used [http://tools.ietf.org/html/rfc3161 RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol] by adding data-level security requirements that can ensure data integrity against a reliable time source that is provable to any third party. Applicable to both unsigned and digitally signed data, this newer standard has been used by financial institutions and regulatory bodies to create trustworthy timestamps that cannot be altered without detection and to sustain an evidentiary trail of authenticity. Timestamps based on the X9.95 standard can be used to provide:
* authenticity: trusted, non-refutable time when data was digitally signed
* integrity: protection of the timestamp from tampering without detection
* timeliness: proof that the time of the digital signature was in fact the actual time
* an evidentiary trail of authenticity for legal sufficiencyA superset of the RFC 3161 protocol, the X9.95 standard includes definitions for specific data objects, message protocols, and trusted timestamp methods, such as digital signature, MAC, linked token, linked-and-signature and transient-key methods. X9.95 compliance can be achieved via several technological approaches, such as transient-key cryptography. Several vendors market X9.95-compliant systems.

Definitions

In an X9.95 trusted timestamp scheme, there are five entities: the time source entity, the Time Stamp Authority, the requestor, the verifier, and a relying party.
* Time source entity - Any National Measurement Institute or master clock that provides time calibration services. Examples include NIST and Bureau International des Poids et Mesures (BIPM).
* Time Stamp Authority (TSA) - The issuer of timestamps, which can be internal to an organization or a third party. The TSA receives trusted time from one or more time source entities and generates timestamps according to the X9.95 scheme.
* requestor - The entity requesting a timestamp.
* verifier - The entity that verifies a timestamp. A verifier can be a relying party, regulatory body, or entity that employs a third-party verification service.
* relying party - The entity receiving the timestamp. The relying party uses the time stamp token in operations.

Creating a timestamp

Before a timestamp can be created, the Time Stamp Authority calibrates its clock with an upstream time source entity, such as a master clock or a national measurement institute. When accurate and trusted time has been acquired, it can issue timestamps for unsigned and digitally signed data.

Applications using timestamps on unsigned data can provide evidence to a verifier that the underlying digital data has existed since the timestamp was generated.

When a requestor requires a timestamp for a dataset, it creates a hash of the data, which is a unique string of data that is different for any dataset. Representing a snapshot of the data, the hash is sent to the Time Stamp Authority, which has no awareness of the contents and therefore assumes no liability for the content. Using a cryptographic binding, the TSA binds the hash and a timestamp into a timestamp token, which is returned to the requestor for association with the dataset.

For applications using digitally signed data, the requestor signs the digital hash with its private key and submits the digital signature to the TSA, which performs the same operations as in the previous example: bind the submitted data with a timestamp using its cryptographic binding and return the results to the requestor.

When the requestor receives the timestamp token from the TSA, it signs the token with its private key. The requestor now has evidence that the data existed at the time issued by the TSA. When verified by a verifier or relying party, the timestamp token also provides evidence that digital signature has existed since the timestamp was issued, provided that no challenges to the digital signature's authenticity repudiate that claim.

Timestamp tokens can be obtained from different TSAs on the same data and can be verified at any time by a third party.

Verifying a timestamp

When verification is needed, the verifier uses the RSA public key for the purported interval to decrypt the timestamp token. If the original digital hash inside the token matches a hash generated on the spot, then the verifier has verified:
# The hash in the time stamp token matches the data
# The TSAs cryptographic binding
# The requestor's digital signatureThese three verifications provide non-repudiable evidence of who signed the data (authentication), when it was signed (timeliness) and what data was signed (integrity). Since public keys are used to decrypt the tokens, this evidence can be provided to any third party.The American National Standard X9.95-2005 Trusted Time Stamps was developed based on [http://tools.ietf.org/html/rfc3161 RFC 3161 protocol] [TSP] and the ISO/IEC 18014 standards [ISO] yet extends its analysis and offerings. The X9.95 standard can be applied to authenticating digitally signed data for financial transactions, regulatory compliance, and legal evidence.

External links

* [http://www.x9.org/news/pr050701 X9.95 Standard for Trusted Time Stamps]
* [http://tools.ietf.org/html/rfc3161 RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)]
* [http://www.nist.gov National Institute of Standards and Technology]
* [http://www.bipm.org/en/home Bureau International des Poids et Mesures (BIPM)]
* [http://www.rsasecurity.com/rsalabs/node.asp?id=2347 RSA Laboratories - What is digital timestamping?]
* Stuart Haber & W. Scott Stornetta “ [http://citeseer.ist.psu.edu/244805.html How to Time-stamp a Digital Document] ” 1991.
* [http://www.proofspace.com/technology/timestamping.php The Trouble with Timestamps]