"Phil Smiley" <phillipsmiley(_at_)attbi(_dot_)com> writes:
My company is evaluating a number of options for deployment of AS2 in our
product. In one of our evaluation meetings, it was said that care must be
taken when choosing the correct S/MIME toolkit because of the dependence that
S/MIME has on ASN.1 and the complications that introduces.
Given that any vendor which plays in this area has (presumably) done
reasonable interop testing, there isn't much in the way of complications,
unless you're using oddball/obscure features. When I looked at it a few years
back using standard signed/encrypted data, the code I was using worked out of
the box with the apps I tried it with (Outlook/Netscape/whatever Tumbleweed's
one was called then/etc).
(Having said that, I've seen a few homebrew implementations from Europe
deployed in vertical-market applications (e.g. your CA also sells you the
software you use, and you can't talk to anyone else) where the vendor never
did any interop testing and the data formatting is often surprising, but
that's the exception rather than the rule).
I can accept that certificates and related cryptographic materials are DER or
BER encoded but I would expect that to be done by a cryptographic toolkit
from RSA, Baltimore Technologies, Certicom, etc. I would not expect this to
be value added by an S/MIME toolkit.
There's no difference between a "crypto toolkit" (which does the PKCS #7/CMS
data format) and an "S/MIME toolkit", S/MIME is just PKCS #7/CMS with base64-
encoding. In other words, you use a crypto toolkit to do PKCS #7/CMS, and an
MUA/MTA to do the MIME part.
Peter.