Subject: Re: TSP interoperability testing

From: Peter Sylvester <[email-masked]>
Date: Fri, 15 Mar 2002 21:21:06 +0100 (MET)

Denis, 

although I cannot speak for Thomas with whom I
will most like share very soon some interesting
open source activity: You just experience a delay
caused by some administrational and postal 
problems postponing the begin of the EU project 
openevidence. 
 
Peter

> Date: Fri, 15 Mar 2002 15:02:30 +0100
> From: Denis Pinkas <[email-masked]>
> Organization: Integris. A Bull Company
> To: tho <[email-masked]>, Peter Sylvester <[email-masked]>,
>         Peter Gutmann <[email-masked]>,
>         Taglialagamba Bianca <[email-masked]>,
>         Andrea Caccia <[email-masked]>, Antonio Lioy <[email-masked]>,
>         [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked], [email-masked],
>         [email-masked]
> Subject: TSP interoperability testing
> 
> Thomas (and all the TSP list)
> 
> On January 8, I thanked you for taking the lead of the testing, but until
> now, I have not seen any result, according to RFC 2026.
> 
> On February 18, I have sent a table for helping, but until now, no one has
> indicated that he had started to fill in the matrix.
> 
> I attach again the document.
> 
> FYI, I got delegation for the PKIX chair (Steve Kent) for "documenting the
> specific implementations which qualify the specification for Draft or
> Internet Standard status along with documentation about testing of the
> interoperation of these implementations".
> 
> Unless the table is filed in, the TSP document cannot move to "Draft
> Standard". 
> 
> Regards,
> 
> Denis
> 
> Note: Please always use "TSP" in any of your messages so that they can be
> searched more easily.
> 
>  
> > Tho,
> > 
> > Thank you for taking the lead of the interoperability testing. You proposal
> > sounds very good. However, I would suggest that you continue detailed
> > discussions on this topic by using the direct e-mail addresses of the
> > implementers (that I have used by removing the pkix e-mail list address) and
> > thus not copy the whole PKIX mailing list. I would be pleased to stay on
> > this smaller list since I am interested to follow it.
> > 
> > Regards,
> > 
> > Denis
> > 
> > 
> > > hello everybody,
> > > in trying to organize some interop testing between all the publicly available
> > > rfc3161 implementations I have begun sketching down a set of test vectors and
> > > I'd like to discuss the matter with you ;-)
> > >
> > > the first (TSRQ-G_i) is made up of correctly formatted TimeStampReqs which
> > > we expect to be fulfilled by the TSA.
> > > Starting from a very basic request, we make vary some parameters:
> > >
> > >   o TSRQ-G_001 -> basic request (none of the optional fields)
> > >   o TSRQ-G_002 -> TSRQ-G_001 + nonce
> > >   o TSRQ-G_003 -> TSRQ-G_001 + reqPolicy{=one supported by the actual TSA}
> > >   o TSRQ-G_004 -> TSRQ-G_001 + certReq=TRUE
> > >   ... other
> > >
> > >   for all these TimeStampReqs we expect to get the signed receipt of the
> > >   TSTInfo back from the TSA (which must be then verified in the many ways
> > >   stated by the rfc)
> > >
> > > the second (TSRQ-E_i) is a vector of malformed (in a number of ways)
> > > TimeStampReqs:
> > >
> > >   o TSRQ-E_001 -> bad asn.1 encoding (expected badDataFormat)
> > >   o TSRQ-E_002 -> policy id not recognized (expected unacceptedPolicy)
> > >   o TSRQ-E_003 -> weak or unknown hash algorithm (expected badAlg)
> > >   o TSRQ-E_004 -> wrong protocol version (expected badRequest or badDataFormat)
> > >   o TSRQ-E_005 -> length mismatch in messageImprint (expected badDataFormat)
> > >   o TSRQ-E_006 -> unrecognized extension (expected unacceptedExtension)
> > >   ... other
> > >
> > > the third (SBP-E_i) is `Socket Based Protocol' specific (really there should
> > > be one of these vectors for each of the transport protocols including HTTP,
> > > SMTP, etc. but for now we can start with `Socket Based Protocol' which seems
> > > to be the most widely deployed) and consists of the following:
> > >
> > >   o SBP-E_001 -> packet with pollRep flag set
> > >   o SBP-E_002 -> packet with pollReq flag set
> > >   o SBP-E_003 -> packet with negPollRep flag set
> > >   o SBP-E_004 -> packet with partialMsgRep flag set
> > >   o SBP-E_005 -> packet with finalMsgRep flag set
> > >   o SBP-E_006 -> packet with errorMsgRep flag set
> > >
> > >   for all those above we expect a rejection with failInfo=badRequest
> > >
> > >   o SBP-E_007 -> packet with length discrepancy (or a similar trick to
> > >                  test if there is a time-out mechanism on I/O)
> > >   ... other
> > >
> > > I have just tried to use this framework for testing against my own
> > > implementation, the one from SIA and Peter Sylvester's (no SBP-E_i for him
> > > since the exposed interface is HTTP) and I've found it quite useful as it
> > > offers an _unified_ approach and the possibility to automate the procedure.
> > >
> > > Surely we can go more in-depth than this, and in fact this is just a starting
> > > point.
> > >
> > > tho

---

From: "todd glassey" <[email-masked]>
Date: Fri, 15 Mar 2002 15:23:26 -0800

Mr. Kent - when did you do this and isn't there an issue of propriety  in
this decision?

Todd Glassey
----- Original Message -----
From: "Peter Sylvester" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 15, 2002 12:21 PM
Subject: Re: TSP interoperability testing

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Mar 2002 19:33:05 -0500

>Mr. Kent - when did you do this and isn't there an issue of propriety  in

Todd,

The requirement for progression of an RFC is that we document 
interoperability among at least two independent implementations of 
the protocol in question. The documentation is provided by the folks 
who have performed the testing, usually folks who have implemented 
the protocol, and thus this is typically a distributed activity. 
That's what has happened here. The PKIX list has received numerous 
accounts of TSP testing experiences from a number of implementors of 
TSP clients and servers over several months. I asked Denis, as the 
RFC author, to collect the received info and construct the required 
documentation for submission to the IESG. This is exactly what we did 
for OCSP recently; I believe Ambarish led that effort and he too was 
an author of the relevant RFC.

I see no problem with this approach in general, given the diverse set 
of folks who typically provide the inputs.  I would worry of we had 
only a couple of implementations of a protocol and there might be 
some concern re collusion, but that is not the case for TSP, since it 
is a simple protocol and thus not hard to implement for either the 
client or server side.  Bigger protocols pose more of a problem in 
terms of the scope of interoperability testing and diversity of 
implementations.

Steve