Single Sign-On Deployment Guide

Appendix A
Netscape's Use of Public-Key Cryptography

Public-key cryptography and related standards underlie key security features of many Netscape products, including signed and encrypted email, object signing, single sign-on, and SSL. This document introduces some basic concepts of public-key cryptography that underlie Netscape security features.

Public-Private Key Pairs

Certificates

Digital Signatures

Getting a Certificate

Authenticating a User's Identity

For a comprehensive discussion of these topics, see Applied Cryptography by Bruce Schneier (Wiley, 1996).

Public-Private Key Pairs

Public-key cryptography 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 as part of a certificate, and the corresponding private key is kept secret. Data encrypted with your public key can be decrypted only with your private key. Figure 17 shows a simplified view of the way this works.

Figure 17 Using public and private keys for encryption

The scheme shown in Figure 17 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.

As it happens, the reverse is also true: 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. Client software such as Communicator (with the aid of your public key) can then confirm that the message was signed with your private key and that it hasn't been tampered with since being signed. For more information about the way this works, see Digital Signatures.

Certificates

A certificate is an electronic document used to identify an individual, company, or other entity. 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. 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.

Before submitting a request for a certificate to a CA, client software such as Communicator generates a public key and the corresponding private key. The certificate issued by the CA binds the public key to the name of the requesting entity (such as the name of an employee or a server). Certificates help prevent the use of fake public keys for impersonation.

A certificate is like a driver's license, a passport, or any other personal ID that provides generally recognized proof of a person's identity. A certificate always includes a public key, 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.

Types of Certificates

Communicator recognizes five kinds of certificates. The first two in this list are used with the Secure Sockets Layer (SSL), a standard protocol for authentication and encryption over TCP/IP networks:

Client SSL certificates. Used to identify clients to servers via SSL.

Server SSL certificates. Used to identify servers to clients via SSL.

S/MIME certificates. Used for signed and encrypted email.

Object-signing certificates. Used to identify signers of Java code, JavaScript scripts, or other signed files.

CA certificates. Used to identify CAs.

Navigator 3.x and earlier versions recognize only SSL certificates and CA certificates. Communicator recognizes all five. It's also possible to issue a single certificate that can function as both an S/MIME certificate and a client SSL certificate.

Any certificate binds a distinguished name (DN) to a public key. A DN is the string representation of an entity's name. It consists of a series of comma-separated attribute-value assertions (AVAs). Here is an example:

uid=doe,e=doe@netscape.com,cn=John Doe,o=Netscape Communications Corp.,c=US

Each attribute tag, such as uid, labels a value, such as doe. The attribute tags used in a DN may vary somewhat from one organization to another, but the combination of AVAs must be unique to the entity the certificate identifies.

Every certificate includes the following information:

information about the user's public key, including the algorithm used and a representation of the key itself

the certificate's serial number

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

the DN of the CA that issued the certificate

the algorithm used by the CA to create its own digital signature

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

A certificate can also contain extensions, not listed here, that provide additional data used by the client or server. For example, certificates used with Netscape products include the Netscape certificate type extension, which 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.

Keeping Track of Certificates

When a user receives a client SSL certificate, it is typically installed in the user's copy of Communicator or other client software. Communicator supports the public-key cryptography standard known as PKCS #12, which governs key portability. This means, for example, that you can move your certificates (and the corresponding private keys) from one computer to another on floppy disks.

Communicator also supports PKCS #11, which governs communication with devices like smartcards and PCMCIA cards. This support means that Communicator can exchange information with smartcards in smartcard readers attached to client machines. For example, Communicator can use certificates and private keys stored on smartcards as well as those stored within Communicator itself.

Navigator 3.x doesn't support PKCS #11 or PKCS #12, although it is possible, for example, to manually move certificate (cert5.db) and key (key.db) database files from a central directory on the network into the Navigator directory (on Windows 95) or equivalent.

To validate a certificate, Netscape client software relies in part on its list of accepted CAs. A CA can be a publicly recognized independent company (such as those listed at Certificate Authority Services), or it can be an individual or department recognized only within a corporation's intranet or extranet (such as the internal Netscape CA). The user can add CAs to the list of trusted CAs and, if necessary, delete CAs that the user decides not to trust. If a certificate cannot be traced back to one of the CAs on Communicator's list, the user identified by that certificate can't be authenticated by a server that supports single sign-on.

To view your current list of CAs in Communicator, click the Security button near the top of the Navigator window, then click Signers under Certificates. The list of certificate signers (that is, CAs recognized by your copy of Communicator for validating certificates) looks like the one shown in Figure 18.

Figure 18 Viewing CA certificates in the Security Info window

Communicator's list of certificate signers is just a collection of CA certificates--that is, certificates issued by CAs for the purpose of identifying themselves. You can select a CA and use the Edit button to control the kind of certificates (such as SSL or email) certified by that CA that you are willing to accept. You can also use the Delete button to delete a CA from the list.

Mission Control allows network administrators to set up this initial list for copies of Communicator and also to modify it dynamically for copies of Communicator Professional Edition. Since both Communicator and Navigator 3.x come with a default list of CAs, it may also be necessary to remove some of them if an administrator wants users to trust only certain CAs, such as those operated by a company.

In Navigator 3.x, you can view the list of all installed certificates by choosing Security Preferences from the Options menu, then clicking Site Certificates. To view the CA list only, choose Certificate Authorities from the pop-up menu near the top of the window. You can then edit or delete any particular CA listing much as you can in Communicator.

Servers maintain similar lists of CAs. To view the list of CAs for a given server, follow these steps from within the Administration Server:

Click the Keys & Certificates tab.
Click Manage Certificates in the left frame.
Using the pop-up menu, select the server whose certificates you want to see, then click OK.

The frame that appears next is shown in Figure 19. It includes all certificates in the server's database, including CA certificates. When you click the name of a certificate listed as a CA, a dialog box appears that allows you to delete the certificate, trust the CA, or not trust the CA.

Figure 19 A server's list of certificates

For an overview of the way certificates are used to confirm a signer's identity, see Authenticating a User's Identity.

Digital Signatures

When Netscape software signs data, such as an email message or Java code, it first creates a one-way hash of that data. A one-way hash (also called a message digest) is a number of fixed length with the following characteristics:

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 explained in Public-Private Key Pairs, 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 is known as the signer's digital signature.

Figure 20 shows a simplified view of the way a digital signature can be used to validate the integrity of signed data.

Figure 20 Using a digital signature to validate data integrity

Figure 20 shows two items transferred to the recipient of some signed data: the original data and the digital signature, which is 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, Communicator first uses the signer's public key to decrypt the hash. It then uses the same hashing algorithm that was used to generate the original one-way hash to generate a new one-way hash of the same data. (Information about the hashing algorithm used is also sent with the digital signature, although this isn't shown in the figure.) Finally, Communicator 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 in the signer's certificate corresponds to the signer's private key. To confirm the identity of the signer, however, also involves confirming the validity of the digital signature of the CA who issued the signer's certificate. For a discussion of the way this works, see Authenticating a User's Identity.

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 is described as nonrepudiation. In some situations, a digital signature may be as legally binding as a handwritten signature. Therefore, signers should take great care to ensure that they can stand behind any data they sign.

Getting a Certificate

The public key and the corresponding private key are created locally by the server or client software that requests the certificate. To help ensure that the private key isn't compromised, it remains on the local machine, and client software or the system administrator submits the public key along with other information to the certificate authority (CA) that issues the certificate. The CA may be an independent company that issues certificates for a fee or an administrator running a Netscape Certificate Server within an organization. The CA verifies the identity of the requester according to the CA's security policies, then issues the certificate.

In addition to the public key, DN, and other information, every certificate includes the name and digital signature of the CA that issued it, as shown in Figure 21.

Figure 21 shows a simplified view of the way a user named John Doe might use Communicator to obtain a client SSL certificate from a CA. The details of this procedure vary depending on the kind of certificate requested, the software doing the requesting, and the security policies of the CA. However, the overall process works basically the same way for any software (including Communicator, Navigator 3.x, and SuiteSpot servers) used to request any kind of certificate.

Figure 21 Using Communicator to request a client certificate