Or, you could try a 4th option...
(4) Use S/MIME with the PKCS#7 encryptedData type.
How would that work? I want to encrypt a piece of MIME-encoded
data, not MIME-encode a piece of encrypted data :)...
S/MIME does just what you are looking for, it encapsulates MIME-encoded
data in a PKCS#7 type, and then MIME-encodes the PKCS#7.
In particular, PKCS7 doesn't have a way (at least as of version 1.5, the
most recent I have to hand) to denote that the message content should be
interpreted as a MIME element or message. It has all sorts of options
for denoting what's been done to the data, and by whom :), but not for
denoting what the data actually is. As far as PKCS7 is concerned, the
message itself is just an octet string. Now, I suppose that I could
just say by fiat that the PKCS7 payload may be a MIME-encoded body part,
but that strikes me as courting interoperability problems. Also, since
I'm not already speaking PKCS7 it seems like a lot of trouble to add :).
PEM has the concept of headers inside the encapsulation boundary, so a
liberal
interpretation of PEM would seem to allow for "MIME-Version: 1.0" and/or
"Content-Type:" lines in the encapsulated header. This is actually what
I'm
leaning towards at the moment, although it doesn't address encryption of
individual content elements, only complete messages. It would require
that
the receiving end also look for MIME headers within the PEM encapsulation
boundary, or allow the user to pipe the decrypted text through a MIME
decoder (such as Metamail under UNIX, for example).
Amanda Walker
InterCon Systems Corporation
==========================================
Ray C. Langford
Engineering Manager for Advanced Products
Frontier Technologies Corp.
Email: Ray(_at_)FrontierTech(_dot_)com
Voice: (414) 241-4555 x205
==========================================