It is true that S/MIME exploits more powerful abstractions than MOSS - being
designed to be part of a protection system covering upper-layer
referral/hypermedia, versus classical comsec, communication models.
I'm not sure I follow you. I've been following the S/MIME spec from the
early stages, and understand it to be just a straightforward way of
encapsulating a PKCS7 message for MIME-compliant mail transports.
What kind of "upper-layer referral/hypermedia" orientation are you
referring to? By my reading, anyway, it addresses the same communication
models as PKCS7 itself, which is primarily a message-oriented comsec
service.
I'm not as allergic to S/MIME as Ned and Dave, simply because I haven't
perceived S/MIME as a "competitor" for MOSS. It doesn't secure MIME
message elements, it simply specifies a single MIME encapsulation for
PKCS7 messages. The two offer different services at different levels.
If I want to be able to sign/verify/encrypt MIME messages and message
elements, I'll use MOSS. If I want to allow two PKCS7 messaging systems
to interoperate via SMTP, I'll use S/MIME. I actually see no reason
to integrate the two--S/MIME is simply a standard labeling for a particular
file format, and such is more akin to "application/pdf" or
"video/quicktime" than "multipart/signed" or "multipart/encrypted".
Personally, Im torn on such a question. Do we publish a MOSS RFC which is (in
my
own personal view) too late for the messaging industry's technology
migration curve,
or do we delay yet more?
I do not think that MOSS is behind the curve. I would very much like to
see it published as an Internet standard, and leave S/MIME as an informational
RFC describing RSA's recommended MIME encapsulation for PKCS7 messages.
Amanda Walker
InterCon Systems Corporation