Re: TSP interoperability testing

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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 <Denis.Pinkas@xxxxxxxx>
> Organization: Integris. A Bull Company
> To: tho <thomas.fossati@xxxxxx>, Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>,
>         Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx>,
>         Taglialagamba Bianca <bianca.taglialagamba@xxxxxx>,
>         Andrea Caccia <a.caccia@xxxxxxxxxxxx>, Antonio Lioy <lioy@xxxxxxxxx>,
>         r.pedro@xxxxxxxxxxx, r.galli@xxxxxxxxxxx, stefan.kraxberger@xxxxxxx,
>         medina@xxxxxxxxx, caccia@xxxxxxxxxxx, h-iwanishi@xxxxxxxxxxxxx,
>         ramunno@xxxxxxxxx
> 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