Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard

From: [email-masked] (Peter Gutmann)
Date: Thu, 3 Jan 2002 13:58:01 +1300 (NZDT)

Denis Pinkas <[email-masked]> writes:

>The goal is to be able to perform interoperability testing among at least two
>of these implementations, so that we can report on these tests at the next
>IETF meeting in Minneapolis. This is a necessary step to be able to progress
>RFC 3161 from Proposed Standard to Draft Standard.

I've interoperated with Peter Sylvester's TSA and the timeproof.de one.  I've
never seen the IAIK one running, and there was one at 203.238.37.132:3318 which
I've got question marks next to so I assume that one was never active either.

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 4 Jan 2002 15:51:34 +0100 (MET)

> I've got question marks next to so I assume that one was never active either.

The IAIK TSA was riunning from time to time, I have made a few tests with them. 

Anyway: I am not sure whether it is sufficient to just test sending
'correct' data. I have spend some time sending almost arbitrary data
as requests, both on the TCP socket layer level and as request PDUs
*IN A CLIENT*. 

I am not sure whether there are client or server implementations that
voluntarily send back *wrong* data in order to validate whether the
different MUSTs in the text are respected. 

I would like to invite the editor of the text to review the archive
to see whether comments for changes or enhancements had been rejected
with a reason like 'not now, we can do this in the next round,',
'we can do this later, we need a stable text now'. 

I think there are quite a few of them. 

Some questions that come out of my limited memory: 

- alignment of the socket based protocol with the CMP socket transport?

- How can one indicate a scket protocol transport with a non default
  port in a certificate. 

- How can one correctly create a TSA certificate respecting
  the rules set in TSP. How to do POP of the key.

- Can two time stamps be compared?

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 5 Jan 2002 05:06:10 +1300 (NZDT)

Peter Sylvester <[email-masked]> writes:

>Anyway: I am not sure whether it is sufficient to just test sending 'correct'
>data. I have spend some time sending almost arbitrary data as requests, both
>on the TCP socket layer level and as request PDUs *IN A CLIENT*.

Oh, so you were the one causing all the "Bad data format" entries in the error
log :-).

>voluntarily send back *wrong* data in order to validate whether the different
>MUSTs in the text are respected.

My TSA did that once.  Definitely a deliberate error to test clients, and not
me mis-reading the spec :-).

>- How can one indicate a scket protocol transport with a non default port in a
>  certificate.

I've been using cmp://fqdn:port.

Peter.

---

From: Scott Mustard <[email-masked]>
Date: Tue, 8 Jan 2002 14:46:58 -0500

Datum's StampServer is available for test at 64.241.183.87.  If your request
includes the certReq field set to true, the time-stamp token will include an
attribute certificate in addition to the required TSA certificate.  Some
decoders cannot handle attribute certificates in the certificate list.  If
you have a problem decoding our response, we can supply the ASN.1 definition
for attribute certificates and for our timing-metrics attribute.

Regards,

Scott Mustard

Datum - Trusted Time Division
http://www.datum.com/tt/
10 Maguire Road Suite 120
Lexington, MA 02421-3110

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 9 Jan 2002 16:55:27 +1300 (NZDT)

Scott Mustard <[email-masked]> writes:

>Datum's StampServer is available for test at 64.241.183.87,

Which port, and which protocol?

Peter.

---

From: Jason Yeung <[email-masked]>
Date: Wed, 9 Jan 2002 15:04:40 +0800

I have tried it successfully, port 318 thru tcp socket.

Rgds,
Jason

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 09, 2002 11:55 AM
To: [email-masked]; [email-masked]
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard

Peter.