Its different because most security multipart messages will be signed in their
entirety. There is no reason to do otherwise. This contrasts sharply with
S/MIME, where most if not all messages are destined to be in some variant of
this peculiar format, where servers will have no choice but to deal with a
mixed semantic bag.
Freed and Crocker have both expressed community concern that S/MIME was
developed outside
the IETF framework. There was no choice under the friendly rules we all
follow here; the
MOSS activity within PEM-WG actively reached consensus that IETF standard's
activity on more
powerful security semantics should be avoided until the IETF can first get
MOSS through
to at least RFC status.
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.
The S/MIME properties have been shared widely with the software industry by
RSA DSI.
If the rules of this group can be changed, then it would be appropriate to
review S/MIME
in its entirety. Are we willing to withdraw the request to promote MOSS to
RFC status
in order to pursue S/MIME integration? Given the linkage with the v3 certificate
key management framework, this will take a long time, based on previous
experience
with this list!
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?
Peter.