[unisog] PKI survey
Christopher A Bongaarts
cab at tc.umn.edu
Mon Nov 1 20:56:18 GMT 2004
In the immortal words of David Ressman:
> 2. Are you planning a new campus-wide PKI project, or expanding your
> existing PKI in a new capacity? Are you planning on integrating your
> campus-wide PKI with a Windows CA for use in Active Directory?
We are piloting a limited-purpose PKI deployment for the sole purpose
of doing two-factor authentication using USB smart-card-like tokens.
Taking on all aspects of PKI is unlikely to succeed unless you are
throwing a LOT of people, time, and money at the problem, since the
scope tends to be huge. We're hoping to avoid that by focusing on one
small piece of the PKI puzzle.
> 3. What PKI (CA/RA/etc.) software are you using? What software aren't
> you using and why not?
Homebrew using openssl, and integrated with our X.500 directory and
web signon systems.
I tried to set up OpenCA just to play with, and didn't get too far (it
is still somewhat Solaris-hostile, and configuring it is
non-trivial, but at least you've got source code to figure out what
it's really doing).
> 4. How do you authenticate the certificate chain to the clients?
> Ideally, we want to have someone like RSA or GeoTrust sign our CA
> outright, or use some kind of online validation service. It's not
> exactly clear to me which types of online verification mechanisms are
> ready for prime-time, and which are not. I realize that this could
> potentially be very expensive, but we think it'll be worth it in the
It is easier if you think of cert issuance for servers and users
For client auth, you can send the CA certificate to the
user at issuance time; you just have to document the process well
enough so the user actually trusts the CA cert if necessary. Because
our validation process is tied to the X.500 directory, we have a way
of checking "revocation status" outside of the normal PKI routes (if a
CA were compromised, just set the revoked flag for all certs in that
branch of the directory and they all stop working), so the usual
CRL/OCSP/etc. are not necessary.
For servers, there are generally two categories: ones that are exposed
for "general public" consumption (which might be just your users, but
if you have enough of them it's the same thing), and ones that are
intended for limited deployment. For the latter it may be realistic
to expect users to install a CA cert (as part of training or setting
up to use an application), but for the former it is just not going to
happen. Consider whether the support costs for dealing with (possibly
non-local) end-users having to support a CA, and see whether running
your own actually saves you money...
We use Thawte's SPKI service for server certs, where our office is
authorized to approve certificate requests submitted by departmental
sysadmins, and deducts the cost from a prepaid account. I think most
of the cert vendors offer something like this, but Thawte has always
had the best price by a good margin. No need for monkeying with
browsers unless they are really old and haven't done the root rollover
%% Christopher A. Bongaarts %% cab at tc.umn.edu %%
%% Internet Services %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
More information about the unisog