This section describes how certificates are used to establish trusted relationships.
Describe certificate hierarchies, certificate chains, and trusted relationships.
Certificate Authorities
Certificate authorities (CAs) are entities that validate
identities and issue certificates. They can be either independent third
parties or organizations running their own certificate-issuing server
software (such as the Netscape Certificate Server). A list of third-party
certificate authorities is available at Certificate Authority Services.
Any client or server software that supports certificates maintains a collection
of trusted CA certificates. These CA certificates determine which other
certificates the software can validate--in other words, which issuers
of certificates the software can trust. In the simplest case, the software
can validate only certificates issued by one of the CAs for which it has
a certificate. It's also possible for a trusted CA certificate to be part
of a chain of CA certificates, each issued by the CA above it in a certificate
hierarchy.
Certificate Hierarchies
Figure 2.15
Organizations have a great deal of flexibility in terms of the way
they set up their CA hierarchies.
This shows just one example; many other arrangements are possible.
Certificate Chains
CA hierarchies are reflected in certificate chains.
Figure 2.16
Verifying a Certificate Chain
Certificate chain verification is the process of making sure
a given certificate chain is well-formed, valid, properly signed, and
trustworthy. Netscape software uses the following procedure for forming
and verifying a certificate chain, starting with the certificate being
presented for authentication:
The certificate validity period is checked against the current
time provided by the verifier's system clock.
The issuer's certificate is located. The source can be either the
verifier's local certificate database (on that client or server) or
the certificate chain provided by the subject (for example, over an
SSL connection).
The certificate signature is verified using the public key in the
issuer's certificate.
If the issuer's certificate is trusted by the verifier in the verifier's
certificate database, verification stops successfully here. Otherwise,
the issuer's certificate is checked to make sure it contains the appropriate
subordinate CA indication in the Netscape certificate type extension,
and chain verification returns to the first step to start again, but
with this new certificate.
Expired validity dates, an invalid signature, or the absence of a
certificate for the issuing CA at any point in the certificate
chain causes authentication to fail.
Managing Certificates
The set of standards and services that facilitate the use of
public-key cryptography and X.509 v3 certificates in a networked environment
is called the public key infrastructure (PKI). PKI management is complex
topic beyond the scope of this document. The sections that follow introduce
some of the specific certificate management issues addressed by Netscape products.
Issuing Certificates
Certificates and the LDAP Directory
Key Management
Renewing and Revoking Certificates
Registration Authorities
Issuing Certificates
The process for issuing a certificate depends on the certificate
authority that issues it and the purpose for which it will be used. The
process for issuing nondigital forms of identification varies in similar
ways. For example, if you want to get a generic ID card (not a driver's
license) from the Department of Motor Vehicles in California, the requirements
are straightforward: you need to present some evidence of your identity,
such as a utility bill with your address on it and a student identity
card. If you want to get a regular driving license, you also need to take
a testa driving test when you first get the license, and a written
test when you renew it. If you want to get a commercial license for an
eighteen-wheeler, the requirements are much more stringent. If you live
in some other state or country, the requirements for various kinds of
licenses will differ.
Similarly, different CAs have different procedures for issuing different
kinds of certificates. In some cases the only requirement may be your
email address. In other cases, your Unix or NT login and password may
be sufficient. At the other end of the scale, for certificates that
identify people who can authorize large expenditures or make other sensitive
decisions, the issuing process may require notarized documents, a background
check, and a personal interview.
Depending on an organization's policies, the process of issuing certificates
can range from being completely transparent for the user to requiring
significant user participation and complex procedures. In general, processes
for issuing certificates should be highly flexible, so organizations
can tailor them to their changing needs.
The Netscape Certificate Server, allows an organization to set up
its own certificate authority and issue certificates.
Issuing certificates is one of several management tasks that can be
handled by separate Registration Authorities.
Certificates and the LDAP Directory
The Lightweight Directory Access Protocol (LDAP) for accessing
directory services supports great flexibility in the management of certificates
within an organization. System administrators can store much of the information
required to manage certificates in an LDAP-compliant directory. For example,
a CA can use information in a directory to prepopulate a certificate with
a new employee's legal name and other information. The CA can leverage
directory information in other ways to issue certificates one at a time
or in bulk, using a range of different identification techniques depending
on the security policies of a given organization. Other routine management
tasks, such as Key Management and Renewing and Revoking Certificates,
can be partially or fully automated with the aid of the directory.
Information stored in the directory can also be used with certificates
to control access to various network resources by different users or
groups. Issuing certificates and other certificate management tasks
can thus be an integral part of user and group management.
In general, high-performance directory services are an essential ingredient
of any certificate management strategy. The Netscape Directory Server,
part of the Mission Control family of products, is fully integrated
with the Netscape Certificate Server to provide a comprehensive certificate
management solution.
Key Management
Before a certificate can be issued, the public key it contains
and the corresponding private key must be generated. Sometimes it may
be useful to issue a single person one certificate and key pair for signing
operations, and another certificate and key pair for encryption operations.
Separate signing and encryption certificates make it possible to keep
the private signing key on the local machine only, thus providing maximum
nonrepudiation, and to back up the private encryption key in some central
location where it can be retrieved in case the user loses the original
key or leaves the company.
Keys can be generated by client software or generated centrally by
the CA and distributed to users via an LDAP directory. There are tradeoffs
involved in choosing between local and centralized key generation. For
example, local key generation provides maximum nonrepudiation, but may
involve more participation by the user in the issuing process. Flexible
key management capabilities are essential for most organizations.
Key recovery, or the ability to retrieve backups of encryption keys
under carefully defined conditions, can be a crucial part of certificate
management (depending on how an organization uses certificates). Key
recovery schemes usually involve an m of n mechanism: for example, m
of n managers within an organization might have to agree, and each contribute
a special code or key of their own, before a particular person's encryption
key can be recovered. This kind of mechanism ensures that several authorized
personnel must agree before an encryption key can be recovered.
Renewing and Revoking Certificates
Like a driver's license, a certificate specifies a period of
time during which it is valid. Attempts to use a certificate for authentication
before or after its validity period will fail. Therefore, mechanisms for
managing certificate renewal are essential for any certificate management
strategy. For example, an administrator may wish to be notified automatically
when a certificate is about to expire, so that an appropriate renewal
process can be completed in plenty of time without causing the certificate's
subject any inconvenience. The renewal process may involve reusing the
same public-private key pair or issuing a new one.
A driver's license can be suspended even if it has not expired--for
example, as punishment for a serious driving offense. Similarly, it's
sometimes necessary to revoke a certificate before it has expired--for
example, if an employee leaves a company or moves to a new job within
the company.
Certificate revocation can be handled in several different ways. For
some organizations, it may be sufficient to set up servers so that the
authentication process includes checking the directory for the presence
of the certificate being presented. When an administrator revokes a
certificate, the certificate can be automatically removed from the directory,
and subsequent authentication attempts with that certificate will fail
even though the certificate remains valid in every other respect. Another
approach involves publishing a certificate revocation list (CRL)--that
is, a list of revoked certificates--to the directory at regular intervals
and checking the list as part of the authentication process. For some
organizations, it may be preferable to check directly with the issuing
CA each time a certificate is presented for authentication. This procedure
is sometimes called real-time status checking.
Registration Authorities
Interactions between entities identified by certificates (sometimes
called end entities) and CAs are an essential part of certificate management.
These interactions include operations such as registration for certification,
certificate retrieval, certificate renewal, certificate revocation, and
key backup and recovery. In general, a CA must be able to authenticate
the identities of end entities before responding to the requests. In addition,
some requests need to be approved by authorized administrators or managers
before being services.
As previously discussed, the means used by different CAs to verify
an identity before issuing a certificate can vary widely, depending
on the organization and the purpose for which the certificate will be used.
To provide maximum operational flexibility, interactions with
end entities can be separated from the other functions of a CA and handled
by a separate service called a Registration Authority (RA).
An RA acts as a front end to a CA by receiving end entity requests,
authenticating them, and forwarding them to the CA. After receiving
a response from the CA, the RA notifies the end entity of the results.
RAs can be helpful in scaling an PKI across different departments, geographical
areas, or other operational units with varying policies and authentication
requirements.
Future versions of the Netscape Certificate Server will support the
creation of customizable registration authorities.