our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at www.networkcomputing.com /express/

At one time, support groups needed to deal with only trusted root certificates to support secure Web browsing. Those that implemented SSL (Secure Sockets Layer) for their own Web servers had to acquire server certificates. User authentication certificates have been used occasionally for client authentication via SSL 3.0, but this is just the tip of the iceberg. Now cross-certificates, signing, authorization and authorization delegation certificates must fit into the picture. A user might need many authentication and/or encrypting certificates, to say nothing of authorization certificates.

A Road Map to Trust The purpose of the infrastructure surrounding digital certificates is to establish a level of trust between two public keys. A user's or server's digital certificate starts a chain of trust that is mapped through at least one other certificate to the receiving user's digital certificate. This certificate chain is the trust map. Only a few types of certificates are needed to create a PKI (public key infrastructure), regardless of the PKI's complexity.

All PKIs start with at least one root certificate. To visualize a root certificate, remember one basic feature of a digital certificate: A digital certificate is nothing more than a file that contains the certificate owner's public key and name and the certificate signer's name (among other sundry pieces of information). This file is digitally signed with a cryptographic hash by the signer's private key (this signature is also part of the file). A root certificate is self-signed--that is, the owner and signer names are the same, and the owning public key in the certificate is the matching public key for the signing private key.

The root certificate is trusted because the owner of it claims to be trustworthy. The owner of a root certificate establishes this trust by protecting the signing root private key from theft; if it is stolen, it can be used to falsely sign certificates. A root certificate is in turn a signing certificate, or a certificate whose private key is used to sign other certificates, thereby proclaiming that the public key of those certificates are the equivalent of the owner name and anything done with the matching private key is performed for that named entity.

All root certificates are signing certificates, but not all signing certificates are root certificates. Any certificate can be designated as a signing certificate, in effect creating a signing hierarchy. In a hierarchy, trust is established by walking the certificate chain back to the common root certificate. Another form of trust chaining is created by cross-certificates. These are special certificates created by the owner of a signing certificate where the name is the same as that of the signing certificate and signed by a different signing certificate. Together, these root, signing and cross certificates establish a trust among user certificates.

The Storehouse of Trust If root, signing and cross certificates form the road map of trust, then the repositories that hold them are the rest stops along the way. The repositories are accessed for every trust resolution. The systems that produce these certificates and sign the user certificates see little activity; they are used only when new certificates are signed or current ones are revoked. They don't require high reliability: In some cases, outages lasting hours can be tolerated. The repositories are different: They need to be highly reliable, reachable and very fast.