Technical Details about Integrating DigiStamp TSAs

The information below is provided for software developers and is very technical. End-users of our desktop software will not need these details; instead, easy-to-use desktop software is provided here.

 

The access to Internet-base timetimestamp servers is defined in IETF RFC3161. This standard has been implemented in a variety of client software programs.

 

Below are details about the interaction between the client software and our servers. Our toolkits and most of the generic software hide most of these details and and simply perform the action. But, these details will be helpful if you are using generic software and want understand more about your options.

 

Given the details below, then the next level of greater detail would the the IETF specification itself, here. Generally, the timestamp software that you choose will handle the low level details like PKCS7 record structures, x.509 certificates and ASN encoding.

Timestamp Process Flow

1. Calculate the hash of your data object.

Supported algorithms and their object identifiers:

2. Create the encoded timestamp request for transmission to Digistamp.

Each of these fields is part of the RFC3161 specification.

• Version. The value must be 1.
• TSA Policy ID. Suggest not specifying a value and accept the default that has been configured with your account setup. This setting determines which cryptographic algorithm and key length will be used to sign the timestamp:
  • RSA 2048(2) OID: 1.3.6.1.4.1.8291.2
  • RSA 4096(3) OID: 1.3.6.1.4.1.8291.3
  • NIST 256(4) OID: 1.3.6.1.4.1.8291.4
  • NIST 521(5) OID: 1.3.6.1.4.1.8291.5
  • brainpool 256(6) OID: 1.3.6.1.4.1.8291.6
  • brainpool 512(7) OID: 1.3.6.1.4.1.8291.7
• Nonce. Optional with a length of up to a 112 bit integer. 
• Certificate Requested. A boolean, the default is false. If set to true then the response include two x.509 certificates as part of the returned timestamp. See hierarchy information here. The root certificate is not included with the returned certificates.
• Extensions are not supported.

3. Client authentication and transmit request

• The protocol is via HTTP to ports 80 or 443 with a request header value of 'Content-Type: application/timestamp-query'.
• HTTP Basic Authentication is used for client authentication using your DigiStamp account and password. Or, you can configure your account to use your IP Address to authenticate requests for your account. Other available client authentication options, CMS and client side SSL certificate, can be supported by special arrangement with DigiStamp.
•  
• The URLs for production are (optionally use SSL with https):
• • http://tsa.digistamp.com  (load balances to various locations)
  • http://tsa1.digistamp.com
  • http://tsa2.digistamp.com
• The URLs for Testing timestamps are:
  • http://tsatest.digistamp.com
  • http://tsatest1.digistamp.com
  • http://tsatest2.digistamp.com

4. Verify the returned timestamp

• The X.509 public key certificates are described here.
• The server response contains two elements: 1. The return code is the first few bytes 2. The remainder is actual timestamp. The "return code" can be considered a transient value and if it is 0 "successful" - it can be discarded. The other possible return codes are described in the specification.
• The DigiStamp desktop software can be used to "import", view and authenticate the resulting timestamp (without the "return code" portion described above). On the Windows platform you can rename the file that contains a timestamp as a type ".p7s" and Microsoft Crypto Shell will decode and display any attach certificates (just double click on the .p7s file).
• The public key certificate-chain with a trusted key store is commonly used in the verification of the timestamp signature. The critical task is to verify that the public key that authenticates a timestamp is issued by a valid Audit certificate; described here and here. Here are three approaches:
  1. Easiest: Request that the public key certificates be included with the timestamp response (this is a boolean on the request). This returns two certificates: A. Timestamp B. Audit. Verify this certificate chain to the Root certificate. The Root certificate is downloaded just once from our web site and installed in your trusted certificate store.
  2. Easy and a little more robust: Same method as above, but do not use the Root certificate; instead, put the Audit certificate in your trusted certificate store. More robust because the DigiStamp audit process results in the Audit certificate for the private key that is securely contained in the certified hardware (the chain-of-evidence for the audit process point to the Audit certificate, not the Root certificate).
  3. Alternative: Request that no certificates be included with timestamp request response. Put the timestamp certificate in you certificate store. The problem with this approach is that we change the timestamp certificates and you would need to download/update your certificate store when we do.

The above may look complicated. But, you will find that the software does most of the detailed work without much effort. Also, please contact us if you have any difficulties at support@digistamp.com.