Jeff:
... 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.
Brad:
It seems to me that since pem does two distinct functions (encryption
and authentication) there should be two different body part types
used:
I think the current draft on MIME-PEM interaction addresses the issue
without a proliferation of message subtypes and is preferable.
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).
Why do this when PEM already supports multiple recipients within its
headers? Why not, as the MIME-PEM draft currently dictates, keep the
PEM headers together in a part as they are?
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.
I must admit that this is a new functionality. But note that PEM itself
does not support this functionality and perhaps it should be expanded
to, independently of MIME.
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.
Why not create a multipart/digest where each of the parts is a PEM message?
PEM already includes support for multiple recipients as noted and there
need not be a relationship between the recipients of one part and another.
The issue of multiple signers remains and may need to be addressed as a
PEM issue.
-Ray