The frustrating point that keeps coming up is this. Although "fixing
the gateways" is the right thing to do, it is simply unacceptable to not
have secure email until all the gateways are fixed. Therefore, we have
a need for two formats, hopefully evolving to one in the future.
I do know one way to have a single format which serves both needs. It's
called content duplication (i.e. multipart/signed and signedData in a
single message) and was the basis for the original S/MIME proposal 2
years ago. It's awfully unpopular and has a lot of wierd potential side
effects but it seems to work. Don't get me wrong, message bloat is a
_really bad thing_. Maybe the time is right to revisit if it is a
_worse_ thing than having two signature formats...
-steve
----------
From: Ned Freed[SMTP:Ned(_dot_)Freed(_at_)innosoft(_dot_)com]
Sent: Friday, August 01, 1997 9:08 AM
To: Blake Ramsdell
Cc: 'ietf-smime(_at_)imc(_dot_)org'
Subject: Re: application/signed vs. application/mime vs. signedData
In the hopes of getting closer to consensus, I'm clearing the slate.
I think we've determined that there is still a need to have two formats,
one that is suited to preserving content, and one that suited to
preserving signatures.
Well, I for one disagree with this assessment. The problem with having two
formats is that it then becomes a matter for the sender to choose which one
to
use. And that's simply wrong -- this choice cannot in general be made
intelligently by the sender. (I'm sorry, but a lot of situations exist where
knowledge of the recipient doesn't exist, and I've yet to see a proposal that
deals with what happens when the capabilities of the recipient change over
time.) What you're again trying to do is second-guess any gateways that may
be
present. And while I continue to think that this is mostly harmless, I also
continue to think that it is mostly futile. Use application/mime and my
gateway
will treat it as composite. Nothing gained or lost. Use application/smime and
my gateway will treat it as composite. Nothing gained or lost. Play around
with
encodings and my gateway will decode them all. Nothing gained or lost. Use
signedData in the process raising the bar for gateways to play, and get
widespread deployment and you'll get two things: You'll have pissed off the
gateway vendors and you will force them to implement a lightweight PKCS#7
parser. Here all you gain is the emnity of the gateway implementors, so that
when you do decide to call upon them for a real solution you won't get
anywhere.
FWIW, I do not see application/[s]mime as a second format option. I would
expect it to be used unconditionally if it is used at all. I would also
expect
to see a rapid response from gateway vendors if it comes into widespread use.
Note that another way to do this would be to simply replace the
multipart/signed label with an application/signed label, and don't add any
extra level.
Because we have not been able to arrive at one
format that satisfies both goals, two formats are needed. Because we
have two formats, it is a client determination as to which one gets
sent.
No. What is really needed is a single format and rules for how gateways have
to
handle it. The IETF needs to stop pretending that gateways don't exist and
can
be ignored or worked around.
Ned