|
|
 |
Technical details about integrating time stamp servers |
|
|
|
| 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 time stamp 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 time stamp software that you choose will handle the low
level details like PKCS7 record structures, x.509 certificates and ASN
encoding.
|
|
| Time stamp process flow |
| Steps |
Notes - low level details that are managed by the DigiStamp toolkit |
1. Calculate the hash of your data object. |
Supported algorithms and their object identifiers:
SHA_1, "1.3.14.3.2.26"
SHA256, "2.16.840.1.101.3.4.2.1"
SHA384, "2.16.840.1.101.3.4.2.2"
SHA512, "2.16.840.1.101.3.4.2.3"
RIPEMD_160, "1.3.36.3.2.1" |
2. Create the encoded time stamp 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 default response
"1.3.6.1.4.1.8291.1.1"
- Nonce. Optional with a length of up to a 64 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
time stamp. See hierarchy information here. The root certificate is not include 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. Other available client authentication options, CMS and client side SSL certificate, can be supported by special arrangement with DigiStamp.
- The URLs for test are:
http://tsatest1.digistamp.com/tsa
http://tsatest1.digistamp.com/tsa
The URLs for production are (optionally use SSL with https):
http://tsa1.digistamp.com/tsa
http://tsa2.digistamp.com/tsa
- Failover is automatically provided in the DigiStamp toolkits. Failover
is the behavior that if one of the TSA servers is not available then automatically
use the alternate server. In other client time stamp packages you may need
to add this function of using an alternate server.
|
4. Verify the returned time stamp |
- The DigiStamp servers use the RSA algorithm with a 2048 bit key. The public
key certificates are describe here.
- The server response contains two elements: 1. The return code is the first
few bytes 2. The remainder is actual time stamp. 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 time stamp (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 time stamp signature. The critical task is to
verify that the public key that authenticates a time stamp is issued by
a valid Audit certificate; described here and here. Here are three approaches:
- Easiest: Request that the public key certificates be included with the
time stamp response (this is a boolean on the request). This returns two
certificates: A. Time stamp 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.
- 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).
- Alternative: Request that no certificates be included with time stamp request
response. Put the time stamp certificate in you certificate store. The
problem with this approach is that we change the time stamp 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 |
|
|
|
|
|
 |
|
|
