CAs act as agents of trust in a PKI. As long as users trust a CA and its business processes, they can trust certificates issued by the CA. This is known as third-party trust. The certificate includes the user's name in a format of a distinguished name (DN), that may contain additional attributes (such as employee number) to uniquely identify the user. The certificate also specifies the validity period (or lifetime) of the certificate, and the specific operations for which the public key is to be used (whether for encrypting data, verifying digital signatures, or both)
The CA's signature on
a certificate ensures that any changes to the contents can be
easily detected, which makes them tamper-proof. As the certificates
are inherently secure they can conveniently be distributed in
a completely public manner, and users retrieving a public key
from a certificate can be assured that it is valid. That is, users
can trust that the key belongs to a the entity specified by the
distinguished name, and that the key can be used safely in the
manner for which it was certified by the CA.
Key Backup and Recovery, not Key
Escrow
A business must be able to retrieve encrypted data
when users lose their decryption keys. This means that the enterprise
to which the user belongs requires a system for backing up and
recovering these keys. This is known as commercial key backup
and recovery, and is different than law enforcement-style trusted-third
party key escrow. Key escrow systems are designed so that a third
party (such as law enforcement) can obtain the decryption keys
required to access encrypted information. Key escrow requirements
are currently under public policy debate, however the key backup
and recovery requirements are separate and there is no debate
about them, as users will forget passwords or lose hardware devices
(such as smart cards) that may contain their private keys.
Support for Non-Repudiation
Repudiation occurs when an individual denies involvement
in a transaction. Non-repudiation means that an individual cannot
successfully deny involvement in a transaction. In the paper-world,
individuals' signatures legally bind them to their transactions,
and the signature prevents repudiation of those transactions.
In the electronic world,
the replacement for the pen-based signature is a digital signature.
The most basic requirement
for non-repudiation is that the key used to create digital signatures-the
signing key-be generated and securely stored in a manner under
the sole control of the user at all times. Unlike encryption key
pairs, there is no technical or business requirement to backup
or restore previous signing key pairs when users forget their
passwords or otherwise lose their signing keys. In such cases,
it is acceptable for users to generate new signing key pairs and
continue using them from that time forward.
Two Key Pairs are Required
It appears difficult to simultaneously support key
backup and recovery and non-repudiation. To support key backup
and recovery, the user's private keys must be backed up securely.
To support non-repudiation, the user's private keys used for digital
signature cannot be backed up. To meet these requirements, a PKI
must support two key pairs for each user. At any point in time,
a user must have one current key pair for encryption and decryption,
and a second key pair for digital signature and signature verification.
Key Update and Management of Key
Histories
Over time, users will have numerous key pairs that must be managed
as cryptographic keys should not be used forever. The keys must
be updated over time, and the history of all keys previously used
must be maintained. (For example, users will need to decrypt information
many years from now, and verify a digital signature on a contract
many years in the future).
The process of updating
keys pairs should be transparent to users. This means users do
not have to understand that key update needs to take place and
they will never experience a "denial of service" because
their keys are no longer valid. To meet this requirement, users'
key pairs must be automatically updated before they expire. Also,
when a signing key pair is updated, the previous signing key be
securely destroyed. This prevents anyone else from gaining access
to the signing key and is acceptable because there is no need
to retain previous signing keys.
Certificate Repositories and Certificate
Distribution
The term repository refers to a service that allows for
distribution of certificates. The CA acts as a trusted third-party
issuing certificates to users, and businesses must distribute
those certificates so they can be used by applications. Certificate
repositories store certificates so that applications can retrieve
them on behalf of users.
The de facto standard for
access to these repositories is the
Lightweight Directory Access Protocol (LDAP) mechanism. Many directory
technologies support LDAP and can scale for very large implementations,
provide for different techniques to respond efficiently to search
requests and retrieval methods, and may be distributed throughout
an organization's network.
Certificate Revocation
Every time an application uses a certificate and verifies
the CA's signature on it, the application must also determine
that the certificate is still trustworthy at time of use. Certificates
that are no longer trustworthy must be revoked by the CA.
There are numerous reasons why a certificate may need to be revoked prior to the end of its validity period. For instance, the private key corresponding to the public key in the certificate may be compromised. Alternatively, an organization's security policy may dictate that the certificates of employees leaving the organization must be revoked. In these situations, users in the system must be informed that continued use of the certificate is no longer considered secure.
The revocation status of a certificate must be checked prior to each use. As a result, a PKI must incorporate a scalable certificate revocation system. The CA must be able to securely publish information regarding the status of each certificate in the system. Application software, on behalf of users, must then verify the revocation information prior to each use of a certificate. The combination of publishing and consistently using certificate revocation information constitutes a complete revocation system.
The most popular means
for distributing certificate revocation information is for the
CA to create certificate revocation lists (CRLs) and publish these
to a directory. CRLs specify the unique serial numbers of all
revoked certificates. Prior to using a certificate, the client-side
application must check the appropriate CRL to determine if the
certificate is still trustworthy.
Cross-Certification
Cross-certification extends third-party trust relationships
between CA domains. For example, two trading partners, each with
their own CA, may want to validate certificates issued by the
other partner's CA. Alternatively, a large, distributed organization
may require multiple CAs in various geographic regions. Cross-certification
allows different CA domains to establish and maintain trustworthy
electronic relationships.
In the case of bilateral cross-certification, two CAs securely exchange their public keys, and each CA signs the other's public key in a certificate known as a cross-certificate.
Trust is maintained in
a cross-certified environment by the client-side application software
verifying the CA's signature on certificates. This operation is
often referred to as "walking a chain of trust". The
"chain" refers to a list of cross-certificate validations
that are "walked" from the CA key of the verifying user
to the CA key required to validate the other user's certificate.
When walking a chain of cross-certificates, each one is checked
to ensure that it is still trusted, because as with user certificates,
cross-certificates may also be revoked. This requirement is frequently
overlooked in discussions regarding cross-certification.
Client-Side Software
The PKI must include client-side software to allow
various applications to interact with the PKI to handle all the
issues discussed in this paper, such as automatically checking
the CRL that corresponds to a certificate, renewing certificates,
providing the interface to the key backup system, remembering
key histories, and dealing with all the other lifecycle issues
with keys and certificates. Most importantly, the client-side
software provides for a consistent interface and trust management
for all applications. This allows significant cost of ownership
advantages by offering a corporation one security system to administer
for multiple applications.
Summary
The goal of a PKI is to establish and maintain a trustworthy
networking environment. This goal is achieved by providing key
and certificate management services that enable encryption and
digital signature capabilities across applications. Many of the
necessary functions to achieve an automatic and transparent system
require interactions with client-side software. While it is possible
to provide some level of security to applications without using
a comprehensive PKI, (for example S/MIME compliant mail packages
that only support a peer-to-peer trust model, with user based
certificate management, and no key recovery), it is unlikely however
that this would be acceptable for corporate use.
Brian O'Higgins will be speaking on the
"Public-Key
Infrastructure(PKI)" session on Wednesday, April 29 from 2:30-4:00 at
EMA'98 in Anaheim, California.