pgp/mime vs in-line pgp
graham.todd at dsl.pipex.com
Tue Apr 13 14:53:10 CEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Tuesday 13 Apr 2004 7:43 am, Atom 'Smasher' wrote:
> of course, pgp/mime is an *official* standard, while in-line pgp is
> an *unofficial* standard. why isn't in-line pgp *officially*
> recognized as an email standard?
It is. OpenPGP is an official standard (RFC 2440) and OpenPGP doesn't
include PGP/MIME, which is a function of the email program you are
using and NOT of PGP or GnuPG.
The problem with PGP/MIME comes from the way it has developed. At
first, there were NO standards, and different email programs supported
the theory of PGP/MIME differently. The classic case often quoted is
that of the Windows program Eudora. PGP/MIME created by Eudora in the
early days could not be read by other email programs, and both sender
and recipient had to use the same version of Eudora to be able to
verify or decypt PGP/MIME. Slowly, a standard developed for PGP/MIME
which was RFC2015. I quote from http://www.imc.org/smime-pgpmime.html
which states that:
"RFC 2015 is a Proposed Standard in the IETF, but it is not expected to
move forwards because it relies on RFC 1991, which requires the use of
RSA key exchange, and requires the use of IDEA encryption, both of
which are encumbered by patents. Both of these patents would likely
prevent the protocol from moving forwards as an IETF standard."
Many email programs did, however, implement RFC 2015, and there were a
number of plugins written for various programs complying with this
standard. Versions of PGP had plugins with them that conformed to
RFC2015 (for example PGP 6.5.0ckt). When implemented, these plugins
changed the email program, not PGP or GnuPG, and if you are still using
these plugins you are effectively using the email program which
conforms to RFC2015.
Now, further work went on and a new standard was proposed, which was RFC
3156, which further details MIME wrapping in OpenPGP. However, if you
are not using an email program which conforms to RFC 3156 (and by using
the old PGP 6.5.x plugins, you won't be) then there is no guarantee
that email programs which conform to RFC3156 will produce PGP/MIME code
that those conforming to RFC2015 alone, can verify or decrypt.
This is where the problem lies. Inline PGP/GPG messages conform to RFC
2440 and can be verified or decrypted by any PGP/GPG compliant email
program (if they support PGP or GPG then they will be compliant), but
unless you KNOW which email program and even which version of that
email program you recipient will use, its not always possible to send
or receive messages by PGP/MIME that will be verified or decrypted
properly. As I want to produce messages that can be verified or
decrypted without having to check on the email program that might be
used, then I will always use inline PGP.
The situation is more prevalent in the Windows world as many programs
are not standards compliant than in the Linux world, where they tend to
be standards complant. Nevertheless, there are still anomalies in
Linux, such as Evolution which only generates PGP/MIME which cannot
always be decrypted or verified by other email programs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Please sign and encrypt for internet privacy
-----END PGP SIGNATURE-----
More information about the Gnupg-users