P1: JDW
PublicKey WL040/Bidgolio-Vol I WL040-Sample.cls June 19, 2003 16:56 Char Count= 0
160 PUBLICKEYINFRASTRUCTURE(PKI)in 1988, specifies the authentication framework for the
X.500 Directory. The X.500 Directory requires strong au-
thentication to ensure that only authorized users make
modifications. In addition, when the directory contains
confidential information, authentication can be used to
control directory access.
Over time, the focus shifted from supporting the direc-
tory to developing a general-purpose PKI. As a result, two
upwardly compatible versions have been published since- Version 2 certificates addressed a single issue: reuse
of names. The Version 2 enhancements are rarely used
today. Version 3 of the X.509 certificate introduces cer-
tificate extensions. Extensions are used when the issuer
wishes to include information not supported by the basic
certificate fields. All modern PKI implementations gener-
ate and process X.509 version 3 (X.509 v3) certificates. The
set of extensions used by implementations varies widely.
The Internet Engineering Task Force (IETF) profiled
X.509 certificates for the Internet. Like all Internet stan-
dards, it is published in a request for comment (RFC)
document. The Internet Certificate and CRL Profile, RFC
2459, was published in March 1999. In April 2002, RFC
2459 was replaced by RFC 3280, which identifies optional
features of X.509 that are required for the Internet, and it
discourages the use of other features.
Subjects and issuers are identified using the distin-
guished name (DN), a structured type that supports the
X.500 hierarchical naming system. The X.500 suite of
standards was expected to result in a global directory. This
lofty goal required a name form that could be used to cre-
ate globally unique names. Naming authorities manage
their own name spaces, and only that authority assigns
names in that space, ensuring collision-free names.
Additional name forms are supported through sub-
ject alternative name extension and the issuer alternative
name extension. The additional name forms include, but
are not limited to, the following:
Internet domain names (often called DNS names)
RFC 822 e-mail addresses
X.400 e-mail addresses
World Wide Web URLsCERTIFICATE REVOCATION
Two approaches are used today for certificate status: CRL
and OCSP. The basic mechanism for certificate status is
the CRL, which is profiled for Internet use in RFC 3280.
A CA revokes a certificate by placing the certificate serial
number and revocation date on the signed CRL. Certifi-
cate users simply search the most recent CRL to determine
whether a particular certificate is revoked.
OCSP is specified in RFC 2560, and it enables appli-
cations to determine the status of a particular certificate
by querying an OCSP responder. A certificate user sends a
status request to the OCSP responder, and then the OCSP
responder replies with digitally signed certificate status in-
formation. The CA can host this service locally, or the CA
can delegate this responsibility to an independent OCSP
responder.
When using CRLs, the CA name and certificate se-
rial number identify a certificate, but OCSP uses themore complicated certificate identifier. In the absence of
a global directory system, it is possible that two CAs could
choose the same name. Because an OCSP responder may
provide service for multiple CAs, the OCSP responder
must be able to distinguish CAs with the same name. Two
CAs will not have the same public key, so a hash of the
issuer public key is used in addition to the hash of the CA
name to identify the issuer.
OCSP is often described as providing revocation infor-
mation in a more timely fashion than CRLs. An OCSP
responder can provide the most up-to-date information
it possesses without repository latency. If the OCSP re-
sponder is also the CA, the most up-to-date information
will be provided. With CRLs, the CA may have additional
information that it cannot provide to certificate users. In
practice, however, there has been little difference in fresh-
ness of the certificate status information provided by an
OCSP responder and a CRL.
Most OCSP responders are not CAs. Rather, they are
single-purpose machines that handle certificate status re-
quests for a large number of CAs. Typically, these servers
obtain their revocation information periodically in the
form of CRLs. The information obtained by the requester
is no fresher than if they obtained the same CRLs them-
selves.
The certificate user must place irrevocable trust in the
OCSP responder because there is no way for the certificate
user to determine if the OCSP responder itself has been
revoked. The actions needed to revoke an OCSP responder
are similar to the actions needed to remove a trust anchor.
The real utility of OCSP lies in the single-response ex-
tension fields. If an application is checking a purchase
order signature, the OCSP responder could provide a re-
sponse stating that the certificate is not revoked and that
the signature is acceptable for the stated dollar amount.
CRLs cannot provide this additional context-specific func-
tionality.PKI MANAGEMENT PROTOCOLS
A CA needs to obtain the subscriber’s public key, authen-
ticate the subscriber’s identity, verify that the subscriber
possesses the corresponding private key, and verify any
additional subscriber and key information before it signs
a certificate. If the certificate contains incorrect informa-
tion, a certificate user may establish security services with
the wrong user or employ the public key for an inappropri-
ate application. A CA must also determine that the status
of a certificate has changed before it adds the certificate to
the CRL. If the CA adds a valid certificate to the CRL, sub-
scribers are denied service. If the CA fails to add a certifi-
cate whose status has changed to the CRL, certificate users
will accept the invalid certificate. To meet these require-
ments, the CA must obtain trustworthy information from
PKI participants.PKI management protocolsare used by
CAs to collect the information needed to issue certificates
and CRLs. There are several PKI management protocols.
Management protocols support two basic types of trans-
actions:certificate requestsandrevocation requests.
As noted earlier, a CA needs to obtain trustworthy in-
formation before issuing or revoking a certificate. It may
obtain this information from three PKI participants: the