Phil,
At 7:55 AM 12/15/94, Phil Smiley wrote:
As a start, we could enumerate the object security requirements of the
existing
applications and get some idea of the scope of the problem. However, to be
Let me suggest a rather different approach, since I fear that the
do-a-study approach walks down a path of very, very long production cycles
before anything useful emerges. Besides, that's not the way work is done
in the IETF.
Let me suggest the strawman approach, in particular that we start by
asserting that Mime is an object standard and that the multipart/encrypted
and multipart/signed mechanisms provide substantial, initial utility. Let
me suggest that the key deficiencies to this model/method be defined, to
see whether relatively small changes will permit relatively quick use.
"Key" deficiencies are fundamental showstoppers for basic functionality.
They are NOT a matter of added functionality that many would like to see,
but rather would keep Mime from being used today.
That is, I'm suggesting that there is immediate utility in having basic
authentication, privacy and integrity. (This is not a random assertion.
The feedback from my EDI working group is quite clear on this point. So is
the pressure for this utility NOW. So is the pressure from the Web
community.)
The issue is not whether it would be nice and useful to have a range of
additonal security-related features, such as non-repudiations and
authorization, but that we should get immediate utility where we can and
while we are developing the broader set of functions.
Comments?
d/
ps. In case it isn't obvious from the sequence of my messages, I'm quite
concerned that the production-cycle from this working group may get too
long for utility in the Internet. In fact, I'm concerned that this may
already be true.
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086
dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu