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.

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. privacy is compromised. For example, someone could learn your credit card number, record a password, etc.

• Tampering. Information is changed/replaced in transit. For example, someone could alter an order modifying the destination address for goods ordered.

• Impersonation. Information passes to a person who poses as the intended recipient. Impersonation can take two forms:
  • Spoofing. A person can pretend to be someone else. For example, a person that distribute spam can pretend to have the email address jdoe@hotmail.com, or a computer can identify itself as a site called www.hotmail.com when it is not. This type of impersonation is known as spoofing and it a big problem for SMTP protocol.
  • Misrepresentation. A person or organization can misrepresent itself. For example, suppose the site www.best_escrow.com pretends to be an escrow site for eBay users when it is really just a site that takes payments from a buyer but never transmit them to the seller.

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 will be detected.

• Authentication allows the recipient of information to determine its origin--that is, to confirm the sender's identity.

• Non-repudiation prevents the sender of information from claiming at a later date that the information was never sent.

Attacks on public cryptosystems. The principal attack is called man-in-the-middle attack: The cryptanalyst/attacker places him or herself in the communication channel between two parties who wish to exchange their keys for secure communication. The cryptanalyst/attacker then performs a key exchange with each party, with the original parties believing they are exchanging keys with each other. The two parties then end up using keys that are known to the cryptanalyst/attacker.

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.  Data encrypted with your public key can be decrypted only with your private key.

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.

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. For example, 128-bit keys for use with the RC5 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 RC5 encryption is 3 x 10²⁶ times stronger than 40-bit RC5 encryption.

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 intercept and decrypt encrypted information has historically been a significant military and political asset, until recently the U.S. Government used to restrict export of cryptographic software, including most software that permits use of symmetric encryption keys longer than 40 bits.

Digital Signatures

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:

• 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 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]

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 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 Confirms an Identity

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 4 shows the basic steps involved in authenticating a client by means of a name and password. Figure 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 4    Using a password to authenticate a client to a server

These are the steps shown in Figure 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 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.

Certificate-Based Authentication

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:

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

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

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

SSL Protocol

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.

Signed and Encrypted Email

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.

Single Sign-On

Network users are frequently required to remember multiple passwords for the various services they use. For example, a user might have to type a different password to log into the network, collect email, use directory services, use the corporate calendar program, and access various servers. Multiple passwords are an ongoing headache for both users and system administrators. Users have difficulty keeping track of different passwords, tend to choose poor ones, and tend to write them down in obvious places. Administrators must keep track of a separate password database on each server and deal with potential security problems related to the fact that passwords are sent over the network routinely and frequently.

Solving this problem requires some way for a user to log in once, using a single password, and get authenticated access to all network resources that user is authorized to use--without sending any passwords over the network. This capability is known as single sign-on.

Both client SSL certificates and S/MIME certificates can play a significant role in a comprehensive single sign-on solution. For example, one form of single sign-on supported by 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.

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

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

Contents of a Certificate

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.

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.

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

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

The PKI page

This page contains links to various sites and documents which are related to Public Key Infrastructure (PKI) stuff, especially links to all Certification Authorities (CAs) I'm aware of. Some links may be missing, other links may be out of date so please check back from time to time since I'm regularly updating this page which by definition is far from being complete. Please let me know about missing links.

• Other sites with useful information
  • Cryptography
  • Digital Signatures
  • PGP / OpenPGP / GPG
  • General World Wide Web Security
  • Secure Socket Layer (SSL) / Transport Layer Security (TLS)
  • MIME Security
  • DNSSEC resources
  • Secure Electronic Transactions (SET)
  • Implementations / Toolkits / Products / Vendors
  • Literature / Articles / Publications / RFCs
  • Miscellaneous PKI and Security stuff

Other sites with useful information:

Here are some more links to sites I find interesting.

Cryptography:

• International Cryptography Pages
• RSA Laboratories' "CryptoBytes" technical newsletter
• The "CRYPT NEWSLETTER" Homepage
• Crypto Law Survey (Bert-Jaap Koops)
• Cryptography Export Control Archives
• Steganography Info and Archive
• Cryptographers Homepages
• European Cryptography Resources
• Commercial Encryption Export Controls (BXA)
• The Worldwide Cryptography Debate
• New Cryptography FAQ by RSA Labs
• European expert hearing on digital signatures and encryption (Copenhagen, April 23-24 1998)
• Counterpane Internet Security, Inc. (Bruce Schneier)
• Selecting Cryptographic Key Sizes (Arjen Lenstra, Eric R.Verheul)
• Computational number theory and data security
• Handbook of Applied Cryptography (Menezes, van Oorschot, Vanstone)
• Cryptography Publishing Project
• Cryptographic Software Export Controls in the EU (thesis by Simo-Pekka Parviainen)
• Stegdetect
• NIST's Key Management Standards
• ID-PKC: IDentity-based Public Key Cryptography (CESG)

Digital Signatures:

• Digital Signatures: Software Industry Issues
• US State Digital Signature Laws
• Digital Signature Law Survey
• EFGA: Digital Signature Section
• Summary of international legislation
• Tutorial on Digital Signatures
• Digital Signature Links
• Internet Law & Policy Forum (ILPF): Digital Signature Working Group
• Digital Signature Guidelines
• ICC: General Usage for International Digitally Ensured Commerce
• European Commission Legal Advisory Board: Digital Signatures and Encryption
• W3: Digital Signature Initiative
• UNITED NATIONS (UNCITRAL): Draft Uniform Rules On Electronic Signatures
• ICRI: Legal Aspects of Digital Signatures
• Baker & McKenzie: E-Signatures and D-Signatures
• S.761: Electronic Signatures in Global and National Commerce Act (US federal)
• Bill 88: Electronic Commerce Act, 2000 (Canada)
• Projekt ArchiSig (note: German language!)
• Fst Ricerca (note: Italian language!)

PGP / OpenPGP / GPG:

• The international PGP Home Page
• The domain pgp.net
• PGP Keyserver
• PGP Web of Trust Statistics
• RFC 1991: "PGP Message Exchange Formats"
• RFC 2015: "MIME Security with Pretty Good Privacy (PGP)"
• PGP Corporation
• PGP/MIME
• PGP Attack FAQ
• PGP International
• Robert (Guerra)'s PGP Links
• RFC 2440: "OpenPGP Message Format"
• PGP DH vs. RSA FAQ
• GnuPG - the GNU Privacy Guard
• Key experiments: How PGP Deals With Manipulated Keys
• Experimental PGP key path finder
• PGPdump Interface
• The DSA Flaw in OpenPGP
• PGP Keyring Analysis
• GPGrelay
• Crypt::OpenPGP
• A security analysis of PGP
• CKS: CryptNET Key Server
• RFC 3156: "MIME Security with OpenPGP"
• Public Key Servers
• Tom McCune's page for PGP
• NAI Letter sent to PGP Customers on Feb, 26th (R.I.P. PGP)
• OpenPKSD
• SKS: the synchronizing keyserver
• CryptoEx OpenPGP and S/MIME Gateway
• OpenCDK

General World Wide Web Security:

• The World Wide Web Security FAQ
• Java Security FAQ
• Terisa Systems
• IBM's Surf'N'Sign: Signing Documents on the Web
• Tha Java Security Hotlist
• WWW Security Pointers
• Java Security Resources
• Java Filter
• Java Security: Chronology of security-related bugs (Sun)

Secure Socket Layer (SSL) / Transport Layer Security (TLS):

• SSL Protocol Version 2.0 (Draft)
• SSL Protocol Version 3.0 (Draft)
• Netscape Certificate Specifications
• SSLeay and SSLapps FAQ
• SSL-Talk FAQ
• Free test certificates: Trustfactory by Secude (SSL and S/MIME)
• SSLeay Certificate Cookbook (F. J. Hirsch)
• SSLeay 0.6.6 documentation including libcrypto docs
• Introducing SSL and Certificates using SSLeay (F. J. Hirsch)
• Setting up your own certification environment using SSLeay 0.8.1 and MSIE 4.0 (Samuel Liddicott)
• Set up your own CA using free software (Marint Ouwehand)
• Mozilla Crypto Group
• OpenSSL PKCS#12 Program FAQ (Stephen Henson)
• Enabling Network Security with SSLeay
• Test the strength of your browser's crypto
• OpenSSL: The Open Source toolkit for SSL/TLS
• Introduction to SSL
• RFC 2246: "The TLS Protocol Version 1.0"
• BSAFE patches for SSLeay
• PureTLS - free Java-only implementation of SSLv3 and TLSv1
• More SSL related applications from the OpenSSL web site
• pilotSSLeay: port of SSLeay-0.8.1 to the Pilot
• ssldump: SSLv3/TLS network protocol analyzer
• OpenSSL for Win32
• A design weakness of SSL/TLS (H. Krawczyk)
• GNU TLS library
• OpenSSL Examples
• OpenSSL based PKI

MIME Security:

• All About S/MIME (RSA)
• More information about S/MIME (IMC)
• PGP/MIME
• S/MIME Freeware Library (SFL)
• S/MIME Mail Security (IETF)
• S/MIME and PGP/MIME
• RSA's S/MIME Interoperability Center
• S/MIME tool
• NIST S/MIME Activities
• S/MIME Interop Matrix
• CryptoEx OpenPGP and S/MIME Gateway

DNSSEC resources:

• DNS Security (DNSSEC) in CAIRN
• NLnet Labs DNSSEC resources
• IETF: DNS Extensions (dnsext) System Security
• NIC-SE: Reports on DNSSEC
• Report from the Workshop on DNSSEC, Sweden
• DNSsec Internet Drafts
• DNSSEC Related Links
• DNSSEC Paper
• DNSSEC - Software Integration
• Report on IIS DNSSEC Workshop
• SIGZ.net: DNSSEC signed test zone
• Thesis on DNSSEC (M. Gebien)
• Applied Research DNSSEC Pilot
• DNSSEC.net

Secure Electronic Transactions (SET):

• SET Specification by MasterCard and Visa

Implementations / Toolkits / Products / Vendors:

• SECUDE
• NCSA httpd - Using PGP/PEM encryption
• RSA Euro - Cryptography for the World
• SESAME: Cryptographic applications (secure site)
• TrustedWeb / TrustedMIME by SSE
• OpenPathCA: integrated OSI solutions by SSE
• Information about TIS/MOSS (TIS)
• SSR: Secure Socket Relay
• Frontier Technolgies: e-Lock (alternative site)
• Baltimore Technologies: UniCERT Certification Authority System
• cryptlib: freely available Encryption Toolkit (Peter Gutmann)
• Apache-SSL: Secure Webserver (Ben Laurie)
• JCP Computer Services
• SSLeay
• mod_ssl: Apache interface to SSLeay
• Java Security Toolkit (TU Graz)
• Tools from Diversinet Corp.
• Jonah PKIX: a freeware PKIX (see below) reference implementation (IBM)
• Jonah PKIX: same as above but internationally available! (note: site seems to be dead!)
• J/CA Certification Toolkit (Phaos Corp.)
• Entrust Technologies
• Oscar - DSTC's Public Key Infrastructure Project
• Entegrity Solutions Corp
• Structured Arts Computing Corp
• The OpenCA Project
• SHYM Technology
• pyCA - Software for running a certificate authority
• JCSI - DSTC's Java Crypto and Security Implementation
• SmartTrust
• Radicchio
• Sendmail-TLS
• Chrysalis-ITS: Luna CA and Luna PKI toolkit
• Alphaworks/IBM: KeyMan PKI client side management tool
• R&L GmbH: safeX
• M2Crypto Cryptography, SSL and S/MIMEv2 for Python
• NSS + PSM Open Source PKI projects on Mozilla
• Safelayer Secure Communications S. A.
• Conclusive Logic, Inc.
• SSH Certificate Toolkit
• Kyberpass Corporation
• PHAOS Technology
• Celo Communications
• KeyTrust Certificate Explorer 1.1 (note: German language!)
• Capslock
• Valimo Wireless Oy
• Cylink
• Awanim
• CrypTool
• IDX-PKI
• Biodata Systems GmbH
• Certicom Corp.
• ValiCert
• .pkicomplete
• Java Certification Path API
• trustsuite.de (note: German language!)
• timeproof
• e-Security, Inc.
• Hush Communications
• PKI Group Test (The NSS Group)
• db-order (note: German language!)
• upki
• CertPath APIs (as part of J2SE 1.4)
• BERViewer
• Project Ägypten: Free Software SPHINX Clients
• EJBCA: J2EE Certificate Authority
• AET Europe BV (Advanced Encryption Technology)
• Utimaco Safeware
• HYPERTRUST
• FlexiProvider
• iPlanet CMS
• RSA Keon
• ArticSoft
• SECUonline AG
• Baltimore Keytools
• gpkcs11
• ValiCert ASN.1 Parser
• CryptoEx
• Tekki
• pki.ssh.com
• C&A
• nCipher
• KSIGN Co. Ltd. (Korea)
• Dreamsecurity Co. Ltd. (Korea)
• INITECH Co. Ltd. (Korea)
• OnePKI
• GUIdumpASN
• Tellus Technologies
• CPKtec
• BCQRE (note: Korean language!)
• Glück & Kanja Technology AG
• CSP: Certificate Service Provider
• e-CryptIt Engine 7.0
• SimpleCA
• Evidian
• NewPKI
• Chrysalis-ITS

Literature / Articles / Publications / RFCs:

• X.509 specification (including latest drafts on X.509v4)
• A Survey of Public Key Infrastructures (Marc Branchaud)
• PKI-related activities at NIST (also from the DFN-PCA FTP-Server)
• Secure E-mail (Presentation given by Harald T. Alvestrand)
• Several documents focusing on Electronic Cash from the DFN-PCA FTP-Server
• Sirene Publications
• Certified Electronic Mail (CEM)
• W3: Electronic Payment Schemes (Phillip Hallam-Baker)
• Security and Encryption Links (Peter Gutmann)
• Excellent X.509 Style Guide (Peter Gutmann)
• PEM implementations and documents from the DFN-PCA FTP-Server
• Center for Standards (DISA): PKI Standardization Home Page
• Publications on Java Security et al. (SIP)
• Rethinking PKI and digital certificates --- building in privacy (Thesis of Stefan Brands)
• Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure (B. Schneier, C. Ellison)
  • ...and a response to 10 Risks of PKI (A. Perez)
  • ...and another response to 10 Risks of PKI (B. Laurie)
• The OpenSource PKI book
• The Public-Key Cryptography Standards (PKCS)
• Conventional PKI: An Artefact Ill-Fitted to the Needs of the Information Society (Roger Clark)
• Excerpts from "The Design and Verification of a Cryptographic Security Architecture" (PhD thesis, Peter Gutmann)
• PKI Publications from ETH, Zürich
• Public Key Cryptography based on Braid Groups
• The Ten Minute CEO Briefing on PKI... (note: site seems to be dead!)
• The Shocking Truth About Digital Signatures and Internet Commerce (J. Winn)
• PKI Policy Pitfalls (M. Bobbitt)
• List of CA's
• An introduction to PKI (and more PKI white papers)
• White Papers on PKI
• Digital Certificates (Roedy Green)

  RFCs and internet drafts:

• The IETF Security Area and related IETF working groups
  • PKIX: Public Key Infrastructure (X.509)
    • RFC 2459: "Certificate and CRL Profile"
    • RFC 2510: "Certificate Management Protocols"
    • RFC 2511: "Certificate Request Message Format"
    • RFC 2527: "Certificate Policy and Certification Practices Framework"
    • RFC 2528: "Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates"
    • RFC 2559: "Operational Protocols - LDAPv2"
    • RFC 2560: "Online Certificate Status Protocol - OCSP"
    • RFC 2585: "Operational Protocols - FTP and HTTP"
    • RFC 2587: "LDAPv2 Schema"
    • RFC 2797: "Certificate Management Messages over CMS"
    • RFC 2875: "Diffie-Hellman Proof-of-Possession Algorithms"
    • RFC 3029: "Data Validation and Certification Server Protocols"
    • RFC 3039: "Qualified Certificates Profile"
    • RFC 3161: "Time-Stamp Protocol (TSP)"
    • RFC 3279: "Algorithms and Identifiers for the PKIX Certificate and Certificate Revocation List (CRL) Profile"
    • RFC 3280: "Certificate and CRL Profile"
    • RFC 3281: "An Internet Attribute Certificate Profile for Authorization"
    • RFC 3379: "Delegated Path Validation and Delegated Path Discovery Protocol Requirements"

  • S/MIME: S/MIME Mail Security
    • RFC 2311: "S/MIME Version 2 Message Specification"
    • RFC 2312: "S/MIME Version 2 Certificate Handling"
    • RFC 2630: "Cryptographic Message Syntax"
    • RFC 2631: "Diffie-Hellman Key Agreement Method"
    • RFC 2632: "S/MIME Version 3 Certificate Handling"
    • RFC 2633: "S/MIME Version 3 Message Specification"
    • RFC 2634: "Enhanced Security Services for S/MIME"