Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual page 20

Chapter 1. Introduction to Public-Key Cryptography
messages loses the private key and does not have access to a backup copy of the key, the encrypted
messages can never be decrypted.
1.3.3.1.3. Single Sign-on
Network users are frequently required to remember multiple passwords for the various services they
use. For example, a user might have to type a different password to log into the network, collect email,
use directory services, use the corporate calendar program, and access various servers. Multiple
passwords are an ongoing headache for both users and system administrators. Users have difficulty
keeping track of different passwords, tend to choose poor ones, and tend to write them down in
obvious places. Administrators must keep track of a separate password database on each server
and deal with potential security problems related to the fact that passwords are sent over the network
routinely and frequently.
Solving this problem requires some way for a user to log in once, using a single password, and get
authenticated access to all network resources that user is authorized to use-without sending any
passwords over the network. This capability is known as single sign-on.
Both client SSL certificates and S/MIME certificates can play a significant role in a comprehensive
single sign-on solution. For example, one form of single sign-on supported by Red Hat products
relies on SSL client authentication. A user can log in once, using a single password to the local
client's private-key database, and get authenticated access to all SSL-enabled servers that user is
authorized to use-without sending any passwords over the network. This approach simplifies access
for users, because they don't need to enter passwords for each new server. It also simplifies network
management, since administrators can control access by controlling lists of certificate authorities
(CAs) rather than much longer lists of users and passwords.
In addition to using certificates, a complete single-sign on solution must address the need to
interoperate with enterprise systems, such as the underlying operating system, that rely on passwords
or other forms of authentication.
1.3.3.1.4. Object Signing
Many software technologies support a set of tools called object signing. Object signing uses standard
techniques of public-key cryptography to let users get reliable information about code they download in
much the same way they can get reliable information about shrink-wrapped software.
Most important, object signing helps users and network administrators implement decisions about
software distributed over intranets or the Internet-for example, whether to allow Java applets signed by
a given entity to use specific computer capabilities on specific users' machines.
The objects signed with object signing technology can be applets or other Java code, JavaScript
scripts, plug-ins, or any kind of file. The signature is a digital signature. Signed objects and their
signatures are typically stored in a special file called a JAR file.
Software developers and others who wish to sign files using object-signing technology must first obtain
an object-signing certificate.
1.3.3.2. Types of Certificates
The Certificate System is capable of generating different types of certificates for different uses and in
different formats. Planning which certificates are required and planning how to manage them, including
determining what formats are needed and how to plan for renewal, are important to manage both the
PKI and the Certificate System instances.
10