Howto integrate (G/P)GP into sendmail -D?!

[Robin O'Leary]

--5UGlQXeG3ziZS81+
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Looking back through the archives, I came across this thread from
June 2000 about integrating PGP in to sendmail (or an equivalent mail
transfer agent):

eisert@cybersite.de, at 00:27 +0200 on Fri, 30 Jun 2000, wrote:
>    Actually i wonder how to integrate the
>    PGP stuff into a sendmaildaemon, since
>    i've several users in an intranet and want
>    to automatically crypt just the outgoing
>    mails... is there a good FAQ about this?!
>    BTW, is this stuff usable for VPN's?!
>     (FreeBSD/Linux)

This is something I have been keen on doing for some time.
Only recently have I investigated other attempts: pgpsendmail
(http://www.atnf.csiro.au/~rgooch/PGPsendmail.html) did much of what I
want a few years ago and pgpmail (http://sourceforge.net/projects/pgpmail/)
updates the idea.  But it seems strange to me that nothing like this
has been widely adopted.  Then I started looking at the gnupg list
and from the reaction this question produced, I can see why.  I was
surprised and disappointed to read the rather abrupt brush-off the idea
received from this list.  I agree that it would be better if users had
encryption-capable mail agents, but surely having an encryption-aware MTA
is an excellent first step to getting encryption widely deployed, and,
if properly designed, a great way to encourage end-to-end encryption in
the future?  Why is it such an unpopular idea?

First, just to be clear, let me describe the way I see it working:
  * an organisation installs an encryption-enabled MTA.  Preferably
    this would be implemented as stand-alone filters that could just
    be dropped in to an existing MTA.
  * a trusted person generates a key pair for the organisation.
    This is marked somehow so it can be recognised as belonging to the
    organisation's whole email domain.  The secret key is installed in
    the MTA; the public part is signed and advertised as usual.
  * a trusted person configures the MTA with the email addresses and
    signs the keys of outside recipients (whether they be organisations
    or individuals) who wish to receive encrypted email.
  * the MTA checks the recipients on outgoing email against its
    address/key list.  If any records match, the key or keys identified
    are used to encrypt the email.  If some addresses don't match,
    a policy setting (perhaps influenced by the sender) determines
    whether the mail is bounced or sent unencrypted.
  * the MTA decrypts any incoming email that matches the organisation's
    secret key.

That's it---pretty simple.  Look at the good things we can do now:

An individual outside the organisation (with the necessary software)
can now choose to use the organisation's key to communicate securely
with any person inside.  Of course, if they know an individual's key,
they can use that key in preference and the MTA won't interfere.

An individual outside can contact the trusted person inside and arrange
for their key to be entered in the MTA's database.  Now any email
sent from inside to the individual outside is automatically encrypted
(provided it passes through the MTA).

If someone inside decides to install GnuPG themselves, they can tell their
correspondents to use their personal key, rather than the organisation
key.  Also, they can get a quick start by importing the MTA's keyring
(assuming they trust the organisation's trusted person, those keys will
already be trustworthy).

These all seem to be good features.  On the bad side, there is the need
to store the organisation's secret key securely in the MTA, but at
least that problem can be dealt with in one place by employing suitable
hardware.  I envisage the auto-encrypt and auto-decrypt functions being
implemented separately, probably by two SMTP-filters such as those
that postfix supports for content-filtering.  That way, if no secure
crypto-hardware is available, at least the sensitive secret key can be
kept on a different machine with better physical and network security
since it needs no connections except the filtering service and that is
offered only to the MTA.

On Thu, 29 Jun 2000 17:42:24 -0500 (CDT) Frank Tobin <ftobin@uiuc.edu> wrot=
e:
> This is not a good idea, as there are several flaws that can occur. =20
> First, you have to automate deciding which keys you want to encrypt to...
This doesn't have to be automated to be useful.  As discussed above, just
having the MTA encrypt to addresses whose keys it has already been taught
would work.

It seems to me much more likely that an organisation would have one admin
person capable of correctly configuring the MTA's keys than that all the
email users in the organisation would be capable of doing it themselves.
Email users who *were* capable could still do it themselves anyway.

It would be great if the MTA could somehow figure out which keys to use
automatically, but I believe it is impossible to do this safely without
some other communication channel or trusted third party.  Still, in a
more ambitious scheme than I currently propose it might be possible to
automate a human-readable notification that both ends support encryption,
so at least the both ends could be prompted to set up new keys.

> ...and this is likely not a system-wide thing you want to enforce.
I would have thought that many organisations would like to enforce a
system-wide policy on encryption and would do so if only they had the
means.  Being able to ensure that, for example, all emails between the
parts of a geographically-distributed organisation are encrypted seems
quite desirable.

> Second, you would need to be able to handle things like errors
> from GnuPG and such.
Yes, but this is only hard because of GnuPG's current design.  The problem
is discussed frequently on this list with no resolution yet.  It appears
that GnuPG is currently available only as a command-line tool.  There is
no C function interface, although I think I saw a post saying that an
attempt has been made to kludge something like it by a wrapper to the
command-line version (if so, where it it and are there examples of how
to use it?).

Currently any program that wants to use GnuPG's features has to be able to
invoke it safely (perhaps quoting parameters it wants to pass, worrying
about maximum command line lengths), talk to it down one or more pipes
(coping with write blocking and signals going off), while simultaneously
reading and parsing GnuPG's chatty responses.  That is rather daunting,
and you are right to raise it as a problem.  However, the solution is
not to criticise this application for needing a better interface; the
solution is to come up with a better interface.

Still, even having moaned about it, I think that the current interface
would do for this job.  The functions needed are all very basic.  There is
no requirement to do anything but very simple key or trust management,
which could even be done on the MTA by the admin running GnuPG by hand
in the first instance, although it would be more elegant to have this
done by email eventually.

If a GnuPG operation failed on an outgoing message, the output could
simply be returned to the sender in the same way that any other transport
error would be handled.  An error on an incoming external encrypted
message would be more embarrassing as it might result in the email being
unreadable and hence require the sender to re-transmit.  Perhaps we can
think of some ways to help the administrator make it more robust---perhaps
perform an exchange of test messages before accepting a new key.

> And there are a bunch more issues.  It's not a plug-and-play scenario.
Such as?  Why not?  That's not meant rhetorically---I really have thought
about it and can't see any negative side here.  What problems are there
that I haven't thought of?

> GnuPG is designed for user-level usage, as OpenPGP is generally designed
> as an user-to-user protection.
OpenPGP is quite capable of being used in modes other than user-to-user.
GnuPG is indeed intended as a user-level interface, and that is appropriate
since that is its most common mode of use.  But I contend that having
no more general interface is a mistake.  Perhaps GnuPG is not the right
tool for this purpose and I should be addressing some other forum with
this discussion; if so, please point me in the right direction.


Following further along the thread, I find the same sentiments
expressed again:

On Thu, 29 Jun 2000 18:18:00 -0700 (PDT), "L. Sassaman" <rabbi@quickie.net>=
 wrote:
> GnuPG is definately designed for user-level usage, but OpenPGP can be
> deployed on a wider scale.
Is there an OpenPGP library?  If so, where can I find it?  Wouldn't it
be better to have GnuPG use that library rather than its own?  Having yet
another implementation of OpenPGP seems like an invitation for even more
inter-operability problems than we have now!

On Fri, 30 Jun 2000 01:12:06 +0200 (CEST), Stefan Suurmeijer <stefan@symbol=
ica.nl> wrote:
> Why would you want to integrate it with sendmail? Do you want to use the
> same private key for all users?
Yes, for some organisations this would be ideal.

> Besides, crypting the outgoing mails to which keys? You'd have to have
> the public keys (if they have keys that is) of all recipients.
Yes, just as an individual driving GnuPG does now.  But instead of
getting each user to do it, it can be done once per organisation.

> Why not integrate pgp with pine for instance and
> have the users choose to encrypt?=20
It's not an exclusive choice; having OpenPGP support in every MUA
is the ultimate target.  But at the moment, not everyone uses an
encryption-capable MUA and getting them to change is difficult---I've
tried!  Having a way to do encryption centrally in an organisation gets
things moving in the right direction and builds a base for inter-operation
with more users.  Surely it can only be an improvement.

Anyway, the crypto-related things needed to get this started are:
  * ideas on what technology to use underneath
  * a way to mark an organisation's key for use with a whole email domain
  * a C library for crypto functions
There are some pure implementation details like:
  * definition of the MTA interface (SMTP in and out?)
  * how to store the email/key info (private database or GnuPG keyring?)
For more ambitious plans, it would also be nice to have:
  * a way to give a user control over the encryption of a
    particular message (pgpsendmail uses X-Secure: headers)
  * an email header to advertise encryption capabilities
  * a test mode to verify the operation of new keys
  * a semi-automatic mechanism for exchanging keys
  * more than one secret key in the MTA so individuals or groups
    could have their own keys

I hope the replies this time around won't be quite so negative:-)

Robin.
--=20
R.M.O'Leary <gnupg-users@ro.nu> +44 7010 7070 44, PO Box 20, Swansea SA2 8Y=
B, UK

--5UGlQXeG3ziZS81+
Content-Type: application/pgp-signature

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

iQCVAwUBOgykx+zqYp5jhQYZAQG4ZwP9EfUDVNyrWlIP1kxFEp5BxkCi6wyd5Zzs
GjqEhiBxGZu0PjzNlfsH+UjZ0dQ+ikMWlGLfrn2PDMwAb5OEThtiCsHNly9cJ6Gv
PaLKeSSFuja2MXXaviH//IHweMndvcHScTjgxZ66chWSpafYMp7nplMiFDILQ2D+
zn3cbU6SmSQ=
=b/c8
-----END PGP SIGNATURE-----

--5UGlQXeG3ziZS81+--

-- 
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of  "unsubscribe"  to gnupg-users-request@gnupg.org