Subject: Re: Experimental TSA

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Oct 2000 19:30:44 +0200 (MET DST)

> Rigth now the only interface available is the socket based protocol defined in
> the
> draft-ietf-pkix-time-stamp-09.
> 

With some first tests of sending

   0 30   36: SEQUENCE {
   2 02    1:   INTEGER 1
   5 30   31:   SEQUENCE {
   7 30    7:     SEQUENCE {
   9 06    5:       OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            :       }
  16 04   20:     OCTET STRING
            :       0D E8 66 25 D3 87 2E 02 45 4F 57 94 BD EC DC F6
            :       4F AA 95 77
            :     }
            :   }

I got back a rejection with a bitstring
encoded as
 
   30 0c 30 0a 02 01 02 03 05 00 00 00 00 05

or: 

   0 30   12: SEQUENCE {
   2 30   10:   SEQUENCE {
   4 02    1:     INTEGER 2
   7 03    5:     BIT STRING 0 unused bits
            :       00 00 00 05
            :     }
            :   }

BTW: I think the example of the Graz implementations is wrong:

direct TCP-based TSA message:
00:00:00:37:00:30:34:02.....
XXXXXXXXXXX

This doesn't seem to be network byte order. 

shouldn't this be 

37:00:00:00:00

Furthermore both implementions close the connection after sending the response.
This is unfriendly and pretty inefficien if you want to send may requests,
I am not sure whether this had been intended by the protocol. 

The length field at the beginning indicate to the client and to
the server how many data are transmitted in an exchange. 

it seems that the same problem occured in the CMP interoperability tests,
and this has already resulted in a draft.

---

From: Raffaello <[email-masked]>
Date: Thu, 12 Oct 2000 14:29:16 +0200

Peter,

The TimeStamp protocol  doesn't require to leave the connection open for
other possible requests after the first has been processed.

So if you want to send many requests at the time you need to do many connections.

We could provide some extension payload to the socket based  protocol
to support multiple requests in a single packet (modifying the actual draft, but I
do not
think this is the right time to do that).

Raffaello

Peter Sylvester wrote:

> This is unfriendly and pretty inefficien if you want to send many requests,

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 12 Oct 2000 15:05:41 +0200

> other possible requests after the first has been processed.

Doesn't require, but doesn't restrain either.

What's more :
  There is no mandatory transport mechanism for TSA messages in this
  document.  The mechanisms described below are optional; additional
  optional mechanisms may be defined in the future.

> do not think this is the right time to do that).

Nothing restrains the client and the authority to have an agreement to exchange
several messages in a row in the current proposal.
The problem is that with the current protocol, the client and the TSA need to agree on
that out of band.

This said if we take HTTP 1.1 as an exemple, the server might decide to answer in HTTP
1.0 to an HTTP 1.1 request and close the connexion.

The only difference here is that the client has no way to tell explicitly the TSA that
he wishes to keep the connexion open after the first message.

That means a TSA that's able to handle another request on the same connexion, has to
leave the connexion open after sending the answer and watch if the client decides to
close it.

The client just has to check if the connexion is still open before sending the second
message.

This seems to me to work quite well, even if it's not as elegant as explicitly telling
whether there will be several messages or not.

---

From: Raffaello <[email-masked]>
Date: Thu, 12 Oct 2000 16:50:53 +0200

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.

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?

Our TSA implementation close the connection after a Token is sent back to
the client.

Raffaello