At 10:13 AM 4/26/96, Dave Crocker wrote:
At 4:02 AM -0700 4/26/96, Steve Crocker wrote:
The problem is with multipart/encrypted. And again, the problem
that is the showstopper does not appear to be with the spec. It's
basically fine.
The problem is that it isn't a useful capability unless it can be
meaningfully used to send one message to multiple recipients, with
different security mechanisms, sharing one encrypted content. Without this
benefit, it's just as good to use multipart/alternative and have a set of
wholly independent encryption methods.
That is, we need to be able to generate something like:
multipart/encrypted
application/des3-encrypted
encrypted content
multipart/mixed (alternative?)
application/pgp-encrypted
application/smime-encrypted
application/moss-encrypted
application/msp-encrypted
control information
so that there is one and only one copy of the encrypted data, with
different control sections depending on the certificate scheme being used.
It requires that the different schemes to use exactly the same algorithms
and formats for encrypting the content, however.
It's hard to overemphasize the importance of the previous sentence. If
it's useful and important to provide this capability, then I don't have any
objection to it, but it's also important to note that it doesn't solve the
problem of sending the same message to people using wholly incompatible
encryption schemes.
In the example above, it's obviously understood that des3-encrypted is
compatible with {pgp,smime,moss,msp}-encrypted control information. It's
not completely obvious to me where such knowledge would be distributed and
embedded. Also, the "multipart/encrypted" doesn't give much of a hint that
des3 encryption is what's coming. Suppose, for example, that one wanted to
send the same message to several people, some of whom are using the same
bulk encryption but different control structures, as above, and also to
others who are using an entirely different bulk encryption scheme, e.g. RC4
or IDEA. What scheme would you use, and how would the various recipients
know which one to pick out?
I'm not objecting to any of this, just curious. The idea of sharing bulk
encryption while permitting different control sections was simply not in
front of us at the time we designed MOSS. However, in the spirit of
reusing as much as possible, it seems reasonable.
--------------------
Steve Crocker Main: +1 703 620 4200
CyberCash, Inc. Desk: +1 703 716 5214
2100 Reston Parkway Fax: +1 703 620 4215
Reston, VA 22091
crocker(_at_)cybercash(_dot_)com