Previous | Table of Contents | Next |
Currently, three major technologies are capable of providing electronic commerce services E-mail, the World Wide Web, and open EDI. Typical of advanced technologies, security elements are the last to be developed and yet are essential if these technologies are to be deemed trustworthy for electronic commerce.
The issues of confidentiality, confirmation of identity, time certainty, and legal protection apply to all these technologies. The solutions certification, key repositories, postmarking, return receipts, and storage and retrieval are equally applicable to each of these technologies. Although the state of universality and interoperability varies among these technologies, they are all in a relative state of immaturity.
Electronic messagings most classic manifestation is E-mail. Because of its capacity for handling attachments, E-mail can be used to transfer official business, financial, technical, and a variety of multimedia forms.
Both the Department of Defense standard for E-mail, which is based on the ITUs X.400 standard for E-mail (called the Defense Message System or DMS), and the Internet E-mail standard, the simple mail transfer protocol (SMTP), have made provisions for security. The DMS uses encapsulation techniques at several security levels to encrypt and sign E-mail messages. The security standard for the Internet is called Privacy Enhanced Mail (PEM). Both methods rely on a certificate hierarchy and known and trusted infrastructure. Neither method is fully developed.
The phenomenal growth of the Web makes it a prime candidate for the dissemination of forms and documents. Organizations see the Web as a prime tool for services such as delivery of applications and requests for information. However, Web technology has two competing types of security: one at the application layer that secures hypertext transfer protocol (HTTP) formatted data (known as SHTTP), and one at the socket layer that encrypts data in the format in which it is transported across the network.
In addition, vendors do not yet support either client-side authentication or the use of X.509 certificates. Although software for such activities as client authentication can be developed relatively quickly, vendors have to be convinced that there is a real market for such products. This technology is about to emerge and, although it will emerge first to support Web applications, it will also speed the development of E-mail and EDI security services.
Until now, EDI has been used in closed, value-added networks where security and integrity can be closely controlled. Signing and encryption have been proprietary to the EDI product in use or to the value-added EDI network provider.
By contrast, open EDI, running across open networks, requires adherence to the standards that are still being developed and a yet-to-be-developed infrastructure that can ensure trusted keys. To date, the various schemes to accelerate the use of open systems for EDI have not captured the imagination of EDI users and providers.
The suite of services and technologies described in this chapter depend on trusted public keys and their bindings to users. Users could be completely assured of the integrity of keys and their bindings if they were exchanged manually. Because business is conducted on a national and international scale, users have to be assured of the integrity of the registration authority and the key repository in an inevitably complex, electronic way.
One as-yet-unresolved issue is whether such an authority or authorities should be centralized and hierarchical or distributed. The centralized, hierarchical scheme would mean that certification authorities (and purveyors of the accompanying services) would be certified by a higher authority that, in turn, might be certified by yet a higher authority and so on to the root authority. This kind certification would create a known chain of trust from the highest to the closest certification authority. This scheme is often referred to as the Public Key Infrastructure (PKI).
The alternative assumes that the market will foster the creation of a variety of specialized certification authorities to serve communities of interest. A complicated method of cross-referencing and maintaining those cross-references in the certificate repository for each community of interest would then develop.
The outcome of this debate is likely to result in a combination of both methods, such as several hierarchies with some kind of managed cross-referencing to enable public key exchanges between disparate communities of interest when required. Following are some of the issues yet to be resolved:
Groups such as the Internet Engineering Task Force (IETF), the Federal Government Public Key Infrastructure (PKI) users group, and even the American Bar Association are tackling these knotty issues.
In fact, with toolkits now available that allow the user to become his or her own certificate authority, everyone can get into the act. Private companies such as VeriSign are establishing themselves as certification authorities so that users will give their public keys and certificates credence. The National Security Agency wants to become the certificate authority for the U.S. federal government. The U.S. Postal Service is intent on offering electronic commerce services to businesses and residences by acting as the certificate authority and provider.
An infrastructure will emerge, and it will probably work for users very similar to the way that it has been described in this chapter.
Previous | Table of Contents | Next |