[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TSP interoperability testing
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" <Peter.Sylvester@xxxxxxxxxx>
To: <thomas.fossati@xxxxxx>; <Peter.Sylvester@xxxxxxxxxx>;
<pgut001@xxxxxxxxxxxxxxxxx>; <bianca.taglialagamba@xxxxxx>;
<a.caccia@xxxxxxxxxxxx>; <lioy@xxxxxxxxx>; <r.pedro@xxxxxxxxxxx>;
<r.galli@xxxxxxxxxxx>; <stefan.kraxberger@xxxxxxx>; <medina@xxxxxxxxx>;
<caccia@xxxxxxxxxxx>; <h-iwanishi@xxxxxxxxxxxxx>; <ramunno@xxxxxxxxx>;
<Denis.Pinkas@xxxxxxxx>
Cc: <ietf-pkix@xxxxxxx>
Sent: Friday, March 15, 2002 12:21 PM
Subject: Re: TSP interoperability testing
>
>
> 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