gnupg in large scale at University

[zvrba at globalnet.hr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Fri, Dec 23, 2005 at 06:47:56PM +0100, Thomas Widhalm wrote:
> 
> I just got in charge of managing Linux- and Unix servers at the University of 
> Salzburg (Austria) and one of my first tasks is to implement a secure way of 
> exchanging email and storing data.
> 
You will have to clarify the part about storing data. Do you need
encrypted backups (and then, with per-user keys, or some "master key"
for all backup), a way to transfer data from one facility to another,
what?

>
> My biggest problem is, that our users have many different mailclients, mostly 
> MS Outlook connected to MS exchange.
> 
Sorry, I can't help you with that :)

>
> I think it would be a good idea to create a CA. How to achieve that? How to 
>
Very good idea. I would recommend to go with X.509 certificates which
work quite nicely with out of the box LookOut :) As a bonus, you get to
issue web SSL certificates and you can implement certificate-based
client authentication (e.g. to connect to web-mail)

Here's an open-sourced CA: http://www.openca.org/

I haven't used it, but it seems quite decent judging by the online
documentation. Depending on how large your installation is, you might
even use the CA.pl script which comes in any OpenSSL distribution
(just be sure to set the CRL distribution points correctly).

Browse the manual at http://www.openca.org/openca/docs/online/
it has a "Design Guide" which might give you some rough idea what it
means to deploy a PKI in large organization (either GPG or X.509).

If you have at least one Win2000 or Win2003 server installed, I can heartily
recommend Microsoft CA[1]. Whatever we think of Microsoft, it is a quality
product which works, and readily integrates in a Windows domain, if such
requirement should later occur. Issued certificates are standard X.509
certificates (with some MS specific extensions, which are non-critical and
should be therefore ignored by all compliant non-MS software that doesn't
recognize them).

[1] afaik, you get it in the package, and don't need to pay any extra
    licenses.

I have studied the MS CA a bit, and it has a nice, pluggable architecture
and is completely scriptable, so you can programmaticaly alter certificates
you are issuing. the whole thing is described on the MSDN.

Additionaly, if your users on windows will want to use smart-cards, they
will be free to choose any smart-card which comes with MS CAPI provider. 
Such cards can then be used in addition to e.g. log on to the windows
domain.

No, this is not MS commercial, I'm just giving credit where it is due.
If you have MS CA, it'll save you a lot of work in making things work on
Win platform, and there are no ill consequences for Unix users. They
will just use file-based certificates as they would with GPG. There are
even some PKCS#11 cards for Linux, and it should be possible to make it
work with MS CA (I've never done it though).

>
> keep the key save? Is just one person the CA, or a bunch of people? What if 
> someone leaves us? What if an employee leaves, loses his email address but 
> still has a signature. Should we revoke it?
> 
Depending on your security needs.

I have worked in a commercial CA. The following is a combined list of my
experience working there and some of my own advice and common sense :)

- - heavy physical protection (i.e. several steel doors, safes needing
  both a PIN code and key to unlock it, biometric controls, cameras, etc.)
- - two persons needed to enter the premises
- - root keys stored in a HW cryptographic module
- - k of m scheme to reconstruct the root key in case of catastrophic
  failure
- - BACKUPS of all critical data (most notably, the root key) in TWO
  different physical locations
- - all access-controls codes (smart-card pins, passwords to all systems,
  etc.) locked in safes in sealed envelopes and strict policies when
  and in whose presence such envelopes may be opened
- - people with different roles (e.g. an administrator to manage systems,
  security officers to identify and create users, etc...)
- - written and approved POLICIES! situations DO happen when someone
  barges in your office and needs a new certificate immediately and just
  happens not to have any ID with him/herself but expects you to believe
  him/her that he really IS at the university and DOES have the right to
  get the certificate.
  Of course, you can immediately issue a certificate, but does that
  person REALLY have the legitimate right to receive the cert?
- - if you expect to issue a large number of certificates (e.g. > 100),
  you might want to think about registration offices to identify users
  instead of you, the administrator (i presume that you don't want to
  personally create 100+ certificates for your users?). in which case,
  you'll need some SW and the OpenSSL CA.pl script is out of the
  question.
- - key escrow! are you going to back up your user's private keys? if yes,
  you definetly need some policy under which you disclose the key.
  (users are hasty, often don't know exactly what they are doing and if
  they have used their key to encrypt some data and loose the key..
  they'll get angry. in that case, you could save them :))
- - again, WRITE your policies and MAKE THEM PUBLIC.

Or, it can be one man band with an old desktop computer under your desk locked
in an office with you issuing certificates whenever someone visits your office.
And anything in between the two extremes.

You might even think of using a hardware cryptographic module for maximum
security.
Ask yourself, what happens if your root key gets compromised? are you willing
to pay >= 3000EUR for a tamper-resistant HW device? some of manufacturers that
I can recommend, as I've worked with their products, are Thales E-security and
NCipher. Both deliver PKCS#11 drivers for Linux.

If you choose GPG, you could (should!) use the GPG smart-card for the
root key.

>
> I have some ideas, but need more input. Maybe some of you could help me out.
> 
If you choose to go down the X.509 route, you have MUCH additional reading to
do! And BTW, here's another plus for X.509 certificates: much of the
existing client software (LookOut, Mozilla, Thunderbird, etc.) can be
configured to check CRL each time it verifies a signature. I don't know
whether that is possible with GPG. Except for requesting the key from
the keyserver each time anew, although it is already in the keyring.

Personally, with my experience and in your position, my order of preference
would be:

1. X.509 with Microsoft CA
2. X.509 with OpenCA 
3. X.509 with OpenSSL and CA.pl (for small number of users; not more than 100)
4. GnuPG

This is based on my perceived amount of management in the long run. If
most of your users are Win users, then I'd say that X.509 is definetly a
win, as it works nicely across all platforms and mail clients, with no
additional plugins needed for the most popular software (LookOut,
Mozilla, Thunderbird).

I would rank the initial setup effort as 2, 1, 3, 4.

Note that your security and operational policies are orthogonal to the
standard and technology you choose (i.e. OpenPGP vs. X.509 on any platform).

Hope I've helped a bit :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDrF7cFtofFpCIfhMRA3uWAJ9vlFR9UIJaKEQqSwvKY6c+X1Y09ACfYPi1
DjyY1MAMdDaUltNA65MhMTs=
=j0hn
-----END PGP SIGNATURE-----