Ned,
Many thanks for the (as always) thorough explanation. I had forgotten
about the desire for extra flexibility.
At 11:32 AM 10/27/95, Ned Freed wrote:
But now consider what happens with multipart/encrypted where the various
underlying services all support a common interchange service. Now all you have
Just to make sure that I've got the idea and -- more importantly -- a
terse way to describe it, let's see if the following is an acceptable
summary, albeit one that loses much:
Having multipart/encrypted with the security control information
separate
from the encrypted data greatly facilitates support of exchanges whereby
everyone is using the same data encryption mechanism but different "key
management" schemes.
(In this context, I'm using the term key management to subsume all of
the
work that uses public and accomplishes the "setup" necessary to share the
data-encrypting key. I think such terminology is understandable by average
folk, without getting into all the goo and hair that most folk do NOT want
to hear about. Whaddaya think?)
the blob effect to hide what's key and what's data is nothing but security by
obscurity. And as for hiding the use of encryption, the requirement that we
I concur. (Though one must be amused to see all the IP address
translation (NAT) hype being justified in terms of improving corporate
security...)
My curiosity was for simplicity of mechanism and not about added
security.
The multipart/encrypted mechanism is a tad more mechanism that a single
blob. Not offensively more, just enough to make folks curious.
multipart/encrypted with a blank first part. Its ugly and its loses most of the
benefits of multipart approach, but at least you don't have to add additional
dispatch capabilities to your MIME agent when new subtypes are defined.
Interesting idea.
Again, thanks. Hope this also helps others on the list.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr.
dcrocker(_at_)brandenburg(_dot_)com
Sunnyvale, CA 94086 USA http://users.aimnet.com/~dcrocker/
*** Email address is changed from the
*** long-standing stanford mailbox