On the 822 list Ned recently suggested that it might be possible to use
security multiparts to efficiently send an encrypted message using several
security services at once. For example, a message with both PGP and MOSS
encryption. What I want to bring up is the question of how this could
work. First some background:
The obvious way to do this now would be to build two entirely different
multipart/encrypted body parts, one for PGP and one for MOSS. They then
would be included in the outgoing message with multipart/alternative. This
will double the size of the message. However, if both of the security
services used the same symmetric data encryption algorithm it seems it
might be possible to include the main content of the message only once and
reuse that part for both of the security service. (I believe that MOSS and
PGP don't share the the data encryption algorithm at the moment).
Now the question is, how do you include the control information (which
includes the secret key for the symmetric algorithm) for both the security
services? RFC 1847 is explicit about there being only two parts in any
security/multiparts body part, the control information for one security
service, and the protected data. I could imagine defining some
multi-security service body part that allows multiple this. That or
changing RFC 1847. I'm not sure this feature is so important that 1847
should be changed for this, but I thought it was worth bringing up.
Another question: In RFC 1847, I was wondering if it might not be a good
idea to suggest that UA's should inform users that a signature could was
not verified because the particular security service was unavailable. It
doesn't seem like it should be required, but it seems a helpful thing to
do, especially for a UA that automatically verifies signatures.
Last, it's beginning to dawn on me that real strength of security
multiparts is its generality and usefulness in the long term. For example,
it seems possible to build support for security multiparts into the MIME
machinery of a UA and then more easily swap security services in and out as
security requirements change over the years. This seems important and I
haven't seen it mentioned explicitly here before.
Laurence Lundblade lgl(_at_)qualcomm(_dot_)com
QUALCOMM Inc. 619-658-3584