ietf-openpgp
[Top] [All Lists]

Re: OpenPGP vs. OpenPGP/MIME

2002-02-12 00:20:05

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 25 January 2002 18:07, john(_dot_)dlugosz(_at_)kodak(_dot_)com wrote:
<snip>
Re compatibility: I use (don't laugh) Lotus Notes 4.5 at work, and it
is totally different from normal email.  It has a gateway to
translate internet mail into its own document format.
Mime attachments are turned into embedded documents at the end.

I guess labelling this as re: compatibility is stretching the sense at 
best. If Notes doesn't handle MIME, what's the point in arguing that 
PGP/MIME is bad for interop and citing Notes as an example.

What would it do to PGP/MIME or any other use of MIME that requires
knowing the =meaning= of the parts?  I doubt it would work.

As long as MIME parsers follow the rule to treat unknown multipart/* as 
multipart/mixed, no problem would arise. It's the broken mail software 
that causes problems here.

If the main point of PGP/MIME was to get mail readers to
transparantly handle PGP, it obviously has problems for readers that
=don't=.  And mail readers could just as easily be built to know
about the ===BEGIN...=== lines.

- From the point of view of a MIME parser implementor, old-fashioned pgp 
messages are pure horror. While you can trust that with PGP/MIME signed 
and/or encrypted body parts are correctly labelled, for plain PGP 
messages you have to scan all possible body parts (ie. at least those 
labelled text/plain) to check for pgp message blocks. Worse: Your nice 
DOM that you built around the concepts of rfc(2)822, rfc2015, rfc204x 
and friends is totally wrecked when you have to deal with body parts 
embedded in body parts other that multipart/* or message/*. The same 
issue arises with uuencoded messages.

You have to introduce fake body parts when you want to actually keep 
your DOM. Don't start to think about those broken flat message digests 
with multiple pgp message blocks in them :-(

OTOH, letting aside the cryptographic functions, implementing rfc1847 is 
dead easy.

Just to throw something out, how about ASCII-Armored PGP for the body
of the message, and MIME attachments for multiple (paralell)
signatures?  For that matter, they wouldn't need MIME, just another
ASCII Armor'ed block following the main one.

See above for why this is a bad idea.

Marc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8aMIO3oWD+L2/6DgRAjOMAJ9NnKy2i4rCUss+sMtvKkxYjJmvMwCgmroj
KjCN6jL6OYiLTms/+6VjL+Q=
=dy2i
-----END PGP SIGNATURE-----