**WARNING**Re: gpgme: encrypt/decrypt

[Michael Nguyen]

From: "Albrecht Dreß" <albrecht.dress at arcor.de>
>Am 16.08.05 20:22 schrieb(en) Michael Nguyen:
>> I'm creating a Postfix content filter for the company that automatically
>> does GPG encryption/decryption on incoming and outgoing corporate mail.
>
> This sounds like an ineresting idea!

First, I want to thank you for the response.

>However, are you sure you want to do this on the *mta* level? Most mua's

The CEO has requested this because he wants GPG to be standard at the
company and doesn't want to have any spin up time for any of the employees.
He feels that it has to be as transparent as possible.  If this is
implemented right, no one will never know it's happening.

>(balsa, evolution, kmail, thunderbird, ...) support encryption, which
>seems to be the more logical approach to me. Apart from that, it offers
>more security for the user, as incoming messages are decrypted only on the
>user's machine and using a (hopefully really secure) passphrase only known
>by the user.

Yes, the security is certainly not as good.  We'll be storing private keys,
public keys, and passphrases in our database so I can see how a GPG/PGP
purist would recoil at the thought of what I'm implementing, but it allows
us to do two things:

 - Force GPG on our user base without generating any resistance
 - Allows our user base to converse with other GPG/PGP users without having
to be technically savvy

>> What I wanted to do is have the user's private and public key stored as
>> a TEXT type in MySQL.
>
>Why don't you use the usual gpg key ring for that, maybe with automatic
>retreival of missing keys from a key server? You could store the
>fingerprint as TEXT, but gpg(me) can use email addresses to fetch keys.

Storing these things in SQL allows us to be far more flexible regarding the
management tools that we can write.  Perhaps a normal key ring could be just
as good, but I don't feel it would be.

>>  - Content filter knows who's sending the email and who the recipients
>> are
>
>Not sure if Postfix offers all recipients to the filter. But remember that
>the bcc recipients *must* be treated separately, i.e. they must receive a
>different message as the key id's of all "recipients" can be extracted
>from the crypto envelope.

Yeah, there's definitely a lot more I need to think about.

>>  - Filter uses this user information to encrypt the message
>
>So the whole content is put into a rfc3156 multipart/encrypted container,
>maybe signed by a "company key"?

Yes, but signed by the individual's key.

>If you are concerned about security and want to force the users to encrypt
>messages, another approach might be to reject (bounce) unencrypted
>messages (i.e. with a top-level MIME content type other than
>multipart/encrypted) to certain recipients and/or incoming ones from
>certain senders.

I can tell you right now, that this would not go over well.  ;-)

>> I do something similar for incoming delivery (except that it's even
>> easier because I don't have to search for recipients).
>
>I wonder if this is a good idea... If I send someone an encrypted message,
>I would assume that this is a "for her/his eyes only" one. IMHO some kind
>of company-wide automatic decryption breaks privacy (and may even be
>forbidden by law, at least in Europe).

Yeah, I don't know if it's illegal or not in the US, but this is only for
company-related email.  Most users will never know that their emails are
being encrypted or decrypted.  Part of the new employee account creation
process will be to go to some Java Servlet page and hit the "generate new
key" button which will insert a new private/public key into the database for
NewEmployee1 at domain.com.

>Just my ¤ 0.01...

A very much appreciated 0.01...

I'll let you guys know how it goes.  If I feel it's of good enough quality
and ends up being a decent implementation, I'll release it as a Postfix
module so others can use it.


Michael