EDIINT Functional Specification November 1996 EDIINT Working Group Chuck Shih Internet Draft Mats Jansson Expires: 05/97 Rik Drummond Lincoln Yarbrough Requirements for Inter-operable Internet EDI Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), unnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the EDIINT working group of the IETF, using the address . Requests to subscribe to the mailing list should be addressed to . Abstract This document is a functional specification, discussing the requirements for inter-operable EDI, with sufficient background material to give an explanation for the EDI community of the Internet, and security related issues. Feedback Instructions If you want to provide feedback on this draft, follow these guidelines: - Send feedback via e-mail to chucks@actracorp.com, with EDIINT Requirements in the subject field. - Be specific as to what section you are referring to, preferably quoting the portion that needs clarification or modification. Your comments would then follow the identified section. - If you are recommending some text be replaced with your suggested text, again, quote the section to be replaced, and be clear on how you think the text should read. - If you are questioning fundamental assumptions, make it clear what is being questioned and the editor will bring the issue to the EDIINT list for discussion. To follow the discussion, the reader needs to subscribe to the ietf-ediint@imc.org discussion list. Table of Contents 1.0 INTRODUCTION 4 1.1 THE AUDIENCE 4 2.0 THE INTERNET - A BRIEF HISTORY 5 2.1 THE INTERNET - MYTHS AND REALITY 6 2.2 INTERNET ROUTING AND SECURITY CONSIDERATIONS 7 2.3 EDI VAN COMMUNICATIONS AND SECURITY 8 3.0 FUNCTIONAL REQUIREMENTS 8 3.1 INTRODUCTION AND DEFINITIONS 8 3.2 STANDARD ENCRYPTION ALGORITHMS AND WORLD-WIDE ENCRYPTION 9 3.2.1 INTRODUCTION AND DESCRIPTION 9 3.2.2 SYMMETRIC ENCRYPTION 9 3.2.3 ASYMMETRIC ENCRYPTION - PUBLIC-KEY CRYPTOGRAPHY 9 3.2.4 NEEDS 10 3.2.5 ISSUES 10 3.2.6 RECOMMENDATIONS 10 3.3 KEY MANAGEMENT - SYMMETRIC KEYS 12 3.3.1 INTRODUCTION AND DESCRIPTION 12 3.3.2 NEEDS 13 3.3.3 ISSUES 14 3.3.4 RECOMMENDATIONS 14 3.4 KEY MANAGEMENT - PUBLIC AND PRIVATE KEYS 14 3.4.1 INTRODUCTION AND DESCRIPTION 14 3.4.2 PUBLIC KEYS 15 3.4.3 NEEDS 15 3.4.4 ISSUES 15 3.4.5 RECOMMENDATIONS 16 3.5 CONTENT INTEGRITY 16 3.5.1 INTRODUCTION AND DESCRIPTION 16 3.5.2 NEEDS 17 3.5.3 ISSUES 17 3.5.4 RECOMMENDATIONS 17 3.6 AUTHENTICATION AND NON-REPUDIATION OF ORIGIN 17 3.6.1 INTRODUCTION AND DESCRIPTION 18 3.6.2 NEEDS 18 3.6.4 RECOMMENDATIONS 19 3.7 SIGNED RECEIPT OR NON REPUDIATION OF 19 RECEIPT 3.7.1 INTRODUCTION AND DESCRIPTION 19 3.7.2 NEEDS 20 3.7.3 RECOMMENDATIONS 20 3.8 EDI OBJECT BOUNDARIES AND TRANSACTION PRIVACY 21 3.8.1 INTRODUCTION AND DESCRIPTION 21 3.8.2 GATEWAY FUNCTIONS 21 3.9 SYNTAX AND PROTOCOL FOR SPECIFYING CRYPTOGRAPHIC SERVICES 21 3.9.1 INTRODUCTION AND DESCRIPTION 21 3.9.2 NEEDS 21 3.9.3 ISSUES 21 3.9.4 RECOMMENDATIONS 22 4.0 TRACKING AND ERROR HANDLING BASICS 22 4.1 INTRODUCTION 22 4.2 TRANSMISSION SUCCESSFULLY TRANSLATED FROM INTERNAL FORMAT TO STANDARD EDI FORMAT 23 4.2.1 NEEDS 23 4.2.2 RECOMMENDATIONS 23 4.3 TRANSMISSION SUCCESSFULLY ENCODED, ENCRYPTED, SIGNED AND SENT 23 4.3.1 NEEDS 23 4.3.2 RECOMMENDATIONS 24 4.4 TRANSMISSION SUCCESSFULLY DELIVERED TO THE RECIPIENTS MAILBOX 24 4.4.1 NEEDS 24 4.4.2 RECOMMENDATIONS 24 4.5 TRANSMISSION SUCCESSFULLY RECEIVED 24 4.5.1 NEEDS 24 4.5.2 RECOMMENDATIONS 25 4.6 TRANSMISSION SUCCESSFULLY TRANSLATED BY RECEIVER 25 4.6.1 NEEDS 25 4.6.2 RECOMMENDATIONS 25 4.7 DETECTION AND RECOVERY OF DELAYED OR LOST TRANSMISSIONS 25 4.7.1 NEEDS 25 4.7.2 RECOMMENDATIONS 25 4.8 DETECTION AND HANDLING OF DUPLICATE TRANSMISSIONS 25 4.8.1 NEEDS 26 4.8.2 RECOMMENDATIONS 26 APPENDIX A - A COMPARISON OF SECURITY FORMATS AND PROTOCOLS 26 1.0 Introduction Electronic Data Interchange (EDI) is a set of protocols for conducting highly structured inter-organization exchanges, such as for making purchases or initiating loan requests. The initial RFC1767 defined the method for packaging EDI X.12 and UN/EDIFACT transaction sets in a MIME envelope. However, several additional requirements for obtaining multi-vendor, inter-operable service, over and above how the EDI transactions are packaged, have come to light since the effort concluded. These currently revolve around security issues such as EDI transaction integrity, confidentiality and non- repudiation in various forms. Additional requirements that mimic many of the heading fields found in X.435 EDI messages (e.g., Interchange Sender, Interchange Recipient, Interchange Control Reference, Communications Agreement ID, and Syntax Identifier) are also needed to support efficient exchanges by gateways and Value Added Networks. Standards in these and other areas are necessary to insure inter-operability between EDI implementations over the Internet. Various technologies already exist for these additional features, and the primary requirement is to review and select a common set of components for use by the EDI community when it sends EDI over the Internet. In effect, the effort is to provide an EDI over the Internet Requirements Document and an Applicability Statement Document. This document's current focus is on EDI MIME content transported using SMTP (Simple Mail Transport Protocol), the Internet's mail or messaging system. Traditional VAN connectivity is slow and expensive. The Internet promises lower cost usage and is more easily accessible than traditional methods of communications. The predominant problem with the use of the Internet for EDI is inter-operability between vendor products, specifically in the areas of integrity, confidentiality, digital signature, and non-repudiation. The EDIINT working group's focus is to recommend solutions for each of these areas using existing standards whenever possible. 1.1 The Audience The audience for this document consists of persons directly or indirectly involved in EDI communications decisions, companies trading EDI documents today or in the future, and vendors developing and marketing EDI products. Also included in the audience for this document are people providing services and consulting to the EDI community. 2.0 The Internet - A Brief History The Internet is a world-wide collection of computers, routers, and networks, connected together using the TCP/IP suite of protocols. The Internet itself is not a network, but a collection of networks. The Internet was designed to be decentralized, with no single authority needed to run it. All hosts on the Internet can communicate with one another as peers, and all of the communications protocols are "open" -- the standards are in the public domain, and the standardization process is open to anyone willing to put in the hard work to help define them. One consequence of this standards "openness" is that the Internet can accommodate many different kinds of machines (toasters for example). Its protocols -- the TCP/IP suite -- have therefore become the de facto standards for heterogeneous computer networking. At one level, the Internet is a physical collection of computers connected by common protocols. At another level though, the Internet can be thought of as a distributed medium, offering some important advantages for doing EDI. For instance, the Internet has hundreds of thousands of connected global hosts, and tens of millions of users. The Internet offers a flat rate, volume and time-of-day independent pricing structure for data transmission. The Internet is highly redundant, offering the ability to route data along alternate paths. The Internet's decentralized structure makes adding new hosts relatively easy -- it scales well, and supports high bandwidth communications technologies. 2.1. The Internet - Myths and Reality The Internet had its beginnings in 1969 as an experimental U.S. Defense Department network called ARPANET. The network was built to facilitate research on how to construct networks that could withstand outages to part of the network, but continue to function. Network reliability was a fundamental design point when developing the architecture and protocols associated with the Internet. From the premise that the network was inherently unreliable (parts of it could be destroyed at any moment) emerged a design that was both robust and reliable. Early on, the networks comprising the Internet were primarily those from government agencies and educational institutions. Access to the Internet was pretty much available only to computer science researchers, and government employees and their contractors. In 1986, the National Science Foundation, in order to provide access to what was then a scarce resource, put together an initiative to link five super-computer centers together using the TCP/IP protocols. Two very important results of the NSFNET initiative were the upgrading of the Internet's infrastructure with more powerful processors and higher speed links, and expansion of access to a larger user community. The 1990's has seen the continual upgrading of the Internet infrastructure and its expansion to new constituencies outside the traditional government and university research community. Commercial interests are now the largest as well as the fastest growing segment of the Internet. Commercial Internet providers, such as Performance Systems International (PSI), and UUNET (the Alternet network), have emerged from the collection of intermediate-level networks that came into being as a result of the NSFNET initiative. The national long distance carriers such as MCI, AT&T, and Sprint all provide commercial Internet services. These commercial providers, called Internet Service Providers or ISPs for short, make available Internet connectivity and various other Internet services to their clients. The perception of the Internet as experimental, and primarily used by and for educational and research activities is rooted in the Internet's past, and does not reflect today's situation. The growth in commercial access to the Internet, along with the growth of the ISPs, has radically changed the Internet's network composition. The design and architecture underlying the Internet has proven its robustness by scaling to unprecedented proportions. The Internet is reliable from several perspectives: 1). Technologically, the TCP/IP suite of protocols and the architecture underlying the Internet are stable and mature. 2). Product implementations based on the TCP/IP suite are also stable and mature. 3). Internet routing is dynamic, so packets sent through the Internet get to their destinations even if there are network outages along the way. 4). The commercial ISP administered portions of the Internet, provide essentially the same level of network reliability, availability, monitoring, throughput, implementation and support services as existing EDI Value Added Networks (VANS), but at a lower cost and with higher bandwidth. Although the Internet is reliable, low-cost, highly accessible, supports high bandwidth communications, and is technically mature, there are still some valid concerns relating to the use of the Internet for EDI. These concerns revolve primarily around security, message tracking, audit trails, and authentication. Some of the concerns, encryption for instance, are of a general nature and not specific to the Internet -- encryption may be required regardless of what type of network is traversed. Other concerns, such as tracking, arise because they are required by EDI, or are supported by existing EDI Value Added Networks. 2.2 Internet Routing and Security Considerations By using a common network trace program called Traceroute, the route traversed by a packet from a source host to a destination host on the Internet may be followed. Tracing routes on the Internet yield some interesting characteristics. As expected, the routes traversed go through the networks administered by the ISPs of each of the trading partners. Each route consists of multiple nodes through each network. The route can vary but that is not the typical case. The IP packets are delivered reliably, and within a specified period of time. When a reputable commercial ISP is used, none of the nodes in the route are administered by government or educational entities. By looking at Internet network traces, we can conclude that the Internet does a very good job of getting packets from a source to destination. However, between the source and the destination, the packets are routed through many intermediate nodes. It is at the intermediate nodes where anyone on one of the machines that handle the packets could re-assemble the packets that make up the EDI Interchange and could therefore read it, copy it, alter it, or delete it. In the case where the EDI Interchange is carried using an e-mail transport (SMTP), the situation could arise where the message cannot be delivered to the final recipient, so the message must be stored at an intermediate node. Once again, the message is susceptible to any number of the above mentioned security threats. The likelihood of any security threat, (especially if going through intermediate nodes administered by a quality ISP) are quite low, and practically speaking, are quite difficult. Nonetheless the possibility exists, and therefore is a concern -- particularly if the packets contain high value or sensitive EDI or electronic commerce transactions. The Internet is being singled out in this discussion because our focus is on EDI over the Internet. Networking is by its very nature prone to security threats. Information can be placed on shared media, and may be routed through nodes not under the sender's administrative control. Whether through malicious hacking or administrative glitches, the threat that information sent over a network is read, copied, altered, or deleted in an unauthorized way, is a possibility that exists even if an EDI Interchange is sent via an EDI VAN. A large component of the "value-added" services provided by EDI VANs is precisely the assurance that EDI Interchanges sent via the VAN are not compromised in any way. There are however, measures that can be taken to defend against security threats when an EDI Interchange is in transit across an "open" network like the Internet. These security measures are essential requirements when doing EDI over the Internet. Each of these security measures is described in Section 3.0 of this document, and the issues surrounding each measure is discussed, and recommended solutions are given. 2.3 EDI VAN Communications and Security This section briefly discusses current VAN security services. The security measures recommended in section 3.0 of this document essentially provide the equivalent of the VAN security services described below. The most prevalent EDI VAN communications service provided to EDI trading partners is an asynchronous mailboxing service. A trading partner typically dials into a VAN network access point. The trading partner then uses a file transfer protocol to send the EDI Interchanges to the VAN. The VAN then routes the EDI Interchanges to the receiving trading partner's VAN mailbox. The receiving trading partner then dials into the VAN and down-loads the EDI Interchanges from its VAN mailbox. Other than support for a greater number of communications protocols, and typically lower line speeds, connecting to an EDI VAN is not too much different than connecting to an Internet Service Provider. The EDI VANs however, provide a higher level of EDI services to the EDI trading partner than do the ISPs. The most important of these services is that the EDI VAN acts as a trusted third party to insure that EDI Interchanges sent via the VAN are not compromised in any way. EDI VANs provide for EDI Interchange integrity, authentication, and a number of acknowledgments that track the progress of the EDI Interchange through the Value Added Network. EDI Interchange integrity assures the trading partner that once the EDI Interchange has been transferred to the VAN, that it will be routed to the receiving trading partner without modification. VAN authentication of trading partners consist of the guarantee that EDI Interchanges can be sent and received by trading partners only after they have been authenticated by the VAN. VANs authenticate trading partners by having the trading partners log into the network with the proper userid and password. The VAN has administrative responsibility for maintaining the trading partner accounts and for insuring that the accounts are valid. VANs also provide differing levels of service that allow a trading partner to track the progress of the EDI Interchange through the VAN. Trading partners can subscribe to mailbox delivery notification or mailbox pick-up notification. Mailbox delivery notification is sent by the VAN to the sending trading partner when the EDI Interchange is delivered to the receiving trading partner. Mailbox pick-up notification is sent by the VAN to the sending trading partner when the EDI Interchange is down-loaded by the receiving trading partner. The issue of tracking is covered in more detail in section 4.0. 3.0 Functional Requirements 3.1 Introduction and Definitions The following sections describe the functional and inter-operability requirements, as well as some of the practical considerations of sending and receiving EDI transactions on the Internet. It is assumed that the reader is generally familiar with EDI. 3.2 Standard Encryption Algorithms and World-Wide Encryption 3.2.1 Introduction and Description The goal of encryption is to turn otherwise readable text into something that cannot be read, and therefore understood. By making the text unintelligible, encryption discourages anyone from reading or copying the EDI Interchange while it is in transit between the trading partners. Encryption conveys confidentiality to the EDI Interchange. Traffic analysis is always possible, since many times, header information is not encrypted. (Traffic analysis is the analysis of header information in order to derive useful information from them.) Encryption is based on two components: an algorithm and a key. An algorithm is a mathematical transformation that takes plain-text or other intelligible information and changes it into unintelligible cipher text. The inverse mathematical transformation, back to the original from the cipher text is also done, and is called decryption. In order to encrypt the plain text, a key is used as input in conjunction with an encryption algorithm. An algorithm can use one of any of a large number of possible keys. The number of possible keys each algorithm can support depends on the number of bits in the key. For instance, if the key length is 40, then 2 to the n, where n is the number of bits in the key, results in 1,000,000,000,000 possible key combinations, with each different key causing the algorithm to produce slightly different cipher output. An encryption algorithm is considered secure if its security is dependent only on the length of its key. Security cannot be dependent on the secrecy of the algorithm, the inaccessibility of the cipher or plain text, or anything else -- except the key length. If this were true about a particular algorithm, then the most efficient -- and only -- attack on that algorithm is a brute-force attack, whereby all key combinations must be tried in order to find the one correct key (this is true for symmetric encryption algorithms, asymmetric algorithms work a little differently, and are explained in greater detail later). So by specifying a long enough key length n, even a brute-force attack on a secure algorithm can be made completely non-feasible. 3.2.2 Symmetric Encryption Encryption algorithms whereby two trading partners must use the identical key to encrypt and decrypt the EDI Interchange are called symmetric encryption algorithms. Put another way, if an EDI Interchange is encrypted with one key, it cannot be decrypted with a different key. The key used in most symmetric encryption algorithms is just a random bit string, n bits long. These keys are often generated from random data derived from the source computer. The use of symmetric encryption simplifies the encryption process, each trading partner does not need to develop and exchange secret encryption algorithms with one another (which incidentally would be a near impossible task). Instead, each trading partner can use the same encryption algorithm, and only exchange the shared, secret key. There are drawbacks however with symmetric encryption schemes; a shared secret key must be agreed upon by both parties. If a trading partner has n trading relationships, then n secret keys must be maintained, one for each trading partner. Symmetric encryption schemes also have the problem that origin or destination authenticity (non-repudiation of origin, and receipt) cannot be proved. Since both parties share the secret encryption key, any EDI Interchange encrypted with a symmetric key, could have been sent by either of the trading partners. By using what is called public key cryptography, which makes use of asymmetric encryption algorithms, non-repudiation of origin and receipt, can be unambiguously established. 3.2.3 Asymmetric Encryption - Public-key Cryptography Public-key cryptography is based on the concept of a key pair. Each half of the pair (one key) can encrypt information that only the other half (one key) can decrypt. The key pair is designated and associated to one, and only one, trading partner. One part of the key pair (the private key) is only known by the designated trading partner; the other part of the key pair (the public key) is published widely but is still associated with the designated trading partner. The keys are used in different ways for confidentiality and digital signature. Both confidentiality and signature depend on each entity having a key pair that is identified only with them and each party keeping one pair of their key pair secret from all others. Signature works as follows: Trading Partner A uses her secret key to encrypt part of a message, then sends the encrypted message to Trading Partner B. B gets Trading partner A's public key (anyone may get it) and attempts to decrypt the encrypted part of Trading partner A's message. If it decrypts, then Trading Partner B knows it is from A -- because only A's public key can decrypt a message encrypted with A's private key, and A is the only one who knows her private key. Confidentiality applies the asymmetric key pair, but in a different manner than signature. If Trading partner A wishes to send a confidential message to Trading Partner B she would apply the key pair as follows: Trading partner A would retrieve Trading partner B's public key, and encrypt the message with it. When Trading Partner B receives the message, she would decrypt the message with her private key. Only her private key can decrypt information that was encrypted with her public key. In other-words, anything encrypted with B's public key can only be decrypted with B's private key. Since public-key encryption algorithms are considerably slower than their symmetric key cousins, they are generally not used to do the actual encryption of what could be large EDI Interchanges. For instance, RSA Data Securities, Inc. estimates that software encryption using DES (a symmetric key algorithm) is 100 times faster than software encryption using RSA (a public-key encryption algorithm from RSA Data Securities, Inc.). Hardware encryption using DES is anywhere from 1,000 to 10,000 times faster than hardware encryption using the RSA asymmetric encryption algorithm. Instead of being used for bulk encryption, public-key encryption algorithms are used to encrypt symmetric encryption keys. They are also used as an efficient means of exchanging and managing symmetric encryption keys. 3.2.4 Needs In order to provide confidentiality for EDI Interchanges on the Internet, a standard encryption algorithm(s) and key length(s) must be specified. For inter-operability to occur between two trading partners, the encryption algorithm and key lengths must be agreed upon either before hand or within an individual transaction. 3.2.5 Issues When choosing an encryption algorithm, the following criteria should be considered; how secure the algorithm is; how fast implementations of the algorithm are; the availability of the algorithms for international as well as domestic use; the availability of APIs and tool kits in order to implement the algorithms; and the frequency of the use of the algorithm in existing implementations. Sufficient key lengths must be chosen with regard to the value of the EDI Interchange so that brute-force attacks are not worth the time or effort compared to the value of the Interchange. 3.2.6 Recommendations DES: The most widely used commercial encryption algorithm is DES. It is widely used in the banking industry for Electronic Funds Transfer (EFT). DES is also a U.S. government encryption standard. DES is in the public domain, which means anyone can implement the algorithm, including those in the international community. DES was designed for, and is used for bulk encryption of data. DES is prohibited by the U.S. government for export. The DES algorithm has been analyzed by cryptographers since the mid-1970s, and is considered secure: in other words, the security of DES is completely dependent on the length of its key. DES specifies a 56 bit key, so 2 to the 56th or 10 to the 16th keys are possible. A brute force attack, which means trying every single key to decrypt 8 bytes of known cipher-text into its corresponding 8 bytes of known plain-text is the best attack on the algorithm. The amount of time and money required to mount a successful brute force attack varies with the processing power used -- and how lucky the attacker may be in generating a key that is close to the one used to encrypt the original EDI Interchange. Some estimates which have been put forth claim that a $1 million dollar hardware based, brute-force attack on DES would only take 3.6 hours to recover the DES key. A corresponding $1 million dollar software based brute-force attack on DES would however take 3 years. As the price/performance of processors decrease, a 56 bit key becomes less and less adequate in protecting EDI Interchanges of extreme value. Triple-DES, an algorithm with longer key length (discussed below) should be used in such cases. Triple-DES is a variant on DES that encrypts the EDI Interchange 3 times, with 2 independent 56 bit keys, giving it an effective key length of 112 bits. This makes a brute-force attack on Triple-DES not feasible. DES and Triple-DES actually can be implemented in 3 different modes. It is recommended that DES and Triple- DES be used in Cipher Block Chaining (CBC) mode, which gives added protection by making each cipher-text block depend on each other, so changes in the cipher-text can be detected. RC2, RC4, and RC5: RC2, RC4, and RC5 are proprietary symmetric algorithms of RSA Data Security, Inc. RC2 and RC4 unlike DES, are variable-key length algorithms. By specifying differing key lengths, RC2 and RC4 can be configured to provide greater or lesser security. RC2 and RC4 are alternatives to DES and have special export status, whereby 40 bit versions of RC2 and RC4, and 56 bit versions for foreign subsidiaries and overseas offices of U.S. companies have expedited export approval from the U.S. government. RSA claims that RC2 and RC4 are faster than DES when implemented in software. Several products such as Lotus Notes, Netscape Navigator, and Apple's Open Collaboration Environment make use of these algorithms. It is recommended that a key length of at least 128 bits be used when using RC2 and RC4. A key length of 128 bits would make a brute-force attack impossible now and for the foreseeable future. IDEA: The International Data Encryption Algorithm was published in 1991. The symmetric algorithm is an iterated block cipher with a 64-bit block size and a 128- bit key size. The key length of IDEA is over twice that of DES and is longer than triple-DES. The IDEA algorithm is patented in both the United States and abroad. The IDEA algorithm in CBC mode is used by PGP (Pretty Good Privacy - a popular electronic mail security program) for encryption. Individual users of PGP have a royalty free license to use the IDEA algorithm. There are many encryption algorithms that are secure and can provide confidentiality for an EDI Interchange. For interchanges that carry less value, 40-bit RC2 or 56-bit DES are probably adequate. For more valuable interchanges, use of Triple-DES, IDEA, or longer key length RC2 or RC4 is recommended. DES is currently in wide-spread use, and Triple-DES is projected to be in wide-spread use, as the 56-bit DES key limitation becomes less and less adequate. The DES algorithm is available for implementation outside the U.S., and the DES algorithm has been studied for a long time, and has been found to be secure. RC2 and RC4 are useful because they allow the security of the encryption - the key length specification, to be configurable. The RC2 and RC4 algorithms are proprietary, but products incorporating these algorithms, but limiting the key lengths to 40 bits or less, can be exported outside the U.S. IDEA is a newer algorithm and has not been studied as much as DES. It has an adequate key-length, though it is not configurable. Indications are that IDEA is a secure algorithm and its use in PGP makes it the most widely used encryption algorithm for Internet electronic mail. 3.3 Key Management - Symmetric Keys 3.3.1 Introduction and Description The use of symmetric encryption is based on a shared secret. Two trading partners using a symmetric encryption algorithm must be able to do the following; generate a random symmetric key and agree upon its use; securely exchange the symmetric key with one another; set up a process to invalidate a symmetric key that has been compromised or needs changing. Each trading partner would then need to do this with each and every one of their trading partners. Management and distribution of symmetric keys can become an insecure and cumbersome process. Pure symmetric key management schemes also have the problem that origin authenticity cannot be proved. Since two parties share a secret encryption key, any EDI Interchange encrypted with a symmetric key, could have been sent by either of the trading partners both of whom have knowledge of the key. Using public-key cryptography, the management of symmetric keys is simplified and made more secure. Trading partners do not need to agree on secret symmetric keys as part of the trading partner relationship. Public-key cryptography also solves the origin authenticity problem that are inherent with pure symmetric key management schemes. By generating a unique symmetric encryption key for each EDI Interchange, and using public key cryptography, trading partners no longer need to secretly agree on a shared symmetric key in the trading partner relationship. A symmetric key can be randomly generated by the software for each EDI Interchange between trading partners. Since a unique symmetric key is generated for each EDI Interchange, key maintenance is not needed. Trading partners do not need to invalidate compromised or expired keys. Each symmetric key is used only one time. Additional security is also realized using the method described above; in the unlikely event that one of the symmetric keys is compromised, only one EDI transaction is affected, and not every transaction in the trading partner relationship. Public-key encryption also provides a secure way of distributing symmetric keys between trading partners. Since only the receiving trading partner has knowledge of her private asymmetric key, she is the only one that can decrypt the symmetric key encrypted with her public asymmetric key -- and is thus the only one who can use the symmetric key to decrypt the EDI Interchange. To impart confidentiality to an EDI Interchange which trading partner ABC sends to trading partner XYZ, the following steps would be performed: 1). The EDI Translator outputs the EDI Interchange. 2). A random symmetric key of the specified length is generated. 3). The EDI Interchange is encrypted using the randomly generated symmetric key with the chosen encryption algorithm. 4). The random symmetric key is then encrypted using XYZ's, the receiving trading partner's, public asymmetric key. 5). The encrypted symmetric key and encrypted EDI Interchange are then enveloped and sent to the trading partner. On the receiving side, the following steps would be performed: 1). The symmetric key is decrypted using XYZ's private asymmetric key. 2). The decrypted symmetric key is then used to decrypt the EDI Interchange. 3). The decrypted EDI Interchange is then routed to the EDI translator. 3.3.2 Needs A method to manage the symmetric encryption keys used in encrypting EDI Interchanges. The method should simplify the generation, maintenance, and distribution of the symmetric encryption keys. The method should also provide a secure channel for distributing the symmetric encryption keys between trading partners. 3.3.3 Issues Choose a public-key encryption algorithm that facilitates key management of the symmetric encryption keys. The symmetric encryption keys should be generated on the fly for each EDI Interchange. When choosing a public-key encryption algorithm, the following criteria should be considered; how secure the algorithm is; how fast implementations of the algorithm are; the availability of the algorithms for international as well as domestic use; the availability of APIs and tool kits in order to implement the algorithms; and the frequency of the use of the algorithm in existing implementations. Sufficient key lengths must be chosen with regard to the value of the EDI Interchange so that brute-force attacks are not worth the time or effort compared to the value of the Interchange. 3.3.4 Recommendations RSA is a public-key encryption algorithm that has become a de facto standard in its use for key management. Its use is recommended in managing and distributing symmetric encryption keys when doing EDI over the Internet. The RSA public-key algorithm also has the advantage that it can be used freely outside the U.S. The mathematics of RSA are complicated, but is based on the difficulty in factoring large prime numbers. A public-key is generated by multiplying two large prime numbers together, deriving the private key from the public key involves factoring the large prime number. If the prime is large enough, this becomes an impossible task. The RSA key length is configurable, and is recommended to be at least 512 bits (154 digits long), and preferably 1024 bits (or 308 digits long) or longer. 3.4 Key Management - Public and Private Keys 3.4.1 Introduction and Description The use of public-key cryptography to simplify the management of the symmetric encryption keys presents the user with two problems; protecting the private key, and binding a trading partner's identity to his public key. Most likely the user will never know what his private key is. The software will generate a random private key, encrypt it, and store it in a file or database. The private key is accessed indirectly by the user through access to the software. User access to the software is generally controlled by a password, pass-phrase, and/or certain access rights. These are internal security policies, and are company specific. It is important to control the access to the private key, since any unauthorized access can lead eventually to the revocation of the corresponding public key. 3.4.2 Public Keys A public key is used by an originating trading partner to encrypt a symmetric key, and as we'll discuss later, by a receiving trading partner to verify authenticity of the originator. Trading partners exchange public keys using a public key certificate. A public key certificate is defined in the X.509 standards, and is a binding of an entity's distinguished name (a formal way for identifying someone or something in the X.500 world, in our case it would be a trading partner) to a public key. A certificate also contains the digital signature of the issuer of the certificate, the identity of the issuer of the certificate, and an issuer specific serial number, a validity period for the certificate, and information to verify the issuer's digital signature. Certificate issuers are called certification authorities, and are trusted by both trading partners. In essence, a certificate is a digitally notarized binding of a trading partner to its public key. 3.4.3 Needs Adoption of a trust model and use of certification authorities for issuing commercial grade/class 3 certificates. Each trading partner must choose a certification authority that the other trading partner trusts. Formats and protocols for requesting, revoking, and exchanging certificates and certificate revocation lists between certification authorities and trading partners, as well as between the trading partners themselves. 3.4.4 Issues The lack of wide-spread use of certification authorities in real world commercial applications, and the need to do additional profiling of X.509v3 certificates and standards for requesting, revoking, and exchanging certificates and certificate revocation lists. 3.4.5 Recommendations 3.4.5.1 Near Term Approach Since there already exists a trust relationship between EDI trading partners, until use of certification authorities become more established and better profiling is done with X.509v3 certificates, it is recommended that the trading partners self-certify each other if an agreed upon certification authority is not used. In the near term, the exchange of public keys and certification of these keys must be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption and authentication, in addition to mapping between the EDI trading partner ID and the RFC822 e-mail address. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages. It is still highly recommended that trading partners acquire a X.509v3 certificate from a certificate authority trusted by both trading partners. The process of acquiring a certificate varies among the various certificate authorities. It is recommended that trading partners exchange certificates using the formats and protocols specified by PKCS#7 and S/MIME. 3.4.5.1 Long Term Approach In the long term, additional Internet-EDI standards will need to be developed to simplify the process of establishing a trading partnership, including the acquisition, revocation, exchange, and third party authentication of certificates. PKCS#7 and PKCS#10 as well as the standards being developed by the IETF-pkix (public key infrastructure X.509 work-group) need to be evaluated and adopted as standards for Internet EDI. 3.5 Content Integrity 3.5.1 Introduction and Description Encryption guarantees the confidentiality of an EDI Interchange. Content integrity guarantees that the receiving trading partner gets the EDI Interchange in its originally sent state. Content integrity assures that no modifications -- additions, deletions, or changes -- have been made to the EDI Interchange when it is in transit between trading partners. Content integrity is achieved if the sender includes with the EDI Interchange, an integrity control value. This value can be computed by using an appropriate cryptographic algorithm to "fingerprint" the EDI Interchange. These cryptographic algorithms are called one-way hash functions or message integrity checks. Similar to encryption, a one-way hash function turns the intelligible EDI plain-text into something unintelligible. Unlike encryption algorithms however, one-way hash functions can't be decrypted. One-way hash functions are constructed so the probability is infinitely small that some arbitrary length piece of plain-text can be hashed to a particular value, or that any two pieces of plain-text can be hashed to the same value. One-way hash values are usually from 112 to 160 bits long. The longer the hash value, the more secure it is. One-way hash functions don't require a key, and the algorithm used must be agreed upon by the trading partners. To insure content integrity, the sending trading partner needs to calculate a one-way hash value of the EDI Interchange. This value is unique and "fingerprints" the EDI Interchange. The sending trading partner sends the hash value along with the EDI Interchange. The receiving trading partner using the same one-way hash function calculates the hash value for the received EDI Interchange. If the received hash value matches the calculated hash value, then the receiving trading partner knows that the EDI Interchange has not been tampered with. 3.5.2 Needs Choice of a one-way hash algorithm to calculate the hash value required to insure content integrity. 3.5.3 Issues The one-way hash algorithm should be secure, publicly available, and should produce hash values of at least 128 bits. 3.5.4 Recommendations SHA-1 is the Secure Hash Algorithm, a one-way hash function invented by the National Security Agency. SHA-1 produces a 160-bit hash value that makes a brute-force attack on it not feasible. It is being recommended by most e-mail security programs and other security specifications, as weaknesses are being found in MD5. MD5 is a one-way hash function that is publicly available, and produces a 128 bit hash value called a Message Digest. It is currently widely used by most e-mail security programs, such as PEM, PGP, and S/MIME. The recommendation is for all new implementations to use SHA-1 outgoing, but to continue to accept MD5 incoming, since there already exist many MD5 implementations. 3.6 Authentication and Non-Repudiation of Origin 3.6.1 Introduction and Description Encryption guarantees confidentiality. Applying a one- way hash function guarantees content integrity. Both authentication and non-repudiation of origin guarantee the identity of the sender of the EDI Interchange. Non- repudiation of origin, identifies the original sender, and is the same as authentication when the EDI Interchange is sent point-to-point, i.e. when there is no forwarding involved. Authentication and non- repudiation of origin discourages any spoofing attacks that may occur while the EDI Interchange is in transit between the trading partners. Both authentication and non-repudiation of origin are accomplished using digital signatures. A digital signature is another application of public-key cryptography, and is explained in more detail in the following paragraphs. Up to this point, a receiving trading partner's public- key has been used to encrypt a symmetric key, and this symmetric key could only be decrypted by the receiving trading partner's private key. However the roles of the private and public keys can be reversed, so that you encrypt with the private key, and decrypt with the public key. Again the keys are reciprocal, if encryption is done with the private key, decryption can only be done with the public key. Since only trading partner ABC knows her own private- key, only trading partner ABC can encrypt something with that private-key. Encryption with a private key therefore has the effect of uniquely identifying the person or entity doing the encryption. It is in effect, a digital signature. Since ABC's public-key is known to all her trading partners, they can all decrypt something encrypted with ABC's private-key. Successful decryption using ABC's public-key of something encrypted with ABC's private key has the effect of authenticating ABC as the trading partner that did the encrypting, or in other words it identifies ABC as applying the digital signature. ABC cannot deny that she did not do the encryption, since she is the only one with knowledge of her private key. In this way, non-repudiation of origin is achieved. So what should a trading partner sign or encrypt with her private-key to guarantee authentication and non- repudiation of origin? Remember, public-key encryption algorithms are not meant to encrypt something very large, they are too slow for that. The symmetric key is encrypted with a public-key, and encrypting this with a private-key is not recommended, as this would allow other than the authorized recipient to decrypt the EDI Interchange. Since a one-way hash value is pretty small, usually only between 112-160 bits long, it is a natural choice for what can be digitally signed. If the message integrity value is signed with a private key, then not only could authentication and non-repudiation of origin be guaranteed, but message integrity as well. 3.6.2 Needs Choice of a digital signature algorithm. 3.6.3 Issues When choosing a digital signature algorithm, the following criteria should be considered; how secure the algorithm is; how fast implementations of the algorithm are; the availability of the algorithms for international as well as domestic use; the availability of APIs and tool kits in order to implement the algorithms; and the frequency of the use of the algorithm in existing implementations. Sufficient key lengths must be chosen with regard to the value of the EDI Interchange so that brute-force attacks are not worth the time or effort compared to the value of the Interchange. 3.6.4 Recommendations In addition to using the RSA public-key algorithm to encrypt keys, it is also recommended that RSA be used for digital signatures as well. Unlike encryption algorithms, strong digital signature (greater than 40 bit key lengths) algorithms can be freely exported outside the U.S. 3.7 Signed Receipt or Non Repudiation of Receipt 3.7.1 Introduction and Description The signed receipt (or the Non Repudiation of Receipt), is a receipt acknowledgment sent by the receiving trading partner to the sending trading partner. The signed receipt is used to solve the following issues when doing EDI over the Internet: 1). Lack of mailbox delivery notification within the Internet standards, though these are currently being addressed within RFCs 1891-1894. 2). Provide the equivalent of VAN mailbox delivery notification. 3). Provide the equivalent of VAN mailbox pick-up notification. 4). Provide the equivalent of VAN mailbox authentication. 5). Detect the situation where EDI Interchanges are maliciously deleted, or are not delivered by the transport. Receipt by the sender of a signed receipt, is an implicit acknowledgment of successful mailbox delivery. It is also an explicit acknowledgment that the Interchange was retrieved from the mailbox -- pick-up notification. By having the receiver sign the receipt, it authenticates that the intended receiver picked up the EDI Interchange -- mailbox authentication -- and that the intended receiver verified the integrity of the EDI Interchange, and the identity of the sender. By returning the original message id and the one-way hash value of the received message back in the signed receipt, the sender can reconcile the acknowledged EDI Interchange with what was sent. 3.7.2 Needs Define the format and protocol for the signed receipt so that it provides the following: 1). Implicit acknowledgment of mailbox delivery of the EDI Interchange to the recipient. 2). Explicit acknowledgment that the receiver has authenticated the sender and verified the integrity of the sent EDI Interchange. 3). Guarantees non-repudiation of receipt when the signed receipt is digitally signed by the receiving trading partner. 4). Provide information in the signed receipt so it can be used for tracking, logging, and reconciliation purposes. The re-transmission timer, and retry count to detect lost Interchanges should be recommended, but needs to be configurable. Additionally, it should be specified what the receiver should do when it receives duplicate Interchanges, and what the sender should do when it receives duplicate receipt acknowledgments. 3.7.3 Recommendations The syntax for a signed receipt should not be specific to EDI content, since many of the uses of a signed receipt can be broadly applied to other MIME encapsulated objects. It is recommended that the results of the IETF receipt working group be adopted for use in implementing a signed receipt. The receipt working group has published an Internet draft -- draft-ietf-receipt-mdn-01, which can be obtained off of the IETF World Wide Web site. The EDIINT working group is working with the receipt working group to specify additional disposition-field values, as well as specification of how the MDN (message disposition notification) should be used within an EDI environment. Specifically, within an EDI environment, requests for message disposition requests cannot be silently ignored. In addition, if non-repudiation of receipt is agreed to by the trading partners, the message integrity check that is verified by the receiving trading partner must be returned to the originating trading partner in the MDN. The time-out and retry values for the signed receipt should be configurable. Duplicates should be checked by the UA and discarded. The signed receipt should be implemented using a MIME multipart/signed with the MDN as the first part of the multipart/signed, and with the digital signature signed over the MDN. 3.8 EDI Object Boundaries and Transaction Privacy 3.8.1 Introduction and Description The specification by this work group applies to the EDI Interchange level, and not the group or document level. Any security services, packaging, transport, or non- repudiation services are assumed to be applied to an EDI Interchange. Unlike the X12.58 and UN/EDIFACT 9735-5 and 9735-6 security standards, the security services cannot be applied at a group or document level. The purpose of the specification is to move these services out of the translator, and into the "communications" subsystem. The "communications" subsystem should know as little about the structure of the EDI data as possible. The entire EDI Interchange including the enveloping headers (ISA/IEA or UNA/UNB/UNZ) are also encrypted. Since the routing of the EDI Interchange is through the Internet, and not a VAN, the sender/receiver ids are not used in mailbox routing, so the EDI envelops can be encrypted when sending EDI over the Internet. 3.8.2 Gateway Functions Situations exist whereby a VAN, or internal gateway, in order to route an EDI Interchange received on the Internet, will need to be able to access the information in the EDI envelope. The enveloping information as well as other information useful to gateways may need to be copied and sent as a separate MIME body part. A new MIME content should be defined for this type of information. 3.9 Syntax and Protocol for Specifying Cryptographic Services 3.9.1 Introduction and Description Once cryptographic services are applied to EDI Interchanges, then the formats and protocols must be specified on how the cryptographic information is conveyed during the EDI message exchange. Encryption algorithm information, one-way hash algorithm information, symmetric keys, initialization vectors, one- way hash values, public-key certificates, need to be enveloped and sent along with the EDI Interchange. 3.9.2 Needs A syntax and protocol for specifying EDI Interchanges that have had cryptography applied to it needs to be specified. Several suitable standards already exist, so it is preferable to choose one of these existing standards rather than specifying a new one. 3.9.3 Issues The syntax should be transport independent so it can be used with different Internet transports. The standard should have broad support, and implementations should be available. Finally it should be international in nature. 3.9.4 Recommendations The IETF EDIINT working group has put together a matrix comparing many of the different ways that EDI with cryptography applied to it can be transmitted. The use of S/MIME and PGP/MIME (version 3.0 with the elkins draft) are both viable alternatives. Each has its strengths and weaknesses as the comparison matrix brings out. The S/MIME specification allows signed and encrypted and signed to be distinguished. The signatories in an S/MIME signed and encrypted content type can be distinguished, which in certain EDI and electronic commerce situations is not acceptable. S/MIME specifies 40 bit RC2 as the default encryption algorithm and key length. In some applications neither this default algorithm or key length are acceptable. S/MIME can accommodate other security algorithms and key lengths such as those recommended in section 3.3.2 however. PGP/MIME supports a set profile of security algorithms and some user configurable key lengths. PGP/MIME does not have the signatory problem as described above for S/MIME. However, PGP/MIME does not give the user as much flexibility in choosing algorithms and key lengths, although the security profile used by PGP/MIME is more than adequate to insure confidentiality, non-repudiation of origin, and message integrity. 4.0 Tracking and Error Handling Basics 4.1 Introduction It's important to recognize that the Value Added Networks provide some inherent tracking mechanisms between EDI trading partners. In Internet EDI, the ISPs provide a certain level of transmission tracking as does the TCP/IP protocols themselves. However, not all the tracking provided by EDI VANs are completely covered by the current TCP/IP protocol suite or ISP tracking. The new tracking information associated with the additional security requirements and support of signed receipts, must be implemented in the EDI UA, in order for Internet EDI to be as traceable as VAN EDI. Aside from the communications between companies, "tracking" touches many other points within the trading relationship. This is where the use of 997 functional acknowledgments come in, the EDIFACT CONTRL message, and the common translator tracking of sequential group control numbers. All of this needs to be considered in Internet EDI tracking. In addition, some recent developments within S/MIME warrant some analysis -- "positive acknowledgment", which refers to mail response not just if the delivery failed, but also if it succeeded. The following is a list of the common tracking information needed when sending and receiving EDI Interchanges between trading partners: 1). Transmission successfully translated from internal format to EDI standard format. 2). Transmission successfully encoded, signed, encrypted, and sent.(The equivalence of transmission successfully received by the VAN.) 3). Transmission successfully delivered to the recipient's mailbox.(The equivalence of a VAN delivery acknowledgment that the sent transmission has been forwarded to the receiver's VAN mailbox.) 4). Transmission successfully picked-up by the recipient. (The equivalence of a VAN mail-box pick-up acknowledgment.) 5). Transmission successfully translated by the receiver. (The EDI Interchange was determined to be syntactically correct.) 6). Detection and recovery of delayed or lost transmissions. 7). Detection and handling of duplicate transmissions. The following section addresses in what components the new Internet EDI tracking information must be maintained, and discusses how this new tracking information relates to the tracking information kept by the EDI application. 4.2 Transmission Successfully Translated From Internal Format to Standard EDI Format 4.2.1 Needs There needs to be a facility by which a sender can assure that the EDI transmission was correctly translated and prepared for outbound transmission. 4.2.2 Recommendations This is standard functionality for most if not all EDI translators. This should NOT be required functionality of an EDI UA. 4.3 Transmission Successfully Encoded, Encrypted, Signed and Sent 4.3.1 Needs There needs to be a facility by which a sender can be assured that an EDI transmission was successfully encoded, encrypted, signed, and sent. 4.3.2 Recommendations The tracking of the success or failure of the security services required for Internet EDI must be maintained by the EDI UA. The EDI UA needs to be able to identify the transmission by its interchange control #, AND a user defined value, if desired. 4.4 Transmission Successfully Delivered to the Recipient's Mailbox 4.4.1 Needs There needs to be a facility by which a sender can be assured that an EDI transmission was successfully delivered to a recipient's mailbox. 4.4.2 Recommendations This type of tracking information is kept by the UA and is returned to the sender as a delivery notification. The delivery notification is specified in RFC1891-1894. 4.5 Transmission Successfully Received 4.5.1 Needs There needs to be a facility by which a sender of a transmission can be assured that the transmission was correctly received by the intended receiver. 4.5.2 Recommendations This type of tracking information is kept by the EDI UA and is returned to the sender as a signed receipt. (See section 3.7.3 for a discussion about signed receipts.) Note: The X.12 997 or EDIFACT CONTRL message can also provide the equivalent of an implicit transmission received acknowledgment. However, the use of signed receipts is still recommended for the following reasons: * The implied success of the receiver's decryption through the receipt of a legible 997, binds the certificate to a control ID only (997) and not to the actual data (NRR). * Translators are very different, and the CONTRL message isn't supported by all EDI translators or is it in widespread use yet. 4.6 Transmission Successfully Translated by the Receiver 4.6.1 Needs There needs to be a facility for the sender to be assured that the receiver could "understand" (in EDI terms) the transmission. 4.6.2 Recommendations This should NOT be tracked by the EDI UA, following our recommendation for object boundaries. The Functional acknowledgment 997, and the EDIFACT CONTRL serve this exact purpose - this should be tracked by the EDI translator. 4.7 Detection and Recovery of Delayed or Lost Transmissions 4.7.1 Needs There needs to be a facility by which a sender can detect sent transmissions that have not been acknowledged as correctly received, by a specified, configurable, period of time, and be able to configure actions accordingly. 4.7.2 Recommendations 1). The use of time stamps for each of the two events: * MIME message sent. * Signed Receipt received. 2). The ability to automatically detect transmissions that have failed the time trigger. 3). The ability to configure automatic actions based on failure. Actions may include: * Re-transmit: If re-transmitted, the receiving UA needs to be able to detect the second transmission as a duplicate and discard it. * Alert/Report. * Ignore/delete - this option may be chosen by someone that has decided to track only at the EDI translator level through 997/CNTRL. 4.8 Detection and Handling of Duplicate Transmissions 4.8.1 Need There needs to be a facility by which a receiver of EDI transmissions is able to detect different types of duplicate transmissions, and handle them the way they should be handled. First, translator initiated duplicates should NOT be halted in any way - we should assume that translators will handle that level. In other words, there should be no checking of ISA control numbers by the UA. Secondly, the use of a re- transmission feature in attempts to deliver transmissions quickly, should allow for a UA to identify duplicate transmissions generated by the sending UA, and discard of duplicate transmissions after the first has been received. 4.8.2 Recommendations The ability to pass through translator initiated re- transmissions to the receiving translator without a hitch. This means EDI related control numbers, such as the ISA control number, should not be checked by the EDI UA. Appendix A - A Comparison of Security Protocols Version: 3.0 Date: July 18, 1996 Sources: EDIINT- EDI over Internet, Internet Mail Consortium Workshop data, Chuck Shih, Steve Dusse, David Darnell, Kent Landfield, David Chia, Rik Drummond, Jeff Cook, Alan Cox, Ralph Levien, Russ Housley, and many others. 1) Exportable Out Side Of The USA ------------------------------------ PGP V3.0 * PGP is already outside the USA and except for countries that prohibit encrypted messages with long key lengths (instead of just restricting the import of long key length algorithms) PGP long key length messages can be read. This is included in the PGP ViaCrypt documentation. * No since the encryption algorithm specified is IDEA. S/MIME * Has the 40 and 56 bit export restrictions if RC2 or RC4 is used for encryption. MOSS * Not with full key length * Depends on the data encryption algorithm used. RFC 1423 specifies DES in CBC mode, which is not exportable. Moss however allows the use of variety of cryptographic algorithms. MSP * Depends on the key management and data encryption algorithm used. MSP allows the use of variety of cryptographic algorithms. 2) Easily Integrated Into Products In A User Transparent Manner ------------------------------------------------------------ PGP V3.0 * Maybe in V.30. Not in earlier versions. * There seems to be general disagreement on this one. S/MIME * Yes. MOSS * Do not know. MSP * Yes. Support for signed receipts may require GUI enhancements. 3) Fully Compatible With Like Versions World Wide ----------------------------------------------------- PGP V3.0 * PGP version 2.6 is compatible with any earlier versions. Version 3.0 should be also. S/MIME * RSA has an active interoperability program in place * Implementations to the spec should guarantee interoperability. MOSS * Moss does not require any particular security algorithm. Moss provides the means to identify which algorithms are used for each message. A suite of algorithms is defined in RFC 1423. MSP * Implementations to the spec should guarantee interoperability when the same cryptography is used. 4) Current Implementation Status ---------------------------------- PGP V3.0 * Version 3.0 is due out 4Q96. * Version 2.6 is available. * Qualcomm. * Premail. * Michael's PGPMIME. S/MIME * Two companies have implemented several others have committed. Twelve companies currently committed to implementing in a pilot sponsored by Commercenet. * Products and development tool-kits currently shipping. MOSS * TIS, Innosoft and SupplyTech. MSP * SPYRUS, Nortel, Xerox, LJL, BBN, and J. G. Van Dyke all have implementations. * Product is shipping. * In use for military messages. 5) Confidentiality ------------------ PGP V3.0 * Yes S/MIME * Yes MOSS * Yes MSP * Yes 6) Signature ------------ PGP V3.0 * Yes S/MIME * Yes MOSS * Yes MSP * Yes 7) Return Receipt ------------------ PGP V3.0 * No S/MIME * No MOSS * No MSP * Yes - supports non-repudiation with proof of delivery. 8) Delivery Notification ------------------------- PGP V3.0 * Via MIME extensions RFC1891-94. S/MIME * Via MIME extensions RFC1891-94. MOSS * Via MIME extensions RFC1891-94. MSP * Via MIME extensions RFC1891-94. 9) Authentication ----------------- PGP V3.0 * Yes S/MIME * Yes MOSS * Yes MSP * Yes 10) Multimedia -------------- PGP V3.0 * Yes S/MIME * Yes MOSS * Yes MSP * Yes 11) Integrity ------------- PGP V3.0 * Yes S/MIME * Yes MOSS * Yes MSP * Yes 12) Trust Model (Key Management & Revocation) ------------------------------------------------- PGP V3.0 * PGP 3.0 will have hierarchical model of public-key certificates. * RSA used for key management in current versions. * Ad hoc key revocation. S/MIME * RSA based using X.509 all versions. * NT's Entrust will be usable with this product very soon. MOSS * Both RSA and DES based key management. MSP * X.509 all versions. 13) Certificate (Information, Format, Distribution) ------------------------------------------------------ PGP V3.0 * Yes using proprietary "Key rings". Not clear what V3 will use. S/MIME * Yes using X.509 - all versions. MOSS * Yes with optional X.509. MSP * Yes using X.509. 14) Infrastructure Overhead ---------------------------- PGP V3.0 * Base 64 encoding. S/MIME * ASN.1 - BER and DER encoding. * Base 64 encoding. MOSS * Base 64 encoding. MSP * Base64 encoding and ASN.1 encoding. 15) Envelope Type ------------------ PGP V3.0 * MIME/ ASCII S/MIME * PKCS #7 and MIME MOSS * MIME/ ASCII MSP * MIME /ASN.1 16) Envelope / Structure Specification (ASN1 or ASCII) ------------------------------------------------------- PGP V3.0 * ASCII S/MIME * ASN.1 and ASCII MOSS * ASCII MSP * ASN.1 17) Algorithms Supported (List Them: Encryption, Key Management, One Way Hash, Digital Signature, Key Lengths For Encryption) ------------------------------------------------------------ - PGP V3.0 * RSA and IDEA in pre 3.0. * Diffie Hellman and DSA in Ver. 3.0. * IDEA in CBC. * MD5 & RSA. * A 128 for casual grade, 512 commercial grade, 2048 military grade. * A 128 bit IDEA key length. S/MIME * RSA. * RC2, RC4 and RC5. * MD5 & RSA. * SHA-1. * Note: S/MIME like Moss is a format and allows any type of algorithm to be specified. RSA of course specifies their own algorithms. * Triple-DES/RC5. MOSS * DES in CBC. * RSA or DES. * MD2/MD5 and RSA. * A 56 bit key lengths for DES. * FORTEZZA. * Note: Moss like S/MIME allows a variety of cryptographic algorithms to be used. The suite of algorithms defined above are found in RFC 1423. MSP * Algorithm independent. Implementations exist using: * RSA & DES. * FORTEZZA (DSS SHA-1, KEA, Skipjack). 18) Common Algorithms With EDIFACT AUTACK List Of Codes ----------------------------------------------------------- PGP V3.0 * RSA (yes). * IDEA (yes). * DSA (yes). * MD5 (yes). S/MIME * RSA (yes). * RC2 and RC4 (yes). * DES (yes). * MD5 (yes). MOSS * RSA (yes). * DES (yes). * MD5 (yes). MSP * RSA (yes). * DES (yes). * MD5 (yes). * DSS (yes). * SHA-1 (yes). 19) Coexistence With Others For Reception (signature not readable) of MIME Multipart/Signed Data ------------------------------------------------------------ PGP V3.0 * Yes V3.0. S/MIME * Yes, but user selectable. MOSS * Yes. MSP * Yes, if used with MIME encapsulation (see . 20) Signed Message Body Readable By RFC822/ MIME Readers ------------------------------------------------------------ - PGP V3.0 * Should be in V3.0. S/MIME * Yes - if one of the options multipart/signed is used. MOSS * Yes. MSP * Yes, if used with MIME encapsulation. 21) Signature Separate From Signed Document ---------------------------------------------- PGP V3.0 * Yes. S/MIME * No. MOSS * Yes MSP * Yes 22) Backward Compatibility --------------------------- PGP V3.0 * To PGP. S/MIME * To PEM. MOSS * To PEM. MSP * No. 23) Uses Proprietary Algorithms? --------------------------------- PGP V3.0 * Ver 3.0 will use Diffie-Hellman with expiring patents in 1997. Ver 3.0 will use DSA (Digital Signature Algorithm invented at the NSA). S/MIME * Yes, but it supports different options. MOSS * YES, but it supports different. MSP * It supports both standard (FIPS and X9) as well as proprietary algorithms. 24) Adequate Security For EDI Purposes ----------------------------------------- PGP V3.0 * Yes. S/MIME * Yes. MOSS * Yes. MSP * Yes. 25) Scaleable ------------- PGP V3.0 * Not enough experience to tell. The current trust model will not scale well. S/MIME * Not enough experience to tell. MOSS * Not enough experience to tell. MSP * Yes. 26) Solid MIME Integration --------------------------- PGP V3.0 * V3.0 - yes. S/MIME * Yes - but it mixes PKCS technology with MIME. MOSS * Yes. MSP * Yes (see . 27) Variable Key Sizes Supported ---------------------------------- PGP V3.0 * No. S/MIME * Yes, 40- 128 bit. * Symmetric 512-2048 bit RSA. MOSS * Yes. MSP * Yes. * Symmetric (DES = 56 bits; SKIPJACK = 80 bits).. * Signature (DSS = 512 .. 1024 bits; RSA = 512 .. 2048 bits). * Key Management (KEA = 1024 bits; RSA = 512 .. 2048 bits). 28) Only X.509 Or Other Certificate Distribution Methods ------------------------------------------------------------ PGP V3.0 S/MIME * X.509 any version. MOSS MSP * X.509 any version. 29) Very Solid API And Took Kit --------------------------------- PGP V3.0 * V3.0 Yes - anticipated. S/MIME * Yes. MOSS * No. MSP * Yes. DISA is submitting an API to X/Open. * At least two tookkits for sale. 30) Tool Kits Can Be Made Available To All Countries Not Under UN Embargo ------------------------------------------------------------ - PGP V3.0 * Probably from alternate sources. S/MIME * Export version probably to most countries. MOSS * Export version probably to most countries . MSP * Export version probably to most countries. Toolkits exported to many countries, including France. * Alternate source likely. 31) Fit With Future Direction Of EDI --------------------------------------- PGP V3.0 * Unknown. S/MIME * Unknown. MOSS * Unknown. MSP * Unknown. Primary Author's Address: Chuck Shih 610 Caribbean Drive Sunnyvale, CA. 94089 Phone: 408-542-3282 Fax: 408-542-3210 e-mail: chucks@actracorp.com