|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|See Also||Recommended Books||Recommended Links||Tutorials||FAQs and References||Usenet|
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:
firstname.lastname@example.org, or a computer can identify itself as a site called
www.hotmail.comwhen it is not. This type of impersonation is known as spoofing and it a big problem for SMTP protocol.
www.best_escrow.compretends 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:
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.
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 1026 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.
Encryption and decryption address the problem of eavesdropping, one of the three Internet security issues mentioned at the beginning of this document. But encryption and decryption, by themselves, do not address the other two problems mentioned in Internet Security Issues: tampering and impersonation.
This section describes how public-key cryptography addresses the problem of tampering. The sections that follow describe how it addresses the problem of impersonation.
Tamper detection and related authentication techniques rely on a mathematical function called a one-way hash (also called a message digest). A one-way hash is a number of fixed length with the following characteristics:
As mentioned in Public-Key Encryption, it's possible to use your private key for encryption and your public key for decryption. Although this is not desirable when you are encrypting sensitive information, it is a crucial part of digitally signing any data. Instead of encrypting the data itself, the signing software creates a one-way hash of the data, then uses your private key to encrypt the hash. The encrypted hash, along with other information, such as the hashing algorithm, is known as a digital signature.
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.
A Certificate Identifies
Someone or Something
Authentication Confirms an Identity
How Certificates Are Used
Contents of a Certificate
How CA Certificates Are Used to Establish Trust
A certificate is an electronic document used to identify an individual, a server, a company, or some other entity and to associate that identity with a public key. Like a driver's license, a passport, or other commonly used personal IDs, a certificate provides generally recognized proof of a person's identity. Public-key cryptography uses certificates to address the problem of impersonation (see Internet Security Issues).
To get a driver's license, you typically apply to a government agency, such as the Department of Motor Vehicles, which verifies your identity, your ability to drive, your address, and other information before issuing the license. To get a student ID, you apply to a school or college, which performs different checks (such as whether you have paid your tuition) before issuing the ID. To get a library card, you may need to provide only your name and a utility bill with your address on it.
Certificates work much the same way as any of these familiar forms of identification. Certificate authorities (CAs) are entities that validate identities and issue certificates. They can be either independent third parties or organizations running their own certificate-issuing server software (such as Netscape Certificate Server). The methods used to validate an identity vary depending on the policies of a given CA--just as the methods to validate other forms of identification vary depending on who is issuing the ID and the purpose for which it will be used. In general, before issuing a certificate, the CA must use its published verification procedures for that type of certificate to ensure that an entity requesting a certificate is in fact who it claims to be.
The certificate issued by the CA binds a particular public key to the name of the entity the certificate identifies (such as the name of an employee or a server). Certificates help prevent the use of fake public keys for impersonation. Only the public key certified by the certificate will work with the corresponding private key possessed by the entity identified by the certificate.
In addition to a public key, a certificate always includes the name of the entity it identifies, an expiration date, the name of the CA that issued the certificate, a serial number, and other information. Most importantly, a certificate always includes the digital signature of the issuing CA. The CA's digital signature allows the certificate to function as a "letter of introduction" for users who know and trust the CA but don't know the entity identified by the certificate.
For more information about the role of CAs, see How CA Certificates Are Used to Establish Trust.
Authentication is the process of confirming an identity. In the context of network interactions, authentication involves the confident identification of one party by another party. Authentication over networks can take many forms. Certificates are one way of supporting authentication.
Network interactions typically take place between a client, such as browser software running on a personal computer, and a server, such as the software and hardware used to host a Web site. Client authentication refers to the confident identification of a client by a server (that is, identification of the person assumed to be using the client software). Server authentication refers to the confident identification of a server by a client (that is, identification of the organization assumed to be responsible for the server at a particular network address).
Client and server authentication are not the only forms of authentication that certificates support. For example, the digital signature on an email message, combined with the certificate that identifies the sender, provide strong evidence that the person identified by that certificate did indeed send that message. Similarly, a digital signature on an HTML form, combined with a certificate that identifies the signer, can provide evidence, after the fact, that the person identified by that certificate did agree to the contents of the form. In addition to authentication, the digital signature in both cases ensures a degree of nonrepudiation--that is, a digital signature makes it difficult for the signer to claim later not to have sent the email or the form.
Client authentication is an essential element of network security within most intranets or extranets. The sections that follow contrast two forms of client authentication:
Figure 4 shows the basic steps involved in authenticating a client by means of a name and password. Figure 4 assumes the following:
Figure 4 Using a password to authenticate a client to a server
These are the steps shown in Figure 4:
With this arrangement, the user must supply a new password for each server, and the administrator must keep track of the name and password for each user, typically on separate servers.
As shown in the next section, one of the advantages of certificate-based authentication is that it can be used to replace the first three steps in Figure 2 with a mechanism that allows the user to supply just one password (which is not sent across the network) and allows the administrator to control user authentication centrally.
Figure 5 shows how client authentication works using certificates and the SSL Protocol. To authenticate a user to a server, a client digitally signs a randomly generated piece of data and sends both the certificate and the signed data across the network. For the purposes of this discussion, the digital signature associated with some data can be thought of as evidence provided by the client to the server. The server authenticates the user's identity on the strength of this evidence.
Like Figure 4, Figure 5 assumes that the user has already decided to trust the server and has requested a resource, and that the server has requested client authentication in the process of evaluating whether to grant access to the requested resource.
Figure 5 Using a certificate to authenticate a client to a server
Unlike the process shown in Figure 4, the process shown in Figure 5 requires the use of SSL. Figure 5 also assumes that the client has a valid certificate that can be used to identify the client to the server. Certificate-based authentication is generally considered preferable to password-based authentication because it is based on what the user has (the private key) as well as what the user knows (the password that protects the private key). However, it's important to note that these two assumptions are true only if unauthorized personnel have not gained access to the user's machine or password, the password for the client software's private key database has been set, and the software is set up to request the password at reasonably frequent intervals.
Important Neither password-based authentication nor certificate-based authentication address security issues related to physical access to individual machines or passwords. Public- key cryptography can only verify that a private key used to sign some data corresponds to the public key in a certificate. It is the user's responsibility to protect a machine's physical security and to keep the private-key password secret.
These are the steps shown in Figure 3:
As you can see by comparing Figure 5 to Figure 4, certificates replace the authentication portion of the interaction between the client and the server. Instead of requiring a user to send passwords across the network throughout the day, single sign-on requires the user to enter the private-key database password just once, without sending it across the network. For the rest of the session, the client presents the user's certificate to authenticate the user to each new server it encounters. Existing authorization mechanisms based on the authenticated user identity are not affected.
Types of Certificates
Signed and Encrypted Email
Five kinds of certificates are commonly used with Netscape products:
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.
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.
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.
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.
The sections that follow describes how certificates are used by Netscape products.
The Secure Sockets Layer (SSL) protocol, which was originally developed by Netscape, is a set of rules governing server authentication, client authentication, and encrypted communication between servers and clients. SSL is widely used on the Internet, especially for interactions that involve exchanging confidential information such as credit card numbers.
SSL requires a server SSL certificate, at a minimum. As part of the initial "handshake" process, the server presents its certificate to the client to authenticate the server's identity. The authentication process uses Public-Key Encryption and Digital Signatures to confirm that the server is in fact the server it claims to be. Once the server has been authenticated, the client and server use techniques of Symmetric-Key Encryption, which is very fast, to encrypt all the information they exchange for the remainder of the session and to detect any tampering that may have occurred.
Servers may optionally be configured to require client authentication as well as server authentication. In this case, after server authentication is successfully completed, the client must also present its certificate to the server to authenticate the client's identity before the encrypted SSL session can be established.
For an overview of client authentication over SSL and how it differs from password-based authentication, see Authentication Confirms an Identity. For more detailed information about SSL, see Introduction to SSL.
Some email programs (including Messenger, which is part of Communicator) support digitally signed and encrypted email using a widely accepted protocol known as Secure Multipurpose Internet Mail Extension (S/MIME). Using S/MIME to sign or encrypt email messages requires the sender of the message to have an S/MIME certificate.
An email message that includes a digital signature provides some assurance that it was in fact sent by the person whose name appears in the message header, thus providing authentication of the sender. If the digital signature cannot be validated by the email software on the receiving end, the user will be alerted.
The digital signature is unique to the message it accompanies. If the message received differs in any way from the message that was sent--even by the addition or deletion of a comma--the digital signature cannot be validated. Therefore, signed email also provides some assurance that the email has not been tampered with. As discussed at the beginning of this document, this kind of assurance is known as nonrepudiation. In other words, signed email makes it very difficult for the sender to deny having sent the message. This is important for many forms of business communication. (For information about the way digital signatures work, see Digital Signatures.)
S/MIME also makes it possible to encrypt email messages. This is also important for some business users. However, using encryption for email requires careful planning. If the recipient of encrypted email messages loses his or her private key and does not have access to a backup copy of the key, for example, the encrypted messages can never be decrypted.
Network users are frequently required to remember multiple passwords for the various services they use. For example, a user might have to type a different password to log into the network, collect email, use directory services, use the corporate calendar program, and access various servers. Multiple passwords are an ongoing headache for both users and system administrators. Users have difficulty keeping track of different passwords, tend to choose poor ones, and tend to write them down in obvious places. Administrators must keep track of a separate password database on each server and deal with potential security problems related to the fact that passwords are sent over the network routinely and frequently.
Solving this problem requires some way for a user to log in once, using a single password, and get authenticated access to all network resources that user is authorized to use--without sending any passwords over the network. This capability is known as single sign-on.
Both client SSL certificates and S/MIME certificates can play a significant role in a comprehensive single sign-on solution. For example, one form of single sign-on supported by Netscape products relies on SSL client authentication (see Certificate-Based Authentication). A user can log in once, using a single password to the local client's private-key database, and get authenticated access to all SSL-enabled servers that user is authorized to use--without sending any passwords over the network. This approach simplifies access for users, because they don't need to enter passwords for each new server. It also simplifies network management, since administrators can control access by controlling lists of certificate authorities (CAs) rather than much longer lists of users and passwords.
In addition to using certificates, a complete single-sign on solution must address the need to interoperate with enterprise systems, such as the underlying operating system, that rely on passwords or other forms of authentication.
For information about the single sign-on support currently provided by Netscape products, see Single Sign-On Deployment Guide.
Many kinds of e-commerce require the ability to provide persistent proof that someone has authorized a transaction. Although SSL provides transient client authentication for the duration of an SSL connection, it does not provide persistent authentication for transactions that may occur during that connection. S/MIME provides persistent authentication for email, but e-commerce often involves filling in a form on a web page rather than sending an email.
The Netscape technology known as form signing addresses the need for persistent authentication of financial transactions. Form signing allows a user to associate a digital signature with web-based data generated as the result of a transaction, such as a purchase order or other financial document. The private key associated with either a client SSL certificate or an S/MIME certificate may be used for this purpose.
When a user clicks the Submit button on a web-based form that supports form signing, a dialog box appears that displays the exact text to be signed. The form designer can either specify the certificate that should be used or allow the user to select a certificate from among the client SSL and S/MIME certificates that are installed in Communicator. When the user clicks OK, the text is signed, and both the text and the digital signature are submitted to the server. The server can then use a Netscape utility called the Signature Verification Tool to validate the digital signature.
For more information about support for form signing in Netscape products, see Netscape Form Signing.
Communicator and other Netscape products support a set of tools and technologies called object signing. Object signing uses standard techniques of public-key cryptography to let users get reliable information about code they download in much the same way they can get reliable information about shrink-wrapped software.
Most importantly, object signing helps users and network administrators implement decisions about software distributed over intranets or the Internet--for example, whether to allow Java applets signed by a given entity to use specific computer capabilities on specific users' machines.
Software developers and others who wish to sign files using object-signing technology must first obtain an object-signing certificate.
For more information about support for object signing in Netscape products, see Netscape Object Signing: Establishing Trust for Downloaded Software.
The contents of certificates supported by Netscape and many other software companies are organized according to the X.509 v3 certificate specification, which has been recommended by the International Telecommunications Union (ITU), an international standards body, since 1988.
Users don't usually need to be concerned about the exact contents of a certificate. However, system administrators working with certificates may need some familiarity with the information provided here.
An X.509 v3 certificate binds a distinguished name (DN) to a public key. A DN is a series of
name-value pairs, such as
uid=doe, that uniquely identify
an entity--that is, the certificate subject.
For example, this might be a typical DN for an employee of Netscape Communications Corporation:
uid=doe,email@example.com,cn=John Doe,o=Netscape Communications Corp.,c=US
The abbreviations before each equal sign in this example have these meanings:
DNs may include a variety of other name-value pairs. They are used to identify both certificate subjects and entries in directories that support the Lightweight Directory Access Protocol (LDAP).
The rules governing the construction of DNs can be quite complex and are beyond the scope of this document. For comprehensive information about DNs, see A String Representation of Distinguished Names.
Every X.509 certificate consists of two sections:
Here are the data and signature sections of a certificate in human-readable format:
Certificate: Data: Version: v3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US Validity: Not Before: Fri Oct 17 18:36:25 1997 Not After: Sun Oct 17 18:36:25 1999 Subject: CN=Jane Doe, OU=Finance, O=Ace Industry, C=US Subject Public Key Info: Algorithm: PKCS #1 RSA Encryption Public Key: Modulus: 00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86: ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22: 43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00: 98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9: 73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e: 9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0: 7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54: 91:f4:15 Public Exponent: 65537 (0x10001) Extensions: Identifier: Certificate Type Critical: no Certified Usage: SSL Client Identifier: Authority Key Identifier Critical: no Key Identifier: f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36: 26:c9 Signature: Algorithm: PKCS #1 MD5 With RSA Encryption Signature: 6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06: 30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb: f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc: 2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5: b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5: 4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8: dd:c4
Here is the same certificate displayed in the 64-byte-encoded form interpreted by software:
-----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0 dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG 7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3 UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84 hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A== -----END CERTIFICATE-----
Certificate authorities (CAs) are entities that validate identities and issue certificates. They can be either independent third parties or organizations running their own certificate-issuing server software (such as the Netscape Certificate Server). A list of third-party certificate authorities is available at Certificate Authority Services.
Any client or server software that supports certificates maintains a collection of trusted CA certificates. These CA certificates determine which other certificates the software can validate--in other words, which issuers of certificates the software can trust. In the simplest case, the software can validate only certificates issued by one of the CAs for which it has a certificate. It's also possible for a trusted CA certificate to be part of a chain of CA certificates, each issued by the CA above it in a certificate hierarchy.
The sections that follow explains how certificate hierarchies and certificate chains determine what certificates software can trust.
Verifying a Certificate Chain
In large organizations, it may be appropriate to delegate the responsibility for issuing certificates to several different certificate authorities. For example, the number of certificates required may be too large for a single CA to maintain; different organizational units may have different policy requirements; or it may be important for a CA to be physically located in the same geographic area as the people to whom it is issuing certificates.
It's possible to delegate certificate-issuing responsibilities to subordinate CAs. The X.509 standard includes a model for setting up a hierarchy of CAs like that shown in Figure 6.
Figure 6 Example of a hierarchy of certificate authorities
In this model, the root CA is at the top of the hierarchy. The root CA's certificate is a self-signed certificate: that is, the certificate is digitally signed by the same entity--the root CA--that the certificate identifies. The CAs that are directly subordinate to the root CA have CA certificates signed by the root CA. CAs under the subordinate CAs in the hierarchy have their CA certificates signed by the higher-level subordinate CAs.
Organizations have a great deal of flexibility in terms of the way they set up their CA hierarchies. Figure 6 shows just one example; many other arrangements are possible.
CA hierarchies are reflected in certificate chains. A certificate chain is series of certificates issued by successive CAs. Figure 7 shows a certificate chain leading from a certificate that identifies some entity through two subordinate CA certificates to the CA certificate for the root CA (based on the CA hierarchy shown in Figure 6).
Figure 7 Example of a certificate chain
A certificate chain traces a path of certificates from a branch in the hierarchy to the root of the hierarchy. In a certificate chain, the following occur:
Certificate chain verification is the process of making sure a given certificate chain is well-formed, valid, properly signed, and trustworthy. Netscape software uses the following procedure for forming and verifying a certificate chain, starting with the certificate being presented for authentication:
Figure 8 Verifying a certificate chain all the way to the root CA
Figure 8 shows what happens when only Root CA is included in the verifier's local database. If a certificate for one of the intermediate CAs shown in Figure 8, such as Engineering CA, is found in the verifier's local database, verification stops with that certificate, as shown in Figure 9.
Figure 9 Verifying a certificate chain to an intermediate CA
Expired validity dates, an invalid signature, or the absence of a certificate for the issuing CA at any point in the certificate chain causes authentication to fail. For example, Figure 10 shows how verification fails if neither the Root CA certificate nor any of the intermediate CA certificates are included in the verifier's local database.
Figure 10 A certificate chain that can't be verified
For general information about the way digital signatures work, see Digital Signatures. For a more detailed description of the signature verification process in the context of SSL client and server authentication, see Introduction to SSL.
The set of standards and services that facilitate the use of public-key cryptography and X.509 v3 certificates in a networked environment is called the public key infrastructure (PKI). PKI management is complex topic beyond the scope of this document. The sections that follow introduce some of the specific certificate management issues addressed by Netscape products.
Certificates and the LDAP Directory
Renewing and Revoking Certificates
The process for issuing a certificate depends on the certificate authority that issues it and the purpose for which it will be used. The process for issuing nondigital forms of identification varies in similar ways. For example, if you want to get a generic ID card (not a driver's license) from the Department of Motor Vehicles in California, the requirements are straightforward: you need to present some evidence of your identity, such as a utility bill with your address on it and a student identity card. If you want to get a regular driving license, you also need to take a test--a driving test when you first get the license, and a written test when you renew it. If you want to get a commercial license for an eighteen-wheeler, the requirements are much more stringent. If you live in some other state or country, the requirements for various kinds of licenses will differ.
Similarly, different CAs have different procedures for issuing different kinds of certificates. In some cases the only requirement may be your email address. In other cases, your Unix or NT login and password may be sufficient. At the other end of the scale, for certificates that identify people who can authorize large expenditures or make other sensitive decisions, the issuing process may require notarized documents, a background check, and a personal interview.
Depending on an organization's policies, the process of issuing certificates can range from being completely transparent for the user to requiring significant user participation and complex procedures. In general, processes for issuing certificates should be highly flexible, so organizations can tailor them to their changing needs.
The Netscape Certificate Server, part of the Mission Control family of products, allows an organization to set up its own certificate authority and issue certificates.
Issuing certificates is one of several managements tasks that can be handled by separate Registration Authorities.
The Lightweight Directory Access Protocol (LDAP) for accessing directory services supports great flexibility in the management of certificates within an organization. System administrators can store much of the information required to manage certificates in an LDAP-compliant directory. For example, a CA can use information in a directory to prepopulate a certificate with a new employee's legal name and other information. The CA can leverage directory information in other ways to issue certificates one at a time or in bulk, using a range of different identification techniques depending on the security policies of a given organization. Other routine management tasks, such as Key Management and Renewing and Revoking Certificates, can be partially or fully automated with the aid of the directory.
Information stored in the directory can also be used with certificates to control access to various network resources by different users or groups. Issuing certificates and other certificate management tasks can thus be an integral part of user and group management.
In general, high-performance directory services are an essential ingredient of any certificate management strategy. The Netscape Directory Server, part of the Mission Control family of products, is fully integrated with the Netscape Certificate Server to provide a comprehensive certificate management solution.
Before a certificate can be issued, the public key it contains and the corresponding private key must be generated. Sometimes it may be useful to issue a single person one certificate and key pair for signing operations, and another certificate and key pair for encryption operations. Separate signing and encryption certificates make it possible to keep the private signing key on the local machine only, thus providing maximum nonrepudiation, and to back up the private encryption key in some central location where it can be retrieved in case the user loses the original key or leaves the company.
Keys can be generated by client software or generated centrally by the CA and distributed to users via an LDAP directory. There are trade-offs involved in choosing between local and centralized key generation. For example, local key generation provides maximum nonrepudiation, but may involve more participation by the user in the issuing process. Flexible key management capabilities are essential for most organizations.
Key recovery, or the ability to retrieve backups of encryption keys under carefully defined conditions, can be a crucial part of certificate management (depending on how an organization uses certificates). Key recovery schemes usually involve an m of n mechanism: for example, m of n managers within an organization might have to agree, and each contribute a special code or key of their own, before a particular person's encryption key can be recovered. This kind of mechanism ensures that several authorized personnel must agree before an encryption key can be recovered.
Like a driver's license, a certificate specifies a period of time during which it is valid. Attempts to use a certificate for authentication before or after its validity period will fail. Therefore, mechanisms for managing certificate renewal are essential for any certificate management strategy. For example, an administrator may wish to be notified automatically when a certificate is about to expire, so that an appropriate renewal process can be completed in plenty of time without causing the certificate's subject any inconvenience. The renewal process may involve reusing the same public-private key pair or issuing a new one.
A driver's license can be suspended even if it has not expired--for example, as punishment for a serious driving offense. Similarly, it's sometimes necessary to revoke a certificate before it has expired--for example, if an employee leaves a company or moves to a new job within the company.
Certificate revocation can be handled in several different ways. For some organizations, it may be sufficient to set up servers so that the authentication process includes checking the directory for the presence of the certificate being presented. When an administrator revokes a certificate, the certificate can be automatically removed from the directory, and subsequent authentication attempts with that certificate will fail even though the certificate remains valid in every other respect. Another approach involves publishing a certificate revocation list (CRL)--that is, a list of revoked certificates--to the directory at regular intervals and checking the list as part of the authentication process. For some organizations, it may be preferable to check directly with the issuing CA each time a certificate is presented for authentication. This procedure is sometimes called real-time status checking.
Interactions between entities identified by certificates (sometimes called end entities) and CAs are an essential part of certificate management. These interactions include operations such as registration for certification, certificate retrieval, certificate renewal, certificate revocation, and key backup and recovery. In general, a CA must be able to authenticate the identities of end entities before responding to the requests. In addition, some requests need to be approved by authorized administrators or managers before being services.
As previously discussed, the means used by different CAs to verify an identity before issuing a certificate can vary widely, depending on the organization and the purpose for which the certificate will be used. To provide maximum operational flexibility, interactions with end entities can be separated from the other functions of a CA and handled by a separate service called a Registration Authority (RA).
An RA acts as a front end to a CA by receiving end entity requests, authenticating them, and forwarding them to the CA. After receiving a response from the CA, the RA notifies the end entity of the results. RAs can be helpful in scaling an PKI across different departments, geographical areas, or other operational units with varying policies and authentication requirements.
Future versions of the Netscape Certificate Server will support the creation of customizable registration authorities.
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.
Here are some more links to sites I find interesting.
- 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)
- NIST's Key Management Standards
- ID-PKC: IDentity-based Public Key Cryptography (CESG)
- 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 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
- 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)
- SKS: the synchronizing keyserver
- CryptoEx OpenPGP and S/MIME Gateway
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
- All About S/MIME (RSA)
- More information about S/MIME (IMC)
- 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
- 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
Secure Electronic Transactions (SET):
- SET Specification by MasterCard and Visa
Implementations / Toolkits / Products / Vendors:
- 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
- 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
- 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!)
- Valimo Wireless Oy
- Biodata Systems GmbH
- Certicom Corp.
- Java Certification Path API
- trustsuite.de (note: German language!)
- e-Security, Inc.
- Hush Communications
- PKI Group Test (The NSS Group)
- db-order (note: German language!)
- CertPath APIs (as part of J2SE 1.4)
- Project Ägypten: Free Software SPHINX Clients
- EJBCA: J2EE Certificate Authority
- AET Europe BV (Advanced Encryption Technology)
- Utimaco Safeware
- iPlanet CMS
- RSA Keon
- SECUonline AG
- Baltimore Keytools
- ValiCert ASN.1 Parser
- KSIGN Co. Ltd. (Korea)
- Dreamsecurity Co. Ltd. (Korea)
- INITECH Co. Ltd. (Korea)
- Tellus Technologies
- BCQRE (note: Korean language!)
- Glück & Kanja Technology AG
- CSP: Certificate Service Provider
- e-CryptIt Engine 7.0
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)
- 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"
- RFC 2785: "Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME"
- RFC 2876: "Use of the KEA and SKIPJACK Algorithms in CMS"
- RFC 2984: "Use of the CAST-128 Encryption Algorithm in CMS"
- RFC 3058: "Use of the IDEA Encryption Algorithm in CMS"
- RFC 3125: "Electronic Signature Policies"
- RFC 3126: "Electronic Signature Formats for long term electronic signatures"
- RFC 3183: "Domain Security Services using S/MIME"
- RFC 3185: "Reuse of CMS Content Encryption Keys"
- RFC 3211: "Password-based Encryption for CMS"
- RFC 3217: "Triple-DES and RC2 Key Wrapping "
- RFC 3218: "Preventing the Million Message Attack on Cryptographic Message Syntax"
- RFC 3274: "Compressed Data Content Type for CMS"
- RFC 3278: "Use of Elliptic Curve Cryptography (ECC) Algorithms in CMS"
- RFC 3394: "Advanced Encryption Standard (AES) Key Wrap Algorithm"
- TLS: Transport Layer Security
- SPKI: Simple Public Key Infrastructure (Note: WG has concluded)
- OpenPGP: An Open Specification for Pretty Good Privacy
- XML-DSig: XML Digital Signatures (see also: IETF/W3C XML Signature WG
- IPSEC: IP Security Protocol
- IPSRA: IP Security Remote Access
- The PEM specification:
- RFC 1847: "Security Multiparts for MIME"
- RFC 1848: "MIME Object Security Services (MOSS)"
- RFC 2015: "MIME Security with Pretty Good Privacy (PGP)"
- RFC 2480: "Gateways and MIME Security Multiparts"
- RFC 3156: "MIME Security with OpenPGP"
- RFC 3174: "US Secure Hash Algorithm 1 (SHA1)"
Miscellaneous PKI and Security stuff:
- TERENA's Security Working Group: WG-SEC
- UKERNA Technology Group Secure Email Project Homepage
- About the Digital Notary Service
- MMMSec: Security in Multimedia - Mail
- Internet Law & Policy Forum (ILPF): CA Working Group
- SPKI: Simple Public Key Infrastrucure (Carl Ellison)
- Electronic Commerce Promotion Council (Japan)
- INFOSEC page from DGXIII of the European Commission
- Meta-Certificate Group
- University of Colorado Certification Practices Statement (DRAFT)
- The Global Trust Register (University of Cambridge)
- Certificate Authority Interoperability Pilot (Internet Council)
- Fortify for Netscape!
- An Overview of the Issue of E-mail Privacy
- European Certification Authority Forum (ECAF)
- "PKI Architecture" - Network Strategy Report by The Burton Group
- PKI Task Group (Open Group)
- Netscape Object Signing Resources
- Government of Canada Public Key Infrastructure Secretariat
- "CLOUD COVER" (UK Government)
- CA Resource Center
- The "Thin PKI" concept
- The PKI Forum
- ISETO: The International Secure Electronic Transactions Organisation
- ESCA: Electronic Signatures and Certification Authorities (ITU)
- e-STIO: Electronic Signature Testsuite for Inter-Operability
- Baker & McKenzie: Certification Authorities
- ChamberSign initiative by the British Chambers of Commerce
- The PKI Challenge (EEMA)
- HEPKI: Higher Education PKI
- PKI-COORD: PKI Coordination for Europe
- XKMS: XML Key Management Services (XKMS at w3.org)
- TECS: The Encyclopedia of Computer Security
- WebTrust Program for Certification Authorities
- SiegeSoft.com (Internet Privacy and Security)
- Project MailTrusT (note: German language!)
- Network and Information Security: Proposal for a European Policy
- ABA's PKI Assessment Guidelines (Draft)
- PKI Symposium 2002 (note: German language!)
- Dartmouth PKI Lab
- De Taskforce PKI Overheid (note: Dutch language!)
- Electronic Commerce for Developing Countries (ITU)
- VPNC: VPN Consortium
- PKC 2002
- tScheme Ltd
- Internet2 PKI Labs
- Healthcare PKI
- SSTC: XML-Based Security Services Technical Committee (OASIS)
- SigLab (note: German language!)
- A bridge CA for Europe's public administrations
- Questionnaire on Public Key Infrastructure applications and requirements for the European Academic Networks
Digital Signature Links
Digital Signatures Illustrated
Digital Signature Guidelines - Tutorial
In today's commercial environment, establishing a framework for the authentication <1> of computer-based information requires a familiarity with concepts and professional skills from both the legal and computer security fields. Combining these two disciplines is not an easy task. Concepts from the information security field often correspond only loosely to concepts from the legal field, even in situations where the terminology is similar. For example, from the information security point of view, "digital signature" means the result of applying to specific information certain specific technical processes described below. The historical legal concept of "signature" is broader. It recognizes any mark made with the intention of authenticating the marked document. <2> In a digital setting, today's broad legal concept of "signature" may well include markings as diverse as digitized images of paper signatures, typed notations such as "/s/ John Smith," or even addressing notations, such as electronic mail origination headers.
From an information security viewpoint, these simple "electronic signatures" are distinct from the "digital signatures" described in this tutorial and in the technical literature, although "digital signature" is sometimes used to mean any form of computer- based signature. These Guidelines use "digital signature" only as it is used in information security terminology, as meaning the result of applying the technical processes described in this tutorial.
To explain the value of digital signatures in legal applications, this tutorial begins with an overview of the legal significance of signatures. It then sets forth the basics of digital signature technology, and examines how, with some legal and institutional infrastructure, digital signature technology can be applied as a robust computer-based alternative to traditional signatures.
Signatures and the Law
A signature is not part of the substance of a transaction, but rather of its represen tation or form. Signing writings serve the following general purposes:<3>
- Evidence: A signature authenticates a writing by identifying the signer with the signed document. When the signer makes a mark in a distinctive manner, the writing becomes attributable to the signer.<4>
- Ceremony: The act of signing a document calls to the signer's attention the legal significance of the signer's act, and thereby helps prevent "inconsiderate engagements.<5>
- Approval: In certain contexts defined by law or custom, a signature expresses the signer's approval or authorization of the writing, or the signer's intention that it have legal effect.<6>
- Efficiency and logistics: A signature on a written document often imparts a sense of clarity and finality to the transaction and may lessen the subsequent need to inquire beyond the face of a document.<7> Negotiable instruments, for example, rely upon formal requirements, including a signature, for their ability to change hands with ease, rapidity, and minimal interruption.<8>
The formal requirements for legal transactions, including the need for signatures, vary in different legal systems, and also vary with the passage of time. There is also variance in the legal consequences of failure to cast the transaction in a required form. The statute of frauds of the common law tradition, for example, does not render a transaction invalid for lack of a "writing signed by the party to be charged," but rather makes it unenforceable in court,<9> a distinction which has caused the practical application of the statute to be greatly limited in case law.
During this century, most legal systems have reduced formal requirements,<10> or at least have minimized the consequences of failure to satisfy formal requirements. Nevertheless, sound practice still calls for transactions to be formalized in a manner which assures the parties of their validity and enforceability.<11> In current practice, formalization usually involves documenting the transaction on paper and signing or authenticating the paper. Traditional methods, however, are undergoing fundamental change. Documents continue to be written on paper, but sometimes merely to satisfy the need for a legally recognized form. In many instances, the information exchanged to effect a transaction never takes paper form. Computer-based information can also be utilized differently than its paper counterpart. For example, computers can "read" digital information and transform the information or take programmable actions based on the information. Information stored as bits rather than as atoms of ink and paper can travel near the speed of light, may be duplicated without limit and with insignificant cost.
Although the basic nature of transactions has not changed, the law has only begun to adapt to advances in technology. The legal and business communities must develop rules and practices which use new technology to achieve and surpass the effects historically expected from paper forms.
To achieve the basic purposes of signatures outlined above, a signature must have the following attributes:<12>
- Signer authentication: A signature should indicate who signed a document, message or record,<13> and should be difficult for another person to produce without authorization.
- Document authentication: <14> A signature should identify what is signed, <15> making it impracticable to falsify or alter either the signed matter or the signature without detection.
Signer authentication and document authentication are tools used to exclude impersonators and forgers and are essential ingredients of what is often called a "nonrepudiation service" in the terminology of the information security profession. A nonrepudiation service provides assurance of the origin or delivery of data in order to protect the sender against false denial by the recipient that the data has been received, or to protect the recipient against false denial by the sender that the data has been sent. <16> Thus, a nonrepudiation service provides evidence to prevent a person from unilaterally modifying or terminating legal obligations arising out of a transaction effected by computer-based means. <17>
- Affirmative act: The affixing of the signature should be an affirmative act which serves the ceremonial and approval functions of a signature and establishes the sense of having legally consummated a transaction.
- Efficiency: Optimally, a signature and its creation and verification processes should provide the greatest possible assurance of both signer authenticity and document authenticy, with the least possible expenditure of resources.
Digital signature technology generally surpasses paper technology in all these attributes. <18> To understand why, one must first understand how digital signature technology works.
How Digital Signature Technology Works
Digital signatures are created and verified by cryptography, the branch of applied mathematics that concerns itself with transforming messages into seemingly unintelligible forms and back again. Digital signatures use what is known as "public key cryptography," which employs an algorithm using two different but mathematically related "keys;" one for creating a digital signature or transforming data into a seemingly unintelligible form, and another key for verifying a digital signature or returning the message to its original form. <19> Computer equipment and software utilizing two such keys are often collectively termed an "asymmetric cryptosystem."
The complementary keys of an asymmetric cryptosystem for digital signatures are arbitrarily termed the private key, which is known only to the signer <20> and used to create the digital signature, and the public key, which is ordinarily more widely known and is used by a relying party to verify the digital signature. If many people need to verify the signer's digital signatures, the public key must be available or distributed to all of them, perhaps by publication in an on-line repository or directory where it is easily accessible. Although the keys <21> of the pair are mathematically related, if the asymmetric cryptosystem has been designed and implemented securely <22> it is "computationally infeasible <23> to derive the private key from knowledge of the public key. Thus, although many people may know the public key of a given signer and use it to verify that signer's signatures, they cannot discover that signer's private key and use it to forge digital signatures. This is sometimes referred to as the principle of "irreversibility."
Another fundamental process, termed a "hash function," is used in both creating and verifying a digital signature. A hash function is an algorithm which creates a digital representation or "fingerprint" in the form of a "hash value" or "hash result" of a standard length which is usually much smaller than the message but nevertheless substantially unique to it. <24> Any change to the message invariably produces a different hash result when the same hash function is used. In the case of a secure hash function, sometimes termed a "one-way hash function," it is computationally infeasible <25> to derive the original message from knowledge of its hash value. Hash functions therefore enable the software for creating digital signatures to operate on smaller and predictable amounts of data, while still providing robust evidentiary correlation to the original message content, thereby efficiently providing assurance that there has been no modification of the message since it was digitally signed.
Thus, use of digital signatures usually involves two processes, one performed by the signer and the other by the receiver of the digital signature:
- Digital signature creation uses a hash result derived from and unique to both the signed message and a given private key. For the hash result to be secure, there must be only a negligible possibility that the same digital signature could be created by the combination of any other message or private key.
- Digital signature verification is the process of checking the digital signature by reference to the original message and a given public key, thereby determining whether the digital signa ture was created for that same message using the private key that corresponds to the referenced public key.
To sign a document or any other item of information, the signer first delimits precisely the borders of what is to be signed. The delimited information to be signed is termed the "message" in these Guidelines. Then a hash function in the signer's software computes a hash result unique (for all practical purposes) to the message. The signer's software then transforms the hash result into a digital signature using the signer's private key. <26> The resulting digital signature is thus unique to both the message and the private key used to create it.
Typically, a digital signature (a digitally signed hash result of the message) is attached to its message and stored or transmitted with its message. However, it may also be sent or stored as a separate data element, so long as it maintains a reliable association with its message. Since a digital signature is unique to its message, it is useless if wholly disassociated from its message.
Verification of a digital signature is accomplished by computing a new hash result of the original message by means of the same hash function used to create the digital signature. Then, using the public key and the new hash result, the verifier checks: (1) whether the digital signature was created using the corresponding private key; and (2) whether the newly computed hash result matches the original hash result which was transformed into the digital signature during the signing process. The verification software will confirm the digital signature as "verified" if: (1) the signer's private key was used to digitally sign the message, which is known to be the case if the signer's public key was used to verify the signature because the signer's public key will verify only a digital signature created with the signer's private key; <27> and (2) the message was unaltered, which is known to be the case if the hash result computed by the verifier is identical to the hash result extracted from the digital signature during the verification process.
Various asymmetric cryptosystems create and verify digital signatures using different algorithms and procedures, but share this overall operational pattern.
The processes of creating a digital signature and verifying it accomplish the essential effects desired of a signature for many legal purposes:
- Signer authentication: If a public and private key pair is associated with an identified signer, the digital signature attributes the message to the signer. The digital signature cannot be forged, unless the signer loses control of the private key (a "compromise" of the private key), such as by divulging it or losing the media or device in which it is contained.
- Message authentication: The digital signature also identifies the signed message, typically with far greater certainty and precision than paper signatures. Verification reveals any tampering, since the comparison of the hash results (one made at signing and the other made at verifying) shows whether the message is the same as when signed.
- Affirmative act: Creating a digital signature requires the signer to use the signer's private key. This act can perform the "ceremonial" function of alerting the signer to the fact that the signer is consummating a transaction with legal consequences. <28>
- Efficiency: The processes of creating and verifying a digital signature provide a high level of assurance that the digital signature is genuinely the signer's. As with the case of modern electronic data interchange ("EDI") the creation and verification processes are capable of complete automation (sometimes referred to as "machinable"), with human interaction required on an exception basis only. Compared to paper methods such as checking specimen signature cards -- methods so tedious and labor-intensive that they are rarely actually used in practice -- digital signatures yield a high degree of assurance without adding greatly to the resources required for processing.
The processes used for digital signatures have undergone thorough technological peer review for over a decade. Digital signatures have been accepted in several national and international standards developed in cooperation with and accepted by many corporations, banks, and government agencies. <29> The likelihood of malfunction or a security problem in a digital signature cryptosystem designed and implemented as prescribed in the industry standards is extremely remote, <30> and is far less than the risk of undetected forgery or alteration on paper or of using other less secure electronic signature techniques.
Public Key Certificates
To verify a digital signature, the verifier must have access to the signer's public key and have assurance that it corresponds to the signer's private key. However, a public and private key pair has no intrinsic association with any person; it is simply a pair of numbers. Some convincing strategy is necessary to reliably associate a particular person or entity to the key pair.
In a transaction involving only two parties, each party can simply communicate (by a relatively secure "out-of-band" channel such as a courier or a secure voice telephone) the public key of the key pair each party will use. Such an identification strategy is no small task, especially when the parties are geographically distant from each other, normally conduct communication over a convenient but insecure channel such as the Internet, are not natural persons but rather corporations or similar artificial entities, and act through agents whose authority must be ascertained. As electronic commerce increasingly moves from a bilateral setting to the many-on-many architecture of the World Wide Web on the Internet, where significant transactions will occur among strangers who have no prior contractual relationship and will never deal with each other again, the problem of authentication/nonrepudiation becomes not merely one of efficiency, but also of reliability. An open system of communication such as the Internet needs a system of identity authentication to handle this scenario.
To that end, a prospective signer might issue a public statement, such as: "Signatures verifiable by the following public key are mine." However, others doing business with the signer may for good reason be unwilling to accept the statement, especially where there is no prior contract establishing the legal effect of that published statement with certainty. A party relying upon such an unsupported published statement in an open system would run a great risk of trusting a phantom or an imposter, or of attempting to disprove a false denial of a digital signature ("nonrepudiation") if a transaction should turn out to prove disadvantageous for the purported signer.
The solution to these problems is the use of one or more trusted third parties to associate an identified signer with a specific public key. <31> That trusted third party is referred to as a "certification authority" in most technical standards and in these Guidelines.
To associate a key pair with a prospective signer, a certification authority issues a certificate, an electronic record which lists a public key as the "subject" of the certificate, and confirms that the prospective signer identified in the certificate holds the corresponding private key. The prospective signer is termed the "subscriber. <32> A certificate's principal function is to bind a key pair with a particular subscriber. A "recipient" of the certificate desiring to rely upon a digital signature created by the subscriber named in the certificate (whereupon the recipient becomes a "relying party") can use the public key listed in the certificate to verify that the digital signature was created with the corresponding corresponding private key. <33> If such verification is successful, this chain of reasoning provides assurance that the corresponding private key is held by the subscriber named in the certificate, and that the digital signature was created by that particular subscriber.
To assure both message and identity authenticity of the certificate, the certification authority digitally signs it. The issuing certification authority's digital signature on the certificate can be verified by using the public key of the certification authority listed in another certificate by another certificate authority (which may but need not be on a higher level in a hierarchy) <34>, and that other certificate can in turn be authenticated by the public key listed in yet another certificate, and so on, until the person relying on the digital signature is adequately assured of its genuineness. In each case, the issuing certification authority must digitally sign its own certificate during the operational period of the other certificate used to verify the certification authority's digital signature.
A digital signature, whether created by a subscriber to authenticate a message or by a certification authority to authenticate its certificate (in effect a specialized message) should be reliably time-stamped to allow the verifier to determine reliably whether the digital signature was created during the "operational period" stated in the certificate, which is a condition upon verifiability of a digital signature under these Guidelines. <35>
To make a public key and its identification with a specific subscriber readily available for use in verification, the certificate may be published in a repository or made available by other means. Repositories are on-line databases of certificates and other information available for retrieval and use in verifying digital signatures. Retrieval can be accomplished automatically by having the verification program directly inquire of the repository to obtain certificates as needed.
Once issued, a certificate may prove to be unreliable, such as in situations where the subscriber misrepresents his identity to the certification authority. In other situations, a certificate may be reliable enough when issued but come to be unreliable sometime thereafter. If the subscriber loses control of the private key ("compromise" of the private key), the certificate has become unreliable, and the certification authority (either with or without the subscriber's request depending on the circumstances) may suspend (temporarily invalidate) or revoke (permanently invalidate) the certificate. Immediately upon suspending or revoking a certificate, the certification authority must publish notice of the revocation or suspension or notify persons who inquire or who are known to have received a digital signature verifiable by reference to the unreliable certificate.
Challenges and Opportunities
The prospect of fully implementing digital signatures in general commerce presents both benefits and costs. The costs consist mainly of:
- Institutional overhead: The cost of establishing and utilizing certification authorities, repositories, and other important services, as well as assuring quality in the performance of their functions.
- Subscriber and Relying Party Costs: A digital signer will require software, and will probably have to pay a certification authority some price to issue a certificate. Hardware to secure the subscriber's private key may also be advisable. Persons relying on digital signatures will incur expenses for verification software and perhaps for access to certificates and certificate revocation lists (CRL) in a repository.
On the plus side, the principal advantage to be gained is more reliable authentication of messages. Digital signatures, if properly implemented and utilized offer promising solutions to the problems of:
- Imposters, by minimizing the risk of dealing with imposters or persons who attempt to escape responsibility by claiming to have been impersonated;
- Message integrity, by minimizing the risk of undetected message tampering and forgery, and of false claims that a message was altered after it was sent;
- Formal legal requirements, by strengthening the view that legal requirements of form, such as writing, signature, and an original document, are satisfied, since digital signatures are functionally on a par with, or superior to paper forms; and
- Open systems, by retaining a high degree of information security, even for information sent over open, insecure, but inexpensive and widely used channels.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2020 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to to buy a cup of coffee for authors of this site|
Last modified: March 12, 2019