Jeff notes:
... different body parts to be encrypted for different principals.
I can envision applications where someone might send me a multi-part
message where some of the parts are encrypted, but not for me.
Instead I forward these parts (perhaps with additional information)
to other parties who can decrypt them.
This is an entirely credible scenario. One should be able to delegate
virtual papershuffling chores without worrying about the clerk steaming
the envelopes or jewelry boxes open just because all arrived in the same
shipment and he's allowed to read the cover letter.
MIME's message/rfc822 is a simple way to recursivly encapuslate
messages withing messages. Assuming we have a pem message type which
encloses an arbitrary rfc822 message this is easy.
It seems to me that since pem does two distinct functions (encryption
and authentication) there should be two different body part types
used:
message/encrypted would be a multipart type ("boundary" defined in the
usual mime way) the first n parts would be keys for each of the
targeted recipients. The last part would be the encrypted message
itself. The enclosed message would only need a few 822 headers (like
Subject: for example).
message/signed would be also be a multipart type ("boundary" defined in
the usual mime way) the first part would be a message the rest of the
parts would be signatures. This would facilitate multiple signers on a
single message.
This is certainly one way you can do it; as a matter of fact our original
attempt at this stuff used pretty much this sort of scheme. However, on
consideration we chose to do it slightly differently in our I-D. Please get a
copy of draft-ietf-pem-mime-00.txt from the nearest I-D site; although this is
somewhat out of date and will be replaced shortly it is more than sufficient to
provide a context for discussions of these issues.
To do the above, you would create each seperate part of the message,
encrypt the sensitive ones and include decriptions keys for each of the
recipients that need them. Bundle these together into a message/rfc822
type. Enclose that in a message/signed with a signature. Encrypt the
result and create decryption keys for all recipients.
This is all addressed in detail in the I-D; we provide a model for this sort of
thing and suggest some ways of implementing it. The issues that came up in the
working group changed some of the implementation details without mucking up the
model much at all.
Now you have a single signed message parts of which can be read by
several different people.
There are all sorts of neat things that PEM and MIME together can do for you.
We'll probably need to write some informational stuff about this in the future;
the critical thing that needs to be done now is formalization of how you
combine them. As I have said on more than one occasion, I'm less concerned with
how we formalize their combination than with how we prevent them from clashing
disasterously. I believe the integration we've proposed is our I-D fine, but it
is just one of several nearly equivalent ways it can be done.
Ned