OpenPGP vs inline PGP
Robin Lynn Frank
Tue Jul 8 06:59:02 2003
On Monday 07 July 2003 07:31 pm, Ben Finney wrote:
> On Mon 07-Jul-2003 17:27 -0700, Robin Lynn Frank wrote:
> > On Monday 07 July 2003 04:40 pm, Ingo Kl?cker wrote:
> > > It's looking for the OpenPGP plugin which is necessary for PGP/MIME
> > > support.
> > Although I thank you for that info, I have to say I am astounded by
> > the human mind's ability to create complex solutions to simple
> > problems.
> What simple problem has been made complex, in your view?
If nothing else, the software.
> OpenPGP is an attempt to use a flexible, common attachment method,
> instead of the domain-specific, inflexible attachment method of inline
> signatures. This seems like a simplification, not a complication.
> > It will be easier to tell those few of our business clients who use
> > MUAs that put the sig in an attachment that we won't be accepting
> > those sigs anymore.
> I don't see a good reason to reject them. Your choice, of course.
It had been our policy to reject any mail with a Content-Type of
multipart/<anything> as a security measure.
> > At least it will allow me to go back to our standard of rejecting mail
> > that isn't plain text.
> A signed PGP message isn't "plain text"; it has an attached signature.
> Whether tha signature is attached by the MIME attachment standard or by
> the PGP-specific attachment method, it's still an attachment.
> If it's attached by MIME, any MIME processing software can recognise
> that, and can even determine what type of attachment it is, without
> needing to know anything about PGP or GPG. The plain text can be
> extracted by any MIME-aware program, without needing to know anything
> but MIME.
> If it's attached by PGP's own method, it isn't recognised by anything
> that hasn't been specifically told about PGP's way of attaching
> signatures. This means the plain text cannot be extracted without this
> domain-specific knowledge.
> You can choose to reject MIME signature attachments and allow only PGP
> signature attachments, but by doing so you'll miss a growing segment of
> the crypto-using community: those attempting to conform to mail
In the years we've used PGP and then GPG, we have come to trust the approach.
To put our trust in an approach that gained much of its popularity due to the
world's most insecure mailer would require more antacid than I have in the
Now, as to the software required to accomplish this, I will point to this
quote from KDE's howto page:
Now, compile and install them (note that you need much stuff here only to make
newpg's configure script happy):
I'm sorry, but installing software that is not actually needed??? I don't
know about you, but the idea of being subject to potential vulnerabilities of
software I don't actually need. The rule usually is, if it isn't needed,
don't install it.
Now, I ate my own words and compiled and installed, following the instructions
to the letter. After finding it wouldn't work unless one of the libraries
was symlinked to /usr/lib from/usr/local/lib (not included in the
documentation), I then discovered that kgpgcertmanager crashed everytime I
tried to start it and that no key requiring a passphrase was useable.
You will, however note that gpg, when used as nature intended, works just
fine. No, I take that back, It won't recognize my passphrase. Progress :-(
Robin Lynn Frank
Director of Operations