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.
What "powerful security semantics" are you talking about? V3 certificates? If
so, you should know that S/MIME does NOT require that V3 certificates be used.
In fact it doesn't even require support for them. (This as of the August 29,
1995 docs.) As far as security services go S/MIME is basically RFC1421-style
PEM with the addition of 40 bit RC2 as a private key system. (This last is
obviously motivated by the desire to use this internationally.)
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.
Say what?!? I disagree 100% with this assessment. In fact its the other way
around. MOSS exploits a much more powerful and general abstraction -- a new
subtype of MIME's multipart -- rather than adopting the S/MIME course of
over-defining the far weaker and far less general abstraction available in PKCS
#7. I've already demonstrated, and as yet no one has come close to refuting,
the various problems inherent in the S/MIME approach that are the result of
essential weaknesses in their abstraction mechanism.
I challenge you to come up with an example where S/MIME's abstraction mechanism
is demonstrably more capable than that of security multiparts.
The S/MIME properties have been shared widely with the software industry by
RSA DSI.
Not at all. They have been shared only after they were developed.
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?
Even if we were willing to do this, there would be absolutely no need to. The
present model already allows multiple security services to coexist. The IETF
could standardize one of them or a million of them. (Hopefully not the
latter...) MOSS is just the first one to appear -- there are guaranteed to be
others. As it happens I am reviewing a draft for PGP integration into MIME
right now. S/MIME could easily become the third, without withdrawing anything.
It is clear that you do not understand IETF, the work we've done in this group,
or this work is to be used. I suggest that you review the security multiparts
document again -- it would be trivial to retrofit S/MIME into this framework,
and doing so would fix all of the problems I've pointed out.
Given the linkage with the v3 certificate
key management framework, this will take a long time, based on previous
experience
with this list!
What linkage? The use of v3 certs is a separate matter. Work in this area is
already well underway on the PKIX mailing list.
As for it taking a long time, while it is true that work on this list has taken
far too long to accomplish, this has not been the case with many if not most
other IETF efforts. Since this group is now defunct, any future work on v3
certs or on anything else will not be done here.
Ned