The larger point I'd like to make with respect to PGP/MIME is that it is
not just a transfer encoding which is applied on top of PGP. It is really
a full protocol in itself, closely related to PGP, but with its own
rules and formatting.
If it were a transfer encoding, like PGP's ascii armor, it would allow
you to take an arbitrary PGP binary message and encode it for transport.
PGP/MIME does not do this.
Instead, PGP/MIME enforces its own rules on the kinds of binary encoding
which can be created. For example, it insists that the only data which
can be encrypted or signed MUST be in MIME body part format, with a MIME
header, blank line, and MIME body. It also requires that the data must
be converted to 7-bit form before being signed, and it limits the kinds
of PGP binary packets which can be sent around, eliminating detached
signatures among others.
These kinds of rules require the encryption/signature engine to know
whether it is producing data that will be used for PGP/MIME or whether
the data is for straight PGP, possibly with ascii armor. The rules for
formatting the data and determining what kinds of inputs are allowed
will be different in the two cases.
Despite their superficial similarities, PGP/MIME is really not the
equivalent of ascii armor. They are not alternatives which can substitute
for each other. I think people are being misled by the fact that both
produce ascii readable output and are assuming that it is an either/or
situation. But that is not the best way to look at it.
This is why I have been objecting all along to the notion that we could
eliminate ascii armor in favor of PGP/MIME. It might make sense to make
one or both of them be SHOULD or MUST, but they are not alternatives.
The two should be considered independently.
Hal Finney
hal(_at_)pgp(_dot_)com
hal(_at_)rain(_dot_)org