Re: New test TSA available

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

tho <tho@xxxxxxxxxx> writes:

>draft (rfc) states that "The eContent SHALL be the DER-encoded value of
>TSTInfo" instead it seems that you wrapped it into a further SEQUENCE so that
>the resulting token appears as
>
>[...]
>
>is there any particular reason for this double wrapping ?

Yes, PKCS #7 and AuthentiCode.  What happened was that RFC 2630 slightly
changed the definition for eContent, in PKCS #7 this was:

        content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL

but now it's:

        eContent [0] EXPLICIT OCTET STRING OPTIONAL

however there are some implementations which still use the PKCS #7
interpretation (specifically, AuthentiCode, which AFAIK is the only widely-
deployed implementation which signs something other than data (= OCTET STRING)
content).  This uses the ANY DEFINED BY interpretation where ANY is a SEQUENCE
{ ... }, so you get:

        content [0] EXPLICIT SEQUENCE [...]

rather than an OCTET STRING.  My code has a horrible kludge in there to check
the contentType and vary the encoding depending on whether it's an
spcIndirectDataContext or not, so it will produce this encoding as well under
the right circumstances (and in fact in the TSTInfo you saw it had this turned
on for any eContent type, which was wrong, I'll rebuild the test program with
the option disabled in a minute.  With any luck I'll have broken the
AuthentiCode handling now :-).

(I've suggested to the RFC 2630 author that it might be worth including a
cautionary note about this in the RFC update).

Peter.