On 2009-02-09 at 15:40 +0000, Jonathan wrote: > I work for a UK university and we need to set up some infrastructure to > allow staff to send/receive PGP/GPG signed e-mails.
So, the infrastructure is really "local PGP keyserver if you're feeling generous" and "some kind of trusted introducer to get a web of trust kick-started". The former is lightweight for one machine, the latter is a personnel decision, "who knows PGP and understands signing and the fact that you're making a strong attestation of fact, to others, when you sign a key". For the local PGP keyserver, you're providing a public copy of data where the trust is calculated by the client, so you're not dealing with a high-security server here. There's SKS, which is in Debian packages and FreeBSD ports. When you add an SKS keyserver and set up peering for exchanging data, you automatically become part of pool.sks-keyservers.net. I have SKS on my colo box, it uses at peak 1% CPU on a single-core old Opteron. Network -- not too significant, I've never bothered tracking the separated total. Disk, you're looking currently at 5G to 6G. You need to pull down the initial data, build the indices (a few hours) and then set up peering. A cron job to keep the Berkeley DB indices compacted and no other routine maintenance besides keeping an eye out for people wanting peers and helping to improve the peering mesh by adding links. There are two or three ports of interest. 11371 for HKP retrievals, standardised and used by clients. 11380 is the standard peering/reconciliation mesh port for SKS. And port 80, if you want; 11371 is overlaid with an HTTP server and a query form for presenting the usual results of a key search. If you put a form on port 80, or something minimal to redirect to another server, you can make it cleaner for people wanting to just go to "keyserver.example.ac.uk". See http://sks.spodhuis.org/ for an example (the "Peers" link is not part of SKS, "Stats" is). Without the local PGP keyserver, you're still fine. Just note that you really MUST steer people away from pgp.mit.edu which is old and doesn't accept subkey updates, so if someone renews their key then the really old PGP keyservers won't accept that update and the key will appear invalid. Just use subkeys.pgp.net or pool.sks-keyservers.net or your local server. Both are just DNS-based pools. For the trusted introducer, it can be someone technical who understands PGP or someone legal or whomever. At $previous_employer I found that our legal counsel understood public key vs private key and key-signing better than most of the technical folks. Some patient explanation to walk her through the first time, and some reassurance when some government IT folks (from a security-focused dept) convinced her she was wrong (when she wasn't) and it was fine. > Our infrastructure is Exim gateways, feeding MS Exchange. The majority > of users (including those with the immediate requirement) are running > Outlook, but we also have Entourage and Thunderbird users. We also use > mail-enabled public (shared) folders in Exchange. MTA and storage server are irrelevant; it's all on the client. > We're on a tight time-line, and I'd like to build a solution using open > source products unless there is a good case for spending money. Start at http://www.gnupg.org/ and follow the link for http://www.gpg4win.org/ to get the Windows software. Includes an Outlook 2003 plugin and WinPT which is the keychain manager, lives in the system tray IIRC. Enigmail for Thunderbird works with the gpg4win setup, WinPT lets people manage the signing. It's been 3 or 4 years since I dealt with this. Sort out getting the software installed on clients, integrating the docs and integrating a workflow for people to present ID and stuff for signing at a local trusted introducer; get the trusted introducers trained and mutually signed, so that that anyone within your organisation is at most 3 hops away from anyone else. In your docs, advise giving strong trust to the keys of the trusted introducers. Take a look at the Wotsap stuff (below) and pathfinders, to see if you want to provide such interfaces locally, or connection graphs of local users, or whatever. > Are you doing this already? Are there any good FAQs? War stories? I've gotten more people using PGP inside an ISP (and got others using it right), was trusted introducer. That stopped when I left in 2006. The Windows PGP keychain manager mentioned above was flaky then, don't know about now. And I've mentioned our bedrijfsjurist (legal counsel) above. The GnuPG manual is good reading and from what I recall, mostly good for presenting as educational material (or at least, it was; even with "to be written" sections). I managed to stop some developers from assigning ultimate trust to other peoples' keys, anyway. Even if it was flattering to be the one so trusted. *cough* For setting up the SKS keyserver, there's the [email protected] mailing-list and http://www.keysigning.org/sks/ to get you started. Ask on the mailing-list for peers, when you're ready, and people tend to be very helpful with advice if you have problems. More introductions and guides from someone clueful: http://www.phildev.net/pgp/ which has a lot that should be of use to you. If you're interested in getting an understanding of what the Strong Set is, then: http://www.lysator.liu.se/~jc/wotsap/ http://pgp.cs.uu.nl/mk_path.cgi Regards, -Phil PS: I'm always happy to add more SKS peers. Call me a peering @#$&%. :) [email protected] _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
