TSA service upgrade completed in 2017
Likely nothing. Continue to use the timestamp service as you have been.
You will hardly notice it, but only good things: You will be getting timestamp with upgraded encryption algorithms and an upgraded warranty for 7 years.
Changes have been completed.
The legacy servers will continue to be available and unchanged until clients have made their transition to the new servers.
Changes:
More choices for signature algorithm – current systems are RSA 2048. We’ve added 3 options
- NIST Recommended Elliptic Curve
- Brainpool Elliptic Curve
- RSA 4096
Our legacy public key certificates use SHA-1 in the certificate-chaining signatures. We are moving all signatures to SHA-512
Change to FIPS 140-2 Level-4 Certified hardware TimeStamp Robot protecting, keys, and timestamp process. The Robot can't be tamper or compelled to create backdated timestamps. Our legacy system has a mix of both Level-3 and Level-4.
Cryptology FALLBACK: A user’s timestamp is part of the daily Merkle tree (linked-hash chain) and it’s root timestamped by each of these: RSA 4096, NIST ECDSA 521, brainpool 512. Only 1 of those needs to be valid in 7 years for you to have the proof you need: the hash of your document existed at a point in time.
The Merkle trees create by our Archive includes each timestamp and produces a single, hash-chain linked, SHA2-512 root value. It is this Merkle root value that is recored in a variety of Evidence Records that support the Cryptology FALLBACK timestamping methods described here.
Cryptology FALLBACK: Every 30 days the Merkle root hash value is published on our web-site, into distributed blockchain technology platforms (reduced to SHA2-256) and additional widely-witnessed methods.
DigiStamp Public Policy commits us to maintains our Archive and execute additional renewals as need to preserve the timestamp quality of evidence related to cryptic obsolescence.
Understanding Cryptology FALLBACK failure risk of "missed renewal": the IETF standards intent that a renewal is performed if 1. the public key algorithm of the timestamp or 2. the hash algorithm used to build a Merkle tree is going to become insecure. This renewal must be done "before algorithm becomes insecure". There could be unforseen reasons why DigiStamp would be unable to perform the renewal whereby your timestamp authenticity would be lost. Alternatively, you can perform your own timestamp renewal action (it is a published IETF procedure documented below).
The other failure risk with no Cryptology FALLBACK: the hash algorithm used to hash your original data becomes insecure. We have added support for SHA3 hash-algorithms to help with this risk. To perform this renewal, your original data is needed, and DigiStamp does not have that file. The solution, and we will help you, is a renewal whereby you need to create a new timestamp request with an upgraded hash value of your original document. As background: All of these timestamp renewal methods are part of IETF published methods related to the basic problem of long term archive of digital data. Any of these renewal can be done without involving DigiStamp, they are public domain, accepted techniques described in technical standards.
The DigiStamp warranty is: If a timestamp’s original crypto method is compromised within 7 years of creation then you have free access to DigiStamp's Archived renewals for that timestamp. After that 7 year period you would need to purchase Archive Access from DigiStamp. Timestamps created since January 2016 are included with this warranty. This wording of this warranty is still in draft form and will not be finalized.
PKI Signatures algorithms:
The new systems include:
RSA
- RSA 2048 - same as current systems
- RSA 4096 - reserved for Merkle-tree timestamps
NIST recommended elliptic curves. Sometimes called Prime elliptic curve.
- secp256r1 - {1.2.840.10045.3.1.7}
- secp521r1 - {1.3.132.0.35} - reserved for Merkle-tree timestamps
Brainpool defined elliptic curves
- brainpoolP256r1 - {1.3.36.3.3.2.8.1.1.7}
- brainpoolP512r1 - {1.3.36.3.3.2.8.1.1.13} - reserved for Merkle-tree timestamps
We have tested the Elliptic curves in a variety of third-party tools. We think it likely you will choose to migrate to one of the elliptic curve algorithms. Your essential choice is between NIST or Brainpool and that choice is nebulous; "USA" compared to "EU" preference is one perspective. The NIST curves currently have wider acceptance; for example, Brainpool is not currently supported in Adobe products, but it is in Microsoft products.
On your end, at the code level, when creating the timestamp requests nothing has changed. Instead, in your account configuration at DigiStamp we set your "default algorithm" choice. For the test environment that setting is here and production is here . Alternatively, but more difficult for you, is to specify a TSA Policy in each request that specifies the algorithm used to create your timestamp.
Related to note above "reserved for Merkle-tree timestamps": All of the timestamps being produced meet or exceed current standards for cryptographic strength. The reserved options are of longer key lengths, making them more computationally intensive to create and verify. These will not be made available for most users due to the greatly increased cost of guaranteeing sufficient rates of signature creation. Larger keys are each used for the secondary Evidence Records that are hash-linked to each of your timestamps, and which we keep in our Archive for Fallback and Warranty purposes.
In this new release there are additional upgrades related to audit and certification of our hardware. OCSP, CRL, x.509 certificate upgrades are also being made but these will not generally impact client operations.
Examples of actual timestamps: NIST ECDSA 256 or brainpool 256