Certificate Revocation: When Not To Trust

[InfoSec News <isn () C4I ORG>]

http://networkcomputing.com/1112/1112ws1.html

June 26, 2000
By Mike Fratto

Installing and managing a PKI (public key infrastructure) have
far-reaching implications in an enterprise. A PKI by itself offers no
value until it is paired with applications and services designed to
leverage its functionality. Briefly, a PKI needs to issue digital
certificates to individuals and organizations, manage the certificates
during their life cycles and publish information about the
certificates to directories. In this article, we'll explain managing
and applying certificate revocation.

Revocation data can be published in a CRL (certificate revocation
list), which is a signed list of certificate serial numbers; a CRDP
(certificate revocation distribution point), which consists of
partitioned CRLs; or an OCSP (online certificate status protocol), a
client/server protocol used to query a VA (validation authority) for
certificate status.

Some aspects of revocation, however, are the same regardless of the
publishing method. In fact, many of the issues surrounding revocation
have little to do with technology--they are primarily organizational.
And often your choice of revocation method will be determined by the
end application. But understanding the revocation methods will help
you make the most of what you have.

Certificate Contents

Certificates contain information about the end entities as minimally
defined by Internet X.509 Public Key Infrastructure Certificate and
CRL Profile in RFC 2459. Other attributes may be entered into a
certificate as well. For example, common fields in a certificate might
define mailing addresses, spending limits or access-control fields. A
certificate can contain virtually any information that is customizable
via the CA (certificate authority).

Certificates are given a set life span when issued. For example, a
certificate may be valid for 365 days. Then it expires and a new
certificate must be issued. There is an indirect relationship,
however, between the information contained in the certificate and its
useful lifetime. Generally speaking, the more information in the
certificate, the shorter its usefulness, because the information may
change and a new certificate will have to be reissued before the first
expires. Moreover, any information contained in the certificate will
be publicly available. Therefore, the rule of thumb is to include as
little information as possible.

Certificate revocation is a necessary part of the certificate process.
There are many reasons why you might want to revoke a certificate long
before it expires. For example, a user might change organizations or
lose his or her key pair, or an e-commerce site using SSL (Secure
Sockets Layer) may close up shop. In all these cases, the certificate
needs to be revoked before it expires so that it cannot be
used--either unwittingly or for nefarious purposes.

Revocation Methods

CAs often offer multiple revocation methods, because they support a
wide range of applications. And revocation methods usually can be
added as needed. The most common revocation method is the CRL, though
OCSP is gaining favor. If your applications support multiple
revocation methods, OCSP is the better choice because with OCSP the
applications don't need to process potentially large CRLs and the
revocation data may be more up to date.

A CRL is simply a list of certificate serial numbers signed by the CA.
Every certificate has a unique serial number assigned to it by the CA;
this number is part of the signed certificate and cannot be altered.
When an application attempts to validate the certificate, it needs
only to look up the serial number in the CRL associated with the
signing CA. However, getting the CRL is a separate problem. Minimally,
some applications may import CRLs via files or through some other
mechanism, such as FTP or HTTP. Obviously, the process of importing
files doesn't scale well and is best used for pilot programs or
troubleshooting. Ideally, applications should be able to query the CRL
from the signing CA's directory via LDAP. Note that generic client
applications, such as Netscape Communications Corp.'s Navigator, can't
query or even download CRLs. In fact, client applications don't do any
revocation checking at all. Client applications need to be capable of
checking CRLs.

CRLs, while widely supported, pose two potential problems: They may
become very large in size, and they may not be published often enough.

The size issue hasn't had much impact yet, because PKI installations
are relatively small at present. CRDP can shorten a large list by
partitioning it into smaller chunks of data. A user certificate
contains a URL that points to the directory location holding a
certificate's distribution point, which may be a different directory
than the CA uses.

Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC 2459 defines CRDP as being based on certificate types. This
addresses the other reason for CRDP: Some certificates may require
more rapid notification of revocation. Typically, a CA publishes one
CRL at set intervals regardless of certificate type. However,
high-value certificates, such as CA certificates, must be published
much more often because of the loss of trust involved.

Sometimes CRLs are just not enough for timely certificate validation.
Consider an online banking transaction. Both the client and the bank
need to authenticate and validate each other. If CRLs are published
only every hour, however, that leaves nearly 60 minutes during which a
revoked certificate is still valid. OCSP, a PKIX protocol defined in
Online Certificate Status Protocol-OCSP RFC 2560, addresses this need
well. A CA publishes revocation data via CRL or LDAP update to an
OCSP-enabled directory or to a VA. When a PKI application wishes to
validate a certificate, it queries the OCSP responder, which in turn
replies with one of three statuses: "good," "revoked" or "unknown." A
response of "good" doesn't mean the certificate is valid; it means
that the certificate was not revoked at the time the request was made.

CAs publish revocation data to OCSP responders in a variety of ways.
CRLs can be pushed or pulled into the OCSP responder, or the
revocation data can be published directly. In either case, the
responder must trust the publishing CA's certificate to confirm the
information published to it is from the correct source. Additionally,
the client must trust the responder that is signing the OCSP
responses. This means a bit more work in securely distributing
certificates, but the value is well worth it.

OCSP has been widely deployed through the efforts of ValiCert: The
company has aggressively formed strategic partnerships with PKI
vendors and offers a client plug-in for common Internet applications,
such as Netscape Communicator and Microsoft Internet Explorer. The
plug-ins work seamlessly with these applications, offering the
possibility to check certificate status. ValiCert also offers online
certificate processing.

OCSP does have its drawbacks. Unlike a CRL, OCSP does not offer a
method for offline validation processing, and the load on the OCSP
responder can be quite high because each response must be signed by
the responder.

OCSP, while aimed at providing timely certificate-status checking, may
be prone to the same impediments of CRLs--namely the time lag between
revoking a certificate and its publishing. The time lag is beyond the
scope of OCSP.

Managing Revocation

Fundamentally, revocation is a balancing act, and as much attention
needs to be paid to laying out its policies and procedures as is given
to any other business task. When you install your CA, you often can
define how revocation data is posted to the directory--per revocation
or periodically--in addition to pushing a CRL manually. Each method
has a different impact on the CA and the trust model.

If you choose to publish revocation data periodically, you have to set
a reasonable time limit--depending on your needs. The issue is the
time lag between publishing. If you publish CRLs every 12 hours, say
at noon and midnight, then a certificate that is revoked at 12:01 a.m.
won't show up in the list until noon, 11 hours and 59 minutes later.
If you are using certificates for user authentication or business
transactions, the lag becomes more important.

Revocation publishing time also impacts applications that are using
your CA for trust, because many applications use CRLs to validate
certificates. Because CRLs are published periodically, the application
can download a new CRL as soon as it is published. If you change the
publication period, however, the trusting applications will need to
update their time schedules to ensure they have the latest CRL. Many
CAs allow revocation data to be published manually, but that doesn't
mean all applications will take advantage of the data, because those
apps may not have retrieved the updated CRL yet.

Certificates can be revoked, or they can be temporarily suspended.
Baltimore UniCert, Entrust Authority, VeriSign, Xcert Sentry CA and
other CAs all support suspension. Suspension is used when revocation
is too drastic. For example, if a user forgets the PIN to his or her
certificate store or misplaces his or her PKI token, the associated
certificates can be suspended until the user recalls the PIN or finds
the token. The suspended certificate will be placed on the revocation
list but can later be restored. Suspension suffers from the same
time-lag problem as revocation, however, both for getting on the
revocation list and for getting off.

There is one last aspect of certificate revocation that needs context.
Issuing multiple certificates is a common practice in PKIs. For
example, a user may be issued one certificate and key pair that are
used solely for encryption and a second certificate and key pair for
signing. The purpose is to limit the damage in case of compromise and
to escrow keys used for encryption. You never want to escrow keys used
for signing because there is no way to prove the owner of the keys is
the sole user. Other certificates may be issued for other reasons,
such as object signing. As the number of certificates per user grows,
so does the task of managing them. The resulting certificate
revocation data will grow accordingly.

For the most part, the vendor community has addressed revocation with
custom-built applications for individual PKI installations. Given not
only the technical complexity but also the organizational complexity a
PKI foists on organizations, revocation hasn't posed a significant
concern compared with other implementation issues.

Send your comments on this article to Mike Fratto at mfratto () nwc com.

ISN is hosted by SecurityFocus.com
---
To unsubscribe email LISTSERV () SecurityFocus com with a message body of
"SIGNOFF ISN".