Since October 2000 EdelWeb provides an experimental time stamping service.
as part of EdelWeb's Project K7
Illudium Ultraspace Gas Factory.
Die Zeit gut auszufüllen,
le mérite des Allemands,
ist das Verdienst der Deutschen,
c'est de bien remplir le temps;
sie vergessen zu machen,
le talent des Français,
das Talent der Franzosen,
c'est de le faire oublier.
(Madame de Staël)
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.
If you try the service, feel free to send a message to email@example.com 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:
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.
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.
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.
Here is an example of a time stamp request content in
a hexadecimal representation and formatted using Peter Gutmann's dumpasn1 program:
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.
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) use 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 section 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.
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.
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.
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  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.
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.
After an problem in our infrastructure, on NTP server was no longer available, and we accumulated a shift of almost one minute into the future. It seems that nobody actually checks whether the returned time stamps are "plausible".
About 500000 timestamps are concerned. Due to the time travel to the presence, some timestamps of 25 november 2013 are issued after others showing an earlier time.
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.
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.
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.
The Project K7 Illudium Ultraspace Gas Factory is a test bed for the Illudium Q36 Explosive Space Modulator.