I would have some questions about using PGP-MIME for all the ascii output
modes, outside of the email environment.
With email (and the web and news) there is a distinction between header
and body. MIME requires some data to go into the header, and some to go
into the body. If you're just encrypting files but you want ascii output
for some reason, you would have to introduce the notion of a header and
body within a file. You'd have header lines as for email, then a blank,
then the body of the encrypted data, all within the file.
So an encrypted, ascii-encoded file would look like this (example from
RFC2015):
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundary=foo;
protocol="application/pgp-encrypted"
--foo
Content-Type: application/pgp-encrypted
Version: 1
--foo
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj
eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ
g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA
AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3
1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8=
=zzaA
-----END PGP MESSAGE-----
--foo--
Now if you want to send this to someone, you have two ways you can go.
First, you can just send the file itself as an attachment. In that case
the recipient would receive the file, then he needs to run his MIME parser
on that disk file. But if his MIME parser is part of his mail client,
he may have difficulty convincing it to parse the MIME information in a
disk file.
The second approach is to take that file and put the headers from it
(the first three lines above) into the outgoing mail header part, with
the rest of the file going into the outgoing mail body. If you do this,
then the recipient will see the file as an ordinary MIME message and he
will be able to decrypt it easily. However this sending mechanism is
a bit ad hoc. The sending mail client would have to have a special kind
of file-sending mode, or recognize that a file being sent as an attachment
looks like it already has MIME headers in it, so it should be treated
specially.
Another issue related to headers is that all encrypted or signed parts
must themselves be in "MIME canonical format (body and headers)". This
means (I think) that there needs to be one or more MIME header lines put
before the cleartext of the data which will be signed or encrypted.
As with the earlier case, confusion can arise once you move outside the
email environment. You could clearsign a file on disk, and then later
want to encrypt it. Now, the file already has MIME headers from clear-
signing. Should the encryption program check and/or ask whether the file
is already in MIME canonical form, or should it just assume that it is
not, and always wrap the file in its own headers before encrypting?
Or suppose you are decrypting a PGP-MIME file. Are you supposed to leave
the MIME headers in the output? If the output is just some data which
the user encrypted, it would probably be best to remove the MIME headers
and undo whatever content-transfer-encoding is specified. On the other
hand if the output is a MIME multipart, then maybe you should leave them
in.
It seems to me that MIME is not very well suited to providing the ascii
encoding for a general purpose encryption utility, unless it is tightly
integrated into a MIME-aware environment. I would welcome suggestions for
how these situations would be handled.
A limitation with PGP-MIME is that data which is signed and encrypted must
be in 7-bit form. This means that if you are signing and encrypting 8-bit
data, and you are going to produce ASCII output using PGP-MIME, you must
first convert the input to 7-bit form, probably using base64 encoding.
This will bloat the size of the output file.
This restriction makes sense in the email environment, where gateways may
want to strip off the encryption and leave a legal MIME message which has
no 8-bit data. But if we are generalizing beyond mail applications this
limitation may not be appropriate.
Related to this, with PGP we have two types of "ascii" signatures:
cleartext signatures, and ascii armored non-cleartext signatures.
PGP-MIME has only one type. There is no mechanism in PGP-MIME to create
the equivalent of an ascii armored non-cleartext signature (like what
would be created with "pgp -sa" using PGP 2.6.2). There is also no
PGP-MIME way of encoding a detached signature, as far as I know.
In this sense, PGP-MIME is more than just a transport layer for PGP
messages. It applies its own set of rules and semantics to the data
being transported. While these rules are often reasonable and appropriate
for the email environment, they are not as flexible as the general
capability to transport any PGP data which PGP's ascii armor provides.
Hal Finney