19.6 CONCLUSIONS

Team-Fly

In this chapter, we elaborated on PKI considerations for the Internet. More specifically, we overviewed and discussed the state of the art related to public key and attribute certificates. There exist a number of standards and standardized procedures to issue, manage, and possibly revoke certificates. This is particularly true for public key certificates, but is also becoming true for attribute certificates. With regard to attribute certificates, however, most security protocols must be modified to make use of them. For example, the SSL and TLS protocols are able to handle public key certificates to address authentication and key exchange; they are not yet able to handle attribute certificates to address authorization. Nevertheless, it would be convenient to have an SSL/TLS client submit a list of relevant attribute certificates to access an intranet server. To make this happen, the SSL and TLS protocols must be extended and the extended protocols must be implemented and deployed. Consequently, there is still a long way to go until we will see attribute certificates deployed in practice.

Because of the steadily increasing role of authorization (in addition to authentication), the term PKI is currently being replaced with one of the following terms:

Privilege management infrastructure (PMI);
Authentication and authorization infrastructure (AAI).

It is possible and very likely that such a term will become a new buzzword in the future. In either case, the long-term goal of security professionals is to design, implement, and deploy PMIs or AAIs that are both sufficiently secure and scalable to the size of the Internet (or at least to the size of large corporate intranets).

The role of a PKI and some alternative technologies to address authentication and authorization are being reconsidered in a new branch of research that is collectively referred to as "trust management." Trust management is a rather artificial term, and its use is greatly overblown in the PKI arena. In fact, there is a large body of literature that addresses trust management and various aspects thereof [31–37].

Following the line of arguments introduced in [38] and further explored in Chapter 21, one may also argue that trust management is not particularly important and that all that matters is risk management:

"Trust management is surely exciting, but like most exciting ideas it is unimportant. What is important is risk management, the sister, the dual of trust management. And because risk management makes money, it drives the security world from here on out."

To clarify the point, we consider the situation in which a customer wants to order some goods from an on-line merchant. In this situation, there are two possible questions a customer may ask:

Does he or she trust the merchant (to handle his or her order properly)?
Does he or she carry the risk of having the merchant not properly handling his or her order?

Obviously, the first question is related to trust management, whereas the second question is related to risk management. In many situations, it is much simpler and more efficient to elaborate on risks that it is to discuss trust. In fact, trust is difficult to address and even more difficult to quantify. In either case, however, it is important to note that trust and risks are not independent, and that the two things basically try to measure the same (or at least closely related) things. For example, if we trust something we usually mean that the risks involved using it are small. Similarly, if we assume high risks we usually do not trust something or somebody.

As of this writing, many companies and organizations face the problem of how to get the X.509v3 certificates they require for emerging technologies, such as IPsec, SSL/TLS, and S/MIME.^[15] In general, there are two possibilities:

The companies and organizations can establish a PKI of their own;
The companies and organizations can outsource certification services and buy corresponding X.509v3 certificates from one or several commercial certification service providers.

If a company or organization wants to establish a PKI of its own, it can use one of the many commercial PKI solutions and products that are available on the market. Examples include Entrust/PKI^[16] from Entrust Technologies or UniCERT^[17] from Baltimore Technologies. Refer to the trade press to get a more comprehensive and up-to-date overview about currently available PKI solutions and products.

If a company or organization wants to outsource certification services, it can buy corresponding X.509v3 certificates from one (or several) commercial certification service provider(s). Exemplary certification service providers are VeriSign, Inc.^[18] and Entrust.net.^[19] In fact, an increasingly large number of commercial certification service providers are offering their services to the general public. Again, this trend is strengthened by legislation initiatives for digital or electronic signatures.

In addition to the two possibilities mentioned, there is a whole range of intermediate possibilities. The general idea is to have the company or organization act as RA for its users and make use of a commercial certification service provider to actually issue certificates. This is interesting mainly because it is simple for the company or organization to register and authenticate its users, and also because almost everything can be batched from the certification service provider's point of view. A corresponding architecture was proposed in [39] and has been implemented and marketed in various offerings, such as VeriSign's OnSite Managed Trust Service.^[20]

A more critical word should be said about the overall cost of public key cryptography in general, and PKIs in particular. Note that one of the original claims of public key cryptography was to minimize the initiation cost of a secure communication path between parties that share no prior administrative relationship. It was assumed that this would be the major reason why public key cryptography would dominate electronic commerce applications in the first place. Note, however, that with no shared administrative structure to connect the parties, we must invent many things, such as certificate chaining, certificate revocation, and certificate directory services. In other words, we have to invent the very thing that public key cryptography claimed not to need, namely administrative overhead. This point was made by Aviel D. Rubin, Daniel Geer, and Marcus J. Ranum in [40]. In fact, they do not argue against public key cryptography in general, but they argue that much of the implied cost savings of public key cryptography over secret key cryptography is nothing more than an illusion. To further clarify the point, they argue that the sum of the cost for cryptographic-key issuance and the cost for cryptographic-key revocation is more or less constant (for both public key cryptography and secret key cryptography). Note that this argument is only an assertion and is not yet substantiated by any detailed analysis. Also note that much of the initial motivation for use of public key cryptography was not cost based, but rather security based. For example, the argument was made that there are many more vulnerabilities associated with schemes that make use of secret key cryptography only as compared with schemes that selectively make use of public key cryptography, especially when one crosses organization boundaries. Remember the discussion of the Kerberos authentication system, especially in the case of inter-realm authentication. In spite of the fact that the argument is not substantiated by any detailed analysis and that the initial motivation for the use of public key cryptography and corresponding PKIs was security (not costs), the argument should still be considered with care. Note, for example, the problems we face when we try to establish and operate a PKI today. Some of the problems are caused by the need to revoke certificates. This problem makes it necessary to have an on-line component permanently available for an otherwise off-line CA. Ideally, certificate revocation is handled by an on-line component that is physically or logically separated from the off-line CA [41].

Finally, it should be kept in mind that the widespread use of public key certificates that include (or are logically linked to) globally unique names, such as DNs, may also provide the means to build a worldwide tracking system for user transactions. If a user acquires multiple certificates, each of which contains a different subject name with only local significance, he or she will not be able to be tracked. If, however, he or she acquires only one certificate and this certificate is used for multiple (or all) applications, he or she can be tracked very easily. Consequently, the widespread use of a single certificate per person may also contradict his or her privacy requirements. Against this background, Stefan A. Brands developed a technological approach that can be used to replace X.509-based certificates [42]. The resulting certificates can be used to authenticate and authorize their owners; they do not, however, reveal any information that is not necessary to the certificate verifier. This is an example of a privacy enhancing technology (PET), and it is possible and very likely that we will see similar PETs being developed and deployed in the future. You may refer to Chapter 13 of [1] for an overview about PETs for Internet messaging and the WWW.

^[15]Refer to Part II of this book if these acronyms do not mean anything to you.

^[16]http://www.entrust.com/entrust/

^[17]http://www.baltimore.com/products/unicert/

^[18]http://www.verisign.com

^[19]http://www.entrust.net

^[20]http://www.verisign.com/products/onsite/

Team-Fly