pgp/mime vs in-line pgp

Graham graham.todd at
Tue Apr 13 14:53:10 CEST 2004

Hash: SHA1

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 
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.
- -- 


Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Please sign and encrypt for internet privacy


More information about the Gnupg-users mailing list