Re: tsp interop test vector (proposal)

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

tho <thomas.fossati@xxxxxx> writes:

>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 ;-)

I don't know how well some of the negative-response testing will work.  For
example most of the policies I've seen are either unknown or just randomly-
invented OIDs, so my implementation ignores policies because otherwise it
couldn't interop with anything at all.  Based on the incredible number of bugs
in related stuff like certs (see for example the X.509 style guide) I'm also
extremely flexible with message contents, for example if the field looks more
or less right or doesn't affect the entire operation I just skip it and move
on.  In particular I ignore most of the stream-protocol flags based on the
confusion I saw in CMP interop testing when, no matter what flags were
(presumably erroneously) set, the other side usually just wanted the most basic
request-response operation.  Trying to fiddle with polling when the other side
has lost interest and gone home doesn't make your software look very functional
to the user.

(Aside: I have probably spent about an order of magnitude more time adding
 workarounds for bugs to my cert-handling code than in writing the original
 code itself.  Over time, I've also removed more and more checks on (non-
 security-related) items in order to get it to work with broken certs coming
 from other software.  There are still (security-related) checks in there which
 are rejecting certs which result in people sending me "bug" reports, but I'm
 not going to remove those... as a non-commercial vendor I can afford to lose a
 few users if they think it's a problem).

I would expect that other implementors are also writing code which tries to
DTRT in the face of broken requests and implementations.  This means that a lot
of the negative-response tests you're proposing would fail, because the other
side would look at the problem, decide it's irrelevant to the operation of the
protocol, and continue.  For example my policy OID is:

/* Dummy policy OID for the TSA ('snooze policy, "Anything that arrives, we
   sign") */

and I've never found an implementation which has any problems with this.

Peter.