idnits 2.17.1 draft-ietf-ediint-req-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 47 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 93 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 50 has weird spacing: '...nternet and s...' == Line 382 has weird spacing: '... a very good ...' == Line 577 has weird spacing: '... random data ...' == Line 593 has weird spacing: '...must be maint...' == Line 709 has weird spacing: '...cluding those...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 2462, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2480, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2298 (ref. '5') (Obsoleted by RFC 3798) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 821 (ref. '7') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2630 (ref. '8') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 1892 (ref. '9') (Obsoleted by RFC 3462) == Outdated reference: A later version (-17) exists of draft-ietf-ediint-as1-10 ** Obsolete normative reference: RFC 1894 (ref. '11') (Obsoleted by RFC 3464) ** Downref: Normative reference to an Historic RFC: RFC 1848 (ref. '12') -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EDIINT Working Group T. Harding 2 Internet Draft Cyclone Software 3 Expires: Mar / 2000 R. Drummond 4 Drummond Group 5 Chuck Shih 6 Gartner Group 7 September, 1999 9 Requirements for Inter-operable Internet EDI 11 draft-ietf-ediint-req-08.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as "work 27 in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Any questions, comments, and reports of defects or ambiguities in 36 this specification may be sent to the mailing list for the EDIINT 37 working group of the IETF, using the address 38 . Requests to subscribe to the mailing list 39 should be addressed to . 41 Copyright Notice 43 Copyright (c) The Internet Society (1998). All rights reserveds. 45 Abstract 47 This document is a functional specification, discussing the 48 requirements for inter-operable EDI, with sufficient background 49 material to give an explanation for the EDI community of the 50 Internet and security related issues. 52 Requirements For Inter-operable Internet EDI September 1999 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 55 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 56 "OPTIONAL" in this document are to be interpreted as described in 57 RFC 2119. 59 Feedback Instructions: 61 If you want to provide feedback on this draft, follow these 62 guidelines: 64 -Send feedback via e-mail to the ietf-ediint list for discussion, 65 with "Requirements" in the Subject field. To enter or follow the 66 discussion, you need to subscribe to ietf-ediint@imc.org. 68 -Be specific as to what section you are referring to, preferably 69 quoting the portion that needs modification, after which you state 70 your comments. 72 -If you are recommending some text to be replaced with your 73 suggested text, again, quote the section to be replaced, and be 74 clear on the section in question. 76 Table of Contents 78 Security Considerations 4 79 1.0 Introduction 4 80 1.1 The Audience 5 81 2.0 The Internet - A Brief History 5 82 2.1. The Internet - Myths and Reality 6 83 2.2 Internet Routing and Security Considerations 7 84 2.3 EDI VAN Communications and Security 8 85 2.4 EDI Object Boundaries and Transaction Privacy 9 86 3.0 Functional Requirements 10 87 3.1 Introduction and Definitions 10 88 3.2 Standard Encryption Algorithms and World-Wide Encryption 10 89 3.2.1 Introduction and Description 10 90 3.2.2 Symmetric Encryption 11 91 3.2.3 Asymmetric Encryption - Public-key Cryptography 12 92 3.2.4 Needs 13 93 3.2.5 Issues 13 94 3.2.6 Recommendations 14 95 3.3 Key Management - Symmetric Keys 16 96 3.3.1 Introduction and Description 16 97 3.3.2 Needs 17 98 3.3.3 Issues 18 99 3.3.4 Recommendations 18 100 3.4 Key Management - Public and Private Keys 18 101 3.4.1 Introduction and Description 18 102 3.4.2 Public Keys 19 104 Requirements For Inter-operable Internet EDI September 1999 106 3.4.3 Trust and Public Keys 20 107 3.4.4 Needs 20 108 3.4.5 Issues 20 109 3.4.6 Recommendations 21 110 3.4.6.1 Near Term Approach 21 111 3.4.6.2 Long Term Approach 21 112 3.5 Content Integrity 21 113 3.5.1 Introduction and Description 21 114 3.5.2 Needs 22 115 3.5.3 Issues 22 116 3.5.4 Recommendations 22 117 3.6 Authentication and Non-Repudiation of Origin 23 118 3.6.1 Introduction and Description 23 119 3.6.2 Needs 24 120 3.6.3 Issues 24 121 3.6.4 Recommendations 24 122 3.7 Signed Receipt or Non Repudiation of Receipt 25 123 3.7.1 Introduction and Description 25 124 3.7.2 Needs 26 125 3.7.3 Recommendations 26 126 3.8 Syntax and Protocol for Specifying Cryptographic Services 27 127 3.8.1 Introduction and Description 27 128 3.8.2 Needs 27 129 3.8.3 Issues 27 130 3.8.4 Recommendations 28 131 4.0 Tracking and Error Handling Basics 28 132 4.1 Introduction 28 133 4.2 Transmission Successfully Translated From Internal Format to 134 Standard EDI Format 29 135 4.2.1 Needs 29 136 4.2.2 Recommendations 29 137 4.3 Transmission Successfully Encoded, Encrypted, Signed and Sent 29 138 4.3.1 Needs 29 139 4.3.2 Recommendations 29 140 4.4 Transmission Successfully Delivered to the Recipient's Mailbox 30 141 4.4.1 Needs 30 142 4.4.2 Recommendations 30 143 4.5 Transmission Successfully Received 30 144 4.5.1 Needs 30 145 4.5.2 Recommendations 30 146 4.6 Transmission Successfully Translated by the Receiver 30 147 4.6.1 Needs 30 148 4.6.2 Recommendations 31 149 4.7 Detection and Recovery of Delayed or Lost Transmissions 31 150 4.7.1 Needs 31 151 4.7.2 Recommendations 31 152 4.8 Detection and Handling of Duplicate Transmissions 32 153 4.8.1 Need 32 154 4.8.2 Recommendations 32 155 5.0 Appendix A - Implementation Considerations, Formats, and Examples 32 156 5.1 Introduction 32 158 Requirements For Inter-operable Internet EDI September 1999 160 5.2 Referenced RFCs and their contribution 33 161 5.2.1 RFC 821 SMTP [7] 33 162 5.2.2 RFC 822 Text Message Format [3] 33 163 5.2.3 RFC 1847 MIME Security Multiparts [6] 33 164 5.2.4 RFC 1892 Multipart/report [10] 33 165 5.2.5 RFC 1767 EDI Content [2] 33 166 5.2.6 RFC 2015 PGP/MIME [4] 33 167 5.2.7 RFC 2045, 2046, and 2049 MIME [1] 33 168 5.2.8 RFC2298 - Message Disposition Notification [5] 34 169 5.2.9 RFC2633 and RFC2630 -- S/MIME v3 Message Specification [8] 34 170 5.3 Structure of an EDI MIME message - No encryption/No signature 34 171 5.4 Structure of an EDI MIME message - S/MIME 34 172 5.4.1 S/MIME Overview 34 173 5.4.2 Example: S/MIME - Signature Only (Multipart/Signed) 36 174 5.4.3 Example: S/MIME - Signature Only (signedData) 37 175 5.4.4 Example: S/MIME - Encryption Only 37 176 5.4.5 Example: S/MIME - Signature and Encryption(Multipart/Signed)38 177 5.4.6 Example: S/MIME - Signature and Encryption (signedData) 40 178 5.5 Structure of an EDI MIME message - PGP/MIME 41 179 5.5.1 Overview 41 180 5.5.2 Example: PGP/MIME - Signature Only 42 181 5.5.3 Example: PGP/MIME - Encryption Only 43 182 5.5.4 Example: PGP/MIME - Signature and Encryption 44 183 5.6 Additional Considerations 46 184 6.0 Acknowledgments 46 185 7.0 References 46 186 8.0 Author's Address: 47 188 Security Considerations 190 This document discusses the mechanisms, requirements and 191 technologies necessary to conduct secure EDI over the Internet 192 using either PGP/MIME or S/MIME. It further discusses the 193 implementation of encryption, digital signature, integrity and 194 signed-receipt for MIME objects transported over SMTP, HTTP or 195 FTP. 197 1.0 Introduction 199 Electronic Data Interchange (EDI) is a set of formats for 200 Conducting highly structured inter-organization exchanges, such as 201 for making purchases or initiating loan requests. The initial 202 RFC1767 defined the method for packaging EDI X12 and UN/EDIFACT 203 transaction sets in a MIME envelope. However, several additional 204 requirements for obtaining multi-vendor, inter-operable service, 205 over and above how the EDI transactions are packaged, have come to 206 light since the effort concluded. 208 These currently revolve around security issues such as EDI 209 transaction integrity, confidentiality and non-repudiation in 210 various forms. Standards in these and other areas described later 212 Requirements For Inter-operable Internet EDI September 1999 214 in this document are necessary to insure inter-operability between 215 EDI implementations over the Internet. Various technologies 216 already exist for these additional features, and the primary 217 requirement is to review and select a common set of components for 218 use by the EDI community when it sends EDI over the Internet. In 219 effect, the effort is to provide an EDI over the Internet 220 Requirements Document, and an Applicability Statement Document(s). 222 Additional requirements that mimic many of the header fields 223 found in X.435 EDI messages (e.g., Interchange Sender, Interchange 224 Recipient, Interchange Control Reference, Communications Agreement 225 ID, and Syntax Identifier) are also needed to support efficient 226 EDI exchanges between the Internet, and the Value Added Networks. 227 However, this specification is not intended to cover the EDI VAN 228 and Internet gateway requirements. 230 This document's current focus is on EDI MIME content transported 231 using SMTP (Simple Mail Transport Protocol), the Internet's mail 232 or messaging system. 234 Traditional VAN connectivity is slow and expensive. The Internet 235 promises lower cost usage and is more easily accessible than 236 traditional methods of communications. The predominant problem 237 with the use of the Internet for EDI is inter-operability between 238 vendor products, specifically in the areas of integrity, 239 confidentiality, digital signature, and non-repudiation. The 240 EDIINT working group's focus is to recommend solutions for each of 241 these areas, using existing standards whenever possible. 243 1.1 The Audience 245 The audience for this document consists of persons directly or 246 indirectly involved in EDI communications decisions, companies 247 trading EDI documents today or in the future, and vendors 248 developing and marketing EDI products. Also included in the 249 audience for this document are people providing services and 250 consulting to the EDI community. 252 2.0 The Internet - A Brief History 254 The Internet is a world-wide collection of computers, routers, and 255 networks, connected together using the TCP/IP suite of protocols. 256 The Internet itself is not a network, but a collection of 257 networks. The Internet was designed to be decentralized, with no 258 single authority needed to run it. All hosts on the Internet can 259 communicate with one another as peers, and all of the 260 communications protocols are "open" -- the standards are in the 261 public domain, and the standardization process is open to anyone 262 willing to put in the hard work to help define them. 264 One consequence of this standards "openness" is that the Internet 266 Requirements For Inter-operable Internet EDI September 1999 268 can accommodate many different kinds of machines (toasters for 269 example). Its protocols -- the TCP/IP suite -- have therefore 270 become the de facto standards for heterogeneous computer 271 networking. At one level, the Internet is a physical collection of 272 computers connected by common protocols. At another level though, 273 the Internet can be thought of as a distributed medium, offering 274 some important advantages for doing EDI. For instance, the 275 Internet has hundreds of thousands of connected global hosts, and 276 tens of millions of users. The Internet offers a flat rate, volume 277 and time-of-day independent pricing structure for data 278 transmission. The Internet is highly redundant, offering the 279 ability to route data along alternate paths. The Internet's 280 decentralized structure makes adding new hosts relatively easy - 281 it scales well, and the Internet supports high bandwidth 282 communications technologies. 284 2.1. The Internet - Myths and Reality 286 The Internet had its beginnings in 1969 as an experimental U.S. 287 Defense Department network called ARPANET. The network was built 288 to facilitate research on how to construct networks that could 289 withstand outages to part of the network, but continue to 290 function. Network reliability was a fundamental design point when 291 developing the architecture and protocols associated with the 292 Internet. From the premise that the network was inherently 293 unreliable (parts of it could be destroyed at any moment) emerged 294 a design that was both robust and reliable. Early on, the 295 networks comprising the Internet were primarily those from 296 government agencies and educational institutions. Access to the 297 Internet was pretty much available only to computer science 298 researchers, and government employees and their contractors. 300 In 1986, the National Science Foundation, in order to provide 301 access to what was then a scarce resource, put together an 302 initiative to link five super-computer centers together using the 303 TCP/IP protocols. Two very important results of the NSFNET 304 initiative were the upgrading of the Internet's infrastructure 305 with more powerful processors and higher speed links, and 306 expansion of access to a larger user community. The 1990's has 307 seen the continual upgrading of the Internet infrastructure 308 and its expansion to new constituencies outside the traditional 309 government and university research community. Commercial interests 310 are now the largest as well as the fastest growing segment of the 311 Internet. 313 Commercial Internet providers, such as Performance Systems 314 International (PSI), and UUNET (the Alternet network), have 315 emerged from the collection of intermediate-level networks that 316 came into being as a result of the NSFNET initiative. The national 317 long distance carriers such as MCI, AT&T, and Sprint all provide 318 commercial Internet services. These commercial providers, called 320 Requirements For Inter-operable Internet EDI September 1999 322 Internet Service Providers or ISPs for short, make available 323 Internet connectivity and various other Internet services to their 324 clients. The perception of the Internet as experimental, and 325 primarily used by and for educational and research activities is 326 rooted in the Internet's past, and does not reflect today's 327 situation. The growth in commercial access to the Internet, along 328 with the growth of the ISPs, has radically changed the 329 Internet's network composition. 331 The design and architecture underlying the Internet has proven its 332 robustness by scaling to unprecedented proportions. The Internet 333 is reliable from several perspectives: 335 1). Technologically, the TCP/IP suite of protocols and 336 the architecture underlying the Internet are stable and 337 mature. 339 2). Product implementations based on the TCP/IP suite 340 are also stable and mature. 342 3). Internet routing is dynamic, so packets sent through 343 the Internet get to their destinations even if there are 344 network outages along the way. 346 4). The commercial ISP administered portions of the 347 Internet, provide essentially the same level of network 348 reliability, availability, monitoring, throughput, 349 implementation and support services as existing EDI 350 Value Added Networks (VANS), but at a lower cost and 351 with higher bandwidth. 353 Although the Internet is reliable, low-cost, highly accessible, 354 supports high bandwidth communications, and is technically mature, 355 there are still some valid concerns relating to the use of the 356 Internet for EDI. These concerns revolve primarily around 357 security, message tracking, audit trails, and authentication. Some 358 of the concerns, encryption for instance, are of a general nature 359 and not specific to the Internet -- encryption may be required 360 regardless of what type of network is traversed. Other concerns, 361 such as tracking, arise because they are required by EDI, or are 362 supported by existing EDI Value Added Networks. 364 2.2 Internet Routing and Security Considerations 366 By using a common network trace program called Traceroute, the 367 route traversed by a packet from a source host to a destination 368 host on the Internet may be followed. Tracing routes on the 369 Internet yield some interesting characteristics. As expected, the 370 routes traversed go through the networks administered by the ISPs 371 of each of the trading partners. Each route consists of multiple 372 nodes through each network. The route can vary but that is not the 374 Requirements For Inter-operable Internet EDI September 1999 376 typical case. The IP packets are delivered reliably, and within a 377 specified period of time. When a reputable commercial ISP is used, 378 none of the nodes in the route are administered by government or 379 educational entities. 381 By looking at Internet network traces, we can conclude that the 382 Internet does a very good job of getting packets from a source to 383 destination. However, between the source and the destination, the 384 packets are routed through many intermediate nodes. It is at the 385 intermediate nodes where anyone on one of the machines that handle 386 the packets could re-assemble the packets that make up the EDI 387 Interchange and could therefore read it, copy it, alter it, or 388 delete it. In the case where the EDI Interchange is carried using 389 an e-mail transport (SMTP), the situation could arise where the 390 message cannot be delivered to the final recipient, so the message 391 must be stored at an intermediate node. Once again, the message is 392 susceptible to any number of the above mentioned security threats. 394 The likelihood of any security threat, (especially if going 395 through intermediate nodes administered by a quality ISP) are 396 quite low, and practically speaking, are quite difficult. 397 Nonetheless the possibility exists, and therefore is a concern - 398 particularly if the packets contain high value or sensitive EDI or 399 electronic commerce transactions. 401 The Internet is being singled out in this discussion because our 402 focus is on EDI over the Internet. Networking is by its very 403 nature prone to security threats. Information can be placed on 404 shared media, and may be routed through nodes not under the 405 sender's administrative control. Whether through malicious hacking 406 or administrative glitches, the threat that information sent over 407 a network is read, copied, altered, or deleted in an unauthorized 408 way, is a possibility that exists even if an EDI Interchange is 409 sent via an EDI VAN. 411 A large component of the "value-added" services provided by EDI 412 VANs is precisely the assurance that EDI Interchanges sent via the 413 VAN are not compromised in any way. There are however, measures 414 that can be taken to defend against security threats when an EDI 415 Interchange is in transit across an "open" network like the 416 Internet. These security measures are essential requirements when 417 doing EDI over the Internet. 419 Each of these security measures is described in Section 3.0 of 420 this document, and the issues surrounding each measure is 421 discussed and recommended solutions are given. 423 2.3 EDI VAN Communications and Security 425 This section briefly discusses current VAN security services. The 426 security measures recommended in section 3.0 of this document 428 Requirements For Inter-operable Internet EDI September 1999 430 essentially provide the equivalent of the VAN security services 431 described below. 433 The most prevalent EDI VAN communications service provided to EDI 434 trading partners is an asynchronous mail-boxing service. A trading 435 partner typically dials into a VAN network access point. The 436 trading partner then uses a file transfer protocol to send the EDI 437 Interchanges to the VAN. The VAN then routes the EDI Interchanges 438 to the receiving trading partner's VAN mailbox. The receiving 439 trading partner then dials into the VAN and down-loads the EDI 440 Interchanges from its VAN mailbox. 442 Other than support for a greater number of communications 443 protocols, and typically lower line speeds, connecting to an EDI 444 VAN is not too much different than connecting to an Internet 445 Service Provider. The EDI VANs however, provide a higher level of 446 EDI services to the EDI trading partner than do the ISPs. The 447 most important of these services is that the EDI VAN acts as a 448 trusted third party to insure that EDI Interchanges sent via the 449 VAN are not compromised in any way. 451 EDI VANs provide for EDI Interchange integrity, authentication, 452 and a number of acknowledgments that track the progress of the EDI 453 Interchange through the Value Added Network. EDI Interchange 454 Integrity assures the trading partner that once the EDI 455 Interchange has been transferred to the VAN, that it will be 456 routed to the receiving trading partner without modification. 458 VAN authentication of trading partners consist of the guarantee 459 that EDI Interchanges can be sent and received by trading partners 460 only after they have been authenticated by the VAN. VANs 461 authenticate trading partners by having the trading partners log 462 into the network with the proper user-id and password. The VAN has 463 administrative responsibility for maintaining the trading partner 464 accounts and for insuring that the accounts are valid. VANs also 465 provide differing levels of service that allow a trading partner 466 to track the progress of the EDI Interchange through the VAN. 467 Trading partners can subscribe to mailbox delivery notification or 468 mailbox pick-up notification. 470 Mailbox delivery notification is sent by the VAN to the sending 471 trading partner when the EDI Interchange is delivered to the 472 receiving trading partner'. Mailbox pick-up notification is sent 473 by the VAN to the ending trading partner when the EDI Interchange 474 is down-loaded by the receiving trading partner. 476 The issue of tracking is covered in more detail in section 4.0. 478 2.4 EDI Object Boundaries and Transaction Privacy 480 The specification by this work group applies to the EDI 482 Requirements For Inter-operable Internet EDI September 1999 484 Interchange or Bundle (multiple EDI Interchanges) level, and not 485 the group or document level. 487 Any security services, packaging, transport, or non-repudiation 488 services are assumed to be applied to an EDI Interchange(s). 489 Unlike the X12.58 and UN/EDIFACT 9735-5 and 9735-6 security 490 standards, the security services cannot be applied at a group or 491 document level. The purpose of the specification is to move these 492 services out of the translator, and into the "communications" 493 subsystem. This will give a "communication" subsystem the ability 494 to send or receive non-EDI business documents in addition to the 495 standard X12 or EDIFACT EDI document. The "communications" 496 subsystem should know as little about the structure of the EDI 497 data as possible. 499 As specified by this document, the entire EDI Interchange, 500 including the envelope headers (ISA/IEA or UNA/UNB/UNZ) are 501 encrypted, when encryption security services are applied. Since 502 the routing of the EDI Interchange is through the Internet, and 503 not a VAN, the sender/receiver ids are not used in mailbox 504 routing, so the EDI envelops can be encrypted when sending EDI 505 over the Internet. 507 3.0 Functional Requirements 509 3.1 Introduction and Definitions 511 The following sections describe the functional and inter- 512 operability requirements, as well as some of the practical 513 considerations of sending and receiving EDI and non-EDI 514 transactions on the Internet. It is assumed that the reader is 515 generally familiar with EDI. 517 3.2 Standard Encryption Algorithms and World-Wide Encryption 519 3.2.1 Introduction and Description 521 The goal of encryption is to turn otherwise readable text into 522 something that cannot be read, and therefore understood. By making 523 the text unintelligible, encryption discourages anyone from 524 reading or copying the EDI Interchange while it is in transit 525 between the trading partners. Encryption conveys confidentiality 526 to the EDI Interchange. Traffic analysis is always possible, since 527 many times, header information is not encrypted. (Traffic analysis 528 is the analysis of header information in order to derive useful 529 information from them.) 531 Encryption is based on two components: an algorithm and a key. An 532 algorithm is a mathematical transformation that takes plain-text 533 or other intelligible information and changes it into 534 unintelligible cipher text. The inverse mathematical 536 Requirements For Inter-operable Internet EDI September 1999 538 transformation, back to the original from the cipher text is also 539 done, and is called decryption. In order to encrypt the plain 540 text, a key is used as input in conjunction with an encryption 541 algorithm. An algorithm can use one of any of a large number of 542 possible keys. The number of possible keys each algorithm can 543 support depends on the number of bits in the key. For instance, if 544 the key length is 40, then 2 to the n, where n is the number of 545 bits in the key, results in 1,000,000,000,000 possible key 546 combinations, with each different key causing the algorithm to 547 produce slightly different cipher output. 549 An encryption algorithm is considered "secure" if its security is 550 dependent only on the length of its key. Security cannot be 551 dependent on the secrecy of the algorithm, the inaccessibility of 552 the cipher or plain text, or anything else -- except the key 553 length. If this were true about a particular algorithm, then the 554 most efficient -- and only -- attack on that algorithm is a brute- 555 force attack, whereby all key combinations must be tried in order 556 to find the one correct key (this is true for symmetric 557 encryption algorithms, asymmetric algorithms work a little 558 differently, and the derivation of the private key is based on 559 mathematical manipulations of large numerical quantities. The 560 security provided by asymmetric algorithms is not quite 561 proportional to the key length. See section 3.4.2 for more details 562 on the RSA and Diffie-Hellman public-key encryption algorithms). 564 Regardless of whether a symmetric or asymmetric encryption 565 algorithm is used, by specifying a long enough key length n, even 566 a brute-force attack on a "secure" algorithm can be made 567 completely non-feasible. 569 3.2.2 Symmetric Encryption 571 Encryption algorithms whereby two trading partners must use the 572 identical key to encrypt and decrypt the EDI Interchange are 573 called symmetric encryption algorithms. Put another way, if an EDI 574 Interchange is encrypted with one key, it cannot be decrypted with 575 a different key. The key used in most symmetric encryption 576 algorithms is just a random bit string, n bits long. These keys 577 are often generated from random data derived from the source 578 computer. 580 The use of symmetric encryption simplifies the encryption process, 581 each trading partner does not need to develop and exchange secret 582 encryption algorithms with one another (which incidentally would 583 be a near impossible task). Instead, each trading partner can use 584 the same encryption algorithm, and only exchange the shared, 585 secret key. 587 There are drawbacks however with "pure" symmetric encryption 588 schemes; a shared secret key must be agreed upon by both parties. 590 Requirements For Inter-operable Internet EDI September 1999 592 If a trading partner has n trading partners, then n secret keys 593 must be maintained, one for each trading partner. Symmetric 594 encryption schemes also have the problem that origin or 595 destination authenticity (non-repudiation of origin, and receipt) 596 cannot be proved. Since both parties share the secret encryption 597 key, any EDI Interchange encrypted with a symmetric key, could 598 have been sent by either of the trading partners. 600 By using what is called public key cryptography, management of 601 symmetric keys can be simplified to the point whereby a symmetric 602 key can be used not only for each trading partner, but for each 603 exchange between trading partners. In addition, public key 604 cryptography can be used to unambiguously establish non- 605 repudiation of origin and receipt. 607 3.2.3 Asymmetric Encryption - Public-key Cryptography 609 Public-key cryptography is based on the concept of a key pair. 610 Each half of the pair (one key) can encrypt information that only 611 the other half (one key) can decrypt. The key pair is designated 612 and associated to one, and only one, trading partner. One part of 613 the key pair (the private key) is only known by the designated 614 trading partner; the other part of the key pair (the public key) 615 is published widely but is still associated with the designated 616 trading partner. 618 The keys are used in different ways for confidentiality and 619 digital signature. Both confidentiality and signature depend on 620 each entity having a key pair that is identified only with them 621 and each party keeping one pair of their key pair secret from all 622 others. 624 Signature works as follows: Trading Partner A uses her secret key 625 to encrypt part of a message, then sends the encrypted message to 626 Trading Partner B. B gets Trading partner A's public key (anyone 627 may get it) and attempts to decrypt the encrypted part of Trading 628 partner A's message. If it decrypts, then Trading Partner B knows 629 it is from A - because only A's public key can decrypt a message 630 encrypted with A's private key, and A is the only one who knows 631 her private key. 633 In most real world applications, asymmetric encryption algorithms 634 are not actually used to encrypt the message or part of the 635 message itself. Instead, they are used in conjunction with a 636 Message Integrity Check (MIC), also known as the "Message Digest" 637 and it is the MIC that is encrypted using the public key 638 encryption algorithm. See section 3.5.1 for details on how 639 asymmetric encryption algorithms are applied to a MIC. 641 Confidentiality applies the asymmetric key pair, but in a 642 different manner than signature. If Trading partner A wishes to 644 Requirements For Inter-operable Internet EDI September 1999 646 send a confidential message to Trading Partner B, she would apply 647 the key pair as follows: Trading partner A would retrieve Trading 648 partner B's public key, and encrypt the message with it. When 649 Trading Partner B receives the message, she would decrypt the 650 message with her private key. Only her private key can decrypt 651 information that was encrypted with her public key. In other- 652 words, anything encrypted with B's public key can only be 653 decrypted with B's private key. 655 Since public-key encryption algorithms are considerably slower 656 than their symmetric key cousins, they are generally not used 657 to do the actual encryption of what could be large EDI 658 Interchanges. The preferred method is to create a symmetric key 659 which is used to encrypt the EDI Interchange and the symmetric key 660 is then encrypted using the recipients asymmetric public-key. 661 The encrypted EDI Interchange and symmetric key is then sent to 662 the recipient. The recipient of the encrypted EDI Interchange 663 would then decrypt the Symmetric using her private key. After 664 recovering the symmetric key, the recipient would then decrypt the 665 EDI Interchange. 667 For instance, RSA Data Securities, Inc. estimates 668 that software encryption using DES (a symmetric key algorithm) is 669 100 times faster than software encryption using RSA (a public-key 670 encryption algorithm from RSA Data Securities, Inc.). Hardware 671 encryption using DES is anywhere from 1,000 to 10,000 times faster 672 than hardware encryption using the RSA asymmetric encryption 673 algorithm. Instead of being used for bulk encryption, public-key 674 encryption algorithms are used to encrypt symmetric encryption 675 keys. They are also used as an efficient means of exchanging and 676 managing symmetric encryption keys. 678 3.2.4 Needs 680 In order to provide confidentiality for EDI Interchanges on the 681 Internet, a standard encryption algorithm(s) and key length(s) 682 must be specified. For inter-operability to occur between two 683 trading partners, the encryption algorithm and key lengths must be 684 agreed upon either before hand, or within an individual 685 transaction. 687 3.2.5 Issues 689 When choosing an encryption algorithm, the following criteria 690 should be considered; how secure the algorithm is; how fast 691 implementations of the algorithm are; whether the algorithm is 692 available for international as well as domestic use; the 693 availability of APIs and tool kits in order to implement the 694 algorithms; and the frequency of the use of the algorithm in 695 existing implementations. 697 Requirements For Inter-operable Internet EDI September 1999 699 Sufficient key lengths must be chosen with regard to the value of 700 the EDI Interchange so that brute-force attacks are not worth the 701 time or effort compared to the value of the Interchange. 703 3.2.6 Recommendations 705 DES: The most widely used commercial encryption algorithm is DES. 706 It is widely used in the banking industry for Electronic Funds 707 Transfer (EFT). DES is also a U.S. government encryption standard. 708 DES is in the public domain, which means anyone can implement the 709 algorithm, including those in the international community. DES 710 was designed for, and is used for bulk encryption of data. For a 711 number of years, the government rarely approved the export of DES 712 for use outside of the financial sector or by foreign subsidiaries 713 of U.S. companies. But recently the government is allowing the 714 export of DES to companies that demonstrate plans to implement key 715 recovery systems in the next few years. 717 The DES algorithm has been analyzed by cryptographers since the 718 mid-1970s, and its security is considered "known": in other words, 719 the security of DES is dependent on the length of its key, and 720 estimates can be provided for the time and effort required to 721 derive the DES key from a known 8 byte plain-text/cipher-text 722 pair. DES specifies a 56 bit key, so 2 to the 56th or 10 to the 723 16th keys are possible. A brute force attack, which means trying 724 every single key to decrypt 8 bytes of known cipher-text into its 725 corresponding 8 bytes of known plain-text is the best attack on 726 the algorithm. 728 The amount of time and money required to mount a successful brute 729 force attack varies with the processing power used -- and how 730 lucky the attacker may be in generating a key that is close to the 731 one used to encrypt the original EDI Interchange. Some estimates 732 which have been put forth claim that a $1 million dollar hardware 733 based, brute-force attack on DES would only take 3.6 hours to 734 recover the DES key. A corresponding $1 million dollar software 735 based brute-force attack on DES would however take 3 years [13]. 736 As the price/performance of processors decrease, a 56 bit key 737 becomes less and less adequate in protecting EDI Interchanges of 738 extreme value. Triple-DES, an algorithm with longer key length 739 (discussed below) SHOULD be used in such cases. Note: Electronic 740 Frontier Foundation was successful in cracking the RSA DES 741 challenge in 22 hours, 15 minutes using a distributed net. 743 Triple-DES is a variant on DES that encrypts the EDI Interchange 3 744 times, with 2/3 independent 56 bit keys, giving it an effective 745 key length of 112/168 bits. This makes a brute-force attack on 746 Triple-DES not feasible. DES and Triple-DES actually can be 747 implemented in 3 different modes. It is RECOMMENDED that DES and 748 Triple-DES be used in Cipher Block Chaining (CBC) mode, which 749 gives added protection by making each cipher-text block depend on 751 Requirements For Inter-operable Internet EDI September 1999 753 each other, so changes in the cipher-text can be detected. 755 RC2 and RC5: RC2 and RC5 are proprietary symmetric algorithms of 756 RSA Data Security, Inc. RC2 and RC5 unlike DES, are variable-key 757 length algorithms. By specifying differing key lengths, RC2 and 758 RC5 can be configured to provide greater or lesser security. RC2 759 and RC5 are alternatives to DES, and RC2 has special export 760 status, whereby 40 bit versions of RC2, and 56 bit versions of RC2 761 for foreign subsidiaries and overseas offices of U.S. companies, 762 have expedited export approval from the U.S. government. RSA 763 claims that RC2 and RC5 are faster than DES when implemented in 764 software. Several products such as Lotus Notes, Cyclone 765 Interchange, Apple's Open Collaboration Environment, Netscape's 766 ECXpert, and Harbinger's Templar make use of these algorithms. 768 It is RECOMMENDED that key sizes of 40 bits, 75 bits, and 128 bits 769 be supported for incoming and outgoing EDI messages, when used 770 domestically. U.S. Government restrictions limit RC2 771 implementations to 40 bits when exported outside the United 772 States. RC2 SHOULD be used in CBC mode, and RC5 in CVC Pad mode. A 773 key length of 128 bits would make a brute force attack on RC2 or 774 RC5 not feasible. 776 IDEA: The International Data Encryption Algorithm was published in 777 1991. The symmetric algorithm is an iterated block cipher with a 778 64-bit block size and a 128-bit key size. The key length of IDEA 779 is over twice that of DES. The IDEA algorithm is patented in both 780 the United States and abroad. The IDEA algorithm in CBC mode is 781 used by PGP (Pretty Good Privacy - a popular electronic mail 782 security program) for encryption. Individual users of PGP have a 783 royalty free license to use the IDEA algorithm. 785 There are many encryption algorithms that are secure and can 786 provide confidentiality for an EDI Interchange. For most 787 commercial applications a key length of at least 75 bits is 788 RECOMMENDED. See [13] and [14] for additional guidance on choosing 789 key lengths. For EDI Interchanges of minimal value, 40-bit RC2 or 790 56-bit DES are probably adequate. For more valuable EDI 791 interchanges, use of Triple-DES, IDEA, or 128 bit length RC2 or 792 RC5 is RECOMMENDED. 794 DES is currently in wide-spread use, and Triple-DES is projected 795 to be in wide-spread use, as the 56-bit DES key limitation becomes 796 less and less adequate. The DES algorithm is available for 797 implementation outside the U.S., and the DES algorithm has been 798 studied for a long time, and its security is "known". RC2 and RC5 799 are useful because they allow the security of the encryption - the 800 key length specification, to be configurable. The RC2 and RC4 801 algorithms are proprietary, but products incorporating these 802 algorithms, but limiting the key lengths to 40 bits or less, can 803 be exported outside the U.S. 805 Requirements For Inter-operable Internet EDI September 1999 807 IDEA is a newer algorithm and has not been studied as much as DES. 808 IDEA's 128 bit key-length provides more than adequate security. 810 Indications are that IDEA is a secure algorithm and its use in PGP 811 makes it the most widely used encryption algorithm for Internet 812 electronic mail. 814 3.3 Key Management - Symmetric Keys 816 3.3.1 Introduction and Description 818 The use of symmetric encryption is based on a shared secret. Two 819 trading partners using a symmetric encryption algorithm must be 820 able to do the following; generate a random symmetric key and 821 agree upon its use; securely exchange the symmetric key with one 822 another; set up a process to invalidate a symmetric key that has 823 been compromised or needs changing. Each trading partner would 824 then need to do this with each and every one of their trading 825 partners. Management and distribution of symmetric keys can become 826 an insecure and cumbersome process. 828 Pure symmetric key management schemes also have the problem that 829 Origin authenticity cannot be proved. Since two parties share a 830 secret encryption key, any EDI Interchange encrypted with a 831 symmetric key, could have been sent by either of the trading 832 partners -- both of whom have knowledge of the key. 834 As previously mentioned, by using public key cryptography, 835 management of symmetric keys can be simplified such that a 836 symmetric key can be used not only for each trading partner, but 837 for each exchange between trading partners. In addition, public 838 key cryptography can be used to unambiguously establish non- 839 repudiation of origin and receipt. 841 The use of public-key cryptography, whereby the symmetric 842 encryption key is encrypted using an asymmetric encryption 843 algorithm, simplifies the management of the symmetric keys and 844 makes their exchange much more secure. Trading partners do not 845 need to agree on secret symmetric keys as part of the trading 846 partner agreement, nor is there the origin authenticity problem 847 that is inherent with pure symmetric key management schemes. 849 A symmetric key can be randomly generated by the software for each 850 EDI transaction between trading partners. Symmetric keys generated 851 on a per transaction basis are sometimes referred to as "session 852 keys". Since a unique symmetric key is generated for each EDI 853 transaction, symmetric key maintenance is no longer required. 854 Trading partners do not need to invalidate compromised or expired 855 keys. Each symmetric or "session" key is used only one time. 857 Requirements For Inter-operable Internet EDI September 1999 859 Additional security is also realized using the method described 860 above; in the unlikely event that one of the symmetric keys is 861 compromised, only one EDI transaction is affected, and not every 862 transaction in the trading partner relationship. Public-key 863 encryption also provides a secure way of distributing symmetric 864 keys between trading partners. Since only the receiving trading 865 partner has knowledge of her private asymmetric key, she is the 866 only one that can decrypt the symmetric key encrypted with her 867 public asymmetric key -- and is thus the only one who can use the 868 symmetric key to decrypt the EDI Interchange. 870 To impart confidentiality to an EDI Interchange using public key 871 cryptography for symmetric key management, the following steps 872 would be performed when trading partner ABC sends to trading 873 partner XYZ: 875 1). The EDI Translator outputs the EDI Interchange. 877 2). A random symmetric key of the specified length is 878 generated. 880 3). The EDI Interchange is encrypted using the randomly 881 generated symmetric key with the chosen encryption 882 algorithm. 884 4). The random symmetric key is then encrypted using XYZ's, 885 the receiving trading partner's, public asymmetric key. 887 5). The encrypted symmetric key and encrypted EDI 888 Interchange are then enveloped and sent to the trading 889 partner. 891 On the receiving side, the following steps would be performed: 893 1). The symmetric key is decrypted using XYZ's private 894 asymmetric key. 896 2). The decrypted symmetric key is then used to decrypt the 897 EDI Interchange. 899 3). The decrypted EDI Interchange is then routed to the EDI 900 translator. 902 3.3.2 Needs 904 A method to manage the symmetric encryption keys used in 905 encrypting EDI Interchanges on a transaction basis. The method 906 should simplify the generation, maintenance, and distribution of 907 the symmetric encryption keys. The method should also provide a 908 secure channel for distributing the symmetric encryption keys 909 between trading partners. 911 Requirements For Inter-operable Internet EDI September 1999 913 3.3.3 Issues 915 Agreement by trading partners to use public-key cryptography to 916 manage symmetric keys, and to generate a symmetric key for each 917 EDI transaction. 919 When choosing public-key encryption algorithms, the following 920 criteria should be considered; how secure the algorithm is; how 921 fast implementations of the algorithm are; whether the algorithm 922 is available for international as well as domestic use; the 923 availability of APIs and tool kits in order to implement the 924 algorithms; and the frequency of the use of the algorithm in 925 existing implementations. 927 Sufficient key lengths must be chosen with regard to the value of 928 the EDI Interchange so that brute-force attacks are not worth the 929 time or effort compared to the value of the Interchange. 931 3.3.4 Recommendations 933 RSA is a public-key encryption algorithm that has become a de 934 facto standard in its use for symmetric key management. But today, 935 Diffie-Hellman is the selected asymmetric algorithm for managing 936 symmetric keys. Diffie-Hellman is RECOMMENDED in managing and 937 distributing symmetric encryption keys when doing EDI over the 938 Internet. The Diffie-Hellman public-key algorithm's patent has 939 expired therefore can be freely used within or outside the U.S. 941 Both S/MIME v3 and PGP/MIME make use of the Diffie-Hellman 942 encryption algorithm to encrypt/decrypt "session keys". 944 For a recommendation on DH or RSA key lengths, see Section 3.4.2, 945 on Public Keys. 947 3.4 Key Management - Public and Private Keys 949 3.4.1 Introduction and Description 951 The use of public-key cryptography to simplify the management of 952 symmetric encryption keys presents the user with two problems; 953 protecting the private key, and binding a trading partner's 954 identity to his public key. Most likely the user will never know 955 what his private key is. The software will generate a random 956 private key, encrypt it, and store it in a file or database. The 957 private key is accessed indirectly by the user through access to 958 the software. User access to the software is generally controlled 959 by a password, pass-phrase, and/or certain access rights. These 960 are internal security policies, and are company specific. It is 961 important to control the access to the private key, since any 962 unauthorized access can lead eventually to the revocation of the 964 Requirements For Inter-operable Internet EDI September 1999 966 corresponding public key. 968 3.4.2 Public Keys 970 A public key is used by an originating trading partner to encrypt 971 a symmetric key, and as will be discuss later, by a receiving 972 trading partner to verify authenticity of the originator. 974 The mathematics of public key cryptography is complicated, but are 975 based on mathematical manipulations of large numerical quantities. 976 In the case of RSA, deriving the private key from the public key 977 is based on the difficulty in factoring large numbers. An RSA 978 public key is generated by multiplying two large prime numbers 979 together, deriving the private key from the public key involves 980 factoring the product of the two large prime number. 982 Unlike the symmetric encryption algorithms discussed above, the 983 RSA asymmetric encryption algorithm's security is based on the 984 size of the number that needs to be factored. The size or 985 "modulus" of the product of two prime numbers can be factored 986 using some "fast factoring algorithms" which currently exist. The 987 computing power required by these "fast factoring algorithms" can 988 be estimated, and thus the time and cost to factor a number of any 989 given size can also be estimated. 991 Some estimates which have been put forth claim that a 1 "MIP" 992 computer operating for 1 year would take 74 years to factor a 993 modulus of 100 digits or approximately 332 bits. A 150 (~500 bits) 994 digit modulus would take 1,000,000 MIP years, a 200 digit modulus 995 (~664 bits) 4,000,000,000 MIP years, and a 350 digit modulus 996 (~1162 bits) would take 10 to 16th MIP years. 998 Given a large enough modulus, it becomes an impossible task to 999 "break" or derive a private key from a public key. The RSA key 1000 length is configurable, but as the cost of computing power 1001 decreases - assume for instance, a decrease in computing costs by 1002 a factor of ten every 5 years -- then by the year 2030, a 512 bit 1003 public key can be "broken" for $10 [13]. 1005 When using the RSA encryption algorithm to encrypt symmetric keys, 1006 support of 512 bit to 1024 bit variable key lengths is REQUIRED. 1007 In general, asymmetric algorithms require longer keys to provide 1008 the same level of security as their symmetric key cousins. A 1009 comparison of asymmetric key lengths (for algorithms like RSA that 1010 are based on the factoring problem), needed to provide the 1011 equivalent "security" against "brute force" attacks can be found 1012 in [14]. For example, a 512 bit RSA encryption key is equivalent 1013 to a 64 bit symmetric key. A 768 bit RSA encryption key is 1014 equivalent to an 80 bit symmetric key. 1016 It is RECOMMENDED that for EDI transactions requiring the use of 1018 Requirements For Inter-operable Internet EDI September 1999 1020 RSA encryption to protect "session keys", that at least a 768 bit 1021 RSA encryption key be used. For very "high" value EDI 1022 transactions, at least a 1024 bit or higher key SHOULD be used. 1024 3.4.3 Trust and Public Keys 1026 When using public key cryptography, there is a "trust" issue that 1027 arises: how can one trading partner be sure that the public key of 1028 another trading partner is bound to that trading partner, and is 1029 valid? 1031 Trading partners must exchange public keys or be able to access 1032 each other's public key in a manner that is acceptable to each of 1033 the trading partners. 1035 One method by which trading partners can exchange public key 1036 information is through the use of public key certificates. 1038 Public key certificates come in many different formats, and the 1039 trust model on which they are based also come with different 1040 underlying assumptions. 1042 Public key certificates based on the X.509 standards however are 1043 becoming prevalent in their use. The X.509 certificate is a 1044 binding of an entity's distinguished name (a formal way for 1045 identifying someone or something in the X.500 world, in our case 1046 it would be a trading partner) to a public key. A certificate also 1047 contains the digital signature of the issuer of the certificate, 1048 the identity of the issuer of the certificate, and an issuer 1049 specific serial number, a validity period for the certificate, and 1050 information to verify the issuer's digital signature. Certificate 1051 issuers are called certification authorities, and are trusted by 1052 both trading partners. In essence, a certificate is a digitally 1053 notarized binding of a trading partner to its public key. 1055 3.4.4 Needs 1057 Adoption of a trust model, or the use of certification authorities 1058 for issuing commercial grade/class 3 certificates. Each trading 1059 partner must choose a trust model. For instance, trading partners 1060 can self-certify one another, or they could use certification 1061 authorities acceptable to their other trading partners. 1063 Formats and protocols for requesting, revoking, and exchanging 1064 certificates and certificate revocation lists between 1065 certification authorities and trading partners, as well as between 1066 the trading partners themselves need to be agreed to and 1067 standardized. 1069 3.4.5 Issues 1071 Requirements For Inter-operable Internet EDI September 1999 1073 The lack of wide-spread use of certification authorities in real 1074 world commercial applications, and the need to do additional 1075 profiling of X.509v3 certificates and standards for requesting, 1076 revoking, and exchanging certificates and certificate revocation 1077 lists. 1079 3.4.6 Recommendations 1081 3.4.6.1 Near Term Approach 1083 Since there already exists a trust relationship between EDI 1084 trading partners, until use of certification authorities become 1085 more established and better profiling is done with X.509v3 1086 certificates, it is recommended that the trading partners "self- 1087 certify" each other, if an agreed upon certification authority is 1088 not used. 1090 In the near term, "self-certification" means that the exchange of 1091 public keys and certification of these keys must be handled as 1092 part of the process of establishing a trading partnership. 1094 The UA and/or EDI application interface must maintain a database 1095 of public keys used for encryption and authentication, in addition 1096 to mapping between the EDI trading partner ID and the RFC822 1097 e-mail address. The procedures for establishing a trading 1098 partnership and configuring the secure EDI messaging system might 1099 vary among trading partners and software packages. 1101 It is still highly RECOMMENDED that trading partners acquire a 1102 X.509v3 certificate from a certificate authority trusted by both 1103 trading partners. The process of acquiring a certificate varies 1104 among the various certificate authorities. It is also RECOMMENDED 1105 that trading partners exchange certificates using the formats and 1106 protocols specified by PKCS7 "certs-only" when using S/MIME, 1107 and PGP certificate formats and protocols when using PGP/MIME. 1109 3.4.6.2 Long Term Approach 1111 In the long term, additional Internet-EDI standards will need to 1112 be developed to simplify the process of establishing a trading 1113 partnership, including the acquisition, revocation, exchange, and 1114 third party authentication of certificates. 1116 PKCS7 and PKCS10 as well as the standards being developed by the 1117 IETF-pkix (public key infrastructure X.509 work-group) need to be 1118 evaluated and adopted as standards for Internet EDI. 1120 3.5 Content Integrity 1122 3.5.1 Introduction and Description 1124 Requirements For Inter-operable Internet EDI September 1999 1126 Encryption guarantees the confidentiality of an EDI Interchange. 1127 Content integrity guarantees that the receiving trading partner 1128 gets the EDI Interchange in its originally sent state. Content 1129 integrity assures that no modifications -- additions, deletions, 1130 or changes -- have been made to the EDI Interchange when it is in 1131 transit between trading partners. 1133 Content integrity is achieved if the sender includes with the EDI 1134 Interchange, an integrity control value. This value can be 1135 computed by using an appropriate cryptographic algorithm to 1136 "fingerprint" the EDI Interchange. These cryptographic algorithms 1137 are called one-way hash functions or message integrity checks. 1139 Unlike encryption algorithms however, one-way hash functions can't 1140 be reversed or "decrypted". One-way hash functions are constructed 1141 so the probability is infinitely small that some arbitrary length 1142 piece of plain-text can be hashed to a particular value, or that 1143 any two pieces of plain-text can be hashed to the same value. One- 1144 way hash values are usually from 112 to 160 bits long. The longer 1145 the hash value, the more secure it is. 1147 One-way hash functions don't require a key, and the algorithm used 1148 must be agreed upon by the trading partners. To insure content 1149 integrity, the sending trading partner needs to calculate a one- 1150 way hash value of the EDI Interchange and MIME content headers. 1151 This value is unique and "fingerprints" the transaction. The 1152 sending trading partner sends the hash value along with the EDI 1153 Interchange. The receiving trading partner using the same one-way 1154 hash function calculates the hash value for the received EDI 1155 Interchange and MIME content headers. If the received hash value 1156 matches the calculated hash value, then the receiving trading 1157 partner knows that the EDI Interchange has not been tampered with. 1159 3.5.2 Needs 1161 Choice of a one-way hash algorithm to calculate the hash value 1162 required to insure content integrity. 1164 3.5.3 Issues 1166 The one-way hash algorithm should be secure, publicly available, 1167 and should produce hash values of at least 128 bits. 1169 3.5.4 Recommendations 1171 SHA-1 is the RECOMMENDED Secure Hash Algorithm, a one-way hash 1172 function invented by the National Security Agency. SHA-1 produces 1173 a 160-bit hash value that makes a brute-force attack on it not 1174 feasible. It is being recommended by most e-mail security programs 1175 and other security specifications, as weaknesses are being found 1176 in MD5. 1178 Requirements For Inter-operable Internet EDI September 1999 1180 MD5 is a one-way hash function that is publicly available, and 1181 produces a 128 bit hash value called a Message Digest. It is 1182 currently widely used by most e-mail security programs, such as 1183 PEM, PGP, and S/MIME. 1185 It is RECOMMENDED that all new implementations use SHA-1 for 1186 outgoing messages, but to continue to accept MD5 incoming (SHA1 as 1187 well) as there already exist many MD5 implementations. 1189 3.6 Authentication and Non-Repudiation of Origin 1191 3.6.1 Introduction and Description 1193 Encryption guarantees confidentiality. Applying a one-way hash 1194 function guarantees content integrity. Both authentication and 1195 non-repudiation of origin guarantee the identity of the sender of 1196 the EDI Interchange. Non-repudiation of origin, identifies the 1197 original sender, and is the same as authentication when the EDI 1198 Interchange is sent point-to-point, i.e. when there is no 1199 forwarding involved. Authentication and non-repudiation of origin 1200 discourages any spoofing attacks that may occur while the EDI 1201 Interchange is in transit between the trading partners. 1203 Both authentication and non-repudiation of origin are accomplished 1204 using digital signatures. A digital signature is another 1205 application of public-key cryptography, and is explained in more 1206 detail in the following paragraphs. 1208 Up to this point, a receiving trading partner's public-key has 1209 been used in symmetric key management to encrypt a symmetric key. 1210 This symmetric key could only be decrypted by the receiving 1211 Trading partner's private key. However the roles of the private 1212 and public keys can be reversed, so that encryption is done with 1213 the private key, and decryption is done with the public key. Again 1214 the keys are reciprocal, if encryption is done with the private 1215 key, decryption can only be done with the public key. 1217 Since only trading partner ABC knows her own private-key, only 1218 trading partner ABC can encrypt something with that private-key. 1219 Encryption with a private key therefore has the effect of uniquely 1220 identifying the person or entity doing the encryption. It is in 1221 effect, a digital signature. Since ABC's public-key is known to 1222 all her trading partners, they can all decrypt something encrypted 1223 with ABC's private-key. Successful decryption using ABC's public- 1224 key of something encrypted with ABC's private key has the effect 1225 of authenticating ABC as the trading partner that did the 1226 encrypting, or in other words it identifies ABC as applying the 1227 digital signature. 1229 ABC cannot deny that she applied the encryption, since she is the 1231 Requirements For Inter-operable Internet EDI September 1999 1233 only one with knowledge of her private key. In this way, non- 1234 repudiation of origin is achieved. 1236 So what should a trading partner sign or encrypt with her private- 1237 key to guarantee authentication and non-repudiation of origin? 1238 Remember, public-key encryption algorithms are not meant to 1239 encrypt something very large, they are too slow for that. The 1240 symmetric key is encrypted with a public-key, and encrypting this 1241 with a private-key is not recommended, as this would allow other 1242 than the authorized recipient to decrypt the EDI Interchange. 1243 Since a one-way hash value is pretty small, usually only between 1244 112-160 bits long, it is a natural choice for what can be 1245 digitally signed. If the message integrity value is signed with a 1246 private key, then not only is authentication and non-repudiation 1247 of origin guaranteed, but message integrity as well. 1249 3.6.2 Needs 1251 Choice of a digital signature algorithm. 1253 3.6.3 Issues 1255 When choosing a digital signature algorithm, the following 1256 criteria should be considered; how secure the algorithm is; how 1257 fast implementations of the algorithm are; whether the algorithm 1258 is available for international as well as domestic use; the 1259 availability of APIs and tool kits in order to implement the 1260 algorithms; and the frequency of the use of the algorithm in 1261 existing implementations. 1263 Sufficient key lengths must be chosen with regard to the value of 1264 the EDI Interchange so that brute-force attacks are not worth the 1265 time or effort compared to the value of the Interchange. 1267 3.6.4 Recommendations 1269 In addition to using the Diffie-Hellman public-key algorithm to 1270 encrypt symmetric keys, it is also RECOMMENDED that NIST FIPS PUB 1271 186, DSS, signature standard be used for digital signatures. 1273 Unlike encryption algorithms, strong digital signature (greater 1274 than 40 bit key lengths) algorithms can be freely exported outside 1275 the U.S. 1277 The RECOMMENDED key lengths when using the DSA signature algorithm 1278 for signatures, are the same as when using DH encryption for 1279 managing symmetric keys: 1281 For most EDI transactions requiring digital signatures, a 768 bit 1282 DSA signature key SHOULD be used. For very "high" value EDI 1283 transactions, at least a 1024 bit or higher key SHOULD be used. 1285 Requirements For Inter-operable Internet EDI September 1999 1287 3.7 Signed Receipt or Non Repudiation of Receipt 1289 3.7.1 Introduction and Description 1291 The term used for both the functional activity and message for 1292 acknowledging receipt of an EDI/EC interchange is "receipt", or 1293 "signed receipt". The first term is used if the acknowledgment is 1294 for an interchange resulting in a receipt which is NOT signed. 1295 The second term is used if the acknowledgment is for an 1296 Interchange resulting in a receipt which is signed. 1298 A term often used in combination with receipts is "Non-repudiation 1299 of Receipt (NRR). NRR refers to a legal event which occurs only 1300 when the original sender of an interchange has verified the sender 1301 and content of a "signed receipt". Note that NRR is not possible 1302 without signatures. 1304 The signed receipt is an acknowledgment sent by the receiving 1305 trading partner to the sending trading partner. The signed receipt 1306 is used to address the following issues when doing Internet EDI: 1308 1). The lack of wide-spread RFC 1894 based mailbox delivery 1309 notification implementations within the Internet mail 1310 infrastructure. 1312 2). It provides the equivalent of VAN mailbox delivery 1313 notification. 1315 3). It provides the equivalent of VAN mailbox pick-up 1316 notification. 1318 4). It provides the equivalent of VAN mailbox 1319 authentication. 1321 5). It can detect the situation where EDI Interchanges are 1322 maliciously deleted, or are not delivered by the 1323 transport. 1325 Receipt by the sender of a signed receipt, is an implicit 1326 acknowledgment of successful mailbox delivery. It is also an 1327 explicit acknowledgment that the Interchange was retrieved from 1328 the mailbox - pick-up notification. By having the receiver sign 1329 the receipt, it authenticates that the intended receiver picked up 1330 the EDI Interchange -- mailbox authentication -- and that the 1331 intended receiver verified the integrity of the EDI Interchange, 1332 and the identity of the sender. By returning the original message 1333 id and the one-way hash value of the received contents back in the 1334 signed receipt, the sender can reconcile the acknowledged EDI 1335 Interchange with what was sent. 1337 Requirements For Inter-operable Internet EDI September 1999 1339 3.7.2 Needs 1341 Define the format and protocol for the signed receipt so that it 1342 provides the following: 1344 1). Implicit acknowledgment of mailbox delivery of the EDI 1345 Interchange to the recipient. 1347 2). Explicit acknowledgment that the receiver has 1348 authenticated the sender and verified the integrity of the 1349 sent EDI Interchange. 1351 3). Guarantees non-repudiation of receipt when the signed 1352 receipt is digitally signed by the receiving trading 1353 partner, and successfully verified by the sender. 1355 4). Provide information in the signed receipt so it can be 1356 used for tracking, logging, and reconciliation purposes. 1358 The re-transmission timer, and retry count to detect lost 1359 Interchanges should be configurable. 1361 3.7.3 Recommendations 1363 The syntax for a signed receipt should not be specific to EDI 1364 content, since many of the uses of a signed receipt can be broadly 1365 applied to other MIME encapsulated objects. The results of the 1366 IETF receipt working group SHALL be adopted as the basis for 1367 implementing signed receipts. The receipt working group has 1368 published an Internet RFC 2298 [5], which can be obtained off of 1369 the IETF World Wide Web site. The EDIINT working group has taken 1370 on the work item to develop the needed extensions to the MDN RFC 1371 that is required within an EDI environment. See Internet Draft 1372 draft-ietf-ediint-as1-10.txt: "MIME-based Secure EDI" [10]. 1374 When a signed receipt is used by trading partners, the message 1375 integrity check that is verified by the receiving trading partner 1376 must be returned to the originating trading partner in the signed 1377 receipt. 1379 The time-out and retry values for the signed receipt SHOULD be 1380 configurable. Duplicates SHOULD be checked by the UA and 1381 discarded. 1383 The signed receipt MUST be implemented using a MIME 1384 multipart/signed type/subtype with the message disposition 1385 notification as the first part of the content of the 1386 multipart/signed. A MIC is then calculated over the message 1387 disposition notification, and this MIC is digitally signed and 1388 MUST be returned as the second part of the multipart/signed 1389 content. 1391 Requirements For Inter-operable Internet EDI September 1999 1393 3.8 Syntax and Protocol for Specifying Cryptographic Services 1395 3.8.1 Introduction and Description 1397 Once cryptographic services are applied to EDI Interchanges, then 1398 the formats and protocols must be specified on how the 1399 cryptographic information is conveyed during the EDI message 1400 exchange. Encryption algorithm information, one-way hash algorithm 1401 information, symmetric keys, initialization vectors, one-way hash 1402 values, and public-key certificates, need to be enveloped and sent 1403 along with the EDI Interchange. 1405 3.8.2 Needs 1407 A syntax and protocol for specifying EDI Interchanges that have 1408 had cryptography applied to them, needs to be specified. Several 1409 suitable standards already exist, so it is preferable to choose 1410 one of these existing standards rather than specifying a new one. 1412 3.8.3 Issues 1414 The IETF EDIINT work group has put together a matrix comparing 1415 many of the different ways that EDI with cryptography applied to 1416 it can be transmitted. Several standards appear to fulfill the 1417 security requirements needed by this work group. 1419 S/MIME [8], and PGP/MIME [4] are both viable alternatives. Each 1420 has its strengths and weaknesses: 1422 The S/MIME specification allows "signed and enveloped" and 1423 "signed" to be distinguished. The signatories in an S/MIME "signed 1424 and enveloped" content type can be distinguished, which in certain 1425 EDI and electronic commerce situations is not acceptable. However, 1426 the S/MIME v3 Message Specification [8], does address this 1427 concern by specifying that "signed and enveloped" not be used, and 1428 a two step sign and then encrypt process be used instead. 1430 S/MIME is very flexible and can accommodate many different 1431 security algorithms and key lengths. 1433 PGP 4.5 supports a set profile of security algorithms and some 1434 user configurable key lengths. PGP/MIME does not have the 1435 signatory problem as described above for S/MIME. However, PGP 4.5 1436 does not give the user as much flexibility in choosing algorithms 1437 and key lengths, although the security profile used by PGP 4.5 is 1438 more than adequate to insure confidentiality, non-repudiation of 1439 origin, and message integrity. 1441 The recommended security format should also be transport 1442 independent so it can be used with different Internet transports. 1444 Requirements For Inter-operable Internet EDI September 1999 1446 The standard should have broad support, and implementations should 1447 be available. 1449 3.8.4 Recommendations 1451 Either one of S/MIME or PGP/MIME fulfill the requirements of the 1452 EDIINT work group. The S/MIME Message Specification [8], requires 1453 the signedData format be supported, and the multipart/signed, as 1454 specified in RFC 1847 [6], is recommended. For use in Internet 1455 EDI, support of multipart/signed is REQUIRED, and signedData is 1456 RECOMMENDED only when sending EDI through known gateways that do 1457 not honor 7-bit transfer encoding. 1459 PGP/MIME is based on multipart/signed and multipart/encrypted. 1461 The Appendix of this document specifies how S/MIME, and PGP/MIME 1462 are to be applied for use in Internet EDI. See section 5.4 for 1463 implementation notes, and examples on S/MIME and PGP/MIME formats. 1465 4.0 Tracking and Error Handling Basics 1467 4.1 Introduction 1469 It is important to recognize that the Value Added Networks provide 1470 some inherent tracking mechanisms between EDI trading partners. In 1471 Internet EDI, the ISPs provide a certain level of transmission 1472 tracking as does the TCP/IP protocols themselves. However, not all 1473 the tracking provided by EDI VANs are completely covered by the 1474 current TCP/IP protocol suite or ISP tracking. The new tracking 1475 information associated with the additional security requirements 1476 and support of signed receipts, must be implemented in the EDI UA, 1477 in order for Internet EDI to be as traceable as VAN EDI. 1479 Aside from the communications between companies, "tracking" 1480 touches many other points within the trading relationship. This 1481 is where the use of 997 functional acknowledgments come in, the 1482 EDIFACT CONTRL message, and the common translator tracking of 1483 sequential group control numbers. All of this needs to be 1484 considered in Internet EDI tracking. 1486 The following is a list of the common tracking information needed 1487 when sending and receiving EDI Interchanges between trading 1488 partners: 1490 1). Transmission successfully translated from internal 1491 format to EDI standard format. 1493 2). Transmission successfully encoded, signed, encrypted, 1494 and sent. (The equivalence of transmission successfully 1495 received by the VAN.) 1497 Requirements For Inter-operable Internet EDI September 1999 1499 3). Transmission successfully delivered to the recipient's 1500 mailbox.(The equivalence of a VAN delivery acknowledgment 1501 that the sent transmission has been forwarded to the 1502 receiver's VAN mailbox.) 1504 4). Transmission successfully picked-up by the recipient. 1505 (The equivalence of a VAN mail-box pick-up acknowledgment.) 1507 5). Transmission successfully translated by the receiver. 1508 (The EDI Interchange was determined to be syntactically 1509 correct.) 1511 6). Detection and recovery of delayed or lost 1512 transmissions. 1514 7). Detection and handling of duplicate transmissions. 1516 The following section addresses in what components the new 1517 Internet EDI tracking information must be maintained, and 1518 discusses how this new tracking information relates to the 1519 tracking information kept by the EDI application. 1521 4.2 Transmission Successfully Translated From Internal Format to 1522 Standard EDI Format 1524 4.2.1 Needs 1526 There needs to be a facility by which a sender can be assured that 1527 the EDI transmission was correctly translated and prepared for 1528 outbound transmission. 1530 4.2.2 Recommendations 1532 This is standard functionality for most if not all EDI 1533 translators. This MUST NOT be required functionality of an EDI UA. 1535 4.3 Transmission Successfully Encoded, Encrypted, Signed and Sent 1537 4.3.1 Needs 1539 There needs to be a facility by which a sender can be assured that 1540 an EDI transmission was successfully encoded, encrypted, signed, 1541 and sent. 1543 4.3.2 Recommendations 1545 The tracking of the success or failure of the security services 1546 required for Internet EDI MUST be maintained by the EDI UA. 1548 The EDI UA MUST be able to identify the transmission by its 1549 message id, AND a calculated MIC value if desired. 1551 Requirements For Inter-operable Internet EDI September 1999 1553 4.4 Transmission Successfully Delivered to the Recipient's Mailbox 1555 4.4.1 Needs 1557 There needs to be a facility by which a sender can be assured that 1558 an EDI transmission was successfully delivered to a recipient's 1559 mailbox. 1561 4.4.2 Recommendations 1563 This type of tracking information is kept by the UA and is 1564 returned to the sender as a delivery notification. The delivery 1565 notification is specified in RFC 1894 [11]. 1567 4.5 Transmission Successfully Received 1569 4.5.1 Needs 1571 There needs to be a facility by which a sender of a transmission 1572 can be assured that the transmission was correctly received by the 1573 intended receiver. 1575 4.5.2 Recommendations 1577 This type of tracking information MUST be kept by the EDI UA and 1578 is returned to the sender as a signed receipt. (See section 3.7.3 1579 for a discussion about signed receipts.) 1581 Note: The X12 997 or EDIFACT CONTRL message can also provide the 1582 equivalent of an implicit transmission received 1583 acknowledgment. However, the use of signed receipts is still 1584 RECOMMENDED for the following reasons: 1586 * The implied success of the receiver's decryption through 1587 the receipt of a legible 997, binds the certificate to a 1588 control ID only (997) and not to the actual data (signed 1589 receipt). 1591 * Translators are very different, and the CONTRL message 1592 isn't supported by all EDI translators or is it in 1593 widespread use yet. 1595 4.6 Transmission Successfully Translated by the Receiver 1597 4.6.1 Needs 1599 There needs to be a facility for the sender to be assured that the 1600 receiver could "understand" (in EDI terms) the transmission. 1602 Requirements For Inter-operable Internet EDI September 1999 1604 4.6.2 Recommendations 1606 This SHOULD NOT be tracked by the EDI UA, following our 1607 Recommendation for object boundaries. 1609 The Functional acknowledgment 997, and the EDIFACT CONTRL serve 1610 this exact purpose -- this SHOULD be tracked by the EDI 1611 translator. 1613 4.7 Detection and Recovery of Delayed or Lost Transmissions 1615 4.7.1 Needs 1617 There needs to be a facility by which a sender can detect sent 1618 transmissions that have not been acknowledged as correctly 1619 received, by a specified, configurable, period of time, and be 1620 able to configure actions accordingly. 1622 4.7.2 Recommendations 1624 1). The sender should specify that a receipt or signed receipt be 1625 returned in response to the sent message. The way to request 1626 that a receipt or message disposition notification be returned 1627 by the recipient is specified in RFC 2298 [5]. The way to 1628 request that a signed receipt be returned by the recipient is 1629 specified in draft-ietf-ediint-as1-10.txt [10]. 1631 2). Both the receipt and signed receipt return the message id that 1632 was sent in the original message. In addition to the original 1633 message id, the signed receipt also returns the message 1634 integrity check calculated on the contents of the received 1635 message. 1637 3). The information in the receipt or signed receipt can then be 1638 used to correlate to the originally signed message. NOTE: A 1639 receipt or signed receipt MUST NOT be requested when sending a 1640 receipt or signed receipt. This is explicitly prohibited by 1641 the standards. 1643 4). If a receipt or signed receipt is not returned within a 1644 configurable time, then actions based on the failure to 1645 receive a receipt or signed receipt may include: 1647 * Re-transmit: If re-transmitted, the receiving 1648 UA MUST be able to detect the second 1649 transmission as a duplicate and discard it. 1651 * Alert/Report: Operator intervention may be required 1652 to track the cause of the delay in receiving the 1653 receipt or signed receipt. 1655 Requirements For Inter-operable Internet EDI September 1999 1657 4.8 Detection and Handling of Duplicate Transmissions 1659 4.8.1 Need 1661 There needs to be a facility by which a receiver of EDI 1662 transmissions is able to detect different types of duplicate 1663 transmissions, and handle them correctly. First, translator 1664 initiated duplicates SHOULD NOT be halted in any way - it should 1665 be assumed that translators will handle that level of duplication. 1666 In other words, there should be no checking of ISA control numbers 1667 by the UA. Secondly, the use of a re-transmission feature in 1668 attempts to deliver transmissions quickly, should allow for a UA 1669 to identify duplicate transmissions generated by the sending UA, 1670 and discard the duplicate transmissions after the first has been 1671 received. 1673 4.8.2 Recommendations 1675 By applying a signature to the EDI MIME content, the originator 1676 will send a message integrity check to the recipient of the 1677 transmission. The recipient SHOULD log the received message 1678 integrity check along with the other security related information 1679 associated with the received message. 1681 Duplicate messages can be detected by the recipient by comparing 1682 the message integrity check received each time, with the log of 1683 received message integrity checks. It is recommended that EDI UAs, 1684 in order to detect duplicate transmissions, agree minimally to 1685 sending and receiving signed content. 1687 EDI related control numbers, such as the ISA control number, 1688 should not be checked by the EDI UA. A duplicate EDI message can 1689 still be distinguished at the MIME messaging level, since EDI time 1690 stamps will change, even if the EDI control number or EDI 1691 transaction are duplicates. 1693 5. Appendix A - Implementation Considerations, Formats, and Examples 1695 5.1 Introduction 1697 The following appendix describes the structure of EDI MIME 1698 messages, making use of the security features previously 1699 discussed in this requirements document. 1701 The structures shown below represent the use of specifications 1702 outlined in the following RFCs. Before moving into the 1703 structures themselves, there is a brief review of what each 1704 document contributes. 1706 NOTE: The examples below are just that - examples. Do not code 1707 according to them. Refer to the RFCs that specify the correct 1709 Requirements For Inter-operable Internet EDI September 1999 1711 grammar in each case. 1713 5.2 Referenced RFCs and their contribution 1715 5.2.1 RFC 821 SMTP [7] 1717 This is the core mail transfer standard that all MTAs need 1718 to adhere to. 1720 5.2.2 RFC 822 Text Message Format [3] 1722 Defines message header fields and the parts making up a 1723 message. 1725 5.2.3 RFC 1847 MIME Security Multiparts [6] 1727 This document defines security multiparts for MIME: 1728 multipart/encrypted and multipart/signed. 1730 5.2.4 RFC 1892 Multipart/report [10] 1732 This RFC defines the use of Multipart/report content type, 1733 something that the MDN RFC 2298 builds upon to define 1734 the receipts functionality. 1736 5.2.5 RFC 1767 EDI Content [2] 1738 This RFC defines the use of content type "application" for 1739 ANSI X12 (application/EDI-X12), EDIFACT 1740 (application/EDIFACT) and mutually defined EDI 1741 (application/EDI-Consent). 1743 5.2.6 RFC 2015 PGP/MIME [4] 1745 This RFC defines the use of content types 1746 "multipart/encrypted", "multipart/signed", "application/pgp 1747 encrypted" and "application/pgp-signature" for defining 1748 MIME PGP content. 1750 5.2.7 RFC 2045, 2046, and 2049 MIME [1] 1752 These are the basic MIME standards, upon which all MIME 1753 related RFCs build, including this one. 1755 Key contributions include definition of "content type", 1756 "sub-type" and "multipart", as well as encoding 1757 guidelines, which establishes 7-bit US-ASCII as the 1758 canonical character set to be used in Internet messaging. 1760 5.2.8 RFC2298 - Message Disposition Notification [5] 1762 Requirements For Inter-operable Internet EDI September 1999 1764 This RFC defines how a message disposition notification 1765 (MDN) is requested, and the format and syntax of the MDN. 1766 The MDN is the basis upon which receipts and signed 1767 receipts are defined for Internet EDI. 1769 5.2.9 RFC2633 and RFC2630 -- S/MIME v3 Message Specification [8] 1771 These specifications describes how MIME shall carry PKCS7 1772 envelopes. 1774 5.3 Structure of an EDI MIME message - No encryption/No signature 1776 To: editest@cyclonesoftware.com 1777 Subject: 1778 From: ediSender@cyclonesoftware.com 1779 Date: Thu, 3 June 1999 11:30:29 -0700 1780 Mime-Version: 1.0 1781 Message-Id: 1782 Content-Type: application/EDI-X12 1783 Content-Transfer-Encoding: base64 1785 SVNBKjAwKnNzc3Nzc3Nzc3MqnJycnJycipaWipJUE5FVCAgICAgICA 1786 gICAqWloqQ1lDc3MqMDAqcnJnJycnJycipaWipJUE5FVCAgICAgICA 1788 5.4 Structure of an EDI MIME message - S/MIME 1790 5.4.1 S/MIME Overview 1792 S/MIME or the Secure/Multipurpose Internet Mail Extensions, 1793 specify formats and procedures when the cryptographic security 1794 services of authentication, message integrity, non-repudiation 1795 of origin, and confidentiality are applied to Internet 1796 MIME messages. 1798 S/MIME v3 is specified in Internet RFC 2630 and RFC 2633 [8]. 1800 This applicability statement sets forth the implementation 1801 requirements and recommendations needed to use S/MIME when 1802 sending EDI on the Internet. These implementation requirements 1803 and recommendations are intended to ensure a base level of 1804 inter-operability among S/MIME EDI implementations. 1806 NOTE: The S/MIME v3 Message Specification specifies a 1807 restricted profile for use for export purposes and an 1808 unrestricted profile for use domestically. These profiles 1809 specify the cryptographic algorithms and key lengths that a 1810 conforming S/MIME implementation must support. It is 1811 RECOMMENDED for Internet EDI, that these profiles be adhered 1812 to. However, cryptographic algorithms, and key lengths are 1813 parameters that need to be set by the trading partnership, and 1815 Requirements For Inter-operable Internet EDI September 1999 1817 can vary from what is specified by the S/MIME messaging 1818 specification, as well as this specification. 1820 Content Types: 1822 The signedAndEnvelopedData content type SHOULD NOT be used when 1823 sending EDI on the Internet. Objections have been raised 1824 concerning the fact that the issuerAndSerialNumber for each 1825 signer of a signedAndEnvelopedData content is left in the 1826 clear. This information could be used to derive the identity of 1827 the signer of the message. The use of signedAndEnvelopedData 1828 also precludes the ability to sign information that is in 1829 addition to, but separate from the primary signed contents. The 1830 use of S/MIME "authenticated attributes" is not required for 1831 Internet EDI, since it is generally sufficient to sign the EDI 1832 MIME content and headers. 1834 The S/MIME Message Specification requires a compliant S/MIME 1835 agent to support the nesting of a signed "message" format 1836 within an enveloped "message", for both incoming and outgoing 1837 messages. For Internet EDI, it is also REQUIRED that 1838 implementations support a nested signed "message" within an 1839 enveloped or encrypted "message". Therefore, when using S/MIME 1840 for the purpose of Internet EDI, a two step process MUST be 1841 used: the user agent first creates a multipart/signed 1842 "content", and uses this multipart/signed "content" as input to 1843 the creation of an application/pkcs7-mime enveloped 1844 "message". 1846 The receiver of an incoming enveloped "message" that is 1847 decrypted and found to contain a multipart/signed "content", 1848 MUST process the multipart/signed "content" and present the 1849 signature status and corresponding first body part of the 1850 multipart/signed to the receipts processing -- if either a 1851 request for a receipt or signed receipt has been made - 1852 otherwise, the first body part of the multipart/signed is 1853 passed to a general MIME processor. 1855 For the purpose of Internet EDI, the first body part of the 1856 multipart/signed SHOULD contain RFC 1767 specified MIME EDI 1857 content, or a MIME multipart/mixed content that has at least 1858 one RFC 1767 MIME EDI content as part of the multipart/mixed 1859 content. 1861 Multipart/Signed and signedData: 1863 The S/MIME specification requires support of the signedData 1864 content format, and recommends support of the multipart/signed 1865 format. For use in Internet EDI however, it is REQUIRED that 1866 the multipart/signed format be supported, whenever message 1867 authentication, integrity, and non-repudiation of origin are 1869 Requirements For Inter-operable Internet EDI September 1999 1871 used. The great value for support of the multipart/signed 1872 format is the ability of non S/MIME-enabled agents to process 1873 the content of the body that was signed. 1875 The PKCS7 signedData format MAY be used only when it is known 1876 that the EDI data is to pass through non RFC 1847 compliant 1877 gateways. 1879 Some non RFC 1847 compliant gateways do not treat the message 1880 contents as opaque, and may change the content transfer 1881 encoding, thereby invalidating the message integrity check 1882 that was calculated by the sender. 1884 Support of the PKCS7 signedData format for use in Internet EDI 1885 is OPTIONAL, and MUST be agreed upon between trading partners. 1887 5.4.2 Example: S/MIME - Signature Only (Multipart/Signed) 1889 To: editest@cyclonesoftware.com 1890 Subject: 1891 From: ediSender@cyclonesoftware.com 1892 Date: Thu, 3 June 1999 11:30:29 -0700 1893 Mime-Version: 1.0 1894 Message-Id: ebac3753.19d6.04bcaec1b@cyclonesoftware.com 1895 Content-Type: multipart/signed; 1896 protocol="application/pkcs7-signature"; 1897 micalg=sha1; boundary="separator" 1899 --separator 1900 & Content-Type: application/EDI-X12 1901 & Content-Transfer-Encoding: base64 1902 & Content-Disposition: attachment; filename="edifile.x12" 1903 & 1904 & SVNBKjAwKnNzc3Nzc3Nzc3MqMDAqcnJycnJycnJycipaWipJUE5FVCAgICA 1905 & gICAgICAqWloqQ1lDTE9ORSAgICAgICAgKjk2MTAwNyoyMDEzKlUqMDAyMD 1906 & AqMDAwMDAzMDAzKjAqVCoqDUdTKlBPKlMxUzFTMVMxUzFTMVMxUypSMVIxU 1907 & jFSMVIxUjFSMVIqOTYxMDA3KjIwMTMqMDAwMDAwMDA0KlgqM== 1909 --separator 1910 Content-Type: application/pkcs7-signature 1911 Content-Transfer-Encoding: base64 1912 Content-Disposition: inline; filename="smime.p7s" 1914 GfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIY 1915 TiutTYT34553//YRytdhfFFQer/876JHJHGIUIU 1916 GsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewR 1917 EWREEWE88POF/DfrtFFKFG+GFff== 1919 --separator-- 1921 Requirements For Inter-operable Internet EDI September 1999 1923 Notes: 1924 -The lines preceded with "&" is what the signature is calculated 1925 over. 1927 5.4.3 Example: S/MIME - Signature Only (signedData) 1928 To: editest@cyclonesoftware.com 1929 Subject: 1930 From: ediSender@cyclonesoftware.com 1931 Date: Thu, 3 June 1999 11:30:29 -0700 1932 Mime-Version: 1.0 1933 Message-Id: ebac3753.19d6.04bcaec1b@cyclonesoftware.com 1934 Content-Type: application/pkcs7-mime; smime-type=signed-data; 1935 name=smime.p7m 1936 Content-Transfer-Encoding: base64 1937 Content-Disposition: inline; filename="smime.p7m" 1939 1940 Version 1941 DigestAlgorithmIdentifiers 1942 Content 1943 &Mime-Version: 1.0 1944 &Content-Type: application/EDI-X12 1945 &Content-Transfer-Encoding: binary 1946 & 1947 & 1948 certificates 1949 crls 1950 SignerInfos 1952 Notes: 1953 -The Content-Transfer-Encoding has been removed from the example 1954 to display the internal structure of the PKCS7 object. 1956 -The lines preceded with "&" is what the signature is calculated 1957 over. 1959 - refer to: 1960 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): 1962 5.4.4 Example: S/MIME - Encryption Only 1964 To: editest@cyclonesoftware.com 1965 Subject: 1966 From: ediSender@cyclonesoftware.com 1967 Date: Thu, 3 June 1999 11:30:29 -0700 1968 Mime-Version: 1.0 1969 Message-Id: ebac3753.19d6.04bcaec1b@cyclonesoftware.com 1970 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 1971 name=smime.p7m 1972 Content-Transfer-Encoding: base64 1973 Content-Disposition: inline; filename="smime.p7m" 1975 Requirements For Inter-operable Internet EDI September 1999 1977 1978 &Mime-Version: 1.0 1979 &Content-Type: Application/; 1980 &Content-Transfer-Encoding: 1981 & 1982 & 1984 Notes: 1986 - The text preceded by "&" indicates that it is really encrypted, 1987 but presented as text for clarity 1989 - consists of (See 1990 PKCS7: Cryptographic Message Syntax Standard from RSA Labs, 1991 Inc.): 1993 contentType = EnvelopedData 1994 version = Version 1995 recipientInfos = RecipientInfos 1997 contentType = Data 1998 contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier 2000 encryptedContent = 2002 NOTE: Except for contentType, the actual object identifiers or 2003 values for the fields are not specified. (See PKCS9 and the 2004 S/MIME v3 Message Specification from RSA Labs, Inc., for these 2005 objects.) 2007 NOTE: The recipientInfos contains the symmetric encryption key 2008 encrypted with the receiver's public key. The 2009 issuerAndSerialNumber field defined within the recipientInfos 2010 identifies a receiving trading partner's public-key 2011 certificate. Since Internet EDI allows self-certification, 2012 this field can contain the distinguished name of the 2013 receiving trading partner or the issuer distinguished name. 2014 NOTE: In general there will be one recipientInfos specified, but 2015 in the case of RFQs, there may be n recipientInfos specified. 2017 5.4.5 Example: S/MIME - Signature and Encryption (Multipart/Signed) 2019 The required support for EDI Internet is to first create a MIME 2020 multipart/signed content, and then to create an 2021 application/pkcs7-mime envelopedData message with the 2022 multipart/signed content as the input to the envelopedData 2023 message. 2025 To: editest@cyclonesoftware.com 2026 Subject: 2028 Requirements For Inter-operable Internet EDI September 1999 2030 From: ediSender@cyclonesoftware.com 2031 Date: Thu, 3 June 1999 11:30:29 -0700 2032 Mime-Version: 1.0 2033 Message-Id: ebac3753.19d6.04bcaec1b@cyclonesoftware.com 2034 Content-Type: application/pkcs7-mime 2035 Content-Transfer-Encoding: base64 2037 2039 *Content-Type: multipart/signed; 2040 * protocol="application/pkcs7-signature" 2041 * micalg=; 2042 * boundary="separator"; 2043 * 2044 *--separator 2045 * &Content-Type: Application/ 2046 * &Content-Transfer-Encoding: 2047 * & 2048 * & 2049 * 2050 * --separator 2051 * Content-Type: application/pkcs7-signature 2052 * Content-Transfer-Encoding: 2053 * 2054 * fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553// 2055 * /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREW 2056 * EEWE88frtFFKFG+GFff= 2057 * 2058 *--separator-- 2060 Notes: 2062 - The lines preceded with "&" is what the signature is 2063 calculated over. 2065 - The text preceded by "*" indicates that it is really 2066 encrypted, but presented as text for clarity. 2068 - consists of (See 2069 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, 2070 Inc.): 2072 contentType = EnvelopedData 2073 version = Version 2074 recipientInfos = RecipientInfos 2076 contentType = Data 2077 contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier 2079 encryptedContent = 2081 Requirements For Inter-operable Internet EDI September 1999 2083 NOTE: Except for contentType, the actual object identifiers or 2084 values for the fields are not specified. (See PKCS9 and the 2085 S/MIME Implementation Guide, Version 2 from RSA Labs, Inc., 2086 for these objects.) 2088 NOTE: The recipientInfos contains the symmetric encryption key 2089 encrypted with the receiver's public key. The 2090 issuerAndSerialNumber field defined within the recipientInfos 2091 identifies a receiving trading partner's public-key 2092 certificate. Since Internet EDI allows self-certification, 2093 this field can contain the distinguished name of the 2094 receiving trading partner or the issuer distinguished 2095 name. 2097 NOTE: In general there will be one recipientInfos specified, but 2098 in the case of RFQs, there may be n recipientInfos specified. 2100 5.4.6 Example: S/MIME - Signature and Encryption (signedData) 2102 To: editest@cyclonesoftware.com 2103 Subject: 2104 From: ediSender@cyclonesoftware.com 2105 Date: Thu, 3 June 1999 11:30:29 -0700 2106 Mime-Version: 1.0 2107 Message-Id: ebac3753.19d6.04bcaec1b@cyclonesoftware.com 2108 Content-Type: application/pkcs7-mime 2109 Content-Transfer-Encoding: base64 2111 2113 *Content-Type: application/pkcs7-mime 2114 * 2115 * 2116 *&Content-Type: Application/; 2117 *&Content-Transfer-Encoding: 2118 *& 2119 * 2120 * 2122 Notes: 2124 - The lines preceded with "&" is what the signature is calculated 2125 over. 2127 - The text preceded by "*" indicates that it is really 2128 encrypted, but presented as text for clarity 2130 - consists of (See 2131 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, 2132 Inc.): 2134 Requirements For Inter-operable Internet EDI September 1999 2136 contentType = EnvelopedData 2137 version = Version 2138 recipientInfos = RecipientInfos 2140 contentType = Data 2141 contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier 2143 encryptedContent = 2145 NOTE: Except for contentType, the actual object identifiers or 2146 values for the fields are not specified. (See PKCS9 and the 2147 S/MIME Implementation Guide, Version 2 from RSA Labs, Inc., 2148 for these objects.) 2150 NOTE: The recipientInfos contains the symmetric encryption key 2151 encrypted with the receiver's public key. The 2152 issuerAndSerialNumber field defined within the recipientInfos 2153 identifies a receiving trading partner's public-key 2154 certificate. Since Internet EDI allows self-certification, 2155 this field can contain the distinguished name of the 2156 receiving trading partner or an issuer's distinguished 2157 name. 2159 NOTE: In general there will be one recipientInfos specified, but 2160 in the case of RFQs, there may be n recipientInfos specified. 2162 - consists of (refer to: 2163 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, 2164 Inc.): 2166 signerInfos = SignerInfo 2168 NOTE: The signerInfo contains the digestAlgorithm, the 2169 digestEncryptionAlgorithm, and the encryptedDigest or the digital 2170 signature. The issuerAndSerialNumber field defined within the 2171 signerInfos identifies a signing trading partner's public-key 2172 certificate. Since Internet EDI allows self-certification, this 2173 field can contain the distinguished name of the sending trading 2174 partner or an issuer's distinguished name. 2176 5.5 Structure of an EDI MIME message - PGP/MIME 2178 5.5.1 Overview 2180 PGP provides two functional services, signature and encryption, 2181 but in reality performs 5 functions in order to do it 2182 effectively. 2184 1) Digital signature (MD5, RSA) 2186 Requirements For Inter-operable Internet EDI September 1999 2188 2) Compression (ZIP) 2189 3) Message Encryption (IDEA) 2190 4) ASCII Armor 2191 5) Message segmentation 2193 When sending a message, the services are performed in that 2194 order. 2196 With the exception of item 5), these services are optional, 2197 meaning a user can choose whether to use signature, encryption, 2198 compression and ASCII armor, but commonly, 2) and 4) are always 2199 used, while 1) and 3) are used in three ways: 2201 1) Signature only, in which case ASCII armor can be applied 2202 only to the signature block to keep the message legible. 2204 2) Encryption only 2206 3) Both signature and encryption 2208 Applicability of PGP/MIME and RFC 2015, for use in Internet EDI 2209 dictates the following: 2211 - When both encryption and signature feature is used, the EDI 2212 data is first signed, then encrypted in a two-step process, as 2213 described in the example. 2215 -Compression and ASCII Armor is optional and could be user 2216 configurable. 2218 The following examples describe use of PGP/MIME without 2219 compression and ASCII armor, since those services are managed 2220 by PGP, and are optional per this draft 2222 5.5.2 Example: PGP/MIME - Signature Only 2224 To: editest@cyclonesoftware.com 2225 Subject: 2226 From: ediSender@cyclonesoftware.com 2227 Date: Thu, 3 June 1999 11:30:29 -0700 2228 Mime-Version: 1.0 2229 Message-Id: ebac3753.19d6.04bcaec1b@cyclonesoftware.com 2230 Content-Type: multipart/signed; 2231 boundary="separator"; micalg=pgp-; 2232 protocol="application/pgp-signature" 2234 --separator 2235 &Content-Type: Application/ 2236 &Content-Transfer-Encoding: 2238 Requirements For Inter-operable Internet EDI September 1999 2240 & 2241 & 2243 --separator 2244 Content-Type: application/pgp-signature 2246 -----BEGIN PGP MESSAGE----- 2247 Version 2.6.2 2249 FgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJH 2250 JuytIYTiutTYT34553//YRytdhfFFQer/8 2251 76JHJHGIUIUgsdIUYgYTRdgggguytUTIUl 2252 bXssfdsfdREWrewREWREEWE88POF/DfrtF 2253 FKFG+GFff== 2255 -----END PGP MESSAGE----- 2257 --separator-- 2259 Notes: 2261 - The lines preceded with "&" is what the signature is calculated 2262 over. 2264 5.5.3 Example: PGP/MIME - Encryption Only 2266 To: editest@cyclonesoftware.com 2267 Subject: 2268 From: ediSender@cyclonesoftware.com 2269 Date: Thu, 3 June 1999 11:30:29 -0700 2270 Mime-Version: 1.0 2271 Message-Id: ebac3753.19d6.04bcaec1b@cyclonesoftware.com 2272 Content-Type: multipart/encrypted; boundary="separator"; 2273 protocol="application/pgp-encrypted" 2275 --separator 2276 Content-Type: application/pgp-encrypted 2278 Version: 1 2280 --separator 2281 Content-Type: application/octet-stream 2283 -----BEGIN PGP MESSAGE----- 2284 Version 2.6.2 2286 & 2287 &Content-Type: Application/; 2288 &Content-Transfer-Encoding: 2289 & 2291 Requirements For Inter-operable Internet EDI September 1999 2293 & 2294 -----END PGP MESSAGE----- 2296 --separator-- 2298 Notes: 2300 - The text preceded by "&" indicates that it is really encrypted, 2301 but presented as text for clarity 2303 - "pgp control information" contains the following, but refer to 2304 PGP specifications or tool kits for details: 2306 -Key ID of recipient's public key 2307 -Session key (symmetric) 2308 -Timestamp 2309 -Key ID of sender's public key 2310 -Leading two octets of message digest 2311 -Message digest 2312 -Filename 2313 -Timestamp 2315 5.5.4 Example: PGP/MIME - Signature and Encryption 2317 The sequence here is that the EDI data is first signed as a 2318 multipart/signed body, and then the data plus the signature is 2319 encrypted to form the final multipart/encrypted body. 2321 To: editest@cyclonesoftware.com 2322 Subject: 2323 From: ediSender@cyclonesoftware.com 2324 Date: Thu, 3 June 1999 11:30:29 -0700 2325 Mime-Version: 1.0 2326 Message-Id: ebac3753.19d6.04bcaec1b@cyclonesoftware.com 2327 Content-Type: multipart/encrypted; boundary="separator"; 2328 protocol="application/pgp-encrypted" 2330 --separator 2331 Content-Type: application/pgp-encrypted 2333 Version: 1 2335 --separator 2336 Content-Type: application/octet-stream 2338 -----BEGIN PGP MESSAGE----- 2339 Version 2.6.2 2341 * 2342 * Content-Type: multipart/signed; boundary="signed separator"; 2344 Requirements For Inter-operable Internet EDI September 1999 2346 * micalg=pgp-; 2347 * protocol="application/pgp-signature" 2348 * 2349 * --signed separator 2350 * &Content-Type: Application/ 2351 * &Content-Transfer-Encoding: 2352 * & 2353 * & 2354 * 2355 * --signed separator 2356 * Content-Type: application/pgp-signature 2357 * 2358 * -----BEGIN PGP MESSAGE----- 2359 * Version 2.6.2 2360 * 2361 * fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytd 2362 * /GIUIUgsIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF 2363 * frtFFKFG+GFff= 2364 * =ndaj 2365 * -----END PGP MESSAGE----- 2366 * 2367 * --signed separator-- 2368 -----END PGP MESSAGE----- 2370 --separator- 2372 Notes: 2374 - The lines preceded with "&" is what the signature is calculated 2375 over. 2377 - The text preceded by "*" indicates that it is really encrypted, 2378 but presented as text for clarity 2380 - "pgp control information" contains the following, but refer to 2381 PGP specifications or tool kits for details: 2383 -Key ID of recipient's public key 2384 -Session key (symmetric) 2385 -Timestamp 2386 -Key ID of sender's public key 2387 -Leading two octets of message digest 2388 -Message digest 2389 -Filename 2390 -Timestamp 2392 -RFC 2015 allows another way to handle the above in a combined 2393 fashion, However, for the purpose of EDI we require the above 2394 method, which is based on MIME Security Multiparts [4] RFC 1847. 2395 This method performs signature and encryption in a two-step 2396 process, first signing the data, then encrypting it. This is 2398 Requirements For Inter-operable Internet EDI September 1999 2400 also consistent with PGP's recommendations. 2402 5.6 Additional Considerations 2404 RFC 1847 [6] and RFC 1848 [12] provide valuable guidance 2405 when implementing the multipart/signed content. In particular, 2406 RFC 1848 provides the canonicalization considerations required 2407 when implementing the multipart/signed content. 2409 6. Acknowledgments 2411 Many thanks go out to the previous authors of the MIME-based 2412 Secure EDI IETF Draft: Mats Jansson. 2414 The authors would like to also extend special thanks to Lincoln 2415 Yarbrough for his support and championing of these open 2416 Internet EDI standards. 2418 This document is the result of the many contributions of the 2419 members of the IETF EDIINT Working group, including Harald 2420 Alvestrand, Jim Galvin, Karen Rosenthal, Dale Moberg, Carl Hage, 2421 Jun Ding, and Pedro Chiang. 2423 7. References 2425 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 2426 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 2427 December 02, 1996. 2429 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 2430 (MIME) Part Two: Media Types", RFC 2046, December 02, 2431 1996. 2433 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 2434 (MIME) Part Five: Conformance Criteria and Examples", RFC 2435 2049, December 02, 1996. 2437 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, 2438 March 2, 1995. 2440 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 2441 Messages", STD 11, RFC 822, August 13, 1982. 2443 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2444 2015, Sept. 1996. 2446 [5] R. Fajman, "An Extensible Message Format for Message Disposition 2447 Notifications", RFC 2298, March 1998. 2449 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security 2450 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 2452 Requirements For Inter-operable Internet EDI September 1999 2454 RFC 1847, Oct. 3, 1995. 2456 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 2457 August 1, 1982. 2459 [8] B. Ramsdell, "S/MIME Version 3 Message Specification; 2460 Cryptographic Message Syntax", RFC 2633 RFC 2630, June 1999. 2462 [9] G. Vaudreuil, "The Multipart/Report Content Type for the 2463 Reporting of Mail System Administrative Messages", RFC 1892, 2464 January 15, 1996. 2466 [10] T. Harding, R. Drummond, "MIME-based Secure EDI", 2467 Internet draft: draft-ietf-ediint-as1-10.txt, September, 1999. 2469 [11] K. Moore, G. Vaudreuil, "An Extensible Message Format for 2470 Delivery Status Notification", RFC 1894, January, 1996. 2472 [12] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object 2473 Security Services", RFC 1848, October, 1995. 2475 [13] B. Schneier, "E-Mail Security", John Wiley & Sons, 1995. 2477 [14] B. Schneier, "Applied Cryptography", 2e. John Wiley & Sons, 2478 1996. 2480 [15] M. Blaze, W. Diffie, R. L. Rivest, B. Schneier, T. Shimomura, 2481 E. Thompson, M. Wiener, "Minimal Key Lengths for 2482 Symmetric Ciphers to Provide Adequate Commercial Security". 2484 8. Author's Address: 2486 Terry Harding 2487 tharding@cyclonesoftware.com 2488 Cyclone Software 2489 14505 N. Hayden Road. Suite 300 2490 Scottsdale, AZ, 85260 2492 Chuck Shih 2493 chuck.shih@gartner.com 2494 Gartner Group. 2495 251 River Oaks Parkway 2496 San Jose, CA 95134-1913 USA 2498 Rik Drummond 2499 drummond@onramp.net 2500 The Drummond Group 2501 5008 Bentwood Ct. 2502 Ft. Worth, TX 76132 USA