Public Key Infrastructure Overview

Download Article  in PDF Format

Complex business systems, e-commerce and automated business transactions require robust and rigorous security measures. Companies using the Internet environment as a platform to conduct business have a better probability of success if they accommodate the needs of security-conscious clientele. Today's Internet clientele demand stringent security protocols to protect their interests, privacy, communication, value exchange, and information assets. This article demonstrates how public key cryptography supports these risk management requirements and solves e-commerce security problems in heterogeneous network environments.

Public key cryptography supports security mechanisms such as confidentiality, integrity, authentication, and non-repudiation. However, to successfully implement these security mechanisms, you must carefully plan an infrastructure to manage them. A public key infrastructure (PKI) is a foundation on which other applications, system, and network security components are built. A PKI is an essential component of an overall security strategy that must work in concert with other security mechanisms, business practices, and risk management efforts.

PKI is a broad subject matter and is constantly evolving to meet the growing demands of the business world. This article addresses PKI at a relatively high-level and does not include details regarding the underlying cryptography.

This article is intended to remove the mystery, fear, and misconceptions of PKI, and offer real world opportunities for its use. Additionally, this article presents business-level reasons for considering a PKI in various environments, and the business problems a PKI can solve. This article is also intended to help organizations determine their requirements and necessity for a PKI, and what features they need for their particular business. This article should be considered as a PKI planning guide.
 
 

Why Implement a PKI?

An illustration presents the point. If a merchant today has a physical presence at a store, that is, brick and mortar, and customers patronize them for goods and services, the merchant will typically request and receive payment for these directly from either the customers or their agent (e.g., their bank via the presentation of a monetary instrument such as a check), at the time that the goods and services were bargained for and/or provided. The process of exchanging goods and services for value is almost as universal as the rules by which those conversions take place. In many cases those rules are codified, in others they reflect accepted custom.

Whether systematic or custom, the processes in use today provide for the establishment of a trusted business relationship in that the customer and merchant both authenticate one another to the extent that they are willing to undertake the transaction. If an easily recognized monetary instrument like cash is used for transactions, there may be very little authentication which must occur. If a credit card or check is used, then the authentication may include the establishment of the customer's identity to the merchant. In addition, the authentication may also allow for a measure of non-repudiation to be set so that the customer does not deny the transaction occurred.

This traditional face-to-face transaction requires only minimal interaction and normally does not necessitate the use of other security and integrity mechanisms. 

However, for e-commerce on the Internet, additional security and integrity mechanisms become necessary. Merchants are typically not willing to ship goods or perform services until a payment has been accepted for them. In addition, authentication can allow for a measure of non-repudiation so the customer cannot deny the transaction occurred. Similarly, consumers need assurance that they are purchasing from a legitimate enterprise, rather than a hacker's site whose sole purpose is to collect credit card numbers.

With the changes in today's business environments and the shift from the traditional face-to-face business models, mechanisms must be developed to ensure that trusted relationships are maintained and can flourish.

The implementation of a PKI is intended to provide mechanisms to ensure trusted relationships are established and maintained. The specific security functions in which a PKI can provide foundation are confidentiality, integrity, non-repudiation, and authentication.
 
 

Uses of PKI

A PKI has many uses and applications. As discussed later in this article, a PKI enables the basic security services for such varied systems as:

• SSL, IPsec and HTTPS for communication and transactional security
• S/MIME and PGP for email security
• SET for value exchange
• Identrus for B2B

• Reduces transactional processing expenses
• Reduces and compartmentalizes risk
• Enhances efficiency and performance of systems and networks
• Reduces the complexity of security systems with binary symmetrical methods

• Student IDs on college campuses
• Voting
• Anonymous value exchange
• Transit ticketing
• Identification (passports and drivers licenses)
• Notarization (contract, emails, etc.)
• Software distribution
• Symmetric key management

Challenges

It is important to understand that a PKI is not by itself an authentication, authorization, auditing, privacy, or integrity mechanism. Rather, a PKI is an enabling infrastructure that supports these various business and technical needs. In particular, a PKI only allows for the identification of entities. For example, a PKI does not infer trust by itself, but requires the establishment of a trust base, on which the PKI can rely. This requirement means that the basis of trust must be established on a personal, business, or other level, before it can be accepted by the PKI.

A real world example of this is, suppose you misplace your drivers license and are issued a temporary one which does not have your photograph. A temporary license without a picture does not allow a store clerk to determine if you are the owner of it. Therefore, you may not be able to write a check or use a credit card because your identification mechanism, the temporary license, is not acceptable. This indicates that the trust inferred by identification is a rather subjective matter.

The issue of trust often arises when designing a PKI. From an e-commerce standpoint, a notable predicament of remote business transactions is that of original entity authentication. How an organization identifies and authenticates a customer or entity remotely the first time is a difficult problem. The amount of risk that an organization is willing to endure determines the level of effort they must expend during initial authentication. If high-value transactions or transactions with significant legal consequences occur in your organization, a stringent set of tests should be satisfied for a customer or entity to authenticate their identity. Conversely, if there is little risk to issue certificates to entities, for example, userids to access a public Web site, then those tests may be more simple. In any case, the original entity authentication can occur offline and out of band when more stringent means are needed, or dynamically and online for those needing less robust methods. The original entity authentication or initializing problem is not solved directly by a PKI, but must be addressed operationally in each unique business environment.

In the e-commerce environment, this problem is magnified when organizations move from local to regional and then extra-regional environments. How does a clerk in Denmark determine if a driver's license, temporary or otherwise, is legitimate if it was issued in Japan? How do they determine if they should trust the credentials presented? What mechanism do they use to make that determination? How did the original authority, which issues the credentials, determine the identity of the requestor? Do you trust the original authority to perform its identification tests properly? These are all fundamental issues that a PKI must contend with. 

With the rapid expansion of e-commerce, closed proprietary legacy systems that only support binary transactional relationships are giving way to more open Internet-based systems, that support remote, many-to-many relationships. Different threats exist in these two very different business models and thus different security functions must be employed to address them. Prior to considering how a PKI can support your business venture into e-commerce, you must identify and evaluate your business requirements for the different security mechanisms that a PKI can enable. You must also identify the specific threats that exist in your environment.
 
 

Planning a PKI Infrastructure

Defining Business Requirements

On the other hand, if a business is selling products or services over the Internet, implementing a PKI may be in order. For an e-commerce business, the following must be accounted for when planning a PKI:

• Integrity for the posted prices
• Identification and authentication for a potentially large population of customers
• Confidentiality of customer and transaction information
• Non-repudiation for supporting dispute resolution

Other considerations for defining business requirements of a PKI include:

• Careful planning ­ Internet-based e-commerce business solutions are often complex, as are the PKI solutions necessary to support them. Take the time to perform a detailed evaluation of your business and technical environments before taking steps to implement a PKI.

 

 

• Interoperability ­ Does your current business model require interoperability? With whom? For what purpose? If your PKI requires interoperability, you should determine which of the different standards and protocols you must adhere. Tangentially, most PKI related standards are in the early stages of development and acceptance. ISO, ANSI, IETF, IEEE, and PKCS are a few examples of standards under development for PKI. Because of the competing standards and protocols and the various interpretations that different vendors have of these, it is critical that organizations determine their interoperability needs.

 

 

• Determining a PKI system and vendor ­ There are different PKI and cryptographic systems from competing vendors. Several different protocols, certificate formats, and platforms exist. Some investigation is needed to decide which PKI and vendor is the best for your particular business enterprise. Often a standards compliant solution from one vendor will not integrate with that of another vendor. This may cause problems if you consider a multi-vendor PKI solution.

 

 

• Performance and capacity ­ In situations where large amounts of data must be enciphered for confidentiality, public key cryptography may not be suitable because the cryptographic algorithms perform at relatively slow speeds. Symmetric or secret key cryptography is typically used for these applications. Key management is where public key cryptography plays a role in supporting the encryption of large amounts of data for confidentiality. A PKI can be established for the distribution of the symmetric or secret keys that are subsequently used for the encipherment of data. Public keys and public key certificates can also be significantly larger than symmetric keys and this can affect how they are stored. For example, in the limited memory constraints of a chip card, size can matter.

 

 

Structure and Components of a PKI

PKI Framework

A PKI enables the establishment of a trust hierarchy. This is one of the primary principles of a PKI. In Internet-based e-commerce, formal trust mechanisms must exist to provide risk management controls. The concept of trust, relative to a PKI, can be explained by the role of the CA. In the Internet environment, entities unknown to each other do not have sufficient trust established between them to perform business, contractual, legal, or other types of transactions. The implementation of a PKI using a CA provides this trust.

In short, a CA functions as follows. Entities that are unknown to one another, each individually establish a trust relationship with a CA. The CA performs some level of entity authentication, according to its established rules as noted in its Certificate Practices Statement or CPS, and then issues each individual a digital certificate. That certificate is signed by the CA and thus vouches for the identity of the individuals. Unknown individuals can now use their certificates to establish trust between them because they trust the CA to have performed an appropriate entity authentication, and the CA's signing of the certificates attests to this fact. A major benefit of a PKI is the establishment of a trust hierarchy because this scales well in heterogeneous network environments.
 
 

Trust Models

Hierarchical

For example, in the financial services world, rather than have a single authority sign all end entities' certificates, there may be one CA at a national level that signs the certificates of particular financial institutions. Then each institution would itself be a CA that signs the certificates of their individual account holders. Within a hierarchical trust model there is a trust point for each certificate issued. In this case, the trust point for the financial institution's certificate is the national or root CA. The trust point for an individual account holder is their institution's CA. This approach allows for an extensible, efficient, and scalable PKI.

There are trade-offs to be considered when determining the placement of trust points for end entities in a PKI. In a tiered hierarchy with multiple CAs, compartmentalization of risk can be established, but each CA multiplies the administrative effort necessary to maintain the entire hierarchy. Conversely, a flat hierarchy with a single CA is much easier to administer; however, a failure of that single CA will corrupt the entire trust model and potentially all certificates signed by it.
 
 

Distributed (Web of Trust)

Direct (Peer to Peer)

Cross Certification

When a cross-certificate is issued, it extends the trust relationship of a CA. A relying entity, for example, may desire to validate the public key certificate of an end entity whose signing CA's public key it is not aware of. Assuming that the relying entity trusts its own CA, when it sees a cross-certificate signed by that CA, it will then also trust that other CA, and subsequent certificates signed by it.

The net effect of cross certification is to allow many PKI deployments to be both extensible and scalable.
 
 

Security Services

Confidentiality

Integrity

Authentication

Non-Repudiation

PKI Logical Components

• End entities or subscribers
• Certificate authorities
• Certificate policies
• Certificate practices statement
• Hardware security modules
• Public key certificates
• Certificate extensions
• Registration authorities
• Certificate depositories

End Entities or Subscribers

Certificate Authorities

To elaborate, a CA functions as a trusted third party and provides various key management services. A CA essentially certifies the identity of an end entity. This is accomplished by an entity providing sufficient proof of their identity to the CA, and then having the CA generate a message containing the entity's identity and public key. This message is called a certificate and is cryptographically signed by the CA. The level of trust that a CA has depends on the level of acceptance that other entities have in that CA. This level of acceptance depends on the policies and procedures the CA has established to ascertain the user's identity.

A CA's public keys must be distributed to all entities that trust the CA's certificates. If a CA is a Root CA, that is, at the top of the trust hierarchy and has no superior CA to vouch for it, then the CA must distribute its public keys as self-signed certificates with an acceptable key certificate format and distribution protocol. The CA must also make its cleartext public keys available, so that relying entities can resolve the self-signed certificates. The key management-related functions performed by a CA are:

• Certificate generation
• Certificate revocation

Certificate Policy

Each PKI implementation should reflect the following in a CP statement:

• Purpose of the PKI
• Specific business requirements the PKI addresses through: 
• Security architecture
• Associated trust model and threat profile 
• Specific security services the PKI supports

Certificate Practices Statement

Hardware Security Modules

Public Key Certificates

The most widely used format for digital certificates are those based on the IETF X.509 standards. A detailed semantic profile of X.509 based public key certificates can be found in the IETF RFC 2459 and related documentation. It should be noted that there is no one single definition of a public key certificate defined in the IETF standards. Vendors, integrators, and others offering PKI solutions each have their own ideas as to what extensions and particular data an X.509 certificate should contain. Organizations should evaluate their business needs relative to the constructs of the public key certificates that they wish to issue.
 
 

Certificate Extensions

Registration Authorities

Certificate Depositories

Certificate distribution can be accomplished by simply publishing certificates in a directory controlled by a CA or RA. When the directory is controlled by the CA or RA, the certificate distribution process is greatly simplified. Rather than trying to distribute every certificate to a unique point, the CA simply updates the directory. A critical factor is that only the CA must have the authority to update or modify the directory, but the directory must be publicly readable.

LDAP is a good example of a simple and efficient standards based directory format and protocol that can be used for certificate distribution. In particular, LDAP is optimized for easy read access by thin clients that are a necessity in many PKI implementations. Because LDAP defines an API for the application layer used by different clients, users realize a level of scalability and portability, and do not have to contend with the upper layers of the stack. This API also makes it easier for different applications to quickly implement LDAP.

Although LDAP is becoming a de facto standard for certificate distribution, organizations that need an even more robust certificate depository can consider alternatives such as X.500.
 
 

PKI Functions

• Public key cryptography ­ Includes the generation, distribution, administration, and control of cryptographic keys.

 

 

• Certificate issuance ­ Binds a public-key to an individual, organization, or other entity, or to some other data-for example, an email or purchase order.

 

 

• Certificate validation ­ Verifies that a trust relationship or binding exists and that a certificate is still valid for specific operations.

 

 

• Certificate revocation ­ Cancels a previously issued certificate and either publishes the cancellation to a Certificate Revocation List or enables an Online Certificate Status Protocol process.

 

 

Public Key Cryptography

Because of its widespread use in e-commerce, this article focuses on the RSA (named for its creators: Rivest, Shamir and Adleman) public key cryptographic system. RSA is a public key cryptographic algorithm that is based on the hard mathematical problem of factoring composite numbers. The keys used by the RSA crypto-system are based on the product of two large prime numbers that derive their cryptographic strength from the fact that it is difficult to factor large composite numbers of this kind. RSA uses a pair of keys: a public key which is made known to many entities, and a private key for which secrecy and integrity are strictly controlled and only used by the owner of that key. Given an appropriate key length, it is computationally infeasible to determine one key from another. The basic cryptographic feature of RSA is that it allows the encryption of clear text data with one key but decryption with the other. This basic cryptographic feature is what provides RSA its asymmetry.

RSA performs the generation of a public/private key pair as follows:

Two large primes, p and q are used to compute their product n = pq, where n is called the modulus. A number is chosen, e, which is less than n and relatively prime to (p-1)(q-1), which means e and (p-1)(q-1) have no common factors except 1. Another number is chosen, d, such that (ed - 1) is divisible by (p-1)(q-1). This is the inverse of e and means that ed = 1 mod (p-1)(q-1).

The values e and d are called the public and private exponents, respectively. The public key is the pair (n, e) and the private key is (d).

RSA supports two basic modes of operation: encryption and digital signatures. These are outlined in the following sections.
 
 

Key strength

• To prevent their potential compromise, keys must be replaced prior to the time feasible to determine them through cryptanalysis.

 

 

• A key must be replaced by a new key within the time feasible to perform a successful dictionary or brute force attack on the old key.

 

 

• A key must not be used to ensure the security or integrity of data where it is feasible to determine that key in a period of time less than the useful life of that data.

 

 

Encryption

RSA encipherment is performed as follows:

Where m is the message to be enciphered and c is the resultant ciphertext.

The specific operation performed is the exponentiation of m^e mod n, where e and n are the public key of the recipient of the ciphertext.

The recovery of the ciphertext by the recipient occurs as follows:

The specific operation performed is the exponentiation of c^d mod n where d and n are the recipients private key.
 
 

Digital Signatures

An RSA digital signature is performed as follows:

Where m is the message and s the resultant digital signature.

The specific operation performed is the exponentiation of m^d mod n where d and n are the sender's (of the message) private key.

The authentication of the digital signature by the recipient occurs as follows:

The specific operation performed is the exponentiation of s^e mod n where e and n are the sender's public key.
 
 

Hash Functions

SHA-1 is a one-way hash function that takes an arbitrary length message, processes it, and returns a fixed length, 20 byte value. A secret key is not used. The primary characteristic of SHA-1 is that it provides a mechanism that makes it easy to compute a hash from some data, but difficult to determine any data from a computed hash value. 

There are two important security properties of SHA-1:

• SHA-1 is one-way, given SHA-1(x) it is difficult to find x.

 

 

• SHA-1 is collision-resistant, given it is hard to find x,y with x  y satisfying:

SHA-1(x)=SHA-1(y).
 
 

Symmetric Key Encryption

The fundamental characteristics of symmetric cryptographic systems used with PKI are that the same key is used for both encryption and decryption. Because of this symmetry the key must be kept secret and shared only between two parties.
 
 

Key Separation

Public Key Certificate Binding

Entity Authentication

If there is little negative consequence to the issuance and use of a certificate, for example, renting movies from a video store, there may be only a simple entity authentication process. Conversely, the issuance of a certificate for use by a passport agency may be more robust if that is a nation's first line of defense against cyber-terrorists. As a simple matter, if an organization is attempting to replicate an existing manual process that requires some form of identity validation, for example, to open a savings account at a bank, they should replicate the same process they use today. The process may be automated or manual but the credentials required and the due diligence verification processes should be the same or equivalent.

Note that the information and credentials requested and the enrollment process which a CA or RA uses must be reflected in its published CPS.
 
 

Certificate Generation

• Acquire a public key from the end entity.

 

 

• Verify the identity of the end entity.

 

 

• Determine the attributes needed for this certificate, if any.

 

 

• Format the certificate.

 

 

• Digitally sign the certificate data.

 

 

Acquiring the Public Key

Verify the Identity of the End Entity

Formatting the Certificate

Signing the Certificate

Certificate Validation

An Example of a PKI in Action

Precursor Steps

1. Alice and Bob each generate a public/private key pair.

 

 

2. Alice and Bob each provide their public keys, name, and descriptive information to an RA.

 

 

3. The RA validates their credentials and forwards the certificate requests to the CA.

 

 

4. The CA generates a certificate for Alice and Bob's public keys by formatting their public keys and other information, and then signs the certificate with the CA's private keys.

 

 

5. The results of this operation are that Alice and Bob each have a public/private key pair and a public key certificate.

 

 

6. Alice and Bob each generate a secret symmetric key.

 

 

Suppose now that Alice wishes to send Bob some data that he will rely upon and thus requires an assurance of integrity; that is, the content of the message cannot be altered. Alice and Bob also want the assurance of confidentiality and want no other parties to be able to view the information. A contract for goods and services where parties agree upon price, time, and value exchange is a good example of such a process. The steps taken to perform the transaction are as follows.

In this example, steps 1-5 involve Alice sending data that needs confidentiality and integrity to Bob, using a digital signature. Steps 6-10 involve Bob decrypting the data.

1. Alice takes the message in question, formats it according to the protocol rules she and Bob have agreed to and then hashes the message. The hash provides a unique value for the message and will later be used by Bob to test the validity and integrity of the message.

 

 

2. Alice concatenates the message and the hash and then signs (i.e., encrypts) these with her private key. This signing provides message integrity because Bob is assured that only Alice could have generated the signature because only Alice has access to the private key used to sign the message. Note that anyone with access to Alice's public key can recover the signed message and so, we have only established message integrity at this point, but not confidentiality.

 

 

3. Because Alice and Bob would like to keep the message confidential, Alice encrypts the signed message and hash with her secret symmetric key. This key is only shared between Alice and Bob and no one else. Note that enabling confidentiality can be implemented through various techniques and protocols. In this example, a symmetric key is used because it can be more efficient than using a public key for encrypting lengthy messages such as the purchase order here.

 

 

4. Alice must provide Bob with her secret symmetric key to enable Bob to decrypt the message encrypted with that key. Alice signs (i.e., encrypts) her secret symmetric key using Bob's public key. For this example, we assume Alice obtained Bob's public key previously. This generates what is known as a digital envelope and which only Bob can recover (i.e., decrypt) because only Bob has access to the private key that is needed to recover the digital envelope. Remember, what is done with one key of a pair can only be undone with the other key of the pair. This provides confidentiality over the transmission of Alice's secret symmetric key to Bob.

 

 

5. Alice forwards to Bob the original message and the hash that are both encrypted with her secret symmetric key and the digital envelope containing the secret key encrypted with Bob's public key.

 

 
 

FIGURE 1 illustrates Alice using a digital signature to send data to Bob (steps 1-5).


6. Bob takes the digital envelope he received from Alice and recovers (i.e., decrypts) it with his private key. The results of performing this operation provide Bob with the secret symmetric key that Alice previously used to encrypt the message and the hash of the message.

 

 

7. Bob can now recover (i.e., decrypt) the encrypted message and hash using Alice's secret symmetric key. Bob now has the signed cleartext message and the signed hash of it.

 

 

8. Bob now recovers (i.e., decrypts) the signed message and hash of the message by using Alice's public key. Remember, what is done with one key of a pair can only be undone with the other key of the pair.

 

 

9. To ensure that no modifications have been made to the message, Bob takes the original message and hashes it using the exact same process that Alice used originally.

 

 

10. Finally, Bob compares the hash he has just produced with the hash he recovered from the original message. If they match he is assured of the message's integrity.

 

 
 

FIGURE 2 illustrates Bob decrypting the data and comparing hashes (steps 6-10).

 
 

Certificate Revocation

Although public key certificates are issued for a fixed period of time before they become void, situations can arise where they are no longer trustworthy and thus must be prematurely expired. This is known as certificate revocation. There are many reasons that a certificate should be revoked. The private keys could be compromised, a user is no longer a customer, or there is a change in the information incorporated within a certificate that is used to determine its validity.

Certificate revocation must be initiated by the CA or their delegate such as an RA, which originated the end entity's certificate. The predominant vehicle for certificate revocation is known as a Certificate Revocation List or CRL. A CRL is a list generated by the CA that contains unique information about the revoked certificates which enables relying entities to determine if a certificate is valid or not. A CRL entry should be serialized, time-stamped, and signed by the CA. It is normally the relying entity's responsibility to retrieve the CRL.

A CRL must be published in a publicly available repository or directory. LDAP is the industry's current directory of choice and has been developed as an X.500 compliant protocol for the Internet. LDAP defines the directory query, data storage, and management protocols.

The timely publication of the CRL is critical in Internet and e-commerce environments. This timely publication is particularly critical during the latency period between when a CA revokes a certificate and its subsequent publication where there is a reliance upon the certificate for making critical decisions. If for example, a high-value transaction is being negotiated and a seller is relying on the CRL so they can make the decision to sell or not, a timely CRL publication cycle may be critical to them.

There are other types of CRLs such as, segmented-CRLs, delta-CRLs, and CRL-like mechanisms-for example, the Online Certificate Status Protocol (OCSP). OCSP is the most interesting because it can address the latency issue associated with standard CRL publication. OCSP is a mechanism that actually requests, in real time, a status check for a particular certificate from the originating CA. This has the benefit of not only being timely but in fact, reduces or eliminates the necessity for a CA to publish a CRL. The CRL simply waits for status check requests and responds to them as necessary.
 
 

Conclusion

PKI is a complex subject and still evolving in terms of its utilization in the commercial and e-commerce sectors. Although the underlying technology is quite sound, issues exist in areas such as interoperability and performance. Nonetheless, PKI offers considerable benefits to those in need of the basic security services described in this article.

Those considering a PKI should evaluate their environment to understand where they require basic security services and thus where a PKI would be most useful.

When progressing to a PKI, careful planning is critical. Start small with a pilot implementation. This will allow you to gain an understanding of the issues and also the operational, security, and practical aspects particular to your environment.

With the successful implementation of a pilot PKI and a clear understanding of focused goals and objectives, which can realistically be satisfied by a PKI, you can proceed to a more comprehensive implementation of a PKI.
 
 

Acronyms

• ANSI ­ American National Standards Institute

 

 

• B2B ­ Business to Business

 

 

• DES - Data Encryption Standard

 

 

• FIPS ­ Federal Information Processing Standard

 

 

• HTTPS ­ Secure Hypertext Transaction Protocol

 

 

• IEEE ­ Institute of Electrical and Electronic Engineers

 

 

• IETF ­ Internet Engineering Task Force

 

 

• IPsec ­ Secure Internet Protocol

 

 

• ISO ­ International Organization for Standardization

 

 

• PGP ­ Pretty Good Privacy

 

 

• PKCS ­ Public Key Cryptography Standards

 

 

• PKI - Public Key Infrastructure

 

 

• SET ­ Secure Electronic Transactions

 

 

• SHA-1: Secure Hash Standard

 

 

• S/MIME ­ Secure Multipurpose INternet Mail Extensions

 

 

• SSL ­ Secure Socket Layer

 

 

Bibliography

Carlisle Adams, Understanding Public-key Infrastructure, Macmillan Technical Publishing, November 1999

Tom Austin, PKI - A Wiley Tech Brief, Wiley, John & Sons Incorporated, December 2000

Arto Salomaa, Public-Key Cryptography, Springer-Verlag, Berlin, Heidelberg, 1990

Bruce Schneier, Applied Cryptography, Wiley, John & Sons, Incorporated, October 1995

Alfred Menezes, Handbook of Applied Cryptography, CRC Press, LLC, October 1996

PKI Practices and Policy Framework Draft, ANSI X9.79 standard

William Polk, Bridge Certification Authorities: Connecting B2B Public Key Infrastructures, 2000

Certificate Issuing and Management Components Protection Profile, 2001

Russell Housley, Internet Public Key Infrastructure, X509 Certificates and CRL Profile RFC 2459, 1999

S. Chokhani, Certificate Policy and Certification Practices Framework, RFC 2527


---

Author's Bio: Joel Weise

Joel Weise has worked in the field of data security for over 20 years. As a Senior Security Architect for Sun Professional Services, he designs system and application security solutions for a range of different enterprises from financial institutions to government agencies. He specializes in cryptography and public key infrastructures. Prior to joining Sun, Joel was a Senior Project Manager for Visa International. There he was responsible for developing cryptographic standards, designing key management and cryptographic systems and architecting security solutions for chipcard, Internet, and other new products.


 

---