Project K7 Illudium Ultraspace Gas Factory Time Stamping

The current software version is of March 29, 2006, the previous was of January 19, 2001. It provides all functionality specified in the IETF's RFC 3161 using the HTTP protocol, and a bit more, e.g., fortune cookies. The server allows for many hash algorithm provided by OpenSSL.

Warning: "experimental" means that at any time we can stop the service or refuse to serve clients.

Using the service

If you try the service, feel free to send a message to tsa@edelweb.fr telling us how it had worked for you. In case of problems, you may want to read the Experiences section first.

To access to the service, you can either use some time stamping client, or prepare a time stamp request in the following way:

Create a TS Request as per the encoding specification of RFC 3161. This most likely requires some software called "Time Stamping Client" (unless You are good in message digest computing).
Create an HTTP or HTTPS request (at least of version 1.0).
Use the default value for Transfer-Encoding, i.e., binary.
Use a Content-type: application/timestamp-query.
Respect RFC 2068 when using HTTP/1.1, i.e., don't forget Host:
And don't forget Content-Length.
Send a hash, not data.

Then send the request using POST as method to one of the following URLs:

http://timestamping.edelweb.fr/service/tsp
As indicated, this service uses a standard HTTP protocol to communicate. If the time stamping request contains a return certificate request, the server includes its signing certificate. The authority certificate corresponding to that entity is this. The public key of this certification authority is published in RFC 3029.
https://clepsydre.edelweb.fr/dvcs/service-tsp
The Time Stamping Authority's certificate is the CA certificate from the DVCS server link above. This is provided so clients can build stronger authentication practices. When trying this, you should notice an error.
https://www.openevidence.org/dvcs/service-tsp
This is the same service providing the same time stamps using a different SSL layer, you may need a client certificate from here.

In some examples you might find www.edelweb.fr/cgi-bin/service-tsp or another URL on the same host. Such are not valid. Do not use them, the results may not be healthy for your software. You are warned.!!!! :-)

An HTTP GET request, like if you type one of the URLs above in a browser, redirects you to this page. For POST requests, the server may respond either with an object of Content-Type: application/timestamp-reply which, in case of success, contains a digitally signed time stamp token asserting the existance of the messagedigest (not the existance of any data). For certain errors, the service may return an object of with a Content-type: text/html. In case of an error, the TSA does not generate very detailed information. And, sometimes you may simply get some megabytes of garbage.

Examples

Here is an example of a time stamp request content in a hexadecimal representation and formatted using Peter Gutmann's dumpasn1 program:

3027 0201 01 301f 3007 0605 2b0e03021a 0414 f5c1 1c2a f278 78b3 28ec f05a 8601 0a70 35f6 7c1d 0101 ff <30 27> 0 30 39: SEQUENCE { <02 01> 2 02 1: . INTEGER 1 <30 1F> 5 30 31: . SEQUENCE { <30 07> 7 30 7: . . SEQUENCE { <06 05> 9 06 5: . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) : . . . } <04 14> 16 04 20: . . OCTET STRING : . . . F5 C1 1C 2A F2 78 78 B3 28 EC F0 5A 86 01 0A 70 : . . . 35 F6 7C 1D : . . } <01 01> 38 01 1: . BOOLEAN TRUE : . }

There are many ways to create a request. You may use something like this perl:

use SHA qw(sha_version);

my $sha = new SHA;

binmode STDIN;

while (<STDIN>) {
    
      $sha->add($_);

}

print pack("H*","3027020101301F300706052B0E03021A0414") .
 
      $sha->digest() . 

      pack("H*","0101FF") ;

Or, using some shell, you could do something like:

export HASH=`openssl dgst -sha1 file-to-stamp|tail -c40`

At somepoint in time openssl added some comment before the hash, even for STDIN input, thus the 'tail'. Now use the mini asn1 compiler of openssl with the following content of a file "conf":


asn1 = SEQUENCE:tspreq

[tspreq]

version=INTEGER:1

digest=SEQUENCE:digest

certreq=BOOLEAN:true

[digest]

algo=SEQUENCE:sha1

hash=FORMAT:HEX,OCTETSTRING:$ENV::HASH

[sha1]

shaoid=OID:sha1

parameters=NULL

and


openssl asn1parse -genconf conf -out tsprequest

To contact the server, you can use curl


curl --data-binary @tsprequest \
 
     --header "Content-Type: application/timestamp-request" \

     -o tspresp http://timestamping.edelweb.fr/service/tsp

to get time stamp response.

You may want to verify the stamp. You can do this for example with openssl (which includes a time stamping feature (i.e. "openssl ts") based on work from OpenTSA). If you want to know how to use timestamping with an OO oriented programming toolkit, you may use your favorite search engine and look for "bouncycastle timestamping.edelweb.fr".

Changing the SHA1 to something more modern is left as an exercise.

Service results

The service is has grown exponentially in the first 10 years. Companies like SUN or Adobe are using the service. Some TTPs (e.g. certfication authorities) are using it in regular intervals. From time to time, other time stamping servers come up and go down in the Internet, We have used ourn client software to test about different servers, The number of tests was small and their nature not systematic. We did not try nasty things like badly encoded data units (so far).

Thanks to all who have noted some errors in my implementation.

HTTP as a transport

Some people try to access to the service URL via a GET method, probably just by using a browser. Our service returns with a redirection to this page.
One client tried to encode the time stamp request in base64 and appending it in different ways to the service URL.
One implementation did only one TCP read to retrieve the response. You will only experience it if your MTU is small so that the TCP response is split into more than one packet. This usually doesn't happen in local networks, and it most likely never happens when you don't set the certReq flag.
Some client sent an HTTP/1.1 request without hostname (see RFC2068 sections 9 and 14.23)
When sending an HTTP/1.1 request, some clients don't understand to receive a 100 Continue answer.
Some clients immediately send some garbage after receiving a 403 Forbidden response. The data look like the content of the TSP request.

Socket protocol

Many implementations only use the TCP socket protocol because it seems to be simpler. Nevertheless:

The first 4 octets need to be in network byte order. There are several ways to implement this in a wrong way.
One implementation did not encode correctly the length field, i.e., it was off by one, missing the 'type' octet.
One implementation returned a X'00' type as an answer in some cases instead of a X'05'.
In case of an error, some implementation generated a errMsg response (X'06'). This is incorrect according to the protocol specification.
One implementation sends an invalid length in the header followed by a good number of decodable data.
All implementations closed the connection after having sent the response. So you cannot several requests through the same tcp connection.
Some implementations did not implement any time-out logic for the TCP connection or they are/were simply single threaded. Nice for
Indicating an access method for the socket protocol with a non default port in a certificate is not possible at the moment. Some client implementations use an URL type like 'cmp://host:port' to indicate the socket protocol.

TSP protocol

One server did not return the nonce of the input.
Not all implementation validate whether the returned data correspond to the requested ones. This concerns validation of the returned message digest, nonces, policies, etc.
Signature validation is also not always done completely, in particular, the test for the ESS signingCertificate and the value of the field tsa in the tstinfo structure.
Clients also do not seem to test the value of the tsa field against one of the several name fields in a signing certificate. For more than two years, our TSA did in fact set a wrong value into the tsa field.
The validity period of our TSA's certificate is longer than the validity period of the CA. One client implemenation does not like that.
One officially registered and qualified TSA uses the Issuer of its certificate instead of the Subject as value for "TSA'. The TSA's certificate is without EntendedKeyUsage for time stamping.
One recent TSA accepts any Content-Type.

TSP encoding:

Nobody has tried to send a very long value for a Nonce so far. The length is restricted in our implementation.

Some users succeeded to talk to other servers, but not with us. In almost all cases, the error was an incorrect laxiste implementation of the other server. Frequent errors are related to the provision of the hash value. Some clients just send a hash value, e.g. 20 octets of a hash, or the datainstead of the hash, or a hash value with an invalid length for the hash function.

It seems that actually most decoders in clients and servers are "BER" decoders, or at least subset of it, this does not really create harm but it is not what the document says.
Some decoders or coders correct errors in invalidly encoded integers, OpenSSL for example. There are two types: Some silently remove ONE leading 00 or FF, others remove several of them. The implementation should report an error.
One implementation encoded the position of one error bit as an integer instead of a bitstring.
One implementation seems to accepts badly encoded requests.
One implementation (mine) did not accept a NULL parameter for the digest algorithm.
The example request given above may be considered incorrect, since depending on your current interpretation of X.500, you either MUST or MAY encode a NULL parameter.
The encoding of tsa [0] GeneralName was completely wrong in my implementation. It took some time until it was noticed.
The policy field syntax was changed in draft 9 of RFC 3161 from "PolicyInformation" to OBJECT IDENTIFIER. This hit some implementations.
If the request does not contain a policy, one implementation returned an OID of length 0 as OID.
One implementation rejects the request if no policy was requested.
Some implementations do encode PKIFailureInfo bitstring in strange ways, like a value of unacceptedPolicy(15) encoded as 03 02 00 0f.
Several people have remarked that the requirement for the TSA to "MUST return the same policy" is unnecessary and should be a "SHOULD", but the editor of the RFC doesn't like to change this.
A least one other TSA accepts any data as a hash, without any length checking according to the hash algorithm. This and creates a token containing the data at the place of the hash, nice result when it is a PDF document.

Error generation:

The way how error messages are generated in case of invalid requests are different in almost all TSAs. Some use the socket protocol error code, some create pkistatus with somewhat arbitrary values in FailInfo.
The direct socket protocol is not clear about what to do if the server decides that one message is simply too long, one implementation writes an error message without reading more than the first 5 octets. It is unclear whether clients are prepared to handle this full-duplex communication. Since the server in question also closes the connection after having send the data, it seems likely that clients never get the error message.

More ...

Some parts of the software used by this TSA is available as a result of the EU IST project OpenEvidence.

There are other known implementations freely available. I don't keep track of them, but here are some: The OpenTSA project for another implementation based on openssl (which has been included into the openssl) and for JAVAoids there is the Bouncycastle.

A list about everything you want to know about time stamping has been compiled since years by Helger Lipmaa.

Time stamping based on RFC 3161 may not be the last word. Other techniques exist, which do not use digital signatures for long term; an implementation is available in the OpenEvidence project.

The initial authors of RFC 3161 were also at the origin of RFC 3029 aka DVCS. This protocol also contains a more enhanced time stamping service which had been implemented in the Clepsydre time stamping demonstrator project for the French Postal Service in 2000.

Statistics

After 10 years, here some statistics showing the numbers of generated tokens each year. No, the figures are not cumulative, there is nearly exponential growth.