The Internet Encyclopedia (Volume 3)

P1: JDW

PublicKey WL040/Bidgolio-Vol I WL040-Sample.cls June 19, 2003 16:56 Char Count= 0

PKI BASICS 157

version

serialNumber

signature

issuer

validity

subject

subjectPublicKeyInfo

issuerUniqueID

subjectUniqueID

extensions

signatureAlgorithm

signatureValue

Figure 1: X.509 certificate structure.

The CA’s job is to link a public key with a subject’s iden-

tity in a trustworthy fashion. If the subject notifies the CA

that the certificate is no longer correct, then the issuer

needs to get that information to anyone who uses the cer-

tificate. To determine if the certificate is still trustworthy,

the certificate user supplements the unexpired certificate

with additional information: either acertificate revocation

list (CRL)or anonline certificate status protocol (OCSP)

response.

The CRL contains a digitally signed list of serial

numbers from unexpired certificates that should not be

trusted. The CA generates a CRL regularly and posts it for

anyone to obtain. The CA includes the issuance date in the

CRL, and usually a date by which an updated CRL will be

published. This allows the certificate user to be sure that

current information is used. Figure 2 illustrates a CRL

that revokes Bob’s certificate.

Alice would like to determine the status of Bob’s certifi-

cate, so she obtains a CRL issued by Hawk CA1. The CRL

was issued at 6:00 p.m. on April 15, 2002, and the next

issue can be expected 24 hours later. The CRL includes a

list of certificate serial numbers forrevokedcertificates.

Alternatively, the OCSP Response provides the revo-

cation status for a single certificate. The certificate user

sends a query to a trusted server using the OCSP, sus-

pending acceptance of the certificate in question until the

server returns a digitally signed response. In some circum-

stances, OCSP can provide more timely revocation infor-

mation than CRLs. More important to many applications,

OCSP can also provide additional certificate status infor-

mation.

One CA cannot reasonably issue certificates to every

Internet user. Obviously, there will be more than just one.

It is not possible for every Internet user to investigate each

CA and determine whether the issuer ought to be trusted.

A company might provide certificates to its employees; a

business might provide certificates to its customers and

business partners; or an Internet user might select a CA

version

signature

issuer

thisUpdate

nextUpdate

revokedCertificates

crlExtensions

signatureAlgorithm

signatureValue

SEQUENCE OF

userCertificate

revocationDate

crlEntryExtensions

Figure 2: X.509 CRL structure.

to issue their certificate. There are many potential sources

of certificate, each satisfying different marketplace needs.

Alice may get a certificate from Hawk CA1. Alice can

also trust other CAs that Hawk CA1 trusts. Hawk CA1 in-

dicates this trust by issuing them a certificate. These CAs

can indicate trust in other CAs by issuing them certifi-

cates. Alice can develop a chain of certificates and auto-

matically decide if certificates from another issuer may

be used for the intended purpose. Figure 3 illustrates two

Figure 3: Hierarchical PKI and mesh PKI architectures.