-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dave Crocker writes:
1. Technical
There is no strong argument that either MIME or Armour are superior at
doing protection against the vagaries of transport.
It is worth noting that Armour combines the control information with
the data, whereas MIME keeps them separate. This facilitates processing by
recipients who either do not have the necessary security software or who
want to defer its use. That is, for authenticated data which is not also
encrypted, the main data can be kept cleartext whereas with Armour it is not.
I described several technical objections to the use of MIME which no one
has addressed.
Many of them are related to the MIME convention you describe of separating
control information from data. This works well in an email environment,
where such separation is already in place. We have mail headers and body,
and it is natural to add the MIME control information to the headers,
and to put the MIME body parts into the body. This also works for HTTP
and news, which have a similar header/body distinction.
But this model breaks down when we are in an environment where such
separation does not exist. I used the example of disk files. Now, some
people have said that this should not count, either because people don't
exchange disk files, or they don't need disk files to be ascii armored.
Actually, people do exchange disk files all the time, either as email
attachments, or by FTP, or by sharing them in other ways. And there
are reasons for ascii armoring files. One good example is a clearsigned
file, where you want to be able to view the contents while maintaining
the signature in the file. There may also be situations where people
find it convenient to be able to view their encrypted files and see BEGIN
PGP MESSAGE, so that they are reminded that they hold encrypted data.
The only way that I can see to support this with PGP/MIME is to make
the file consist of the MIME headers, then a blank line, then the MIME
body parts. In effect we adopt a convention that files do have two parts,
control information and data, and that they are separated by a blank line.
We are forced to do this if the file system does not provide us with
another place to put lengthy control information, as most do not.
But since this convention cannot be applied uniformly throughout the file
system, ambiguities arise. There is no way to tell a priori whether a
file is in this new "MIME format" or whether it is an ordinary file.
I described various examples of where these ambiguities could cause
problems.
I also pointed out other places where PGP/MIME conventions that would be
logical for email don't make sense in more constrained applications, such
as the convention that data to be signed MUST be converted to 7 bit form
beforehand.
In addition, I mentioned that PGP/MIME does not provide methods to
encapsulate some legal PGP packet structures which were expected not to
be used for email.
Sorry to be redundant here, but since my first message apparently made
so little impact, perhaps a repetition will help.
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/AwUBNHxqQsDh8jnv1nHwEQJUCACfeCR18YyDsBBd0rCXEg82NxFhP/cAnjhO
3yOvMKYapbprPB7Xd1EUQHoM
=S2Ud
-----END PGP SIGNATURE-----