Subject: Re: Experimental TSA

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Oct 2000 18:06:04 +0200 (MET DST)

good news.

I have forgotten to cross post the following.

An experimental TSA is available using HTTP and HTTPS,
details how to read it are available under

  http://www.edelweb.fr/tsa.html

The TSA was developed using openssl.  

Peter Sylvester

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Oct 2000 19:37:01 +0200 (MET DST)

> 
> Jean-Marc,
> the proposed protocol could be fine but you know
> that the Time Stamp Authority is one for many different clients
> so the protocol is usually decided by the TSA.

> Is very difficult to serve different clients with different protocol ideas.
Indeed. That's why it necessary to discuss possible ambiguities
in protocols. 

> We need more explicit formalization for this kind of extensions.
> 
> And also what about the "denial of service" problems arised from a client which
> doesn't close the connection and let the server waiting indefinitely or in
> the better for a timeout?
This problem is not much different from those that any web server is
faced today. 

You have the same problem when the client opens a connection and doesn't send
data. Does your server has a time out for that? At least it is pretty long >1h,
as far as I can say. :-) 

> Our TSA implementation close the connection after a Token is sent back to
> the client.
It is a simple solution that works. Anyway, it is good to have something
to experiment with. 

Have fun
Peter

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 13 Oct 2000 12:22:26 +0200 (MET DST)

> 
> Therefore it's more constructive to see if there's a way to work around these problems, and
> what should be the best way for that, than to simply complain.
> 

I may have been misunderstood, the first part of your statement is the
exact purpose of this discussion of early experiemnts. First, it
helps to identify certain problems, then we can find a way to 
handle this in whatever way. 

As I said, the problem is not in the server: In any case, at least
one message and answer get through. It may be a problem for a client,
if the client first wait for the connection to end before treating
a response, or client must not assume that the connection will
be closed by the server. That's all what I think needs to be 
understood.