What are the best practices for deploying PGP in a medium-sized business?
The idea I had was:
- Setup a PGP key server that all mail clients use
- Create a PGP for keymaster@mycompany.com
- All users install and trust the keymaster's key
- All users create a key, which is then signed by the keymaster, and installed in the key server
This appears to meet my basic needs, but I wonder if there are other considerations?
Also, I am not sure where to locate the key server on the network. If it is on the internal network then it won't be accessible to remote workers who do not have VPN access. If it is on the internet, then I am concerned about the privacy risk of external people being able to get the employee list. Is it possible to protect the key server with a password?
Best Answer
Using a common certificate authority will be reasonable, especially if more than a bunch of people will use OpenPGP. Using such a CA does not go counter with the decentralized web of trust approach, it is just a central trust point for a small, limited part of the web of trust and still allows trust connections bypassing the CA.
The basic concept you presented looks totally fine and reasonable. Some things I'd consider follows below, probably it still could be extended by other ideas.
Creating/Choosing a CA
You can create your own CA, which you'll definitely be able to trust (and your employees probably should be able to do so, either). If you want to communicate with external participants, these still will have to trust your CA.
There are also already well-integrated CAs in the web of trust. Of largest importance is probably CAcert, and there also is the German Heise Verlag (but each employee would have to travel to Hannover, Germany to get signed – this is probably not a feasible solution). CAcert on the other hand offers its organization assurance, and allows you to easily create both X.509 and OpenPGP certificates. CAcert owns one of the best-integrated OpenPGP keys and is very likely trusted by lots of OpenPGP users, and might be worth looking at for using as a CA.
Internal or External Key Server
An internal key server (behind a VPN/Firewall/NAT) will not be accessible from outside, so no "stranger" can query it. This might be of interest if only using OpenPGP internally, but if also customers and other stakeholders should be able to communicate privately with your employees, you should probably put them accessible to the internet, anyway. This might be achieved by exposing your own key server to the internet and finding others to synchronize with, or by directly relying on the already available key servers.
Something to be considered anyway is that it's hard to prevent keys getting uploaded to other key servers. Some client received the key and (intentionally or accidentally uploads it? Some employee misconfigured his setup and uses an external key server instead of your local one, for example when he wanted to query for other keys?
Regarding these risks and their probabilities, discussing password-protecting your key server seems not the main problem. I don't think the protocols support that anyway (but they're HTTP-based, maybe HTTP authentication works?). Putting the key server behind a VPN probably is the best solution if you want to keep it private anyway.
Publicly announcing OpenPGP usage might also be of interest as it is some kind of advertising taking security and privacy seriously, and increase trust of (future) clients in your company.
Centrally Withdrawing Employee's OpenPGP Keys
If you want to be able to withdraw employee's OpenPGP keys, for example after he left in conflict, have a look at OpenPGP's possibility to create a revocation key binding signature. If employee's keys use this signature to denote the CA's primary key, this one can revoke the other one's. Though: I'm not aware how widespread implementation of this feature is.
Alternatively, already collect revocation certificates on key creation, and store them centrally – then the revocation date is fixed, but at least you've got an escape route.
You also might want to set the signature expiry (a feature often not used, but widely implemented) to some date not too far in the future, eg. a month. Automatically signing the employee's keys is easy, and if somebody leaves your company his key will expire soon anyway. If the notice arrives early enough, you might even be able to stop signing in time before he quits.
Regularly Updating the Employee's Key Stores
If you've got central management of the employee's computers, think about regularly updating the key stores. Employees might realize to query the key server if they're missing the information for a new key, but they will not realize to update in case of revocations, ... Consider using a simple cron job or similar method to update the key store on a eg. daily base.