EdelWeb Experimental Time Stamping Service

Space Jean-Dominique LOT

Since October 2000 EdelWeb provides an experimental time stamping service based on The IETF's RFC 3161. This effort has been done as part of EdelWeb's  Project K7 Illudium Ultraspace Gas Factory. The current software version is of March 29, 2006, the previous was of January 19, 2001. It provides all functionality specified using the HTTP protocol, and a bit more, e.g., fortune cookies. Since people asked for it, the server now allows several hash algorithms with 160 bits or more. The service has been brought to you by Peter Sylvester.

Warning: The word "experimental" means that at any time we can stop the service or refuse to serve clients, in particular, when we think that clients consume too much of our resources. Clients requesting timestamps in a loop are not welcome.

If you try the service, we would really see some feedback from you. Please feel free to send a message to tsa@edelweb.fr telling us how it had worked for you, see also the previous warning. :-) In case of problems, you may want to read the Experiences section first.

To access to the service, you can either use some time stamp 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.

Time Jean-Dominique LOT

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/tsa/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.

If you read this page using a standard browser you have probably tried to obtain one the two URLs above using an HTTP request with a GET method.

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. For certain errors, the service may return an object of with a Content-type: text/html.

The Disintegration of Persistence of Memory Salvador Dali

Here is an example of a time stamp request content in
a hexadecimal representation	and also 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 () {    
      $sha->add($_);
}
print pack("H*","3027020101301F300706052B0E03021A0414") . 
      $sha->digest() . 
      pack("H*","0101FF") ;

Or you could (adapt this to you favorite shell):

 
export HASH=`cat file|openssl dgst -sha1'

and then 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 could use curl

curl --data-binary @tsprequest 
     --header "Content-Type: application/timestamp-request"
     -o tspresp http://timestamping.edelweb.fr/service/tsp

and get your stamp. finally, you may want to verify the stamp using the latest version of openssl which includes a time stamping feature (i.e. "openssl ts") which had been integrated into openssl based on work from OpenTSA.

Raum - Bewegungen Peter Sylvester, that's not me.

Experiences

The service s delivering betwenn 10000 and 40000 timestamps per month. Sometimes drastic ds are necessary to stop some people.

From time to time, other time stamping servers come up and go down in the Internet, and sometimes people seem to use my server for testing their clients. I have used my own client software to test about 10 servers; The number of tests were not enormous and not systemtic. So far, I did not try nasty requests with really badly encoded data units. Furthermore, 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. (Guessed from an error report about a truncated response.) This error is tricky, because yu will only experience it if your MTU is samll enough to get the TCP response split into more than one packet. This doesn't happen in many local networks, and it doesn't not happen 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:

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. This is a pity, since it doesn't make it possible to make several requests through the same tcp connection, even with some pre-emption logic, something that seems to be one of the goals of this transport protocol. I think 3161bis should have a sentance "The client MUST close the socket if it does not want to send another time stamp request to the server." and "It is recommened that server implementations accept several requests over the one connection and do not close the connection immediately.

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 client sent data instead of a hash. A least one of the other known TSAs accepts this.
• A

TSP encoding:

• It seems that actually most decoders are "BER" decoders, this does not really create harm but it is not what the document says.
• Some decoders or coders correct errors in invalidly encoded integers. 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.
• The policy field syntax was changed in draft 9 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.

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.

Zeit - Folgen - 1 Peter Sylvester, that's not me.

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.

---

The Project K7 Illudium Ultraspace Gas Factory is a test bed for the Illudium Q36 Explosive Space Modulator.
The Space and Time pictures are from Jean-Dominique Lot Copyright (C) 2002, All Rights, reserved.

Maintenance of this site: Peter Sylvester <peter.sylvester@edelweb.fr>