HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:17:36 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 17 Mar 1998 16:31:00 GMT ETag: "2e7a90-1c1f2-350ea544" Accept-Ranges: bytes Content-Length: 115186 Connection: close Content-Type: text/plain EDIINT Working Group Chuck Shih Internet Draft Mats Jansson Expires: 6 /98 Rik Drummond 8 July 1997 Requirements for Inter-operable Internet EDI draft-ietf-ediint-req-04.txt 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. Shih, Janssen, Drummond Page 1 Requirements For Inter-operable Internet EDI 8 July 1997 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Feedback Instructions If you want to provide feedback on this draft, follow these guidelines: -Send feedback via e-mail to the ietf-ediint list for discussion, with "Requirements" in the Subject field. To enter or follow the discussion, you need to subscribe to ietf- ediint@imc.org. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. Table of Contents 1.0 INTRODUCTION 5 1.1 THE AUDIENCE 6 2.0 THE INTERNET - A BRIEF HISTORY 6 2.1 THE INTERNET - MYTHS AND REALITY 6 2.2 INTERNET ROUTING AND SECURITY CONSIDERATIONS 8 2.3 EDI VAN COMMUNICATIONS AND SECURITY 10 2.4 EDI OBJECT BOUNDARIES AND TRANSACTION PRIVACY 11 3.0 FUNCTIONAL REQUIREMENTS 11 3.1 INTRODUCTION AND DEFINITIONS 11 Shih, Janssen, Drummond Page 2 Requirements For Inter-operable Internet EDI 8 July 1997 3.2 STANDARD ENCRYPTION ALGORITHMS AND WORLD-WIDE 11 ENCRYPTION 3.2.1 INTRODUCTION AND DESCRIPTION 11 3.2.2 SYMMETRIC ENCRYPTION 13 3.2.3 ASYMMETRIC ENCRYPTION - PUBLIC-KEY CRYPTOGRAPHY 14 3.2.4 NEEDS 15 3.2.5 ISSUES 15 3.2.6 RECOMMENDATIONS 15 3.3 KEY MANAGEMENT - SYMMETRIC KEYS 18 3.3.1 INTRODUCTION AND DESCRIPTION 18 3.3.2 NEEDS 20 3.3.3 ISSUES 20 3.3.4 RECOMMENDATIONS 20 3.4 KEY MANAGEMENT - PUBLIC AND PRIVATE KEYS 21 3.4.1 INTRODUCTION AND DESCRIPTION 21 3.4.2 PUBLIC KEYS 22 3.4.3 TRUST AND PUBLIC KEYS 23 3.4.4 NEEDS 23 3.4.5 ISSUES 24 3.4.6 RECOMMENDATIONS 24 3.5 CONTENT INTEGRITY 25 3.5.1 INTRODUCTION AND DESCRIPTION 25 3.5.2 NEEDS 26 3.5.3 ISSUES 26 3.5.4 RECOMMENDATIONS 26 3.6 AUTHENTICATION AND NON-REPUDIATION OF ORIGIN 26 3.6.1 INTRODUCTION AND DESCRIPTION 27 3.6.2 NEEDS 28 3.6.3 ISSUES 28 3.6.4 RECOMMENDATIONS 28 3.7 SIGNED RECEIPT AND NON REPUDIATION OF 29 RECEIPT 3.7.1 INTRODUCTION AND DESCRIPTION 29 3.7.2 NEEDS 30 3.7.3 RECOMMENDATIONS 30 3.8 SYNTAX AND PROTOCOL FOR SPECIFYING CRYPTOGRAPHIC 31 SERVICES 3.8.1 INTRODUCTION AND DESCRIPTION 31 3.8.2 NEEDS 31 3.8.3 ISSUES 31 3.8.4 RECOMMENDATIONS 32 Shih, Janssen, Drummond Page 3 Requirements For Inter-operable Internet EDI 8 July 1997 4.0 TRACKING AND ERROR HANDLING BASICS 33 4.1 INTRODUCTION 33 4.2 TRANSMISSION SUCCESSFULLY TRANSLATED FROM 34 INTERNAL FORMAT TO STANDARD EDI FORMAT 4.2.1 NEEDS 34 4.2.2 RECOMMENDATIONS 34 4.3 TRANSMISSION SUCCESSFULLY ENCODED, ENCRYPTED, SIGNED 34 AND SENT 4.3.1 NEEDS 34 4.3.2 RECOMMENDATIONS 34 4.4 TRANSMISSION SUCCESSFULLY DELIVERED TO THE RECIPIENTS 35 MAILBOX 4.4.1 NEEDS 35 4.4.2 RECOMMENDATIONS 35 4.5 TRANSMISSION SUCCESSFULLY RECEIVED 35 4.5.1 NEEDS 35 4.5.2 RECOMMENDATIONS 35 4.6 TRANSMISSION SUCCESSFULLY TRANSLATED BY 36 RECEIVER 4.6.1 NEEDS 36 4.6.2 RECOMMENDATIONS 36 4.7 DETECTION AND RECOVERY OF DELAYED OR LOST 36 TRANSMISSIONS 4.7.1 NEEDS 36 4.7.2 RECOMMENDATIONS 36 4.8 DETECTION AND HANDLING OF DUPLICATE 37 TRANSMISSIONS 4.8.1 NEEDS 37 4.8.2 RECOMMENDATIONS 37 5.0 APPENDIX A - IMPLEMENTATION CONSIDERATIONS, FORMATS, 38 AND EXAMPLES 6.0 ACKNOWLEDGMENTS 52 7.0 REFERENCES 53 8.0 AUTHOR'S ADDRESSES 54 Shih, Janssen, Drummond Page 4 Requirements For Inter-operable Internet EDI 8 July 1997 1.0 Introduction Electronic Data Interchange (EDI) is a set of formats 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. Standards in these and other areas described later in this document 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(s). Additional requirements that mimic many of the header 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 EDI exchanges between the Internet, and the Value Added Networks. However, this specification is not intended to cover the EDI VAN and Internet gateway requirements. 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. Shih, Janssen, Drummond Page 5 Requirements For Inter-operable Internet EDI 8 July 1997 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 the Internet supports high bandwidth communications technologies. 2.1. The Internet - Myths and Reality The Internet had its beginnings in 1969 as an Shih, Janssen, Drummond Page 6 Requirements For Inter-operable Internet EDI 8 July 1997 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. Shih, Janssen, Drummond Page 7 Requirements For Inter-operable Internet EDI 8 July 1997 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 Shih, Janssen, Drummond Page 8 Requirements For Inter-operable Internet EDI 8 July 1997 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. Shih, Janssen, Drummond Page 9 Requirements For Inter-operable Internet EDI 8 July 1997 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 mail-boxing 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 user-id 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. Shih, Janssen, Drummond Page 10 Requirements For Inter-operable Internet EDI 8 July 1997 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. 2.4 EDI Object Boundaries and Transaction Privacy The specification by this work group applies to the EDI Interchange or Bundle (multiple EDI Interchanges) 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(s). 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. As specified by this document, the entire EDI Interchange, including the envelope headers (ISA/IEA or UNA/UNB/UNZ) are encrypted, when encryption security services are applied. 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.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 Shih, Janssen, Drummond Page 11 Requirements For Inter-operable Internet EDI 8 July 1997 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 the derivation of the private key is based on mathematical manipulations of large numerical quantities. The security provided by asymmetric algorithms is not quite proportional to the key length. See section 3.4.2 for more details on the RSA public-key encryption algorithm). Shih, Janssen, Drummond Page 12 Requirements For Inter-operable Internet EDI 8 July 1997 Regardless of whether a symmetric or asymmetric encryption algorithm is used, 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 "pure" symmetric encryption schemes; a shared secret key must be agreed upon by both parties. If a trading partner has n trading partners, 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, management of symmetric keys can be simplified to the point whereby a symmetric key can be used not only for each trading partner, but for each exchange between trading partners. In addition, public key cryptography can be used to unambiguously establish non-repudiation of origin and receipt. Shih, Janssen, Drummond Page 13 Requirements For Inter-operable Internet EDI 8 July 1997 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. In most real world applications, asymmetric encryption algorithms are not actually used to encrypt the message or part of the message itself. Instead, they are used in conjunction with a Message Integrity Check (MIC), and it is the MIC that is encrypted using the public key encryption algorithm. See section 3.5.1 for details on how asymmetric encryption algorithms are applied to a MIC. 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. Shih, Janssen, Drummond Page 14 Requirements For Inter-operable Internet EDI 8 July 199 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; whether the algorithm is available 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 Shih, Janssen, Drummond Page 15 Requirements For Inter-operable Internet EDI 8 July 1997 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 its security is considered "known": in other words, the security of DES is dependent on the length of its key, and estimates can be provided for the time and effort required to derive the DES key from a known 8 byte plain-text/cipher-text pair. 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 [14]. 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 RC5: RC2 and RC5 are proprietary symmetric algorithms of RSA Data Security, Inc. RC2 and RC5 unlike DES, are variable-key length algorithms. By specifying differing key lengths, RC2 and RC5 can be configured to provide greater or lesser security. RC2 and RC5 are Shih, Janssen, Drummond Page 16 Requirements For Inter-operable Internet EDI 8 July 1997 alternatives to DES, and RC2 has special export status, whereby 40 bit versions of RC2, and 56 bit versions of RC2 for foreign subsidiaries and overseas offices of U.S. companies, have expedited export approval from the U.S. government. RSA claims that RC2 and RC5 are faster than DES when implemented in software. Several products such as Lotus Notes, Netscape Navigator, Apple's Open Collaboration Environment, Actra's ECXpert, and Premenos' Templar make use of these algorithms. It is RECOMMENDED that key sizes of 40 bits, 75 bits, and 128 bits be supported for incoming and outgoing EDI messages, when used domestically. U.S. Government restrictions limit | RC2 implementations to 40 bits when exported outside the United States. RC2 SHOULD be used in CBC mode, and RC5 in CVC Pad mode. A key length of 128 bits would make a brute force attack on RC2 or RC5 not feasible. 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 most commercial applications a key length of at least 75 bits is RECOMMENDED. See [14] and [15] for additional guidance on choosing key lengths. For EDI Interchanges of minimal value, 40-bit RC2 or 56-bit DES are probably adequate. For more valuable EDI interchanges, use of Triple-DES, IDEA, or 128 bit length RC2 or RC5 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 its security is "known". RC2 and RC5 are useful because they allow the security of the encryption - the key length specification, to be Shih, Janssen, Drummond Page 17 Requirements For Inter-operable Internet EDI 8 July 1997 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. IDEA's 128 bit key-length provides more than adequate security. 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. As previously mentioned, by using public key cryptography, management of symmetric keys can be simplified such that a symmetric key can be used not only for each trading partner, but for each exchange between trading partners. In addition, public key cryptography can be used to unambiguously establish non-repudiation of origin and receipt. The use of public-key cryptography, whereby the symmetric encryption key is encrypted using an asymmetric encryption algorithm, simplifies the management of the symmetric Shih, Janssen, Drummond Page 18 Requirements For Inter-operable Internet EDI 8 July 1997 keys and makes their exchange much more secure. Trading partners do not need to agree on secret symmetric keys as part of the trading partner agreement, nor is there the origin authenticity problem that is inherent with pure symmetric key management schemes. A symmetric key can be randomly generated by the software for each EDI transaction between trading partners. Symmetric keys generated on a per transaction basis are sometimes referred to as "session keys". Since a unique symmetric key is generated for each EDI transaction, symmetric key maintenance is no longer required. Trading partners do not need to invalidate compromised or expired keys. Each symmetric or "session" 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 using public key cryptography for symmetric key management, the following steps would be performed when trading partner ABC sends to trading partner XYZ: 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. Shih, Janssen, Drummond Page 19 Requirements For Inter-operable Internet EDI 8 July 1997 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 on a transaction basis. 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 Agreement by trading partners to use public-key cryptography to manage symmetric keys, and to generate a symmetric key for each EDI transaction. When choosing public-key encryption algorithms, the following criteria should be considered; how secure the algorithm is; how fast implementations of the algorithm are; whether the algorithm is available 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 Shih, Janssen, Drummond Page 20 Requirements For Inter-operable Internet EDI 8 July 1997 RSA is a public-key encryption algorithm that has become a de facto standard in its use for symmetric key management. Its use is RECOMMENDED in managing and distributing symmetric encryption keys when doing EDI over the Internet. The RSA public-key algorithm is not patented outside the United States, and therefore can be freely used outside the U.S. In the United States, the RSA public-key encryption algorithm is protected by the following patent: R. Rivest, A. Shamir, and L. Adleman "Cryptographic Communications System and Method" U.S. Patent #4,405,829 September, 1983 At this time, a license to use the RSA encryption algorithm is required within the United States. Both S/MIME and PGP/MIME make use of the RSA encryption algorithm to encrypt/decrypt "session keys". For a recommendation on RSA key lengths, see Section 3.4.2, on Public Keys. 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 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. Shih, Janssen, Drummond Page 21 Requirements For Inter-operable Internet EDI 8 July 1997 3.4.2 Public Keys A public key is used by an originating trading partner to encrypt a symmetric key, and as will be discuss later, by a receiving trading partner to verify authenticity of the originator. The mathematics of public key cryptography is complicated, but are based on mathematical manipulations of large numerical quantities. In the case of RSA, deriving the private key from the public key is based on the difficulty in factoring large numbers. An RSA public key is generated by multiplying two large prime numbers together, deriving the private key from the public key involves factoring the product of the two large prime number. Unlike the symmetric encryption algorithms discussed above, the RSA asymmetric encryption algorithm's security is based on the size of the number that needs to be factored. The size or "modulus" of the product of two prime numbers can be factored using some "fast factoring algorithms" which currently exist. The computing power required by these "fast factoring algorithms" can be estimated, and thus the time and cost to factor a number of any given size can also be estimated. Some estimates which have been put forth claim that a 1 "MIP" computer operating for 1 year would take 74 years to factor a modulus of 100 digits or approximately 332 bits. A 150 (~500 bits) digit modulus would take 1,000,000 MIP years, a 200 digit modulus (~664 bits) 4,000,000,000 MIP years, and a 350 digit modulus (~1162 bits) would take 10 to 16th MIP years. Given a large enough modulus, it becomes an impossible task to "break" or derive a private key from a public key. The RSA key length is configurable, but as the cost of computing power decreases - assume for instance, a decrease in computing costs by a factor of ten every 5 years -- then by the year 2030, a 512 bit public key can be "broken" for $10 [14]. When using the RSA encryption algorithm to encrypt symmetric keys, support of 512 bit to 1024 bit variable key lengths is REQUIRED. In general, asymmetric algorithms require longer keys to provide the same level of security as their symmetric key cousins. A comparison of asymmetric key lengths (for algorithms like RSA that are based on the factoring problem), Shih, Janssen, Drummond Page 22 Requirements For Inter-operable Internet EDI 8 July 1997 needed to provide the equivalent "security" against "brute force" attacks can be found in [15]. For example, a 512 bit RSA encryption key is equivalent to a 64 bit symmetric key. A 768 bit RSA encryption key is equivalent to an 80 bit symmetric key. It is RECOMMENDED that for EDI transactions requiring the use of RSA encryption to protect "session keys", that at least a 768 bit RSA encryption key be used. For very "high" value EDI transactions, at least a 1024 bit or higher key SHOULD be used. 3.4.3 Trust and Public Keys When using public key cryptography, there is a "trust" issue that arises: how can one trading partner be sure that the public key of another trading partner is bound to that trading partner, and is valid? Trading partners must exchange public keys or be able to access each other's public key in a manner that is acceptable to each of the trading partners. One method by which trading partners can exchange public key information is through the use of public key certificates. Public key certificates come in many different formats, and the trust model on which they are based also come with different underlying assumptions. Public key certificates based on the X.509 standards however are becoming prevalent in their use. The X.509 certificate 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.4 Needs Adoption of a trust model, or the use of certification authorities for issuing commercial grade/class 3 Shih, Janssen, Drummond Page 23 Requirements For Inter-operable Internet EDI 8 July 199 certificates. Each trading partner must choose a trust model. For instance, trading partners can self-certify one another, or they could use certification authorities acceptable to their other trading partners. 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 need to be agreed to and standardized. 3.4.5 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.6 Recommendations 3.4.6.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, "self-certification" means that 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 Shih, Janssen, Drummond Page 24 Requirements For Inter-operable Internet EDI 8 July 1997 certificate authorities. It is also RECOMMENDED that trading partners exchange certificates using the formats and protocols specified by "certificate-only" PKCS7 when using S/MIME, and PGP certificate formats and protocols when using PGP/MIME. 3.4.6.2 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. PKCS7 and PKCS10 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. Unlike encryption algorithms however, one-way hash functions can't be reversed or "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. Shih, Janssen, Drummond Page 25 Requirements For Inter-operable Internet EDI 8 July 1997 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 and MIME content headers. This value is unique and "fingerprints" the transaction. 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 and MIME content headers. 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. It is RECOMMENDED that all new implementations use SHA-1 for outgoing messages, but to continue to accept MD5 incoming (SHA1 as well) as there already exist many MD5 implementations. 3.6 Authentication and Non-Repudiation of Origin Shih, Janssen, Drummond Page 26 Requirements For Inter-operable Internet EDI 8 July 1997 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 in symmetric key management to encrypt a symmetric key. 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 encryption is done with the private key, and decryption is done 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 applied the encryption, since she is the only one with knowledge of her private key. In this way, non-repudiation of origin is achieved. Shih, Janssen, Drummond Page 27 Requirements For Inter-operable Internet EDI 8 July 199 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 is authentication and non-repudiation of origin 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; whether the algorithm is available 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 symmetric 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. The RECOMMENDED key lengths when using the RSA encryption algorithm for signature, are the same as when using RSA Shih, Janssen, Drummond Page 28 Requirements For Inter-operable Internet EDI 8 July 1997 encryption for managing symmetric keys: For most EDI transactions requiring digital signatures, a 768 bit RSA encryption key SHOULD be used. For very "high" value EDI transactions, at least a 1024 bit or higher key SHOULD be used. 3.7 Signed Receipt or Non Repudiation of Receipt 3.7.1 Introduction and Description The term used for both the functional activity and message for acknowledging receipt of an EDI/EC interchange is "receipt", or "signed receipt". The first term is used if the acknowledgment is for an interchange resulting in a receipt which is NOT signed. The second term is used if the acknowledgment is for an interchange resulting in a receipt which IS signed. A term often used in combination with receipts is "Non-repudiation of Receipt (NRR). NRR refers to a legal event which occurs only when the original sender of an interchange has verified the sender and content of a "signed receipt". Note that NRR is not possible without signatures. The signed receipt is an acknowledgment sent by the receiving trading partner to the sending trading partner. The signed receipt is used to address the following issues when doing Internet EDI: 1). The lack of wide-spread RFC 1894 based mailbox delivery notification implementations within the Internet mail infrastructure. 2). It provides the equivalent of VAN mailbox delivery notification. 3). It provides the equivalent of VAN mailbox pick-up notification. 4). It provides the equivalent of VAN mailbox authentication. 5). It can 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 Shih, Janssen, Drummond Page 29 Requirements For Inter-operable Internet EDI 8 July 1997 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 contents 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, and successfully verified by the sender. 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 configurable. 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. The results of the IETF receipt working group SHALL be adopted as the basis for implementing signed receipts. The receipt working group has published an Internet draft -- draft-ietf-receipt-mdn-04 [5], which can be obtained off of the IETF World Wide Web site. The EDIINT working group has taken on the work item to develop the needed Shih, Janssen, Drummond Page 30 Requirements For Inter-operable Internet EDI 8 July 1997 extensions to the MDN draft that is required within an EDI environment. See Internet Draft: "MIME-based Secure EDI" [10]. When a signed receipt is used by trading partners, the message integrity check that is verified by the receiving trading partner must be returned to the originating trading partner in the signed receipt. 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 MUST be implemented using a MIME multipart/signed type/subtype with the message disposition notification as the first part of the content of the multipart/signed. A MIC is then calculated over the message disposition notification, and this MIC is digitally signed and MUST be returned as the second part of the multipart/signed content. 3.8 Syntax and Protocol for Specifying Cryptographic Services 3.8.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, and public-key certificates, need to be enveloped and sent along with the EDI Interchange. 3.8.2 Needs A syntax and protocol for specifying EDI Interchanges that have had cryptography applied to them, 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.8.3 Issues The IETF EDIINT work group has put together a matrix comparing many of the different ways that EDI with Shih, Janssen, Drummond Page 31 Requirements For Inter-operable Internet EDI 8 July 1997 cryptography applied to it can be transmitted. Several standards appear to fulfill the security requirements needed by this work group. S/MIME [8], and PGP/MIME [4] are both viable alternatives. Each has its strengths and weaknesses: The S/MIME specification allows "signed and enveloped" and "signed" to be distinguished. The signatories in an S/MIME "signed and enveloped" content type can be distinguished, which in certain EDI and electronic commerce situations is not acceptable. However, the S/MIME Implementation Guide, Version 2 [11], does address this concern by specifying that "signed and enveloped" not be used, and a two step sign and then encrypt process be used instead. S/MIME is very flexible and can accommodate many different security algorithms and key lengths. PGP 4.5 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 4.5 does not give the user as much flexibility in choosing algorithms and key lengths, although the security profile used by PGP 4.5 is more than adequate to insure confidentiality, non-repudiation of origin, and message integrity. The recommended security format should also be transport independent so it can be used with different Internet transports. The standard should have broad support, and implementations should be available. 3.8.4 Recommendations Either one of S/MIME or PGP/MIME fulfill the requirements of the EDIINT work group. The S/MIME Implementation Guide [11], requires the signedData format be supported, and the multipart/signed, as specified in RFC 1847 [6], is recommended. For use in Internet EDI, support of multipart/signed is REQUIRED, and signedData is RECOMMENDED only when sending EDI through known gateways that do not honor 7-bit transfer encoding. PGP/MIME is based on multipart/signed and multipart/encrypted. Shih, Janssen, Drummond Page 32 Requirements For Inter-operable Internet EDI 8 July 1997 The Appendix of this document specifies how S/MIME, and PGP/MIME are to be applied for use in Internet EDI. See section 5.4 for implementation notes, and examples on S/MIME and PGP/MIME formats. 4.0 Tracking and Error Handling Basics 4.1 Introduction It is 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. 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 Shih, Janssen, Drummond Page 33 Requirements For Inter-operable Internet EDI 8 July 1997 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 be assured 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 MUST 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. Shih, Janssen, Drummond Page 34 Requirements For Inter-operable Internet EDI 8 July 1997 The EDI UA MUST be able to identify the transmission by its message id, AND a calculated MIC 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 RFC 1894 [12]. 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 MUST be 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 X12 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 (signed receipt). * Translators are very different, and the CONTRL message isn't supported by all EDI translators or is it in widespread use yet. Shih, Janssen, Drummond Page 35 Requirements For Inter-operable Internet EDI 8 July 1997 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 sender should specify that a receipt or signed receipt be returned in response to the sent message. The way to request that a receipt or message disposition notification be returned by the recipient is specified in draft-ietf-receipt-mdn-04.txt [5]. The way to request that a signed receipt be returned by the recipient is specified in draft-ietf-ediint- as1-03.txt [10]. 2). Both the receipt and signed receipt return the message id that was sent in the original message. In addition to the original message id, the signed receipt also returns the message integrity check calculated on the contents of the received message. 3). The information in the receipt or signed receipt can then be used to correlate to the originally Shih, Janssen, Drummond Page 36 Requirements For Inter-operable Internet EDI 8 July 1997 signed message. NOTE: A receipt or signed receipt MUST NOT be requested when sending a receipt or signed receipt. This is explicitly prohibited by the standards. 4). If a receipt or signed receipt is not returned within a configurable time, then actions based on the failure to receive a receipt or signed receipt may include: * Re-transmit: If re-transmitted, the receiving UA MUST be able to detect the second transmission as a duplicate and discard it. * Alert/Report: Operator intervention may be required to track the cause of the delay in receiving the receipt or signed receipt. 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 correctly. First, translator initiated duplicates SHOULD NOT be halted in any way - it should be assumed that translators will handle that level of duplication. 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 the duplicate transmissions after the first has been received. 4.8.2 Recommendations By applying a signature to the EDI MIME content, the originator will send a message integrity check to the recipient of the transmission. The recipient SHOULD log the received message integrity check along with the other security related information associated with the received message. Duplicate messages can be detected by the recipient by comparing the message integrity check received each time, with the log of received message integrity Shih, Janssen, Drummond Page 37 Requirements For Inter-operable Internet EDI 8 July 1997 checks. It is recommended that EDI UAs, in order to detect duplicate transmissions, agree minimally to sending and receiving signed content. EDI related control numbers, such as the ISA control number, should not be checked by the EDI UA. A duplicate EDI message can still be distinguished at the MIME messaging level, since EDI time stamps will change, even if the EDI control number or EDI transaction are duplicates. 5. Appendix A - Implementation Considerations, Formats, and Examples 5.1 Introduction The following appendix describes the structure of EDI MIME messages, making use of the security features previously discussed in this requirements document. The structures shown below represent the use of specifications outlined in the following RFCs and Internet-drafts. Before moving into the structures themselves, there is a brief review of what each document contributes. NOTE: The examples below are just that - examples. Do not code according to them. Refer to the RFCs that specify the correct grammar in each case. 5.2 Referenced RFCs and their contribution 5.2.1 RFC 821 SMTP [7] This is the core mail transfer standard that all MTAs need to adhere to. 5.2.2 RFC 822 Text Message Format [3] Defines message header fields and the parts making up a message. 5.2.3 RFC 1847 MIME Security Multiparts [6] This document defines security multiparts for MIME: multipart/encrypted and multipart/signed. 5.2.4 RFC 1892 Multipart/report [10] Shih, Janssen, Drummond Page 38 Requirements For Inter-operable Internet EDI 8 July 1997 This RFC defines the use of Multipart/report content type, something that the MDN draft (fajman) builds upon to define the receipts functionality. 5.2.5 RFC 1767 EDI Content [2] This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and mutually defined EDI (application/EDI-Consent). 5.2.6 RFC 2015 PGP/MIME [4] This RFC defines the use of content types "multipart/encrypted", "multipart/signed", "application/pgp encrypted" and "application/pgp-signature" for defining MIME PGP content. 5.2.7 RFC 2045, 2046, and 2049 MIME [1] These are the basic MIME standards, upon which all MIME related RFCs build, including this one. Key contributions include definition of "content type", "sub-type" and "multipart", as well as encoding guidelines, which establishes 7-bit US-ASCII as the canonical character set to be used in Internet messaging. 5.2.8 Internet draft (fajman):Message Disposition Notification [5] This Internet draft defines how a message disposition notification (MDN) is requested, and the format and syntax of the MDN. The MDN is the basis upon which receipts and signed receipts are defined for Internet EDI. 5.2.9 Internet draft (dusse): S/MIME Message Specification [8] This specification describes how MIME shall carry PKCS7 envelopes. 5.3 Structure of an EDI MIME message - No encryption/No signature To: Subject: From: Date: Shih, Janssen, Drummond Page 39 Requirements For Inter-operable Internet EDI 8 July 1997 Mime-Version: 1.0 Content-Type: Application/ Content-Transfer-Encoding: 5.4 Structure of an EDI MIME message - S/MIME 5.4.1 S/MIME Overview S/MIME or the Secure/Multipurpose Internet Mail Extensions, specify formats and procedures when the cryptographic security services of authentication, message integrity, non-repudiation of origin, and confidentiality are applied to Internet MIME messages. S/MIME is specified in Internet draft, draft-dusse-mime-msg- spec-00.txt [8], and an S/MIME implementation guide [11] is available from RSA Data Securities, Inc. This applicability statement sets forth the implementation requirements and recommendations needed to use S/MIME when sending EDI on the Internet. These implementation requirements and recommendations are intended to ensure a base level of inter-operability among S/MIME EDI implementations. NOTE: The S/MIME Implementation Guide, Version 2 specifies a restricted profile for use for export purposes and an unrestricted profile for use domestically. These profiles specify the cryptographic algorithms and key lengths that a conforming S/MIME implementation must support. It is RECOMMENDED for Internet EDI, that these profiles be adhered to. However, cryptographic algorithms, and key lengths are parameters that need to be set by the trading partnership, and can vary from what is specified by the S/MIME implementation guide, as well as this specification. Content Types: The signedAndEnvelopedData content type SHOULD NOT be used when sending EDI on the Internet. Objections have been raised concerning the fact that the issuerAndSerialNumber for each signer of a signedAndEnvelopedData content is left in the clear. This information could be used to derive the identity of the signer of the message. The Shih, Janssen, Drummond Page 40 Requirements For Inter-operable Internet EDI 8 July 1997 use of signedAndEnvelopedData also precludes the ability to sign information that is in addition to, but separate from the primary signed contents. The use of S/MIME "authenticated attributes" is not required for Internet EDI, since it is generally sufficient to sign the EDI MIME content and headers. The S/MIME Implementation Guide, Version 2 requires a compliant S/MIME agent to support the nesting of a signed "message" format within an enveloped "message", for both incoming and outgoing messages. For Internet EDI, it is also REQUIRED that implementations support a nested signed "message" within an enveloped or encrypted "message". Therefore, when using S/MIME for the purpose of Internet EDI, a two step process MUST be used: the user agent first creates a multipart/signed "content", and uses this multipart/signed "content" as input to the creation of an application/x-pkcs-7-mime enveloped "message". The receiver of an incoming enveloped "message" that is decrypted and found to contain a multipart/signed "content", MUST process the multipart/signed "content" and present the signature status and corresponding first body part of the multipart/signed to the receipts processing -- if either a request for a receipt or signed receipt has been made -- otherwise, the first body part of the multipart/signed is passed to a general MIME processor. For the purpose of Internet EDI, the first body part of the multipart/signed SHOULD contain RFC 1767 specified MIME EDI content, or a MIME multipart/mixed content that has at least one RFC 1767 MIME EDI content as part of the multipart/mixed content. Multipart/Signed and signedData: The S/MIME specification requires support of the signedData content format, and recommends support of the multipart/signed format. For use in Internet EDI however, it is REQUIRED that the multipart/signed format be supported, whenever message authentication, integrity, and non-repudiation of origin are used. The great value for support of the multipart/signed format is the ability of non S/MIME-enabled agents to process the content of the body that was signed. The PKCS7 signedData format MAY be used only when it is known Shih, Janssen, Drummond Page 41 Requirements For Inter-operable Internet EDI 8 July 1997 that the EDI data is to pass through non RFC 1847 compliant gateways. Some non RFC 1847 compliant gateways do not treat the message contents as opaque, and may change the content transfer encoding, thereby invalidating the message integrity check that was calculated by the sender. Support of the PKCS7 signedData format for use in Internet EDI is OPTIONAL, and MUST be agreed upon between trading partners. 5.4.2 Example: S/MIME - Signature Only (Multipart/Signed) To: Subject: From: Date: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="separator"; micalg=rsa-; protocol="application/x-pkcs7-signature" --separator &Content-Type: Application/ &Content-Transfer-Encoding: & & --separator Content-Type: application/x-pkcs7-signature fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQer /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/D frtFFKFG+GFff= =ndaj --separator-- Notes: -The lines preceded with "&" is what the signature is calculated over. 5.4.3 Example: S/MIME - Signature Only (signedData) To: Subject: From: Shih, Janssen, Drummond Page 42 Requirements For Inter-operable Internet EDI 8 July 1997 Date: Mime-Version: 1.0 Content-Type: application/x-pkcs7-mime Content-Transfer-Encoding: base64 &Mime-Version: 1.0 &Content-Type: Application/; &Content-Transfer-Encoding: & & Notes: -The lines preceded with "&" is what the signature is calculated over - consists of (refer to: PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): ContentType = SignedData version = Version digestAlgorithms = DigestAlgorithmIdentifiers contentType = Data content = NOTE: that except for ContentType and Content, the actual object identifiers or values for the fields are not specified. (See PKCS9 and the S/MIME Implementation Guide, Version 2 from RSA Labs, Inc., for these object identifiers.) - consists of (refer to: PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): signerInfos = SignerInfo NOTE: The signerInfo contains the digestAlgorithm, the digestEncryptionAlgorithm, and the encryptedDigest or the digital signature. The issuerAndSerialNumber field defined within the signerInfos identifies a signing trading partner's public-key certificate. Since Internet EDI allows self-certification, this field can contain the distinguished name of the sending trading partner or it can contain an actual issuer's distinguished name. Shih, Janssen, Drummond Page 43 Requirements For Inter-operable Internet EDI 8 July 199 5.4.4 Example: S/MIME - Encryption Only To: Subject: From: Date: Mime-Version: 1.0 Content-Type: application/x-pkcs7-mime Content-Transfer-Encoding: base64 &Mime-Version: 1.0 &Content-Type: Application/; &Content-Transfer-Encoding: & & Notes: -The text preceded by "&" indicates that it is really encrypted, but presented as text for clarity - consists of (See PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): contentType = EnvelopedData version = Version recipientInfos = RecipientInfos contentType = Data contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier encryptedContent = NOTE: Except for contentType, the actual object identifiers or values for the fields are not specified. (See PKCS9 and the S/MIME Implementation Guide, Version 2 from RSA Labs, Inc., for these objects.) NOTE: The recipientInfos contains the symmetric encryption key encrypted with the receiver's public key. The issuerAndSerialNumber field defined within the recipientInfos identifies a receiving trading partner's public-key certificate. Since Internet EDI allows self-certification, this field can contain the distinguished name of the Shih, Janssen, Drummond Page 44 Requirements For Inter-operable Internet EDI 8 July 1997 receiving trading partner or the issuer distinguished name. NOTE: In general there will be one recipientInfos specified, but in the case of RFQs, there may be n recipientInfos specified. 5.4.5 Example: S/MIME - Signature and Encryption (Multipart/Signed) The required support for EDI Internet is to first create a MIME multipart/signed content, and then to create an application/x-pkcs7-mime envelopedData message with the multipart/signed content as the input to the envelopedData message. To: Subject: From: Date: Mime-Version: 1.0 Content-Type: application/x-pkcs7-mime Content-Transfer-Encoding: base64 *Content-Type: multipart/signed; boundary="separator"; * micalg=rsa-; * protocol="application/x-pkcs7-signature" * *--separator * &Content-Type: Application/ * &Content-Transfer-Encoding: * & * & * *--separator * Content-Type: application/x-pkcs7-signature * Content-Transfer-Encoding: * * fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553// * /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88 * frtFFKFG+GFff= * *--separator-- Notes: - The lines preceded with "&" is what the signature is calculated over. - The text preceded by "*" indicates that it is really encrypted, but Shih, Janssen, Drummond Page 45 Requirements For Inter-operable Internet EDI 8 July 1997 presented as text for clarity. - consists of (See PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): contentType = EnvelopedData version = Version recipientInfos = RecipientInfos contentType = Data contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier encryptedContent = NOTE: Except for contentType, the actual object identifiers or values for the fields are not specified. (See PKCS9 and the S/MIME Implementation Guide, Version 2 from RSA Labs, Inc., for these objects.) NOTE: The recipientInfos contains the symmetric encryption key encrypted with the receiver's public key. The issuerAndSerialNumber field defined within the recipientInfos identifies a receiving trading partner's public-key certificate. Since Internet EDI allows self-certification, this field can contain the distinguished name of the receiving trading partner or the issuer distinguished name. NOTE: In general there will be one recipientInfos specified, but in the case of RFQs, there may be n recipientInfos specified. 5.4.6 Example: S/MIME - Signature and Encryption (signedData) To: Subject: From: Date: Mime-Version: 1.0 Content-Type: application/x-pkcs7-mime Content-Transfer-Encoding: base64 *Content-Type: application/x-pkcs7-mime * * *&Content-Type: Application/; Shih, Janssen, Drummond Page 46 Requirements For Inter-operable Internet EDI 8 July 1997 *&Content-Transfer-Encoding: *& * * Notes: - The lines preceded with "&" is what the signature is calculated over. - The text preceded by "*" indicates that it is really encrypted, but presented as text for clarity - consists of (See PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): contentType = EnvelopedData version = Version recipientInfos = RecipientInfos contentType = Data contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier encryptedContent = NOTE: Except for contentType, the actual object identifiers or values for the fields are not specified. (See PKCS9 and the S/MIME Implementation Guide, Version 2 from RSA Labs, Inc., for these objects.) NOTE: The recipientInfos contains the symmetric encryption key encrypted with the receiver's public key. The issuerAndSerialNumber field defined within the recipientInfos identifies a receiving trading partner's public-key certificate. Since Internet EDI allows self-certification, this field can contain the distinguished name of the receiving trading partner or an issuer's distinguished name. NOTE: In general there will be one recipientInfos specified, but in the case of RFQs, there may be n recipientInfos specified. - consists of (refer to: PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): signerInfos = SignerInfo Shih, Janssen, Drummond Page 47 Requirements For Inter-operable Internet EDI 8 July 1997 NOTE: The signerInfo contains the digestAlgorithm, the digestEncryptionAlgorithm, and the encryptedDigest or the digital signature. The issuerAndSerialNumber field defined within the signerInfos identifies a signing trading partner's public-key certificate. Since Internet EDI allows self-certification, this field can contain the distinguished name of the sending trading partner or an issuer's distinguished name. 5.5 Structure of an EDI MIME message - PGP/MIME 5.5.1 Overview PGP provides two functional services, signature and encryption, but in reality performs 5 functions in order to do it effectively. 1) Digital signature (MD5, RSA) 2) Compression (ZIP) 3) Message Encryption (IDEA) 4) ASCII Armor 5) Message segmentation When sending a message, the services are performed in that order. With the exception of item 5), these services are optional, meaning a user can choose whether to use signature, encryption, compression and ASCII armor, but commonly, 2) and 4) are always used, while 1) and 3) are used in three ways: 1) Signature only, in which case ASCII armor can be applied only to the signature block to keep the message legible. 2) Encryption only 3) Both signature and encryption Applicability of PGP/MIME and RFC 2015, for use in Internet EDI dictates the following: - When both encryption and signature feature is used, the EDI data is first signed, then encrypted in a two-step process, as described in the example. -Compression and ASCII Armor is optional and could be user Shih, Janssen, Drummond Page 48 Requirements For Inter-operable Internet EDI 8 July 1997 configurable. The following examples describe use of PGP/MIME without compression and ASCII armor, since those services are managed by PGP, and are optional per this draft 5.5.2 Example: PGP/MIME - Signature Only To: Subject: From: Date: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="separator"; micalg=pgp-; protocol="application/pgp-signature" --separator &Content-Type: Application/ &Content-Transfer-Encoding: & & --separator Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version 2.6.2 fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQer /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/D frtFFKFG+GFff= =ndaj -----END PGP MESSAGE----- --separator-- Notes: -The lines preceded with "&" is what the signature is calculated over. 5.5.3 Example: PGP/MIME - Encryption Only To: Subject: Shih, Janssen, Drummond Page 49 Requirements For Inter-operable Internet EDI 8 July 1997 From: Date: Mime-Version: 1.0 Content-Type: multipart/encrypted; boundary="separator"; protocol="application/pgp-encrypted" --separator Content-Type: application/pgp-encrypted Version: 1 --separator Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version 2.6.2 & &Content-Type: Application/; &Content-Transfer-Encoding: & & -----END PGP MESSAGE----- --separator-- Notes: -The text preceded by "&" indicates that it is really encrypted, but presented as text for clarity -"pgp control information" contains the following, but refer to PGP specifications or tool kits for details: -Key ID of recipient's public key -Session key (symmetric) -Timestamp -Key ID of sender's public key -Leading two octets of message digest -Message digest -Filename -Timestamp 5.5.4 Example: PGP/MIME - Signature and Encryption The sequence here is that the EDI data is first signed as a Shih, Janssen, Drummond Page 50 Requirements For Inter-operable Internet EDI 8 July 1997 multipart/signed body, and then the data plus the signature is encrypted to form the final multipart/encrypted body. To: Subject: From: Date: Mime-Version: 1.0 Content-Type: multipart/encrypted; boundary="separator"; protocol="application/pgp-encrypted" --separator Content-Type: application/pgp-encrypted Version: 1 --separator Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version 2.6.2 * * Content-Type: multipart/signed; boundary="signed separator"; * micalg=pgp-; protocol="application/pgp-signature" * * --signed separator * &Content-Type: Application/ * &Content-Transfer-Encoding: * & * & * * --signed separator * Content-Type: application/pgp-signature * * -----BEGIN PGP MESSAGE----- * Version 2.6.2 * * fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytd * /GIUIUgsIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF * frtFFKFG+GFff= * =ndaj * -----END PGP MESSAGE----- * * --signed separator-- -----END PGP MESSAGE----- --separator- Shih, Janssen, Drummond Page 51 Requirements For Inter-operable Internet EDI 8 July 199 Notes: - The lines preceded with "&" is what the signature is calculated over. - The text preceded by "*" indicates that it is really encrypted, but presented as text for clarity - "pgp control information" contains the following, but refer to PGP specifications or tool kits for details: -Key ID of recipient's public key -Session key (symmetric) -Timestamp -Key ID of sender's public key -Leading two octets of message digest -Message digest -Filename -Timestamp -RFC 2015 allows another way to handle the above in a combined fashion, However, for the purpose of EDI we require the above method, which is based on MIME Security Multiparts [4] RFC 1847. This method performs signature and encryption in a two-step process, first signing the data, then encrypting it. This is also consistent with PGP's recommendations. 5.6 Additional Considerations RFC 1847 [6] and RFC 1848 [13] provide valuable guidance when implementing the multipart/signed content. In particular, RFC 1848 provides the canonicalization considerations required when implementing the multipart/signed content. 6. Acknowledgments The authors would like to extend special thanks to Lincoln Yarbrough for his support and championing of these open Internet EDI standards. This document is the result of the many contributions of the members of the IETF EDIINT Working group, including Harald Alvestrand, Jim Galvin, Karen Rosenthal, Dale Moberg, Carl Hage, Jun Ding, and Pedro Chiang. Shih, Janssen, Drummond Page 52 Requirements For Inter-operable Internet EDI 8 July 1997 7. References [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 02, 1996. N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 02, 1996. N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 02, 1996. [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 2, 1995. [3] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 13, 1982. [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2015, Sept. 1996. [5] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", draft-ietf-receipt-mdn-04.txt, April 16, 1997. [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 3, 1995. [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1, 1982. [8] S. Dusse, "S/MIME Message Specification; PKCS Security Services for MIME", Internet draft: draft-dusse-mime-msg-spec 00.txt [9] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 15, 1996. [10] M. Jansson, C. Shih, R. Drummond, "MIME-based Secure EDI", Internet draft: draft-ietf-ediint-as1-04.txt, June 9, 1997. Shih, Janssen, Drummond Page 53 Requirements For Inter-operable Internet EDI 8 July 1997 [11] S/MIME Editor, "S/MIME Implementation Guide, Interoperability Profiles, Version 2", Draft, Revised October 8, 1996. [12] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notification", RFC 1894, January, 1996. [13] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security Services", RFC 1848, October, 1995. [14] B. Schneier, "E-Mail Security", John Wiley & Sons, 1995. [15] B. Schneier, "Applied Cryptography", 2e. John Wiley & Sons, 1996. [16] M. Blaze, W. Diffie, R. L. Rivest, B. Schneier, T. Shimomura, E. Thompson, M. Wiener, "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security". 8. Author's Address: Chuck Shih 610 Caribbean Drive Sunnyvale, CA. 94089 Phone: 408-542-3282 Fax: 408-542-3210 e-mail: chucks@actracorp.com Mats Jansson mjansson@agathon.com LiNK 1026 Wilmington Way Redwood City, CA 94062 USA Rik Drummond drummond@onramp.net The Drummond Group 5008 Bentwood Ct. Ft. Worth, TX 76132 USA Shih, Janssen, Drummond Page 54 Requirements For Inter-operable Internet EDI 8 July 1997