Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.

html#wp11284

Previous Contents Index Next

Sun Java(TM) System Administration Server 5.2 2005Q1 Administration Guide

Appendix A
Introduction to Public-Key Cryptography
Public-key cryptography and related standards and techniques underlie security features of
many Sun Java System products, including signed and encrypted mail, form signing, object
signing, single sign-on, and the Secure Sockets Layer (SSL) protocol. This appendix
introduces the basic concepts of public-key cryptography. This appendix contains the
following sections:

Internet Security Issues

Encryption and Decryption
Digital Signatures
Certificates and Authentication
Managing Certificates

For an overview of SSL, see Appendix B, "Introduction to SSL."

Internet Security Issues

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:

Eavesdropping. Information remains intact, but its privacy is compromised. For

example, someone could learn your credit card number, record a sensitive
conversation, or intercept classified information.
Tampering. Information in transit is changed or replaced and then sent on to the
recipient. For example, someone could alter an order for goods or change a person's
resume.
Impersonation. Information passes to a person who poses as the intended recipient.
Impersonation can take two forms, Spoofing and Misrepresentation.
Spoofing. A person pretends to be someone else. For example, a person can pretend to
have the mail address jdoe@example.com, or a computer can identify itself as a site
called www.example.com when it is not. This type of impersonation is known as
spoofing.
Misrepresentation. A person or organization misrepresents itself. For example,
suppose the site www.example.com pretends to be a furniture store when it is really
just a site that takes credit-card payments but never sends any goods.

1 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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:

Encryption and decryption allow two communicating parties to disguise information

they send to each other. The sender encrypts, or scrambles, information before sending
it. The receiver decrypts, or unscrambles, the information after receiving it. While in
transit, the encrypted information is unintelligible to an intruder.
Tamper detection allows the recipient of information to verify that it has not been
modified in transit. Any attempt to modify data or substitute a false message for a
legitimate one is detected.
Authentication allows the recipient of information to determine its origin—that is, to
confirm the sender's identity.
Nonrepudiation prevents the sender of information from claiming at a later date that
the information was never sent.

The sections that follow introduce the concepts of public-key cryptography that underlie
these capabilities.

Encryption and Decryption

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

Symmetric-Key Encryption
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.

Figure A-1 Symmetric Key Encryption

2 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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.

Public-Key Encryption
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 A-2 shows a simplified view of the way public-key encryption
works.

Figure A-2 Public Key Encryption

The scheme shown in Figure A-2 lets you freely distribute a public key, and only you can
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

3 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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 A-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 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 on (more...) and subsequent sections describe how this confirmation
process works.

Key Length and Encryption Strength

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
Appendix B, "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.

Digital Signatures
Encryption and decryption address the problem of eavesdropping, one of the three Internet
security issues mentioned at the beginning of this appendix. 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:

4 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

The value of the hash is unique for the hashed data. Any change in the data, even
deleting or altering a single character, results in a different value.
The content of the hashed data cannot, for all practical purposes, be deduced from the
hash—which is why it is called "one-way."

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 A-3 shows a simplified view of the way a digital signature can be used to validate the
integrity of signed data.

Figure A-3 Digital Signing

Figure A-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 the next section, 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

5 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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.

Certificates and Authentication

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 Identifies Someone or Something

A certificate is an electronic document used to identify an individual, a server, a company, or
some other entity. The certificate also associates 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 Sun Java System Certificate Management System). 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 is 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
works 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 Confirms an Identity

6 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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.

Password-Based Authentication

Figure A-4 shows the basic steps involved in authenticating a client by means of a name and
password. Figure A-4 assumes the following:

The user has already decided to trust the server, either without authentication or on the
basis of server authentication via SSL.
The user has requested a resource controlled by the server.
The server requires client authentication before permitting access to the requested
resource.

Figure A-4 Using a Password to Authenticate a Client

7 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

These are the steps shown in Figure A-4:

1. 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.
2. The client sends the name and password across the network, either in the clear or over
an encrypted SSL connection.
3. 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.
4. 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 A-4 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.

Certificate-Based Authentication

Figure A-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 A-4, Figure A-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 A-5 Using a Certificate to Authenticate a Client

8 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

Unlike the process shown in Figure A-4, the process shown in Figure A-5 requires the use of
SSL. Figure A-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.

Note 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 A-5:

1. The client software 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.
2. 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.
3. 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.
4. The server uses the certificate and the evidence to authenticate the user's identity. (For
a detailed discussion of the way this works, see Appendix B, "Introduction to SSL.")
5. 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

9 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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 A-5 to Figure A-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.

How Certificates Are Used

Types of Certificates
SSL Protocol
Signed and Encrypted Email
Form Signing
Single Sign-On
Object Signing

Types of Certificates

Five kinds of certificates are commonly used with Sun Java System 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.
For more information, see SSL Protocol.

Example: Internet sites that engage in electronic 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 mail. 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

10 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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. For more information, 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. For more information, see How CA
Certificates Are Used to Establish Trust.

Example: The CA certificates stored in client software determine what other

certificates that client can authenticate. An administrator can implement some aspects
of corporate security policies by controlling the CA certificates stored in each user's
client.

The sections that follow describes how certificates are used by Sun Java System products.

SSL Protocol

The Secure Sockets Layer (SSL) protocol 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 Appendix B, "Introduction to SSL."

Signed and Encrypted Email

Some mail programs support digitally signed and encrypted mail using a widely accepted

11 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

protocol known as Secure Multipurpose Internet Mail Extension (S/MIME). Using S/MIME
to sign or encrypt mail messages requires the sender of the message to have an S/MIME
certificate.

An mail 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 mail software on the
receiving end, the user is 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 mail also provides some
assurance that the mail has not been tampered with. As discussed at the beginning of this
appendix, this kind of assurance is known as nonrepudiation. In other words, signed mail
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.

Form Signing

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 mail,
but e-commerce often involves filling in a form on a web page rather than sending a mail
message.

The Sun Java System 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
client SSL and S/MIME certificates. 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 Sun Java
System utility called the Signature Verification Tool to validate the digital signature.

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 different passwords to log into the
network, collect mail, 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.

12 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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
Sun Java System 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.

Object Signing

Sun Java System 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.

Contents of a Certificate
The contents of certificates supported by Sun Java System 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.

Distinguished Names

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 Sun Microsystems, Inc.:

13 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

uid=jdoe,e=john.doe@sun.com,cn=John Doe,dc=sun,dc=com,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 appendix. For comprehensive information about DNs, see A String Representation of
Distinguished Names at the following URL:

http://www.ietf.org/rfc/rfc1485.txt

A Typical Certificate

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 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, 2003 and 1:00 p.m. November 15, 2004)
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:

The cryptographic algorithm, or cipher, used by the issuing CA to create its own digital
signature. For more information about ciphers, see Appendix B, "Introduction to SSL."
The CA's digital signature, obtained by hashing all of the data in the certificate together
and encrypting it with the CA's private key.

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=Example Industry, C=US

14 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

Validity:
Not Before: Fri Oct 17 18:36:25 2003
Not After: Sun Oct 17 18:36:25 2004
Subject: CN=Jane Doe, OU=Finance, O=Example 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:
d:c4

Here is a 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-----

How CA Certificates Are Used to Establish Trust

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 Sun Java System Certificate Management System).

15 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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

CA Hierarchies

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.

Figure A-6 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 A-6 shows just one example; many other arrangements are possible.

Certificate Chains

16 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

CA hierarchies are reflected in certificate chains. A certificate chain is series of certificates

issued by successive CAs. Figure A-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 A-6).

Figure A-7 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:

Each certificate is followed by the certificate of its issuer.

Each certificate contains the name (DN) of that certificate's issuer, which is the same
as the subject name of the next certificate in the chain.

In Figure A-7, the Engineering CA certificate contains the DN of the CA (that is, USA
CA), that issued that certificate. USA CA's DN is also the subject name of the next
certificate in the chain.

Each certificate is signed with the private key of its issuer. The signature can be
verified with the public key in the issuer's certificate, which is the next certificate in the
chain.

In Figure A-7, the public key in the certificate for the USA CA can be used to verify
the USA CA's digital signature on the certificate for the Engineering CA.

Verifying a Certificate Chain

Certificate chain verification is the process of making sure a given certificate chain is
well-formed, valid, properly signed, and trustworthy. Sun Java System software uses the

17 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

following procedure for forming and verifying a certificate chain, starting with the certificate
being presented for authentication:

1. The certificate validity period is checked against the current time provided by the
verifier's system clock.
2. 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).
3. The certificate signature is verified using the public key in the issuer's certificate.
4. 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 Sun Java System
certificate type extension, and chain verification returns to step 1 to start again, but
with this new certificate. Figure A-8 presents an example of this process.

Figure A-8 Verifying A Certificate Chain

Figure A-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 A-8, such as
Engineering CA, is found in the verifier's local database, verification stops with that
certificate, as shown in Figure A-9.

Figure A-9 Verifying A Certificate Chain to an Intermediate CA

18 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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 A-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 A-10 A Certificate Chain that Cannot 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 Appendix B, "Introduction to SSL."

Managing Certificates

19 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

The set of standards and services that facilitate the use of public-key cryptography and X.509
v3 certificates in a network environment is called the public key infrastructure (PKI). PKI
management is complex topic beyond the scope of this appendix. The sections that follow
introduce some of the specific certificate management issues addressed by Sun Java System
products.

Issuing Certificates
Certificates and the LDAP Directory
Key Management
Renewing and Revoking Certificates
Registration Authorities

Issuing Certificates
The process for issuing a certificate depends on the certificate authority that issues it and the
purpose for which it is 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 differ.

Similarly, different CAs have different procedures for issuing different kinds of certificates.
In some cases the only requirement may be your mail address. In other cases, your UNIX
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.

Sun Java System Certificate Management System 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.

Certificates and the LDAP Directory

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
pre-populate 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.

20 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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. Directory Server is fully integrated with Sun Java System Certificate
Management System to provide a comprehensive certificate management solution.

Key Management
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.

Renewing and Revoking Certificates

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 fails.
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 fails 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

21 of 22 16-Oct-08 10:26
Appendix A Introduction to Public-Key Cryptography http://docs.sun.com/source/817-7612/ax_crypt.html#wp11284

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.

Registration Authorities
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 serviced.

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 is 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.

Previous Contents Index Next

Part No: 817-7612-10. Copyright 2005 Sun Microsystems, Inc. All rights reserved.

22 of 22 16-Oct-08 10:26