CHAPTER 37

PKI AND CERTIFICATE AUTHORITIES

Santosh Chokhani, Padgett Peterson, and Steven Lovaas

37.1 INTRODUCTION

37.1.1 Symmetric Key Cryptography

37.1.2 Public Key Cryptosystem

37.1.3 Advantages of Public Key Cryptosystem over Secret Key Cryptosystem

37.1.4 Combination of the Two

37.2 NEED FOR PUBLIC KEY INFRASTRUCTURE

37.3 PUBLIC KEY CERTIFICATE

37.4 ENTERPRISE PUBLIC KEY INFRASTRUCTURE

37.5 CERTIFICATE POLICY

37.6 GLOBAL PUBLIC KEY INFRASTRUCTURE

37.6.1 Levels of Trust

37.6.2 Proofing

37.6.3 Trusted Paths

37.6.4 Trust Models

37.6.5 Choosing a Public Key Infrastructure Architecture

37.6.6 Cross-Certification

37.6.7 Public Key Infrastructure Interoperability

37.7 FORMS OF REVOCATION

37.7.1 Types of Revocation-Notification Mechanisms

37.7.2 Certificate Revocation Lists and Their Variants

37.7.3 Server-Based Revocation Protocols

37.7.4 Summary of Recommendations for Revocation Notification

37.8 REKEY

37.9 KEY RECOVERY

37.10 PRIVILEGE MANAGEMENT

37.11 TRUSTED ARCHIVAL SERVICES AND TRUSTED TIME STAMPS

37.12 COST OF PUBLIC KEY INFRASTRUCTURE

37.13 FURTHER READING

37.14 NOTES

37.1 INTRODUCTION.

Where at one time the use of encryption across the Internet consisted mainly of individuals with Pretty Good Privacy (PGP) exchanging secure e-mail and each maintaining a private “web of trust,” today's use of encryption encompasses a much wider range of elements including proofing, issuance, revocation, identification, federation, bridging, encryption, digital signing and a myriad of ancillary processes. In fact, what the user experiences is just the tip of the required support structure. Proper management of information involved in an encryption infrastructure (or cryptosystem) is about trust, what is required to establish that trust, and how much to grant.

Originally, the prime use of encryption was outside the network perimeter, where unprotected data sent and received by the organization over public networks were perceived as most vulnerable to disclosure, modification, insertion, deletion, and replay attacks. To protect the data being transported over untrusted networks, the only practical and cost-effective technology is cryptography. Cryptography is at the heart of both virtual private networks (VPNs) and public key infrastructures. For further information on encryption, see Chapter 7. For a review of cryptography, see Chapter 7 in this Handbook and Applied Cryptography by Bruce Schneier.¹

37.1.1 Symmetric Key Cryptography.

Symmetrical cryptography (aka single key or secret key) uses the same key to encrypt cleartext into ciphertext and to decrypt ciphertext back into cleartext. This process is illustrated in Exhibit 37.1.

Although symmetric cryptography (e.g., Advanced Encryption Standard (AES), Data Encryption Standard (DES), Rivest Cipher 4 (RC4) has specific advantages in that it has a dense keyspace (any integer) and is computationally very fast, it has a fundamental weakness: Both the originator and each recipient must have the key. Key sharing has two issues:

1. Key exchange must be performed: Somehow each user must have the same key.
2. There is weak accountability: Anyone with the symmetric key could have produced the document.

37.1.2 Public Key Cryptosystem.

In contrast to secret key cryptosystems, public key cryptosystems (PKCs) use pairs of related keys that are generated together. The ciphertext produced by one key can be decrypted only with the other member of the same key pair. One of these keys is kept secret (the private key) and the other is published for all to use (the public key). It does not matter which is designated as which, but once designated, the key cannot be changed. In practice, encryption with one key is often faster than with the other. This one is generally selected as the public key.

EXHIBIT 37.1 Symmetric (Secret) Key Encryption

EXHIBIT 37.2 Asymmetric or Public Key Encryption

In the simplest form, to conceal a message in transit so that only the desired recipient may read it, the cleartext is encrypted using the recipient's public key, as shown in Exhibit 37.2. Only the recipient's secret key can decrypt the transmitted ciphertext. Similarly, to verify message integrity and authenticity, it is possible to encrypt information with a sender's private key. This allows anyone with access to that sender's public key to validate the message by decrypting the ciphertext successfully.

37.1.3 Advantages of Public Key Cryptosystem over Secret Key Cryptosystem.

For securing data transmissions, public key cryptosystems are preferred over secret key cryptosystems for these reasons:

• Public key cryptosystems require fewer keys to manage: Each party (n) has a key pair, so the total number of keys is 2n, instead of being proportional to n² as for secret key cryptosystems.
• Because private keys need not be distributed or otherwise managed, public key cryptosystems require only demonstrated integrity and authenticity of the public keys themselves. Users (the relying parties) must have assurance that their public keys truly belong to the publishers. This requires signing by a trusted third party or by a mutually trusted source.
• Because no secret keys are transmitted over any network, PKCs are not susceptible to compromise even when public keys have to be changed. PKCs can be used to encrypt temporary keys (session keys) that can be used one time for secret key cryptography to obviate the heavier computational load of the PKC.
• To encrypt a message so that multiple PKC users can receive and decipher the ciphertext securely, PKC software can create a session key. This secret key is then encrypted with each recipient's public key and sent with the ciphertext to all recipients without compromising confidentiality.

PKC-based digital signatures can also provide the basis for nonrepudiation in the event of a dispute. Only the possessor of a private key could have sent a message decrypted by its public key. In contrast, because of the use of shared secrets, symmetric secret key cryptosystems alone cannot reasonably support nonrepudiation.

37.1.4 Combination of the Two.

At this point, it may be easiest to consider the elements of the different types of cryptography, as shown in Exhibit 37.3.

The difference is similar to that between electronic data interchange and ecommerce. Symmetric encryption is good for a very few exchanges with people you trust; asymmetric encryption is good for many, many small exchanges with people or devices you may have never met.

EXHIBIT 37.3 Symmetric versus Asymmetric Encryption

Today, the most common use is to combine both types: For a document to be emailed securely, a symmetric algorithm is selected and a random key generated. The document is encrypted using the symmetric algorithm and key. The symmetric key is then encrypted with the asymmetric public key of each recipient and is then added as a header to the document.

For digital signing, a similar mechanism is used except that a hashing algorithm (e.g., Secure Hash Algorithm (SHA), Message Digest 5 (MD5)) is used to create a hash value of the document, and the hash is then encrypted (signed) with the private key of the originator and accompanies the document. The originator's public key can be used to decrypt (verify) the hash, and the hash is used to verify the document.

37.2 NEED FOR PUBLIC KEY INFRASTRUCTURE.

The PKC depends on the integrity of each public key and of that public key's binding to a specific entity, such as a person, an institution, or a network component. Without mechanisms for ensuring integrity and authenticity, a relying party is vulnerable to masquerading attacks through public key substitution.

To illustrate, suppose that ABC Company wants to send a confidential message to XYZ Corp. that no one else can read. ABC could use XYZ's public key to encrypt the message, although, for the sake of efficiency, ABC probably would use a symmetric algorithm to encrypt the message and the public key algorithm to encrypt the symmetric key. However, if ABC can be tricked into using an attacker's public key as if it were XYZ's public key, then the attacker would be able to decrypt the message. This technique is known as public key spoofing.

Such public key spoofing by the attacker would, however, make it impossible for XYZ to read the message from ABC, as was originally intended. Therefore, such an attack probably would continue with the attacker reencrypting ABC's message, using XYZ's real public key, and sending it on to XYZ. Such interception and reencryption is an example of a man-in-the-middle attack. However, if the sender also signed the original message, this is something that the attacker could not duplicate, so the message could not be changed but only intercepted.

Another example of breaching the connection between a public key and its owner involves digital signature verification. Suppose ABC wants to verify XYZ's signature. If the attacker could trick ABC into using the attacker's public key as if it were XYZ's public key, then the attacker would be able to sign messages masquerading as XYZ using the attacker's private key. ABC would unknowingly use the replaced public key and be spoofed into thinking that the message actually was signed by XYZ.

This same problem exists with the core of Internet commerce today, Secure Sockets Layer v2 (SSLv2). SSLv3 and Transport Layer Security (TLS) can prevent this, but then every participant must have a certificate trusted by the other party. This is where the concept of a trust chain comes in. If a trusted third party has signed XYZ's public key, then the attacker would also have to have a key signed by the same authority as well. Otherwise, a warning would appear that the key was not recognized.

A serious issue is the sheer number of certificate authorities (over 100) built into most browsers, from a variety of countries. The browser trusts all certificates issued by any of these by default, and not all are necessarily worthy of trust.

In summary, both for digital signature and encryption services, the relying party must use the public key of the correct party in order to maintain security. There are various manual, electronic, and hybrid mechanisms for the distribution of public keys in a trusted manner, so that the relying party can be sure to have the correct public keys of the subscribers. These mechanisms for distribution and binding of public keys are known as a Public Key Infrastructure (PKI)).

The beauty of a signed public key is that the trust is inherent with the signature provided the signer is trusted. Unlike a web of trust, such as that used by the original PGP which requires all keys be accepted individually by each user, with a chain of trust a single signer (the root certificate authority) can provide trust to millions of certificates. Trust need not be absolute; it may be contextual. For example, a certificate signed by an employer can be trusted for elements relating to employment but not for credit cards. See the discussion of trust levels in Section 37.6.1.

37.3 PUBLIC KEY CERTIFICATE.

The technique that is most scalable uses a public key certificate issued by a trusted party called the certification authority (CA). A CA issues public key certificates to the various subscribers by putting together subscriber information and signing the information using the CA's private key. The generally accepted standard for public key certificates is the X.509 version 3,² as defined in RFC 5280 and subsequent text.

X.509 certificates are expressed in Abstract Syntax Notation 1 (ASN.1), which is a complex binary notation. In order to be passed through e-mail, certificates are usually MIME (aka Base 64) encoded, expressing the binary syntax in ASCII characters.³

The advantage to using a CA and a chain of trust is that by trusting the root, the user automatically trusts all keys that it has issued whether or not the user has ever seen them.

Each CA's certificate may contain this key information:

• Version number of certificate standard
• Certificate serial number (unique for every certificate issued by the CA)
• Algorithm and associated parameters used by CA to sign the certificate
• CA name
• Validity period for the certificate
• Subscriber name
• Subscriber public key, public key algorithm, and associated parameters
• CA unique identifier (optional)
• Subscriber unique identifier (optional)
• Extensions (optional)
• CA's digital signature

The relying parties require the CA's public key so that they can verify the digital signatures on the certificates issued by the CA. The relying party must trust the CA's public key, most likely obtained during the registration process. Once the signatures are verified, relying parties can use the subscriber name and subscriber public key in the certificate with as much confidence in the accuracy of the information as they have in the trustability of the CA.

In some situations, a CA may need to revoke the binding between a subscriber and that subscriber's public key. For example, the subscriber private key may be compromised (i.e., there may be reason to believe that the secret key has fallen into the hands of someone else). Since a public key certificate is an electronic object and can reside in several places at the same time, it is neither practical nor possible to recall, delete, or erase all the copies of the subscriber certificate in a distributed environment. Thus, to invalidate a public key certificate by severing the binding between the subscriber and the subscriber public key, the CA creates a list of invalid certificates. This list is called a certificate revocation list (CRL). The relying parties must check that a certificate is not on the CRL prior to using the public key in the certificate. If the certificate is on the CRL, the relying party must not use it. The CA signs the CRL to allow the relying parties to verify the CRL's integrity and authenticity. The key information in the X.509 version 2 CRL is:

• Version number of CRL standard
• Algorithm and associated parameters used by CA to sign the certificate
• CA name
• This CRL issuance time
• Next CRL issuance time (optional)
• List of revoked certificates (listing these items for each certificate):
  • Certificate serial number
  • Time CA was notified of revocation
  • Extensions related to the revoked certificate (optional)
• Extensions related to CRL (optional)
• A's digital signature

It is important that a certificate contain only those elements specifically required for operation and that these be used properly otherwise confusion and improper/unexpected use may result.

Probably the most misused element is the Key Usage extension. (It is used so badly that often a second extension, the Extended Key Usage, is used to clarify the first.) The most common error is to have the Non-Repudiation Bit set on a key intended for identity only. Non-repudiation should be asserted only on a key intended as a legal signature, not for identity alone.

A dangerous extension (and one that really does not belong in a user certificate) is the SMIME Capabilities extension. This only has meaning in the context of specific e-mail clients but can cripple the use of encryption. Although it may have had some use in early mail applications, today it only establishes a maximum allowed symmetric encryption strength, which may be less than desired. If this extension is not present, RFC 5280 requires a default to triple-DES.

In the case of certificates, less is more. The minimum number of fields and extensions that is required for the assertions the certificate is intended to make is best. PKI systems in the past have failed when too many, and sometimes mission-conflicting extensions, were added.

Particular care needs to be taken that the CA server vendor chosen does not add anything not specified by the certificate template in the Certificate Policy.

37.4 ENTERPRISE PUBLIC KEY INFRASTRUCTURE.

The use of a certificate is relatively simple, but establishing trust that the certificate is valid and appropriate for use requires a complex set of back-office elements, illustrated in Exhibit 37.4. Each group of users covered by a CA is called a domain. Subscribers in a domain receive public key certificates from the appropriate CA. The CA is responsible for generation of subscriber certificates and for CRL generation. The CA posts these signed objects to the repository where the relying parties can obtain them. The CA also archives the certificates and CRLs in case they are required in the future to resolve disputes among the subscribers and the relying parties.

The registration authority (RA) is the trusted representative of the CA and is responsible for authenticating the subscriber identity. The RA typically performs these functions:

• Authenticates (proofs) the subscriber's claimed identity. For example, the RA could require the subscriber to provide a valid photo ID, such as a driver's license or a passport for minimum assurance. Both I-9 authentication, as required by the Immigration Reform and Control Act (IRCA), and a Local Agency Check or a National Agency Check (LAC/NAC) plus “Need to Know” may be required for a higher level.⁴
• Obtains the subscriber public key from the subscriber.
• Provides the CA public key to the subscriber. A trust anchor is a CA's public key that the relying party trusts. This trust generally is established by obtaining the public key from a trusted source using trusted means, such as physical hand-off or via Secure Sockets Layer (SSL) from a trusted or known Web site. The CA public key becomes a subscriber trust anchor.
• Sends the certificate creation request to the CA. Typically, the RA creates an electronic mail message containing the subscriber name and the subscriber public key, digitally signs the message, and sends the message to the CA. Other transport means, such as manual or on the Web, also are appropriate as long as there is assurance that the subscriber identity and the public key are not changed. X.509 standard does not specify a protocol for certificate generation requests. The Public Key Infrastructure for X.509 Certificate (PKIX) working group of the Internet Engineering Task Force (IETF) has developed Internet standards in this area.⁵

EXHIBIT 37.4 Certificate Issuance Cycle

37.5 CERTIFICATE POLICY.

To ensure the security of the PKI, the PKI components need to operate with a high degree of security. To assure this:

• Private keys must be kept confidential.
• Private keys must be used only by the owners of the keys.
• Trust anchors' public key integrity must be assured.
• Initial authentication of the subscriber (private key holder and the subject of the public key certificate) must be strong so that identity theft does not occur at the point of certificate creation.
• CA and RA computer systems and applications must be protected from tampering.
• Requirements for level of trust must be clearly defined

The Certificate Policy (CP) must specifically enumerate the certificate contents, both fields and extensions. Anything absent from the CP should not be found in the certificate.

In addition to the security requirements and in order to facilitate electronic commerce, the PKI must address obligations of all parties and their liabilities in case of dispute. These issues of security, liability, level of trust, and obligations are articulated in a CP.

According to the X.509 standard, a CP is “a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.”⁶ A certificate user may use a CP to decide whether a certificate, and the binding implied between the certificate and its owner, is sufficiently trustworthy for a particular application. The CP addresses security and obligations of all PKI components, not just the CA; this includes the CA, RA, repository, subscriber, and relying party.

A more detailed description of the practices followed by a CA in issuing and managing certificates is contained in a certification practice statement (CPS) published by or referenced by the CA. According to the American Bar Association's Digital Signature Guidelines (hereinafter referred to as ABA Guidelines), “a CPS is a statement of the practices which a certification authority employs in issuing certificates.”⁷

Although a CP and a CPS both address the same topics, the CP defines the security requirements and obligations for an enterprise PKI, and the CPS describes how these requirements are satisfied by the enterprise PKI.

The CP and CPS also are used differently. The CP forms the basis for cross-certification across enterprise boundaries to facilitate secure, interenterprise electronic commerce. An object identifier (OID) pointing to the CP (which may be a Universal Resource Locator [URL]) is used to create a certificate that can be put into the “Certificate Policies” extension of X.509 certificates. The OID thus enables relying parties to learn the care taken during the generation of certificates, recommended usage, and obligations of the various parties.

EXHIBIT 37.5 Elements of a Comprehensive Certification Practice Statement

Since certificates can be created with different levels of trust and can be either based in software or hardware (more secure), often the “Certificate Policies” extension is the only indicator of the level of trust that should be placed in a certificate.

The CPS enables PKI personnel to use and administer the PKI components. The CPS also forms the basis for compliance audits in order to ensure that the PKI components are operating in accordance with the stipulations of the CPS. Exhibit 37.5 illustrates the components of a comprehensive CPS. Components are divided further into subcomponents, which in turn are divided into elements. Components may be appropriate for various PKI entities but may be applied in the same way or differently. For example, technical security controls may apply to CA, RA, subscribers, and relying parties. These controls may be different for each of these entities, being most stringent for the CA, then the RA, and then the subscribers and relying parties.⁸

Sample policies may be found at www.certipath.com/library/library.htm and www.verisign.com/repository/vtnCp.html.

37.6 GLOBAL PUBLIC KEY INFRASTRUCTURE.

The principles of an enterprise PKI with a single CA can be extended to support global, secure, electronic commerce by relying on multiple CAs and/or CAs to certify other CAs and each other. How the CAs cross-certify each other is also called trust model, trust graph, or PKI architecture. For one person to communicate securely with another, there must be a trust path from the trust anchor(s) of the relying party to the subscriber whose signature needs to be verified or to whom an encrypted message is to be sent.

37.6.1 Levels of Trust.

As referenced in Office of Manpower and Budget Memorandum OMB M04-04, Section 2.1, there are four basic levels of trust:⁹

Level 1. Little or no confidence in the asserted identity's validity

Level 2. Some confidence in the asserted identity's validity

Level 3. High confidence in the asserted identity's validity

Level 4. Very high confidence in the asserted identity's validity

Each level requires a different initial authentication of identity, and higher levels (or those used for classified information) require background investigations. Level 3 is also known as Medium Assurance and is divided into two forms: (1) software (certificates and keys can be exported and moved between devices) and (2) hardware (certificates may be exported but keys and cryptographic functions are performed on a specific hardware device [e.g., a smart card, USB token, or PC-Card device]). Most commercial PKI uses the equivalent of the Medium level of assurance.

EXHIBIT 37.6 Trust Level Determination

Exhibit 37.6 shows one way to determine the required trust level as a function of threat of misuse.¹⁰

37.6.2 Proofing.

Each assurance level has a proofing (also known as vetting) requirement that increases with the trust level involved, as shown in Exhibit 37.7. Essentially none is required for level 1 (Basic) while extensive in-person requirements exist for level 4 (High).

37.6.3 Trusted Paths.

The trust model can be viewed as a chain, with its tail a certificate-issuing CA and its head the subscriber (i.e., the subject of the certificate). The subscriber can be another CA or an end entity. To ascertain the trustworthiness of a certificate, it is necessary to start with the relying party trust anchor and to follow in the direction of the chain until the subscriber (of interest to the relying party) is reached. Global secure communications require that there be a trust path from every subscriber to every other subscriber.

EXHIBIT 37.7 Trust Levels and Proofing

EXHIBIT 37.8 Trust Path through Multiple Trusting Certificate Authorities

The relying party can start with its trust anchor and verify the certificates issued by the trust anchor. Once that happens, the public keys can be trusted and used to verify the certificates issued by these CAs. This can be done recursively by the relying party until the public key certificate of the subscriber of interest is verified. Then the subscriber public key can be used to verify digital signatures and to perform encryption. Exhibit 37.8 illustrates this pathway. The arrows represent certificates. This is called a certification path.

37.6.4 Trust Models.

Examples of trust models within PKI that relate to the trust in a certificate and are different from proofing (trust of an identity) include:

• Strict hierarchy
• Hierarchy
• Bridge
• Multiple trust anchors
• Mesh (aka anarchy or web)
• Combination

37.6.4.1 Strict Hierarchy.

Exhibit 37.9 illustrates a strict hierarchy. It is a tree structure with a single root. In a strict hierarchy, for two parties to communicate with each other securely, they require the public key of their common ancestor as the trust anchor. Verifiable certificate chains require that the parties have a common ancestor. For all parties to communicate securely with each other, they require the single root as the trust anchor, since it is the only common trust anchor.

37.6.4.2 Hierarchy.

In a (nonstrict) hierarchy, the subordinate CAs certify their parents. Since the directed graph is bidirectional, any CA can be the trust anchor for the relying parties. But from practical, operational, and performance (i.e., certificate path length) viewpoints, the local CA should be the trust anchor. The local CA is the CA that issued a certificate to the relying party.

EXHIBIT 37.9 Strict Hierarchical Trust Chain

37.6.4.3 Bridge.

Another trust model is the bridge. Under this model, one CA cross-certifies with each CA from various domains. The domains can be organizations or vertical segments, such as banking or healthcare. Exhibit 37.10 illustrates the bridge CA. The bridge CA is not the trust anchor for any relying party. A CA in the domain of the relying party is the trust anchor.

Within a domain, there are no constraints on the trust model. The domain PKI itself could be organized as any of the trusted models, including bridge, leading to possible layers of bridge CAs.

37.6.4.4 Multiple Trust Anchors.

Another alternative is for the relying party to obtain the public keys of the various CAs in a trusted manner and then use those public keys as trust anchors. This approach is attractive when the CAs cannot, or are not willing to, cross-certify, and the relying party needs to communicate securely with the subscribers in the domains of the originating CAs. This approach is called multiple trust anchors. Each trust anchor representing a domain could be a single CA or a PKI with a collection of CAs in a trust model.

37.6.4.5 Mesh.

The final example of trust model is a mesh (aka web or anarchy). The term “mesh” describes any depiction representing trust among CAs or certificates without any particular rules or patterns. This model sometimes is known as a web of trust and is particularly associated with the original design of Pretty Good Privacy, one of the first popular systems implementing public key certificates. Within this structure, each recipient must explicitly trust each other participant. The major problem is that it does not scale very well beyond a few hundred users.

EXHIBIT 37.10 Bridge CA

37.6.5 Choosing a Public Key Infrastructure Architecture.

Whether a domain (enterprise) chooses a single CA or multiple CAs for its intradomain operation should be determined from a variety of factors, including:

• Management culture
• Organization politics
• Certification path size
• Subscriber population size
• Subscriber population distribution
• Revocation information

In many situations, the politics or management structure may dictate that there be multiple CAs within the domain. In other words, organizations at business-unit level, regional office level, corporate level, or national level may want to create a CA in order to provide them with a certain degree of control, independence, autonomy, and prestige. How these CAs are organized (bilateral cross-certification, hierarchy, etc.) also will depend on the management and political landscape of the domain. The trust model should be such that it keeps the certification path size manageable; otherwise, end users will see unacceptable performance degradation in obtaining certificates and CRLs and in verifying digital signatures on the certificates and the CRLs.

Similarly, large subscriber populations may require more than a single CA in order to ensure that the CA can manage the subscribers and to keep the CRL size small. If CA products that issue partitioned CRLs are selected, the CRL sizes can be kept manageable even for a very large subscriber population. For further discussion of the CRL issue, see Section 37.7 on revocation alternatives.

When considering interdomain cross-certification, similar issues should be considered.

37.6.6 Cross-Certification.

In the simplest form, cross-certification consists of two CAs that certify each other by issuing each other a certificate. The certificates can be stored in specific attributes of the directory entry in a certificate; examples include the cross-certificate attribute pair or the CA certificate.

There are two practical problems with cross-certification. One deals with the commercial products. If the two domains use different products, their CAs may not be able to exchange information to cross-certify, and their directories may not be able to chain to permit the relying parties to retrieve certificates.

The other problem is operational. Before certifying another CA, the certificate-issuing CA needs to make sure that the subject CA is operating in accordance with the acceptable controls, articulated in a CP. The issuing CA asserts the appropriate CP in the “certificate policies” extension of the X.509 version 3 certificate of the subject CA.

In practice, the two CAs cross-certify each other after reviewing each other's CP and after ensuring that the CPs can be claimed to be equivalent. This does not mean that all the security controls and obligations are identical, but they need to offer roughly similar amounts of trust and of obligations and similar liability and financial relief.

When two CAs cross-certify each other, the trust generally is for a limited set of policies, through assertions in “certificate policies” extensions, and trust is only bilateral. In other words, trust will not commute; it will remain between the two CAs. The CAs ensure this by inhibiting policy mapping through the “policy constraints” extension. Policy constraint extensions permit differing policy-mapping inhibitions down the certificate chain. In most direct cross-certifications, policy mapping should be inhibited immediately. In the case of cross-certification using the bridge CA model, in order to take advantage of the policy-mapping services of the bridge CA, the policy-mapping inhibition should be different for one certificate (namely the bridge CA certificate).

In addition, the two CAs should use the “name constraints” extension in the X.509 version 3 certificates to ensure that they trust the other domain for the names over which the other has control. The use of this extension also minimizes the chances of name collision.

Exhibits 37.11 and 37.12 illustrate cross-certification examples. These examples are for illustrative purposes only and do not represent real-world entities.

In the case of bilateral cross-certification, policy mapping should be inhibited immediately by using a value of “0” in the “inhibit policy mapping” field of the policy constraints extension in X.509 certificates. When bridge CA is used for interdomain interoperability, a value of “1” should be used in this field. This will permit the issuing CA domain to map its policies to the bridge CA policies and then permit the bridge CA to map its policies to the subject CA domain, in effect mapping from the issuing CA domain to the subject CA domain.

As long as the issuing CA uses its control on inhibit policy mapping, the bridge CA need not use inhibit policy mapping to control the mapping inhibition.

37.6.7 Public Key Infrastructure Interoperability.

The complexity of the technology, standards, and products of PKI technology from one domain to another and from one product to another sometimes creates interoperability problems. Yet without interdomain interoperability there can be no global trust, only individual trust.

EXHIBIT 37.11 Trust Chain Mapping with Dissimilar Policies

EXHIBIT 37.12 Policy Mapping with a Bridge

These factors play a critical role in ensuring PKI interoperability:

• Trust path
• Cryptographic algorithms
• Certificate and CRL formats
• Certificate and CRL dissemination
• Certificate policies
• Names

37.6.7.1 Trust Path.

The communicating parties must be able to form trust paths from their trust anchors to their subscribers. This can be achieved through multiple trust anchors, cross-certification, and other trust models described earlier.

37.6.7.2 Cryptographic Algorithms.

The communicating parties must implement the cryptographic algorithms, such as hashing, digital signatures, key encryption, and data encryption, used by each other.

In addition, the parties should be able to communicate to each other the algorithms they use. In X.509 certificates and CRL, this information may be contained in the objects themselves, as in the algorithm field. In X.509 certificates, for the information being communicated, algorithms such as the digital signature and key encryption algorithm may be carried in the end-entity certificate. The hashing algorithm and the data encryption algorithm can be part of the implicit agreement between the parties or can be carried with the information being communicated. The information also can be obtained from the supported algorithms attribute of the X.500 directory entry of the user, although this option is not widely used.

Although the expected public key algorithms used by the CA to create the certificate must be discernible by the recipient (in order to understand the certificate contents), it is important that the certificate not make any assertions as to the symmetric algorithms that may be used. The certificate should be application-agnostic and not impose any rules on applications when not necessary.

In all these situations, the algorithm is identified using the object identifiers. Different organizations may register the same algorithm under their OID arc. Thus, it is important that either the two domains use the same OID for the algorithms, or that their software interpret the multiple OIDs as the same algorithm. For this reason, OID proliferation for algorithms in not recommended.

Variants of the same base algorithm further exacerbate the problems of algorithm interoperability. For example, subtle padding and other differences exist between definitions of the RSA algorithm in the Public Key Cryptography Standards (PKCS) and in the American National Standards Institute (ANSI) X9 committee. Similarly, the Diffie-Hellman algorithm has various modes and various ways to reduce the calculated secret to symmetric key size (i.e., ways to make session keys smaller). Any of these differences in algorithms must be documented through different OIDs so that the OID invokes the appropriate implementation.

It is important that extensions be chosen carefully. Those pertaining to algorithms often have meaning within the context of a particular application. As mentioned earlier, a good example of an extension that should not be placed in a certificate is the SMIME Capabilities extension, since it does not set minimum expectations and instead may limit the symmetric key length that can be used by applications.

Such application-specific extensions should be avoided in user/subscriber certificates. The algorithms and key lengths used by the public key (asymmetric) elements are specified in the Field values such as Subject Public Key Information.

37.6.7.3 Certificate and Certificate Revocation List Format.

The communicating parties must share, or must be able to understand, each other's certificate and CRL formats. The most common way to achieve this is to use a common standard, such as X.509. Many times this has not been sufficient due to the ambiguity in the standard and associated encoding schemes, although, over time, those bugs have been worked out. The primary reason today why certificates and CRLs issued by one product may not be understood by another is that either one or both are not compliant with the standard, or one product does not implement all the features of the standard used by the other product.

37.6.7.4 Certificate and Certificate Revocation List Dissemination.

The communicating parties must obtain the certificates and CRLs issued by the various CAs in each other's domain. These certificates and CRLs may be obtained from a repository such as an X.500 and Lightweight Directory Access Protocol (LDAP) server. Alternatively, the certificates and CRLs can be carried as part of the communication protocol between the parties, for example, as defined in S/MIME (Secure/Multipurpose Internet Mail Extension) version 3.

The X.500 and LDAP repositories are based on hierarchical databases. Each node in the hierarchical tree structure belongs to an object class. The node's object class determines the attributes that are stored for that node. Examples of attributes are job title, phone number, fax number, and the like. Certificates and CRLs are also attributes.¹¹

X.500 and LDAP have defined a standard schema for PKI certificates and CRLs. For certificates, these attributes are userCertificate, cACertificate, and crossCertificatePair. The end-entity certificates should be stored in userCertificate attribute. All CA certificates should be stored in the forward element of the crossCertificatePair attribute of the subject CA. In addition, all certificates issued to the CAs in the same domain should be stored in the cACertificate attribute of the subject CA.

Various revocation lists should be stored in the cRL, aRL, and deltaCRL attributes of the issuing CA as applicable.

If the certificates and CRLs are not stored in these standardized attributes, the relying-party software may not be able to obtain these objects. Furthermore, X.500 directory products still may not always interoperate due to additional complexity of the X.500 standard and to product differences. When implementing X.500 directories and connecting X.500 directory products from different vendors, implementers should allow time to make the products and directories interoperate.

37.6.7.5 Certificate Policies.

In order to trust and cross-certify each other, the CAs in two domains need to operate under similar policies. Users in the two domains should be able to accept or reject certificates of each other's domains based on the security requirements of the application, and on the policy under which the certificates were issued.

In order to determine the similarity, or equivalence, of the policies of the two domains, the CP should be written using the IETF standard RFC-2527 framework. The CP is represented using an OID in the certificate. To ensure that the user software accepts and rejects certificates based on the application requirements and on the CP, PKI products should be selected and configured so that the CA asserts the certificate policies, policy mapping, and policy constraints extensions appropriately. The user's PKI-enabling software must process these extensions appropriately and fully in compliance with the requirements of X.509 certificate-path validation rules.

37.6.7.6 Names.

The communicating domains must not assign the same name to two different entities. X.500 distinguished names (DN) are steps in that direction but not sufficient to achieve this.

To illustrate the point, consider, for example, CygnaCom, is a company incorporated in the Commonwealth of Virginia. While it is highly unlikely that there is another CygnaCom in Virginia, there is no assurance that there is no CygnaCom incorporated in other U.S. states. Thus, it would be possible that c=US, O=CygnaCom could be asserted by the CAs for several different domains.

In order to avoid this name collision and ambiguity, the name constraints extension in X.509 should be used. The CA for one domain can prevent any other entity from using a name registered in that domain. The issuing CA (CA “Y” in this example) uses the name constraints extension to assert priority and control over the specified identifier. For example, the first CA that certifies a company called CygnaCom in its domain should set the name constraint attribute in its certificate for its CygnaCom stating that only its CygnaCom is allowed to issue certificates under the name space c=US, O=CygnaCom. If another CygnaCom were to come along, CA “Y” would ask the second CygnaCom to choose another name in order to avoid name collision. Although this example focuses on the DN, the name constraint can be used for any hierarchical name forms, including DN, RFC 822-compliant names, and others.

PKI products should be selected and configured so that the CA asserts the name constraints extension appropriately. The user's PKI-enabling software must process this extension appropriately and fully in compliance with the requirements of X.509 certificate-path validation rules.

37.7 FORMS OF REVOCATION.

As discussed earlier, a PKI includes mechanisms for key revocation. It is necessary to make provisions for the revocation of compromised keys in order to maintain the trust relationships of any PKI employed in a real-world environment.

The first form of revocation designed was the CRL. It seems the most appropriate form of revocation, given the distributed authentication framework of PKI. The CRL mechanism allows the CA to generate the objects and the relying parties to process them securely without worrying about the security of the servers or system that supply the CRL, and without concerns about the network(s) over which the CRL has traveled.

37.7.1 Types of Revocation-Notification Mechanisms.

However, there have been several concerns about the CRL, and these concerns have led to other forms of revocation-notification mechanisms. Many of these mechanisms are variations on the CRL in the sense that these are revocation lists, but they are not complete. The second category of revocation mechanisms defers the processing of revocation information to a server e.g. through the Online Certificate Status Protocol (OCSP.), See RFC 2560. A third category of mechanisms lets the users check the status of a single certificate from the directory and allows the CA to update the status of that certificate in the directory. A final category lets a CA or another trusted server organize the revocation information in a B-tree.

Which mechanism(s) to choose depends on a variety of factors, such as:

• The communication model (i.e., which class of users is communicating with which other class). For example, if a user communicates with several users who are subscribers to the same CA, a single CRL from that CA will provide relevant information about all those targeted users. If a user is communicating with users who belong to different CAs, each CRL provides information about only one user.
• The directory architecture: Where they are located and what portions of the directory information is replicated or shadowed?
• The communication bandwidth available.
• The bind time (i.e., the time to set a connection with the repository in order to perform retrievals and updates) to access the repository.
• The size of the revocation response from the repository (e.g., the CRL size).
• The processing load on the repository, especially for digital signature generation on the revocation information.
• The processing load on the user workstation, especially for digital signature verification on the revocation information.

37.7.2 Certificate Revocation Lists and Their Variants.

The first set of mechanisms, CRL and its various forms, is the most versatile, effective, and recommended approach for revocation notification. Like X.509 certificates, CRLs are expressed in ASN.1 format. There are several basic types of CRL, and they should be carefully considered, based on the user communication model and anticipated revocation rate:

• Full and complete CRL
• Authority revocation list (ARL)
• Distribution-point CRL
• Delta CRL

37.7.2.1 Full andComplete CRL.

The full and complete CRL is a CRL that contains the revocation information for all certificates issued by a CA. This type of CRL is rarely seen; instead a normal CRL includes only information about revoked certificates and not currently valid ones. Expired certificates are not included, and revoked certificates will drop off the CRL when they expire.

37.7.2.2 Authority Revocation List.

The ARL is a CRL that contains the revocation information for all the CA certificates issued by a CA; that is, the ARL is a subset of CRL for certificates issued to the CAs only. The ARL is a very desirable mechanism for these reasons:

• It is likely to be short. A CA is likely to certify fewer CAs than other types of subscribers. Also, given that CAs are expected to operate with a great deal of vigilance, and given that CAs are not going to be revoked for reasons such as name change or organizational affiliation change, CAs will be revoked far less often than the end entities. These factors will contribute to making the ARL very small.
• For all of the certificates except one, only the ARL needs to be checked, since in a certificate path all but the last certificate is issued to a CA.

Due to a security flaw in X.509 version 1, a CA should never issue ARLs defined using that version. In X.509 version 1, there is no difference between the CRL format and the ARL format. Since both CRLs and ARLs are signed by the same CA, if an adversary (directory or network adversary) were to supply an ARL to the relying party in lieu of a full CRL, the relying party would have no way of knowing that it had received an ARL instead of the requested CRL. The ARL would not have end-entity revocation information and therefore could mislead the relying party into using the revoked certificate of an end entity.

The X.509 version 2 ARL fixes this security flaw using an issuing distribution point extension. An ARL must use this extension and assert a field that states that the list contains only CA certificates. The presence of this field in the signed ARL tells the relying party that it is not a full CRL. Now, if an adversary were to supply an ARL in lieu of a CRL, the relying party would detect this substitution by using the issuing distribution point field.

This is one of the several security reasons that PKI-enabling software must be able to process the various extensions properly in accordance with the requirements stated in X.509 standard.

37.7.2.3 Distribution-Point CRL.

Distribution-point CRL is a mechanism that has several useful functions:

• To replicate a CRL
• To consolidate revocation information from the various CAs so that the relying parties need to obtain only one CRL
• To partition the revocation information for the subscribers of a CA into multiple smaller pieces

This latter function, partition, is achieved by asserting the CRL Distribution Point extension in the certificate that points to the name entry under which revocation information for the certificate will appear. The partitioned CRL will assert the same name in the Distribution Point field of the issuing distribution point extension in the CRL.

Since all the partitioned (distribution point) CRLs are signed by the same CA, it is not sufficient for the relying party simply to validate the CA's signature on the Distribution Point CRL. The relying party must match the Distribution Point name in the issuing distribution point extension of the CRL with the Distribution Point name in the distribution point extension in the certificate.

37.7.2.4 Delta Certificate Revocation List.

Yet another way to reduce the size of the CRL is to publish changes to the revocation information since the last CRL. The CRL that contains changes only is called the delta CRL, and the CRL to which changes are published is called the base CRL. The delta CRL can be applied to any of these CRLs: CRL, ARL, and Distribution Point CRL. In order to construct current revocation information, the latest delta CRL and its base must be used. There is an algorithm that could be used to allow a subset of changes to be applied to an earlier CRL that would still match the digital signature of the new CRL.

37.7.3 Server-Based Revocation Protocols.

Server-based revocation uses protocols, such as On-Line Certificate Status Protocol (OCSP) and Simple Certificate Validation Protocol (SCVP). In general, these protocols suffer from several flaws, including these:

• Since the revocation information is produced at the server, the communication channel between the relying party and the server must be secured, most likely by using digital signatures.
• Signed operations will limit server scalability since digital signature generation is computationally intensive.
• Since the revocation information is produced at the server, the scheme requires a trusted server as opposed to an untrusted repository.
• Revocation of a server public key requires a method for checking the server public key status. This method is likely to use the server public key as an additional trust anchor or to rely on a CRL mechanism.
• There needs to be a nonsuppressible mechanism for the CA to provide revocation information to the trusted server; that is, the CA should know whether the revocation information has or has not reached the trusted server. Although a CA itself can act as a trusted server, this is not recommended for security reasons; in addition, we do not want to impose the high-performance requirement on the CA architecture. The trusted server must be a high-performance system.
• There are no standards in the area of CA to provide nonsuppressible mechanisms for transmitting the revocation information to the trusted server.

These mechanisms may be desirable under one of four situations:

1. Need to have thinnest possible PKI client
2. Need to generate revenue for CA services
3. Need to check changing credentials, such as available credit
4. Need to update dynamic credentials, such as the remaining credit line

The last two situations permit the trusted server to provide the revocation information and to check or change the credentials of the subscriber.

Delta CRLs and server-based revocation/authentication protocols such as OCSP (RFC 2560) are standards-compliant and can provide the same information as in the CRL for a single certificate in a significantly smaller bandwidth. They do require some form of acceptable authentication since the original CA will not be available for signing.

37.7.4 Summary of Recommendations for Revocation Notification.

The most scalable and versatile revocation-notification mechanism can be achieved by using a combination of:

• CRLs.
• Replication of the CA directory entry, at locations determined by the enterprise network topology, for fast access to CRL.
• Use of ARLs.
• Consolidation of ARLs for all CAs in a domain through the use of distribution points. Consolidation is achieved by placing the name of a CA that can revoke a certificate in the certificate's CRL Distribution Point extension.
• Consolidation of all the reason-codes of key compromise for all certificates in a domain through the use of the Distribution Point extension. This CRL can be issued very frequently to meet the freshness requirements of the domain. This mechanism makes the CRL mechanism as current as the OCSP.
• Partitioning routine revocation information using Distribution Point CRLs if CRLs become too large.

Several other techniques can help improve CRL retrieval efficiency:

• Repositories may store both enciphered CRLs to send to the relying parties and also deciphered (plaintext) CRLs to perform fast searches. Storing both forms reduces the overhead that would result from using encryption or decryption at the time of each request.
• If the repository does not store any private information, bind operations for retrieval can be configured to require no authentication, thus eliminating another potential performance bottleneck.
• CRL size can be reduced by having a short validity period for the certificates, by using a coarse domain name so that reorganization does not invalidate a name, and by allowing some changes (e.g., name change or transfer) without forcing revocation.

37.8 REKEY.

The public key certificates for the subscribers have a defined validity period. Once the validity period expires, subscribers require new public key certificates. There are two primary reasons why public key certificates have a limited life. One relates to the life of a private key based on the potential cryptanalysis threat. Another reason is to help control CRL size since no certificate gets off a CRL until it expires.

No public key should be used longer than the estimated time for brute-force cryptanalysis using current technology (its cryptanalysis threat period). At that point, the certificate should be assigned a new public key (i.e., it should be rekeyed). However, before the cryptanalysis threat period expires, the same key can be renewed or recertified. Certificates can be renewed easily by having subscribers send a digitally signed request to the CA or by having the CA perform automatic renewal. During renewal, any information (other than the subscriber public key) may be changed.

For the foreseeable future, the life of a 1024-bit RSA key can be expected to be 25 years. By reusing the same key with new certificates for as long as possible, the number of past keys required to be escrowed in order to retrieve or validate older files is reduced. The level of trust should also be considered when rekeying, but keys stored in tamper-resistant hardware can be expected to achieve their full lifetime.

Elements using soft keys are inherently at risk to a determined attack and should be used only for lower levels of trust.

Certificates also can be rekeyed easily by having the subscriber send a digitally signed rekey request message that also contains the new public key. The message is signed using the current private key so that it can be verified using the current public key. If the subscriber being rekeyed is a CA, these requirements also come into play:

• The relying parties should be able to verify certificate chains after the CA is rekeyed.
• The relying parties should be able to verify CRLs issued by the CA.
• The rekey should not have a ripple effect on the PKI. Just because one CA rekeys, other CAs or end entities should not have to rekey.
• The length of certificate paths should be minimized.
• The operational impact on the PKI entities should be minimal.

A good way to meet these requirements is for the CA to:

• Issue all current valid certificates when it rekeys, without changing the validity periods in the subscriber certificates.
• Continue to sign CRLs with all current valid private keys. This will result in multiple CRLs, all with the same information. A CA private key is considered valid until all certificates signed using that key have expired.

If the CA is a trust anchor, it can use one of two approaches to rekey itself in-band, over the untrusted network:

1. The CA can send out a rekey message that contains its new public key and is signed using the current key. The CA needs to ensure that all the subscribers receive and process the rekey message prior to expiration of the current key.
2. The CA can provide the hash of the next public key and parameters (if the cryptographic algorithm has parameters; RSA does not have parameters, but Digital Signature Standard [DSS] does) with the current key. When it is time to publish the new public key, the CA can publish a new self-signed public key certificate that contains the new public key and parameters as well as the hash of the next public key and parameters.

37.9 KEY RECOVERY.

Subscriber public keys can be used to encrypt data-encryption keys (for symmetric-key encryption). Such data-encryption keys are used to encrypt data quickly with the lower overhead of symmetric-key encryption. Subscribers require their private keys to decrypt the data-encryption keys and thus allow decryption of the data.

It is critically important to distinguish between signing keys and data-encryption keys. The former may never be subjected to key recovery; the latter may be protected using key-recovery techniques.

High levels of trust keys may require a separate identification key that may not be used to sign a document; this login key should have only the signing bit and not the nonrepudiation bit set in the Key Usage extension.

Sometimes a subscriber's private-key token (e.g., a diskette, hard drive, smart card, etc.) may be corrupted or the subscriber may forget the password associated with the token. Similarly, sometimes a subscriber may not be available yet the subscriber's employer may need to decrypt corporate information encrypted by the missing subscriber. Key-recovery techniques are designed to meet these emergency needs for access to encrypted information. Inherently, they provide a form of back door to the keys, but they also impose additional overhead costs. Thus, the need to provide key recovery should be balanced carefully against potential costs and complexity.

The two most popular forms of key-recovery mechanisms are:

1. Key escrow. Under this form, the subscriber's long-term private decryption key is provided to a trusted third party called a key recovery agent (KRA)
2. Key encapsulation. Under this form, the subscriber encrypts the data-encrypting key using the public key of the KRA so that the KRA can decrypt the data.

Of these two schemes, key escrow is becoming more widely available in the PKI products because it is simpler to implement at the infrastructure level. It is also independent of organization boundaries between the sender and receiver of encrypted communications. If a party's private date-encryption key is escrowed, than communications to the party can be decrypted.

Subscribers may always recover their own data-encryption key from the key-recovery system. Authorized third parties, such as a subscriber's employer, also may request keys. Such an authorized party is called a key recovery requester (KRR). All of the components are governed by a key recovery policy (KRP) and associated key recovery practices statement (KRPS). The KRP and KRPS are akin to the Certificate Policy and Certification Practice Statement but have some differences. One of the main differences is in the technical security-controls sections. There are several requirements to check the communication protocols among the components to ensure confidentiality, integrity, and authorization. Exhibit 37.13 illustrates the components of a key-recovery system, as would be expressed in the KPRS.

A general criticism of key recovery is that it provides secrets to a single party, namely a KRA. One way to mitigate that concern is to share the secret among multiple recipients in a way that requires cooperation (if it is authorized) or collusion (if it is not) among two or more holders of the escrowed secret. For example, superencryption (encryption of ciphertext) can make unauthorized discovery of a key more difficult. The secret key S is encrypted with one recipient's public key (say, K₁ ), producing a ciphertext, represented as E(S, K₁ ), and then that ciphertext is super-encrypted using a second recipient's public key, K₂ to produce the ciphertext E(E(S, K₁ ), K₂). Unlike encryption of the same message for two recipients, where each recipient can decrypt the ciphertext independently, superencryption requires decryption by each recipient in the reverse order of priority. Thus, if a user encrypts a secret key using A's public key and then superencrypts the ciphertext using B's public key, key recovery requires decryption by B using the corresponding private key and then decryption of the resulting ciphertext by A with that user's private key.

EXHIBIT 37.13 Elements of a Key Recovery Policy

To use superencryption so that fewer than all recipients may decrypt the key, the sender encrypts to a first group of recipients and then superencrypts to a second group of recipients. Thus, any one of the members of the first group and any member of the second group of recipients can cooperate to decrypt the secret key.

This technique allows key escrow even in the absence of a formal PKI, such as in informal webs of trust using PGP.

Another solution to making collusion more difficult in key escrow is to split the key using Shamir's n out of m rule.¹² In a properly implemented key-splitting scheme, parts of a secret key are distributed to m destinations and at least n recipients are required to reconstitute the secret key. Thus, n−1 or fewer persons colluding together cannot determine even a single bit of the escrowed key. Successful collusion requires at least n individuals. The split-key approach can be applied to key escrow, in which case the private key can be split and different splits can be provided to different KRAs. Alternatively, the split-key approach may be applied to encapsulation, where the session key can be split, and different splits can be encrypted using public keys of different KRAs.

This strategy also theoretically allows full reconstitution of the secret key to be performed by the authorized recipient of the partial keys, instead of by any of the escrow agents.

37.10 PRIVILEGE MANAGEMENT.

The primary purpose of PKI is to provide entity authentication in a global, distributed environment. In most systems and applications, authentication becomes the basis for access control. There are three fundamental ways to implement access control:

1. The systems and applications can perform access control on their own. The PKI continues to provide the authentication framework.
2. The privileges, attributes, roles, rights, and authorizations can be carried in a public key certificate in the subject directory attribute extension.
3. The privileges, attributes, roles, rights, and authorizations can be carried in an attribute certificate. The X.509 standard is being revised to include the concept of attribute certificates. The attribute certificates carry privileges and authorizations instead of the public key, and thus provide a distributed authorization framework.

EXHIBIT 37.14 Privilege Management

User login, signing, and encryption certificates should never be used to carry authorizations or application information. Where needed, separate certificates can be issued for those tasks. Such authorization certificates can be issued daily, or even for shorter periods, eliminating the need for a CRL since the certificate would expire before one would be issued. These authorization certificates could be used in place of Kerberos (the Greek mythological three-headed dog that guards the entrance to Hades) Tickets. Exhibit 37.14 summarizes the pros and cons of each of the three approaches.

These factors should be considered when architecting an access infrastructure. Although the attribute certificate seems to be the latest fad in the PKI world, users should carefully study putting privileges in public key certificates to save the cost of implementing a Privilege Management Infrastructure (PMI) over and above the cost of PKI.

37.11 TRUSTED ARCHIVAL SERVICES AND TRUSTED TIME STAMPS.

PKI technology supports global electronic commerce through the use of digital signature technology. Digital signature technology is a detection or passive mechanism. In other words, the technology does not prevent someone from modifying data in storage or in transit, nor from impersonating someone else. The technology merely detects that an attempt had been made to modify the data or that someone had tried to impersonate someone else.

In a court of law, digital signatures may be disputed long after they were applied, if, for example, the cryptanalysis threat period for the keys has expired. In those circumstances, producing a document with a verified digital signature may not prevent repudiation. A party could claim that the cryptanalysis threat period has passed and the private key might have been discovered or broken by an adversary.

To mitigate both of these threats—data corruption and expiry of the cryptanalysis threat period—trusted archival services are required for transactions with a potential for this kind of dispute. Such an archival service also would be able to safeguard associated certificates and CRLs. Trusted archival services should depend on controls such as physical security, stable media (e.g., write-once read-many (WORM) devices), and appropriate techniques to maintain readability despite changing technologies. Such services should be capable of error-free transcription of data on older media and of translating outdated encoding into more modern media, and into current encoding schemes. For example, Extended Binary Coded Decimal Interchange Code (EBCDIC)-encoded data on nine-track magnetic tapes could be copied onto optical disks using ASCII encoding.

A related technology is the trusted time stamp, where a trusted third party attaches the current valid time to a document and signs it to prove the existence of the document at a given time. If the document owner does not want to reveal the contents of the document to the time stamp server, then a hash of the document may be stamped and signed instead.

In most applications, a trusted archival service may obviate the need for trusted time stamp service because, for the long term, the trusted archival service can attest to the time of the transaction. For the short term, both parties can date and digitally sign the transaction when it is consummated, rendering it valid as a contract. If the date is not acceptable to any party—it is either too far in the future or in the past—that party can either reject the transaction or invoke some dispute-resolution procedure immediately.

37.12 COST OF PUBLIC KEY INFRASTRUCTURE.

One of the misconceptions about Public Key Infrastructure technology is that it is too costly, but these costs should be compared to the alternatives.

Short of taking a major risk, there is no practical technology other than cryptography to protect data in transit over untrusted network. The only choice, then, is between symmetric key cryptography and public key cryptography. Aside from the difficulties of distributing and supporting symmetric, secret keys, such cryptosystems require approximately n² keys for a group of n individuals who must communicate with each other.

A secret key cryptosystem requires n² keys to be kept confidential, with their integrity maintained; PKI requires managing only n keys. Clearly, it should be cheaper to maintain the integrity of n keys than to manage n² keys and their confidentiality and integrity. PKI is needed to manage the public keys.

PKI costs seem large when they must provide global trust and interoperability, something not asked of most systems or infrastructures. Currently no other technology works as well or is as cost effective as PKI to achieve global, secure, trusted communication and electronic commerce. The alternative is to assume the risk without PKI, or to continue with the last century's approach of paper-based trust.

37.13 FURTHER READING

Adams, C., S. Lloyd, and S. Kent. Understanding the Public-Key Infrastructure, 2nd edition. Upper Saddle River, NJ: Addison-Wesley Professional, 2002.

Atzeni, A. S., and A. Lioy, eds. Public Key Infrastructure, Third European PKI Work-shop: Theory and Practice, EuroPKI 2006, Turin, Italy, June 19–20, 2006. Proceedings. New York: Springer, 2006.

Austin, T. PKI: A Wiley Technical Brief. New York: John Wiley & Sons, 2000.

Australian Government Public Key Infrastructure; see: www.govonline.gov.au/projects/publickey/index.asp.

Baltimore Technologies Learning Center. Introduction to PKI; see: www.baltimore.com/library/pki.

Certipath Certificate Policies: www.certipath.com/library/downloads/CertiPath%20CP.pdf.

Chadwick, D., and G. Zhao, eds. Public Key Infrastructure. Second European PKI Workshop: Research and Applications, EuroPKI 2005, Canterbury, UK, June 30–July 1, 2005. Revised Selected Papers. New York: Springer, 2005.

Desmedt, Y. G., ed. Secure Public Key Infrastructure: Standards, PGP and Beyond. New York: Springer, 2008.

ECA Certificate Policies: http://iase.disa.mil/pki/eca/documents.html.

Ford, W., and M. S. Baum. Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption. Upper Saddle River, NJ: Prentice-Hall, 1997.

Housley, R., and T. Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. New York: John Wiley & Sons, 2001.

Howes, T., et al. Understanding and Deploying LDAP Directory Services. New York: Macmillan, 2002.

IETF Public Key Infrastructure (X.509) charter; see: www.ietf.org/html.charters/pkixcharter.html.

Lopez, J., P. Samarati, and J. L. Ferrer, eds. Public Key Infrastructure: Fourth European PKI Workshop: Theory and Practice, EuroPKI 2007, Palma de Mallorca, Spain, June 28–30, 2007. Proceedings. New York: Springer, 2007.

Menezes, A., P. van Oorschot, and S. Vanstone. Handbook of Applied Cryptography. Boca Raton, FL: CRC Press, 1996.

Level of Trust in E-Authentication Guide OMB M-04-04: www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf

Sabo, J. T., and Y. A. Dzambasow. “PKI Policy in the Business Environment,” SC Magazine Asia (June 2002), http://scmagazine.com/asia/news/article/419807/pkipolicy-business-environment/.

Vacca, J. R. Public Key Infrastructure: Building Trusted Applications and Web Services. Boca Raton, FL: Auerbach, 2004.

37.14 NOTES