-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Keep in mind that you cannot do some things in PGP/MIME that you can with
ascii armor.
- There is no PGP/MIME encoding of a detached signature
- There is no PGP/MIME encoding of a non-clear signed message
- I'm not sure if there is a natural encoding of a signed message which
also includes a key certificate for verification. Maybe you could use
a multipart for this, but it's not in the spec, and it's not clear that
it would interoperate.
It is also unclear what you do with the output when you decrypt a
PGP/MIME message. People may not be aware that before encrypting you
MUST convert your input into a MIME body part, with a MIME header,
if it is not already in that form.
For example, to encrypt the one-line message:
This is a test
you convert it to something like these three lines:
Content-type: text/plain
This is a test
and encrypt that.
Now, some issues arise on decryption. If you added headers on encryption,
probably you should remove them on decryption, right? That would
be pretty easy in the case above. The first line is "Content-type:
text/plain", so you strip that and any related MIME headers off.
But what if that first line was "Content-type: multipart/mixed"? Now do
you leave the MIME header lines on? You can't really strip them because
the message body has structure and it can't be interpreted without the
headers.
What if it says "content-type: audio/basic"? Just strip it and save
the raw data? How about text/richtext? Leave it, strip it, or try to
include a richtext interpreter? At a minimum we would have to specify
the rules to follow for these various cases.
Or do we specify that PGP/MIME MUST only put simple Content-types into
the encrypted body part? That wouldn't work well; the PGP Inc. plug-in
already encrypts multiparts and other cases.
The problem here is that PGP/MIME was designed to encrypt MIME-ish things.
That makes sense for email, especially given that MIME is available or
you wouldn't be using PGP/MIME. But in the PGP world we want to encrypt
a wider range of things than that. This introduces ambiguities such as
I have been describing here and in other messages. Within a MIME-aware
mailer, all the PGP/MIME decryption module has to do is to strip off
the encryption and hand the MIME encoded body part back to the mailer
to worry about all these things. But that is not an adequate solution
for the full range of applications we want to support.
I have struggled with these issues, because I've implemented PGP/MIME
within our SDK. It does not lend itself to the "filter" model used
with the ascii armor and binary messages, where you have a single input
stream and a single output stream. Thorny problems arise when you try to
implement it, as I have described. I don't think it is a good substitute
for ascii armor in its full generality. For email it's fine.
Hal Finney
hal(_at_)pgp(_dot_)com
hal(_at_)rain(_dot_)org
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBNHyoosDh8jnv1nHwEQJolwCfSfsJQeShO3m6kgnVP1+Z8PJ1fwIAnjne
sYx6YEpoIbZ64m+j99RX/K0g
=s0Fl
-----END PGP SIGNATURE-----