Public-key cryptography and
related standards and techniques underlie security features of many Netscape
products, including signed and encrypted email, form signing, object signing,
single sign-on, and the Secure Sockets Layer (SSL) protocol. This document
introduces the basic concepts of public-key cryptography.
Internet
Security Issues
Encryption
and Decryption
Digital
Signatures
Certificates
and Authentication
Managing
Certificates
For more information on these topics and other aspects of
cryptography, see Security Resources.
For an overview of SSL, see Introduction to SSL.
All communication over the Internet uses the
Transmission Control Protocol/Internet Protocol (TCP/IP). TCP/IP allows
information to be sent from one computer to another through a variety of
intermediate computers and separate networks before it reaches its
destination.
The great flexibility of TCP/IP has led to its worldwide
acceptance as the basic Internet and intranet communications protocol. At the
same time, the fact that TCP/IP allows information to pass through intermediate
computers makes it possible for a third party to interfere with communications
in the following ways:
Normally, users of the many cooperating computers that make up the
Internet or other networks don't monitor or interfere with the network traffic
that continuously passes through their machines. However, many sensitive
personal and business communications over the Internet require precautions that
address the threats listed above. Fortunately, a set of well-established
techniques and standards known as public-key cryptography make it
relatively easy to take such precautions.
Public-key cryptography facilitates the following
tasks:
The sections that follow introduce the concepts of
public-key cryptography that underlie these capabilities.
[Top]
Encryption is the process of transforming
information so it is unintelligible to anyone but the intended recipient.
Decryption is the process of transforming encrypted information so that it is
intelligible again. A cryptographic algorithm, also called a
cipher, is a mathematical function used for encryption or decryption. In
most cases, two related functions are employed, one for encryption and the other
for decryption.
With most modern cryptography, the ability to keep
encrypted information secret is based not on the cryptographic algorithm, which
is widely known, but on a number called a key that must be used with the
algorithm to produce an encrypted result or to decrypt previously encrypted
information. Decryption with the correct key is simple. Decryption without the
correct key is very difficult, and in some cases impossible for all practical
purposes.
The sections that follow introduce the use of keys for
encryption and decryption.
Symmetric-Key
Encryption
Public-Key
Encryption
Key
Length and Encryption Strength
With symmetric-key encryption, the encryption key can be
calculated from the decryption key and vice versa. With most symmetric
algorithms, the same key is used for both encryption and decryption, as shown in
Figure
1.
Figure 1 Symmetric-key encryption
Implementations of symmetric-key encryption can be
highly efficient, so that users do not experience any significant time delay as
a result of the encryption and decryption. Symmetric-key encryption also
provides a degree of authentication, since information encrypted with one
symmetric key cannot be decrypted with any other symmetric key. Thus, as long as
the symmetric key is kept secret by the two parties using it to encrypt
communications, each party can be sure that it is communicating with the other
as long as the decrypted messages continue to make sense.
Symmetric-key encryption is effective only if the
symmetric key is kept secret by the two parties involved. If anyone else
discovers the key, it affects both confidentiality and authentication. A person
with an unauthorized symmetric key not only can decrypt messages sent with that
key, but can encrypt new messages and send them as if they came from one of the
two parties who were originally using the key.
Symmetric-key encryption plays an important role in the
SSL protocol, which is widely used for authentication, tamper detection, and
encryption over TCP/IP networks. SSL also uses techniques of public-key
encryption, which is described in the next section.
The most commonly used implementations of public-key encryption are
based on algorithms patented by RSA
Data Security. Therefore, this section describes the RSA approach to
public-key encryption.
Public-key encryption (also called asymmetric
encryption) involves a pair of keys--a public key and a private
key--associated with an entity that needs to authenticate its identity
electronically or to sign or encrypt data. Each public key is published, and the
corresponding private key is kept secret. (For more information about the way
public keys are published, see Certificates
and Authentication.) Data encrypted with your public key can be decrypted
only with your private key. Figure
2 shows a simplified view of the way public-key encryption works.
Figure 2 Public-key encryption
The scheme shown in Figure
2 lets you freely distribute a public key, and only you will be able to read
data encrypted using this key. In general, to send encrypted data to someone,
you encrypt the data with that person's public key, and the person receiving the
encrypted data decrypts it with the corresponding private key.
Compared with symmetric-key encryption, public-key
encryption requires more computation and is therefore not always appropriate for
large amounts of data. However, it's possible to use public-key encryption to
send a symmetric key, which can then be used to encrypt additional data. This is
the approach used by the SSL protocol.
As it happens, the reverse of the scheme shown in Figure
2 also works: data encrypted with your private key can be decrypted only
with your public key. This would not be a desirable way to encrypt sensitive
data, however, because it means that anyone with your public key, which is by
definition published, could decrypt the data. Nevertheless, private-key
encryption is useful, because it means you can use your private key to sign data
with your digital signature--an important requirement for electronic commerce
and other commercial applications of cryptography. Client software such as
Communicator can then use your public key to confirm that the message was signed
with your private key and that it hasn't been tampered with since being signed.
Digital
Signatures and subsequent sections describe how this confirmation process
works.
In general, the strength of encryption is related to the
difficulty of discovering the key, which in turn depends on both the cipher used
and the length of the key. For example, the difficulty of discovering the key
for the RSA cipher most commonly used for public-key encryption depends on the
difficulty of factoring large numbers, a well-known mathematical problem.
Encryption strength is often described in terms of the
size of the keys used to perform the encryption: in general, longer keys provide
stronger encryption. Key length is measured in bits. For example, 128-bit keys
for use with the RC4 symmetric-key cipher supported by SSL provide significantly
better cryptographic protection than 40-bit keys for use with the same cipher.
Roughly speaking, 128-bit RC4 encryption is 3 x 1026 times stronger
than 40-bit RC4 encryption. (For more information about RC4 and other ciphers
used with SSL, see Introduction to SSL.)
Different ciphers may require different key lengths to
achieve the same level of encryption strength. The RSA cipher used for
public-key encryption, for example, can use only a subset of all possible values
for a key of a given length, due to the nature of the mathematical problem on
which it is based. Other ciphers, such as those used for symmetric key
encryption, can use all possible values for a key of a given length, rather than
a subset of those values. Thus a 128-bit key for use with a symmetric-key
encryption cipher would provide stronger encryption than a 128-bit key for use
with the RSA public-key encryption cipher.
This difference explains why the RSA public-key
encryption cipher must use a 512-bit key (or longer) to be considered
cryptographically strong, whereas symmetric key ciphers can achieve
approximately the same level of strength with a 64-bit key. Even this level of
strength may be vulnerable to attacks in the near future.
Because the ability to surreptitiously intercept and
decrypt encrypted information has historically been a significant military
asset, the U.S. Government restricts export of cryptographic software, including
most software that permits use of symmetric encryption keys longer than 40 bits.
For detailed information about these restrictions as they apply to Netscape
products, see Export Restrictions on International Sales.
[Top]
Encryption and decryption address the problem of
eavesdropping, one of the three Internet security issues mentioned at the
beginning of this document. But encryption and decryption, by themselves, do not
address the other two problems mentioned in Internet
Security Issues: tampering and impersonation.
This section describes how public-key cryptography
addresses the problem of tampering. The sections that follow describe how it
addresses the problem of impersonation.
Tamper detection and related authentication techniques
rely on a mathematical function called a one-way hash (also called a
message digest). A one-way hash is a number of fixed length with the
following characteristics:
As mentioned in Public-Key
Encryption, it's possible to use your private key for encryption and your
public key for decryption. Although this is not desirable when you are
encrypting sensitive information, it is a crucial part of digitally signing any
data. Instead of encrypting the data itself, the signing software creates a
one-way hash of the data, then uses your private key to encrypt the hash. The
encrypted hash, along with other information, such as the hashing algorithm, is
known as a digital signature.
Figure
3 shows a simplified view of the way a digital signature can be used to
validate the integrity of signed data.
Figure 3 Using a digital signature to
validate data integrity
Figure
3 shows two items transferred to the recipient of some signed data: the
original data and the digital signature, which is basically a one-way hash (of
the original data) that has been encrypted with the signer's private key. To
validate the integrity of the data, the receiving software first uses the
signer's public key to decrypt the hash. It then uses the same hashing algorithm
that generated the original hash to generate a new one-way hash of the same
data. (Information about the hashing algorithm used is sent with the digital
signature, although this isn't shown in the figure.) Finally, the receiving
software compares the new hash against the original hash. If the two hashes
match, the data has not changed since it was signed. If they don't match, the
data may have been tampered with since it was signed, or the signature may have
been created with a private key that doesn't correspond to the public key
presented by the signer.
If the two hashes match, the recipient can be certain
that the public key used to decrypt the digital signature corresponds to the
private key used to create the digital signature. Confirming the identity of the
signer, however, also requires some way of confirming that the public key really
belongs to a particular person or other entity. For a discussion of the way this
works, see Certificates
and Authentication.
The significance of a digital signature is comparable to
the significance of a handwritten signature. Once you have signed some data, it
is difficult to deny doing so later--assuming that the private key has not been
compromised or out of the owner's control. This quality of digital signatures
provides a high degree of nonrepudiation--that is, digital signatures make it
difficult for the signer to deny having signed the data. In some situations, a
digital signature may be as legally binding as a handwritten signature.
[Top]
A
Certificate Identifies Someone or Something
Authentication
Confirms an Identity
How
Certificates Are Used
Contents
of a Certificate
How
CA Certificates Are Used to Establish Trust
A certificate is an electronic
document used to identify an individual, a server, a company, or some other
entity and to associate that identity with a public key. Like a driver's
license, a passport, or other commonly used personal IDs, a certificate provides
generally recognized proof of a person's identity. Public-key cryptography uses
certificates to address the problem of impersonation (see Internet
Security Issues).
To get a driver's license, you typically apply to a
government agency, such as the Department of Motor Vehicles, which verifies your
identity, your ability to drive, your address, and other information before
issuing the license. To get a student ID, you apply to a school or college,
which performs different checks (such as whether you have paid your tuition)
before issuing the ID. To get a library card, you may need to provide only your
name and a utility bill with your address on it.
Certificates work much the same way as any of these
familiar forms of identification. Certificate authorities (CAs) are
entities that validate identities and issue certificates. They can be either
independent third parties or organizations running their own certificate-issuing
server software (such as Netscape Certificate Server). The methods used to
validate an identity vary depending on the policies of a given CA--just as the
methods to validate other forms of identification vary depending on who is
issuing the ID and the purpose for which it will be used. In general, before
issuing a certificate, the CA must use its published verification procedures for
that type of certificate to ensure that an entity requesting a certificate is in
fact who it claims to be.
The certificate issued by the CA binds a particular
public key to the name of the entity the certificate identifies (such as the
name of an employee or a server). Certificates help prevent the use of fake
public keys for impersonation. Only the public key certified by the certificate
will work with the corresponding private key possessed by the entity identified
by the certificate.
In addition to a public key, a certificate always
includes the name of the entity it identifies, an expiration date, the name of
the CA that issued the certificate, a serial number, and other information. Most
importantly, a certificate always includes the digital signature of the issuing
CA. The CA's digital signature allows the certificate to function as a "letter
of introduction" for users who know and trust the CA but don't know the entity
identified by the certificate.
For more information about the role of CAs, see How
CA Certificates Are Used to Establish Trust.
Authentication is the process of confirming an
identity. In the context of network interactions, authentication involves the
confident identification of one party by another party. Authentication over
networks can take many forms. Certificates are one way of supporting
authentication.
Network interactions typically take place between a
client, such as browser software running on a personal computer, and a
server, such as the software and hardware used to host a Web site.
Client authentication refers to the confident identification of a client
by a server (that is, identification of the person assumed to be using the
client software). Server authentication refers to the confident
identification of a server by a client (that is, identification of the
organization assumed to be responsible for the server at a particular network
address).
Client and server authentication are not the only forms
of authentication that certificates support. For example, the digital signature
on an email message, combined with the certificate that identifies the sender,
provide strong evidence that the person identified by that certificate did
indeed send that message. Similarly, a digital signature on an HTML form,
combined with a certificate that identifies the signer, can provide evidence,
after the fact, that the person identified by that certificate did agree to the
contents of the form. In addition to authentication, the digital signature in
both cases ensures a degree of nonrepudiation--that is, a digital signature
makes it difficult for the signer to claim later not to have sent the email or
the form.
Client authentication is an essential element of network
security within most intranets or extranets. The sections that follow contrast
two forms of client authentication:
- Password-Based
Authentication. Almost all server software permits client authentication
by means of a name and password. For example, a server might require a user to
type a name and password before granting access to the server. The server
maintains a list of names and passwords; if a particular name is on the list,
and if the user types the correct password, the server grants access.
- Certificate-Based
Authentication. Client authentication based on certificates is part of the
SSL protocol. The client digitally signs a randomly generated piece of data
and sends both the certificate and the signed data across the network. The
server uses techniques of public-key cryptography to validate the signature
and confirm the validity of the certificate.
Figure
4 shows the basic steps involved in authenticating a client by means of a
name and password. Figure 4 assumes the following:
Figure 4 Using a password to
authenticate a client to a server
These are the steps shown in Figure 4:
- In response to an authentication request from the server,
the client displays a dialog box requesting the user's name and password for
that server. The user must supply a name and password separately for each new
server the user wishes to use during a work session.
- The client sends the name and password across the network,
either in the clear or over an encrypted SSL connection.
- The server looks up the name and password in its local
password database and, if they match, accepts them as evidence authenticating
the user's identity.
- The server determines whether the identified user is
permitted to access the requested resource, and if so allows the client to
access it.
With this arrangement, the user must
supply a new password for each server, and the administrator must keep track of
the name and password for each user, typically on separate servers.
As shown in the next section, one of the advantages of
certificate-based authentication is that it can be used to replace the first
three steps in Figure 2 with a mechanism that allows the user to supply just one
password (which is not sent across the network) and allows the administrator to
control user authentication centrally.
Figure
5 shows how client authentication works using certificates and the SSL
Protocol. To authenticate a user to a server, a client digitally signs a
randomly generated piece of data and sends both the certificate and the signed
data across the network. For the purposes of this discussion, the digital
signature associated with some data can be thought of as evidence provided by
the client to the server. The server authenticates the user's identity on the
strength of this evidence.
Like Figure
4, Figure
5 assumes that the user has already decided to trust the server and has
requested a resource, and that the server has requested client authentication in
the process of evaluating whether to grant access to the requested resource.
Figure 5 Using a certificate to
authenticate a client to a server
Unlike the process shown in Figure 4, the process
shown in Figure 5 requires the use of SSL. Figure 5 also assumes that the client
has a valid certificate that can be used to identify the client to the server.
Certificate-based authentication is generally considered preferable to
password-based authentication because it is based on what the user has (the
private key) as well as what the user knows (the password that protects the
private key). However, it's important to note that these two assumptions are
true only if unauthorized personnel have not gained access to the user's machine
or password, the password for the client software's private key database has
been set, and the software is set up to request the password at reasonably
frequent intervals.
Important Neither
password-based authentication nor certificate-based authentication address
security issues related to physical access to individual machines or
passwords. Public- key cryptography can only verify that a private key used to
sign some data corresponds to the public key in a certificate. It is the
user's responsibility to protect a machine's physical security and to keep the
private-key password secret.
These are the
steps shown in Figure 3:
- The client software, such as Communicator, maintains a
database of the private keys that correspond to the public keys published in
any certificates issued for that client. The client asks for the password to
this database the first time the client needs to access it during a given
session--for example, the first time the user attempts to access an
SSL-enabled server that requires certificate-based client authentication.
After entering this password once, the user doesn't need to enter it again for
the rest of the session, even when accessing other SSL-enabled servers.
- The client unlocks the private-key database, retrieves the
private key for the user's certificate, and uses that private key to digitally
sign some data that has been randomly generated for this purpose on the basis
of input from both the client and the server. This data and the digital
signature constitute "evidence" of the private key's validity. The digital
signature can be created only with that private key and can be validated with
the corresponding public key against the signed data, which is unique to the
SSL session.
- The client sends both the user's certificate and the
evidence (the randomly generated piece of data that has been digitally signed)
across the network.
- The server uses the certificate and the evidence to
authenticate the user's identity. (For a detailed discussion of the way this
works, see Introduction to SSL.)
- At this point the server may optionally perform other
authentication tasks, such as checking that the certificate presented by the
client is stored in the user's entry in an LDAP directory. The server then
continues to evaluate whether the identified user is permitted to access the
requested resource. This evaluation process can employ a variety of standard
authorization mechanisms, potentially using additional information in an LDAP
directory, company databases, and so on. If the result of the evaluation is
positive, the server allows the client to access the requested resource.
As you can see by comparing Figure
5 to Figure
4, certificates replace the authentication portion of the interaction
between the client and the server. Instead of requiring a user to send passwords
across the network throughout the day, single sign-on requires the user to enter
the private-key database password just once, without sending it across the
network. For the rest of the session, the client presents the user's certificate
to authenticate the user to each new server it encounters. Existing
authorization mechanisms based on the authenticated user identity are not
affected.
Types
of Certificates
SSL
Protocol
Signed
and Encrypted Email
Form
Signing
Single
Sign-On
Object
Signing
Five kinds of certificates are commonly used with Netscape
products:
- Client SSL certificates. Used to identify clients
to servers via SSL (client authentication). Typically, the identity of the
client is assumed to be the same as the identity of a human being, such as an
employee in an enterprise. See Certificate-Based
Authentication for a description of the way client SSL certificates are
used for client authentication. Client SSL certificates can also be used for
Form
Signing and as part of a Single
Sign-On solution.
Examples: A bank gives a customer a
client SSL certificate that allows the bank's servers to identify that
customer and authorize access to the customer's accounts. A company might
give a new employee a client SSL certificate that allows the company's
servers to identify that employee and authorize access to the company's
servers.
- Server SSL certificates. Used to identify servers
to clients via SSL (server authentication). Server authentication may be used
with or without client authentication. Server authentication is a requirement
for an encrypted SSL session. See SSL
Protocol.
Example: Internet sites that engage in
electronic commerce (commonly known as e-commerce) usually support
certificate-based server authentication, at a minimum, to establish an
encrypted SSL session and to assure customers that they are dealing with a
web site identified with a particular company. The encrypted SSL session
ensures that personal information sent over the network, such as credit card
numbers, cannot easily be intercepted.
- S/MIME certificates. Used for signed and encrypted
email. As with client SSL certificates, the identity of the client is
typically assumed to be the same as the identity of a human being, such as an
employee in an enterprise. A single certificate may be used as both an S/MIME
certificate and an SSL certificate. See Signed
and Encrypted Email. S/MIME certificates can also be used for Form
Signing and as part of a Single
Sign-On solution.
Examples: A company deploys combined
S/MIME and SSL certificates solely for the purpose of authenticating
employee identities, thus permitting signed email and client SSL
authentication but not encrypted email. Another company issues S/MIME
certificates solely for the purpose of both signing and encrypting email
that deals with sensitive financial or legal matters.
- Object-signing certificates. Used to identify
signers of Java code, JavaScript scripts, or other signed files. See Object
Signing.
Example: A software company signs
software distributed over the Internet to provide users with some assurance
that the software is a legitimate product of that company. Using
certificates and digital signatures in this manner can also make it possible
for users to identify and control the kind of access downloaded software has
to their computers.
- CA certificates. Used to identify CAs. Client and
server software use CA certificates to determine what other certificates can
be trusted. See How
CA Certificates Are Used to Establish Trust.
Example: The CA certificates stored in
Communicator determine what other certificates that copy of Communicator can
authenticate. An administrator can implement some aspects of corporate
security policies by controlling the CA certificates stored in each user's
copy of Communicator.
The sections
that follow describes how certificates are used by Netscape products.
The
Secure Sockets Layer (SSL) protocol, which was originally developed by Netscape,
is a set of rules governing server authentication, client authentication, and
encrypted communication between servers and clients. SSL is widely used on the
Internet, especially for interactions that involve exchanging confidential
information such as credit card numbers.
SSL requires a server SSL certificate, at a minimum. As
part of the initial "handshake" process, the server presents its certificate to
the client to authenticate the server's identity. The authentication process
uses Public-Key
Encryption and Digital
Signatures to confirm that the server is in fact the server it claims to be.
Once the server has been authenticated, the client and server use techniques of
Symmetric-Key
Encryption, which is very fast, to encrypt all the information they exchange
for the remainder of the session and to detect any tampering that may have
occurred.
Servers may optionally be configured to require client
authentication as well as server authentication. In this case, after server
authentication is successfully completed, the client must also present its
certificate to the server to authenticate the client's identity before the
encrypted SSL session can be established.
For an overview of client authentication over SSL and how
it differs from password-based authentication, see Authentication
Confirms an Identity. For more detailed information about SSL, see Introduction to SSL.
Some email programs (including Messenger, which is part of
Communicator) support digitally signed and encrypted email using a widely
accepted protocol known as Secure Multipurpose Internet Mail Extension (S/MIME).
Using S/MIME to sign or encrypt email messages requires the sender of the
message to have an S/MIME certificate.
An email message that includes a digital signature
provides some assurance that it was in fact sent by the person whose name
appears in the message header, thus providing authentication of the sender. If
the digital signature cannot be validated by the email software on the receiving
end, the user will be alerted.
The digital signature is unique to the message it
accompanies. If the message received differs in any way from the message that
was sent--even by the addition or deletion of a comma--the digital signature
cannot be validated. Therefore, signed email also provides some assurance that
the email has not been tampered with. As discussed at the beginning of this
document, this kind of assurance is known as nonrepudiation. In other words,
signed email makes it very difficult for the sender to deny having sent the
message. This is important for many forms of business communication. (For
information about the way digital signatures work, see Digital
Signatures.)
S/MIME also makes it possible to encrypt email messages.
This is also important for some business users. However, using encryption for
email requires careful planning. If the recipient of encrypted email messages
loses his or her private key and does not have access to a backup copy of the
key, for example, the encrypted messages can never be decrypted.
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 Netscape products relies on SSL client
authentication (see Certificate-Based
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.
For information about the single sign-on support
currently provided by Netscape products, see Single Sign-On Deployment Guide.
Many kinds of e-commerce require the ability to provide persistent
proof that someone has authorized a transaction. Although SSL provides transient
client authentication for the duration of an SSL connection, it does not provide
persistent authentication for transactions that may occur during that
connection. S/MIME provides persistent authentication for email, but e-commerce
often involves filling in a form on a web page rather than sending an email.
The Netscape technology known as form signing addresses
the need for persistent authentication of financial transactions. Form signing
allows a user to associate a digital signature with web-based data generated as
the result of a transaction, such as a purchase order or other financial
document. The private key associated with either a client SSL certificate or an
S/MIME certificate may be used for this purpose.
When a user clicks the Submit button on a web-based form
that supports form signing, a dialog box appears that displays the exact text to
be signed. The form designer can either specify the certificate that should be
used or allow the user to select a certificate from among the client SSL and
S/MIME certificates that are installed in Communicator. When the user clicks OK,
the text is signed, and both the text and the digital signature are submitted to
the server. The server can then use a Netscape utility called the Signature
Verification Tool to validate the digital signature.
For more information about support for form signing in
Netscape products, see Netscape Form Signing.
Communicator and other Netscape products support a set of tools and
technologies 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 importantly, 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.
For more information about support for object signing in
Netscape products, see Netscape Object Signing: Establishing Trust for Downloaded
Software.
The contents of certificates supported by Netscape and many other
software companies are organized according to the X.509 v3 certificate
specification, which has been recommended by the International
Telecommunications Union (ITU), an international standards body, since 1988.
Users don't usually need to be concerned about the exact
contents of a certificate. However, system administrators working with
certificates may need some familiarity with the information provided here.
An X.509 v3 certificate binds a distinguished name (DN) to a
public key. A DN is a series of name-value pairs, such as
uid=doe
, that uniquely
identify an entity--that is, the certificate subject.
For example, this might be a typical DN for an employee
of Netscape Communications Corporation:
uid=doe,e=doe@netscape.com,cn=John Doe,o=Netscape Communications Corp.,c=US
The abbreviations
before each equal sign in this example have these meanings:
uid
: user ID
e
: email address
cn
: the user's common name
o
: organization
c
: country DNs may include a variety of
other name-value pairs. They are used to identify both certificate subjects and
entries in directories that support the Lightweight Directory Access Protocol
(LDAP).
The rules governing the construction of DNs can be quite
complex and are beyond the scope of this document. For comprehensive information
about DNs, see A
String Representation of Distinguished Names.
Every X.509 certificate consists of two sections:
- The data section includes the following information:
- The version number of the X.509 standard supported by
the certificate.
- The certificate's serial number. Every certificate
issued by a CA has a serial number that is unique among the certificates
issued by that CA.
- Information
- Information about the user's public key, including the
algorithm used and a representation of the key itself.
- The DN of the CA that issued the certificate.
- The period during which the certificate is valid (for
example, between 1:00 p.m. on November 15, 1996 and 1:00 p.m. November 15,
1997)
- The DN of the certificate subject (for example, in a
client SSL certificate this would be the user's DN), also called the subject
name.
- Optional certificate extensions, which may
provide additional data used by the client or server. For example, the
certificate type extension indicates the type of certificate--that is,
whether it is a client SSL certificate, a server SSL certificate, a
certificate for signing email, and so on. Certificate extensions can also be
used for a variety of other purposes.
- The signature section includes the following
information:
Here are the data and signature
sections of a certificate in human-readable format:
Certificate:
Data:
Version: v3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US
Validity:
Not Before: Fri Oct 17 18:36:25 1997
Not After: Sun Oct 17 18:36:25 1999
Subject: CN=Jane Doe, OU=Finance, O=Ace Industry, C=US
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key:
Modulus:
00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:
ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22:
43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:
98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:
9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:
7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
91:f4:15
Public Exponent: 65537 (0x10001)
Extensions:
Identifier: Certificate Type
Critical: no
Certified Usage:
SSL Client
Identifier: Authority Key Identifier
Critical: no
Key Identifier:
f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36:
26:c9
Signature:
Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06:
30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc:
2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5:
b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5:
4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:
dd:c4
Here is the same
certificate displayed in the 64-byte-encoded form interpreted by software:
-----BEGIN CERTIFICATE-----
MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER
MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw
MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK
EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0
dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG
7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L
iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ
NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV
HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt
I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3
UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84
hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A==
-----END CERTIFICATE-----
Certificate authorities (CAs) are entities that
validate identities and issue certificates. They can be either independent third
parties or organizations running their own certificate-issuing server software
(such as the Netscape Certificate Server). A list of third-party certificate
authorities is available at Certificate Authority Services.
Any client or server software that supports certificates
maintains a collection of trusted CA certificates. These CA certificates
determine which other certificates the software can validate--in other words,
which issuers of certificates the software can trust. In the simplest case, the
software can validate only certificates issued by one of the CAs for which it
has a certificate. It's also possible for a trusted CA certificate to be part of
a chain of CA certificates, each issued by the CA above it in a certificate
hierarchy.
The sections that follow explains how certificate
hierarchies and certificate chains determine what certificates software can
trust.
CA
Hierarchies
Certificate
Chains
Verifying
a Certificate Chain
In large organizations, it may be appropriate to delegate the
responsibility for issuing certificates to several different certificate
authorities. For example, the number of certificates required may be too large
for a single CA to maintain; different organizational units may have different
policy requirements; or it may be important for a CA to be physically located in
the same geographic area as the people to whom it is issuing certificates.
It's possible to delegate certificate-issuing
responsibilities to subordinate CAs. The X.509 standard includes a model for
setting up a hierarchy of CAs like that shown in Figure
6.
Figure 6 Example of a hierarchy of
certificate authorities
In this model, the root CA is at the top of the
hierarchy. The root CA's certificate is a self-signed certificate: that
is, the certificate is digitally signed by the same entity--the root CA--that
the certificate identifies. The CAs that are directly subordinate to the root CA
have CA certificates signed by the root CA. CAs under the subordinate CAs in the
hierarchy have their CA certificates signed by the higher-level subordinate
CAs.
Organizations have a great deal of flexibility in terms
of the way they set up their CA hierarchies. Figure
6 shows just one example; many other arrangements are possible.
CA hierarchies are reflected in certificate chains. A
certificate chain is series of certificates issued by successive CAs. Figure
7 shows a certificate chain leading from a certificate that identifies some
entity through two subordinate CA certificates to the CA certificate for the
root CA (based on the CA hierarchy shown in Figure
6).
Figure 7 Example of a certificate chain
A certificate chain traces a path of certificates
from a branch in the hierarchy to the root of the hierarchy. In a certificate
chain, the following occur:
Certificate chain verification is the process of making sure a
given certificate chain is well-formed, valid, properly signed, and trustworthy.
Netscape software uses the following procedure for forming and verifying a
certificate chain, starting with the certificate being presented for
authentication:
- The certificate validity period is checked against the
current time provided by the verifier's system clock.
- The issuer's certificate is located. The source can be
either the verifier's local certificate database (on that client or server) or
the certificate chain provided by the subject (for example, over an SSL
connection).
- The certificate signature is verified using the public key
in the issuer's certificate.
- If the issuer's certificate is trusted by the verifier in
the verifier's certificate database, verification stops successfully here.
Otherwise, the issuer's certificate is checked to make sure it contains the
appropriate subordinate CA indication in the Netscape certificate type
extension, and chain verification returns to step 1 to start again, but with
this new certificate. Figure
8 presents an example of this process.
Figure 8 Verifying a certificate chain
all the way to the root CA
Figure 8 shows what happens when only Root CA is
included in the verifier's local database. If a certificate for one of the
intermediate CAs shown in Figure 8, such as Engineering CA, is found in the
verifier's local database, verification stops with that certificate, as shown in
Figure
9.
Figure 9 Verifying a certificate chain
to an intermediate CA
Expired validity dates, an invalid signature, or the
absence of a certificate for the issuing CA at any point in the certificate
chain causes authentication to fail. For example, Figure
10 shows how verification fails if neither the Root CA certificate nor any
of the intermediate CA certificates are included in the verifier's local
database.
Figure 10 A certificate chain that can't
be verified
For general information about the way digital
signatures work, see Digital
Signatures. For a more detailed description of the signature verification
process in the context of SSL client and server authentication, see Introduction to SSL.
[Top]
The set of standards and services that
facilitate the use of public-key cryptography and X.509 v3 certificates in a
networked environment is called the public key infrastructure (PKI). PKI
management is complex topic beyond the scope of this document. The sections that
follow introduce some of the specific certificate management issues addressed by
Netscape products.
Issuing
Certificates
Certificates
and the LDAP Directory
Key
Management
Renewing
and Revoking Certificates
Registration
Authorities
The process for issuing a certificate depends on the certificate
authority that issues it and the purpose for which it will be used. The process
for issuing nondigital forms of identification varies in similar ways. For
example, if you want to get a generic ID card (not a driver's license) from the
Department of Motor Vehicles in California, the requirements are
straightforward: you need to present some evidence of your identity, such as a
utility bill with your address on it and a student identity card. If you want to
get a regular driving license, you also need to take a test--a driving test when
you first get the license, and a written test when you renew it. If you want to
get a commercial license for an eighteen-wheeler, the requirements are much more
stringent. If you live in some other state or country, the requirements for
various kinds of licenses will differ.
Similarly, different CAs have different procedures for
issuing different kinds of certificates. In some cases the only requirement may
be your email address. In other cases, your Unix or NT login and password may be
sufficient. At the other end of the scale, for certificates that identify people
who can authorize large expenditures or make other sensitive decisions, the
issuing process may require notarized documents, a background check, and a
personal interview.
Depending on an organization's policies, the process of
issuing certificates can range from being completely transparent for the user to
requiring significant user participation and complex procedures. In general,
processes for issuing certificates should be highly flexible, so organizations
can tailor them to their changing needs.
The Netscape
Certificate Server, part of the Mission
Control family of products, allows an organization to set up its own
certificate authority and issue certificates.
Issuing certificates is one of several managements tasks
that can be handled by separate Registration
Authorities.
The Lightweight Directory Access Protocol (LDAP) for
accessing directory services supports great flexibility in the management of
certificates within an organization. System administrators can store much of the
information required to manage certificates in an LDAP-compliant directory. For
example, a CA can use information in a directory to prepopulate a certificate
with a new employee's legal name and other information. The CA can leverage
directory information in other ways to issue certificates one at a time or in
bulk, using a range of different identification techniques depending on the
security policies of a given organization. Other routine management tasks, such
as Key
Management and Renewing
and Revoking Certificates, can be partially or fully automated with the aid
of the directory.
Information stored in the directory can also be used with
certificates to control access to various network resources by different users
or groups. Issuing certificates and other certificate management tasks can thus
be an integral part of user and group management.
In general, high-performance directory services are an
essential ingredient of any certificate management strategy. The Netscape
Directory Server, part of the Mission
Control family of products, is fully integrated with the Netscape
Certificate Server to provide a comprehensive certificate management
solution.
Before a certificate can be issued, the public key it contains and
the corresponding private key must be generated. Sometimes it may be useful to
issue a single person one certificate and key pair for signing operations, and
another certificate and key pair for encryption operations. Separate signing and
encryption certificates make it possible to keep the private signing key on the
local machine only, thus providing maximum nonrepudiation, and to back up the
private encryption key in some central location where it can be retrieved in
case the user loses the original key or leaves the company.
Keys can be generated by client software or generated
centrally by the CA and distributed to users via an LDAP directory. There are
trade-offs involved in choosing between local and centralized key generation.
For example, local key generation provides maximum nonrepudiation, but may
involve more participation by the user in the issuing process. Flexible key
management capabilities are essential for most organizations.
Key recovery, or the ability to retrieve backups
of encryption keys under carefully defined conditions, can be a crucial part of
certificate management (depending on how an organization uses certificates). Key
recovery schemes usually involve an m of n mechanism: for example,
m of n managers within an organization might have to agree, and
each contribute a special code or key of their own, before a particular person's
encryption key can be recovered. This kind of mechanism ensures that several
authorized personnel must agree before an encryption key can be recovered.
Like a driver's license, a certificate specifies a period
of time during which it is valid. Attempts to use a certificate for
authentication before or after its validity period will fail. Therefore,
mechanisms for managing certificate renewal are essential for any certificate
management strategy. For example, an administrator may wish to be notified
automatically when a certificate is about to expire, so that an appropriate
renewal process can be completed in plenty of time without causing the
certificate's subject any inconvenience. The renewal process may involve reusing
the same public-private key pair or issuing a new one.
A driver's license can be suspended even if it has not
expired--for example, as punishment for a serious driving offense. Similarly,
it's sometimes necessary to revoke a certificate before it has expired--for
example, if an employee leaves a company or moves to a new job within the
company.
Certificate revocation can be handled in several
different ways. For some organizations, it may be sufficient to set up servers
so that the authentication process includes checking the directory for the
presence of the certificate being presented. When an administrator revokes a
certificate, the certificate can be automatically removed from the directory,
and subsequent authentication attempts with that certificate will fail even
though the certificate remains valid in every other respect. Another approach
involves publishing a certificate revocation list (CRL)--that is, a list
of revoked certificates--to the directory at regular intervals and checking the
list as part of the authentication process. For some organizations, it may be
preferable to check directly with the issuing CA each time a certificate is
presented for authentication. This procedure is sometimes called real-time
status checking.
Interactions between entities identified by certificates (sometimes
called end entities) and CAs are an essential part of certificate
management. These interactions include operations such as registration for
certification, certificate retrieval, certificate renewal, certificate
revocation, and key backup and recovery. In general, a CA must be able to
authenticate the identities of end entities before responding to the requests.
In addition, some requests need to be approved by authorized administrators or
managers before being services.
As previously discussed, the means used by different CAs
to verify an identity before issuing a certificate can vary widely, depending on
the organization and the purpose for which the certificate will be used. To
provide maximum operational flexibility, interactions with end entities can be
separated from the other functions of a CA and handled by a separate service
called a Registration Authority (RA).
An RA acts as a front end to a CA by receiving end entity
requests, authenticating them, and forwarding them to the CA. After receiving a
response from the CA, the RA notifies the end entity of the results. RAs can be
helpful in scaling an PKI across different departments, geographical areas, or
other operational units with varying policies and authentication
requirements.
Future versions of the Netscape
Certificate Server will support the creation of customizable registration
authorities.
[Top]
Last Updated: 10/09/98 10:35:45