A number of projects, the highest profile one being the GRID, are
using Public Key Infrastructure as a security infrastructure. In
public key technology the encryption algorithms have a two-part
identifier for each party: a public key and a private key. Information
encrypted with the public key can only be read by using the private
key (and vice versa). For a more detailed of this topic, see What is a Digital
Signature?
The public key assigned to an identity is intended to be widely known since each person intending to communicate securely via PKI with that individual needs to know their public key. The concept of certificates has been created to bind a public key to some more recognizable identity. Care in issuing certificates only ensures that someone named "John Smith" was issued the certificate and that the issuer should be able to tell you which "John Smith" it was. The subject of a certificate is known as an "End Entity". Certificates are typically grouped into two classes (User and Service) to distinguish between persons and processes. The subject named in the certificate is assumed to be the only holder of the private key.
This is where the work for the key owner comes in. The system is only as good as the protection of that private key. Whoever possesses it can "become" that individual in all PKI regards. There is no way to change protection of a private key after it's been stolen to "fix" things. For example, changing the password which encrypts the private key solves nothing, since changing the user's copy does nothing to the stolen one -- it is still valid. The private key itself must be changed, and hence the certificate associating the old public key to the identity must be revoked and a new one issued. Since identity in PKI is tied to a private/public keypair, this is nearly equivalent to establishing a new identity and so somewhat painful.
To relieve our users of the need to maintain adequate file protection, and avoid the need to re-register folks at FNAL, we have tied our Kerberos infrastructure to a PKI and can generate short-lived (~7 days) PKI credentials that are useful for a number of purposes. (Grid work, Web authentication, and IPSec session establishment are some examples being used). About the only common PKI applications we've come across that are not covered by this system are email signatures and encryption.
The system that implements this is called the "KCA" (for Kerberized
Certificate Authority) and comes from work from the University of
Michigan. Linux and UNIX users can use the kx509 utility (included with Fermi
Kerberos in Scietific Linux (Fermi) and available from UPS/UPD as the
kx509 product otherwise) to obtain a certificate once they have a
Kerberos ticket (after using kinit,
for instance). The Kerberos client and KCA X.509 tools for Windows
users have been packaged in a ZIP file for download
and installation in a directory of the user's choice, this package
includes a readme1st.txt
file which describes the kit's contents. Additionally a webpage on How to get a
Grid Proxy at FNAL is available.
For host/service certificates, there is no particular advantage to a
FNAL
specific CA service, so we recommend that people use the
DOEGrids CA
service provided by ESNET to the DOE Science community. A web page with
instructions for Fermilab system administrators can be found at How
to get a DOEGrids Certificate for Fermilab Hosts or Services (Grid and
Web).
For cases where a KCA certificate is inadequate, such as E-mail
signatures and encryption, Fermilab staff and users can obtain a
Personal Certificate from the DOEGrids CA. The web page How
to get a Personal DOEGrids Certificate for Fermilab Staff and Users
contains instructions on doing this and installing the certificate
multiple browsers on multiple systems (such as home and work systems).