EDIINT Functional Specification July 1996 EDIINT Working Group Chuck Shih Internet Draft Mats Jansson Expires: 12/96 Rik Drummond Lincoln Yarbrough Requirements for Inter-operable Internet EDI Please direct comments to drummond@onramp.net. 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 memo is an informational document discussing the requirements for inter-operable EDI, with sufficient background material to give an explanation for the EDI community of the Internet-related issues. 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 7 3.0 FUNCTIONAL REQUIREMENTS 9 3.1 INTRODUCTION AND DEFINITIONS 9 3.2 STANDARD ENCRYPTION ALGORITHMS AND WORLD-WIDE ENCRYPTION. 9 3.2.1 INTRODUCTION AND DESCRIPTION 9 3.2.2 SYMMETRIC ENCRYPTION 10 3.2.3 ASYMMETRIC ENCRYPTION - PUBLIC-KEY CRYPTOGRAPHY 10 3.2.4 NEEDS 11 3.2.5 ISSUES 11 3.2.6 SOME RECOMMENDED ENCRYPTION ALGORITHMS 11 3.3 KEY MANAGEMENT - SYMMETRIC KEYS 13 3.3.1 INTRODUCTION AND DESCRIPTION 13 3.3.2 NEEDS 15 3.3.3 ISSUES 15 3.3.4 RECOMMENDATION 15 3.4 KEY MANAGEMENT - PUBLIC AND PRIVATE KEYS 16 3.4.1 INTRODUCTION AND DESCRIPTION 16 3.4.2 PUBLIC KEYS 16 3.4.3 NEEDS 16 3.4.4 ISSUES 16 3.4.5 RECOMMENDATIONS 16 3.5 CONTENT INTEGRITY 17 3.5.1 INTRODUCTION AND DESCRIPTION 17 3.5.2 NEEDS 18 3.5.3 ISSUES 18 3.5.4 RECOMMENDATIONS 18 3.6 AUTHENTICATION AND NON-REPUDIATION OF ORIGIN 18 3.6.1 INTRODUCTION AND DESCRIPTION 18 3.6.2 NEEDS 19 3.6.4 EDITOR'S RECOMMENDATIONS 20 3.7 SECTION: SIGNED RECEIPT OR NON REPUDIATION OF RECEIPT20 3.7.1 INTRODUCTION AND DESCRIPTION 20 3.7.2 NEEDS 21 3.7.3 RECOMMENDATIONS 21 3.8 EDI OBJECT BOUNDARIES AND TRANSACTION PRIVACY 22 3.8.1 INTRODUCTION AND DESCRIPTION 22 3.8.2 GATEWAY FUNCTIONS 22 3.9 SYNTAX AND PROTOCOL FOR SPECIFYING CRYPTOGRAPHIC SERVICES 22 3.9.1 INTRODUCTION AND DESCRIPTION 22 3.9.2 NEEDS 22 3.9.3 ISSUES 23 3.9.4 RECOMMENDATION 23 4.0 TRACKING AND ERROR HANDLING BASICS 23 4.1 INTRODUCTION 23 4.2 SECTION: TRANSMISSION SUCCESSFULLY TRANSLATED FROM INTERNAL FORMAT TO STANDARD EDI FORMAT 24 4.2.1 NEED 24 4.2.2 RECOMMENDATIONS 24 4.3 SECTION: TRANSMISSION SUCCESSFULLY ENCRYPTED, SIGNED AND SENT 24 4.3.1 NEED 24 4.3.2 RECOMMENDATIONS 25 4.4 SECTION: TRANSMISSION SUCCESSFULLY RECEIVED 25 4.4.1 NEED 25 4.4.2 RECOMMENDATIONS 25 4.5 SECTION: TRANSMISSION SUCCESSFULLY TRANSLATED BY RECEIVER 25 4.5.1 NEED 25 4.5.2 RECOMMENDATIONS 25 4.6 DETECTION AND RECOVERY OF DELAYED OR LOST TRANSMISSIONS 25 4.6.1 NEED 25 4.6.2 RECOMMENDATIONS 26 4.7 DETECTION AND HANDLING OF DUPLICATE TRANSMISSIONS 26 4.7.1 NEED 26 APPENDIX A - A CONPARISON OF SECURITY PROTOCOLS 27 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 X12 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 ensure inter-operability between EDI packages 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 Informational 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 interoperability between vendor products, specifically in the areas of integrity, confidentiality, 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 ever 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 its past, and does not reflect today's situation. The growth in commercial access to the Internet, along with the growth of the ISPs, is radically changing 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 authorization. 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, and supported by existing EDI Value Added Networks. 2.2 Internet Routing 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 handles the packets can re-assemble the packets that make up the EDI Interchange and can 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 and the message must be stored at the intermediate node. Once again, the message is susceptible to any number of security threats. The likelihood of security attacks, (especially if going through intermediate nodes administered by a quality ISP) are quite low, and practically speaking, may be quite difficult. Nonetheless, since the possibility exists, it 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 EDI over the Internet, but the possibility of security threats and administrative glitches exist even if the EDI Interchanges go through an EDI VAN. It really is a matter of management of the machines that make up the intermediate nodes in any network that is at issue. There are measures that can be taken to defend against security concerns while an EDI interchange is in transit. These security measures are essential requirements when doing EDI over the Internet. Each of the security measures is described, issues are discussed, and recommended solutions given. 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 it) 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, delivery 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, the non-repudiation of origin, delivery and non-repudiation of receipt issues can be solved. 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 Some Recommended Encryption Algorithms 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 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 and RC4: RC2 and RC4 are proprietary symmetric algorithms of RSA Data Security. 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 e- mail products such as Lotus Notes 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, they 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 who 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 pure symmetric key management schemes have. 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 5) XYZ's, the destination's, public asymmetric key. 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 Recommendation 1) RSA is a public-key cryptography 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. 2) 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 a originating trading partner to encrypt a symmetric key, and as we'll discuss later, by a receiving trading partner to do authentication and non-repudiation of origin and receipt. 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 trading partner to public key. 3.4.3 Needs Adoption of a trust model and use of Certification Authorities for verifying public key certificates. 3.4.4 Issues Lack of Certification Authorities. To date only Verisign has stepped forward as a Certification Authority. The U.S. Postal Service is interested in becoming a Certification Authority but is in the process of implementing the services. 3.4.5 Recommendations Since there already exists a trust relationship between EDI trading partners, until Certification Authorities become more prevalent, and the formats and protocols for interacting with Certification Authorities become standardized, it is recommended that the trading partners self-certify each other and exchange public keys as part of the trading partner relationship. The self-certified certificate should still be exchanged between trading partners in X.509 v3 format, so migration to exchange of notarized certificates is made easier. Since the formats and protocols for use in registering, requesting, and revoking certificates have not been standardized, the use of PCKS #10 and S/MIME is one recommendation. Also, PGP with its circle of trust is another valid option. We recommend that S/MIME be tested for interoperability first, and that PGP v3.0 be tested later. Implementation of the standards for Certification Authority interactions being developed by the IETF-pkix (public-key infrastructure X.509) work group should eventually be adopted. 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 EDI intelligible 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 MD5 is a one-way hash function that is publicly available, produces a 128 bit hash value called a Message Digest. It is widely used or recommended by most e-mail security programs and specifications, such as PEM, PGP, and S/MIME. 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 his trading partners, they can all decrypt something encrypted with ABC's private-key. Decryption using ABC's public-key therefore has the effect of authenticating ABC as the trading partner that did the encryption, and it in effect verifies ABC's digital signature. ABC also cannot say that he did not do the encryption, since he is the only one with knowledge of his private key. In this way, non-repudiation of origin is achieved. So what should a trading partner sign or encrypt with his 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 was 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 Editor's Recommendations In addition to using RSA to encrypt keys, it is recommended that RSA also be used for digital signatures. Again, the RSA algorithm has the advantage that it can be used freely outside the U.S. 3.7 Section: Signed Receipt or Non Repudiation of Receipt 3.7.1 Introduction and Description The signed receipt (or alternately Non Repudiation of Receipt), is a receipt acknowledgment sent by the receiving trading partner to the sending trading partner. The receipt is used to solve the following issues when doing EDI over the Internet: * Lack of mailbox delivery notification within the Internet standards, though these are currently being addressed within RFCs 1891-1894. * Provide the equivalent of VAN mailbox delivery notification. * Provide the equivalent of VAN mailbox pick-up notification. * Provide the equivalent of VAN mailbox authentication. * Detect the situation where EDI Interchanges are maliciously deleted, or are not delivered by the transport. Receipt 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 one- way hash value (or original 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: * Implicit acknowledgment of mailbox delivery of the EDI Interchange to the recipient. * Explicit acknowledgment that the receiver has authenticated the sender and verified the integrity of the sent EDI Interchange. * Guarantees non-repudiation of receipt when the receipt acknowledgment is digitally signed by the receiving trading partner. * 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. The signed receipt should be applicable to more than just EDI. 3.7.3 Recommendations The syntax for a signed receipt should not be specific to EDI, 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 as 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 original message sent must be returned in the third component of the message disposition notification--digitally signed by the receiver of the EDI Interchange. The time-out and retry values for the message disposition notification should be recommended, but needs to be configurable. Duplicates should be checked by the UA and discarded. Until the receipt Internet draft is complete, a combination of RFC1847 and draft-ietf-receipts-mdn should be used to implement this functionality 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. Only one EDI Interchange is sent per e-mail message. 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 useful gateway information may need to be copied and sent as a separate body part. It is proposed that additional fields be specified in RFC 1767 to accommodate EDI specific gateway routing requirements, and this be sent as a separate body part from the encrypted EDI Interchange. 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 Syntax and protocol for specifying EDI Interchanges that have had cryptography applied to it. Choose an existing standard and don't reinvent 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 Recommendation 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 encrypted and signed message 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 traditional EDI via Value Added Networks have some inherent tracking mechanisms, that we have to either duplicate in Internet EDI, or decide we don't need. In Internet EDI, there is no third party to call to track a transmission after it has left one company, and before it has been received by the second company. Also, the move from VAN based EDI to Internet EDI changes the connectivity in other ways. From a more batch oriented store-and-forward technology to a more event driven routing technology. Aside from the communications between companies, "tracking" touches many other points within the trading companies. 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. What tracking information do we really need, and where does the UA have a role in providing it? 1) Transmission successfully translated from internal format to EDI standard format 2) Transmission successfully encrypted and sent (The equivalence of transmission successfully forwarded to receiver's VAN mailbox.) 3) Transmission successfully received by the intended receiver and successfully decrypted (The equivalence of a VAN acknowledgment that sent transmission has been picked up by the receiver.) 4) Transmission successfully translated by the receiver (the EDI Interchange was determined to be syntactically correct.) 5) Detection and recovery of delayed or lost transmissions. 6) Detection and handling of duplicate transmissions. 7) Detection and handling of out-of-sequence transmissions. The question of what the UA needs to track as compared to what the EDI translator tracks is addressed in the following sections. Needs, issues and recommendations will be discussed. 4.2 Section: Transmission successfully translated from internal format to standard EDI format 4.2.1 Need 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 in the UA. 4.3 Section: Transmission successfully encrypted, signed and sent 4.3.1 Need There needs to be a facility by which a sender can be assured that an EDI transmission was successfully encrypted, signed, and sent. 4.3.2 Recommendations * This should be required functionality of the UA. * The UA needs to be able to identify the transmission by its interchange control #, AND a user defined value, if desired. 4.4 Section: Transmission successfully received 4.4.1 Need 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.4.2 Recommendations 1) The UA should track this, and provide the sender with signed receipts. 2) The use of the MDN (message disposition notification) as described in Section 3.7.3, according to the Internet draft by Roger Fajman 3) Note: This could theoretically be accomplished by using a 997 in place of the NRR, however, it's our recommendation to not do that for two 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 we feel this RFC should define interoperability between UA's only, and still cover all angles. 4.5 Section: Transmission successfully translated by receiver 4.5.1 Need There needs to be a facility for the sender to be assured that the receiver could "understand" (in EDI terms) the transmission. 4.5.2 Recommendations This should NOT be tracked by the 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.6 Detection and recovery of delayed or lost transmissions 4.6.1 Need 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.6.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 (more on this below). * Alert/Report. * Ignore/delete (this option may be chosen by someone that has decided to track only at the EDI translator level through 997/CONTRL. 4.7 Detection and handling of duplicate transmissions 4.7.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.7.1 Need 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 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, Raph 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 lengths 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 out 3Q96 * Version 2.6 is available * Qualcomm * Premail * Michael's PGPMIME S/MIME * Two companies have implemented several others have committed * Product is 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 * YesS/MIME * YesMOSS * Yes MSP * Yes 6) Signature ------------ PGP V3.0 * Yes S/MIME * Yes MOSS * Yes MSP * Yes 7) Return Receipt ------------------ PGP V3.0 * Via MIME extensions RFC1891-94 S/MIME * Via MIME extensions RFC1891-94 MOSS * Via MIME extensions RFC1891-94 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 ASN.1 and MIME MOSS * MIME/ ASCII MSP * MIME /ASN.1 16) Envelope / Structure Components (ASN1 Or ASCII) ------------------------------------------------------- PGP V3.0 * ASCII S/MIME * ASN.1and 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 * I DEA in CBC * MD5 & RSA * A 384 for casual grade, 512 commercial grade, 2048 military grade * A 128 bit IDEA key length S/MIME * RSA * RC2 / RC5 * MD5 & RSA * SHA-V * 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) * DH (?) * 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 * Verify with RSA is it multipart/alternative and not /signed? MOSS * Yes MSP * Yes, if used with MIME encapsulation 21) Signature Separate From Signed Document ---------------------------------------------- PGP V3.0 * Yes S/MIME * Yes, optional * Verify with RSA 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 MOSS * YES, but it supports different options in a coherent manner. 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. However one can tell the difference between an encrypted message and a signed/encrypted message. There is not consensus as to if this is a problem or not. MOSS * Yes MSP * Yes 25) Scaleable ------------- PGP V3.0 * No enough experience to tell. The current trust model will not scale well. S/MIME * No enough experience to tell MOSS * No 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. Internet purest do not seem to like the mix. MOSS * Yes MSP * Yes (see 27) Variable Key Sizes Supported ---------------------------------- PGP V3.0 S/MIME * Yes, 40- 128 bit * Symmetric 512-2048 bit RSA MOSS 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 (40 bit DES?) * Alternate sources probably yes 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 * Neutral S/MIME * Neutral MOSS * Neutral MSP * Neutral Author: Chuck Shih Phone: 415 937 3511 USA Chair: Rik Drummond Phone: 817 294 7339 USA