GnuPG in the enterprise

[Dan Nelson]

In the last episode (Jun 16), Tony Shadwick said:
> On Wed, 15 Jun 2005, Dan Nelson wrote:
> >In the last episode (Jun 15), Tony Shadwick said:
> >>Are there any good documents out there on managing GnuPG in the
> >>enterprise?
> >>
> >>There are basic issues I need to be able to address, such as a
> >>situation when an employee leaves a company.  The admin needs to
> >>have the rights to revoke that user's public key, and be able
> >>decrypt any old messages to that user, and be able to decrypt
> >>messages sent to that user that are now being redirected to someone
> >>else for handling.
> >>
> >>Are there established mechanisms for handling centralized key
> >>management in a company to where the Administrator has access to
> >>everything required?
> >
> >One solution is to make a copy of all keys (with known passphrases)
> >when they are created, and put the copy in a secure location.  If an
> >employee leaves suddenly, you can retrieve the key to decrypt
> >leftover files and revoke the key.  Pgp.com's Windows PGP software
> >uses special Revoker keys and Additional Decryption keys that get
> >added when files are signed, so files are always encrypted to
> >multiple recipients and keys are always revokable even if the
> >original key no longer exists. gpg doesn't recognize ADKs, though.
> 
> Just so I'm following then, let's say I have gnupg installed on my server, 
> and I'm creating all of my employee's secret keys there, then installing 
> gnupg on their workstations so that they can use local mail clients to 
> encrypt.
> 
> What's to prevent them from chaning their secret key passphrase or 
> revoking the key themselves and creating a new public key, then publishing 
> that to the keyservers? (Other than knowing enough about gnupg in the 
> first place to do any of this of course...)

Nothing.  The first case should actually be common, since the
passphrase is just another password, and all passwords should be
changed occasionally.  Remember you still have a copy of their key with
a known passphrase.  As for the second, you could remove the
key-generating code from gpg, assuming you have also locked down the
accounts/filesystems to prevent them from running unauthorized binaries
(i.e. their own gpg).
 
> Not to mention I've always wondering how gnupg plays with multiple
> recipients or internal company mailing lists.  For example if I send
> a message to VIP1, VIP2, and VIP3, and it is an important internal
> document that requires encryption, when I encrypt the message, won't
> it get encrypted with VIP'1 public key, thus VIP2 and VIP3 won't be
> able to open the message?

It's up to your MUA to fetch the ids for all the recipients and then
call gpg with all the required keyids.  Mutt, for example does a pretty
good job at this.  If you ask for a message to be signed, it won't send
it until it has ids for every recipient.

-- 
	Dan Nelson
	dnelson at allantgroup.com