Kent Crispin wrote:
If the mailer does all the work for you, then why argue that mime is
necessary as a part of the OP spec? I don't mean that to be flip; I am
asking for actual technical reasoning, maybe even with a concrete
example. How, precisely, do you imagine OP interacting with a mime
mailer such that OP has to know mime?
I absolutely agree, Kent. This is the beauty of the MIME solution - it
doesn't need to be part of the standard at all, apart from labelling the
content-types - and that can go in OP-MIME instead.
As Dave Crocker said, we can leave the 7-bit encoding functionality to
MIME and concentrate on the security of the underlying binary data.
Adam Back wrote:
However, there is another 7 bit transport problem which gets solved by
ascii armor currently: cut and paste operations on keys, eg look up on
a keyserver manually, or via finger, or appended to a mail.
This could actually be acheived with MIME in place of armor -- just
include the Content-Type: headers and skip the checksum, and it's
basically the same thing.
This would then need minimal MIME handling ability within the standard
and an implementation -- to be able to accept MIMEd key packets.
There is actually already an application/pgp-keys content-type defined
in PGP/MIME. Therefore, we can do the key-acceptance process even more
easily than PGP 5 makes it (adding keys via the clipboard).
Your mailer simply needs to be configured to use PGP as the "viewer" for
an application/pgp-keys bodypart. The mailer could remove the MIME
encoding and run PGP with the binary key data as input. PGP would
recognise this and add the key. This would work just as well with
keyserver output - when you retrieved a key, you wouldn't need to cut
and paste it from your browser, the browser itself would run PGP on the
key data.
Ian.