idnits 2.17.1 draft-ietf-ediint-req-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 54 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 6 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 221 has weird spacing: '... use of the I...' == Line 233 has weird spacing: '...re, and vendo...' == Line 260 has weird spacing: '...ffering some ...' == Line 266 has weird spacing: '...ffering the a...' == Line 374 has weird spacing: '... a very good ...' == (12 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.) -- The document date (8 July 1997) is 9789 days in the past. Is this intentional? 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 2475, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 2496, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) == Outdated reference: A later version (-07) exists of draft-ietf-receipt-mdn-04 ** Obsolete normative reference: RFC 821 (ref. '7') (Obsoleted by RFC 2821) -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 1892 (ref. '9') (Obsoleted by RFC 3462) == Outdated reference: A later version (-17) exists of draft-ietf-ediint-as1-04 -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1894 (ref. '12') (Obsoleted by RFC 3464) ** Downref: Normative reference to an Historic RFC: RFC 1848 (ref. '13') -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EDIINT Working Group Chuck Shih 3 Internet Draft Mats Jansson 4 Expires: 6 /98 Rik Drummond 5 8 July 1997 7 Requirements for Inter-operable Internet EDI 9 draft-ietf-ediint-req-04.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. Internet-Drafts are draft documents 18 valid for a maximum of six months and may be updated, 19 replaced, or made obsolete by other documents at any 20 time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work 22 in progress." 24 To learn the current status of any Internet-Draft, 25 please check the "1id-abstracts.txt" listing contained 26 in the Internet-Drafts Shadow Directories on 27 ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 unnari.oz.au (Pacific Rim), ds.internic.net (US East 29 Coast), or ftp.isi.edu (US West Coast). 31 Any questions, comments, and reports of defects or 32 ambiguities in this specification may be sent to the 33 mailing list for the EDIINT working group of the IETF, 34 using the address . Requests to 35 subscribe to the mailing list should be addressed to 36 . 38 Abstract 40 This document is a functional specification, discussing 41 the requirements for inter-operable EDI, with sufficient 42 background material to give an explanation for the EDI 43 community of the Internet and security related issues. 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 46 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 47 "OPTIONAL" in this document are to be interpreted as described in 48 RFC 2119. 50 Feedback Instructions 52 If you want to provide feedback on this draft, follow these 53 guidelines: 55 -Send feedback via e-mail to the ietf-ediint list for discussion, 56 with "Requirements" in the Subject field. To enter 57 or follow the discussion, you need to subscribe to ietf- 58 ediint@imc.org. 60 -Be specific as to what section you are referring to, preferably 61 quoting the portion that needs modification, after which you state 62 your comments. 64 -If you are recommending some text to be replaced with your 65 suggested text, again, quote the section to be replaced, 66 and be clear on the section in question. 68 Table of Contents 70 1.0 INTRODUCTION 5 72 1.1 THE AUDIENCE 6 74 2.0 THE INTERNET - A BRIEF HISTORY 6 76 2.1 THE INTERNET - MYTHS AND REALITY 6 78 2.2 INTERNET ROUTING AND SECURITY CONSIDERATIONS 8 80 2.3 EDI VAN COMMUNICATIONS AND SECURITY 10 82 2.4 EDI OBJECT BOUNDARIES AND TRANSACTION PRIVACY 11 84 3.0 FUNCTIONAL REQUIREMENTS 11 86 3.1 INTRODUCTION AND DEFINITIONS 11 87 3.2 STANDARD ENCRYPTION ALGORITHMS AND WORLD-WIDE 11 88 ENCRYPTION 89 3.2.1 INTRODUCTION AND DESCRIPTION 11 90 3.2.2 SYMMETRIC ENCRYPTION 13 91 3.2.3 ASYMMETRIC ENCRYPTION - PUBLIC-KEY CRYPTOGRAPHY 14 92 3.2.4 NEEDS 15 93 3.2.5 ISSUES 15 94 3.2.6 RECOMMENDATIONS 15 96 3.3 KEY MANAGEMENT - SYMMETRIC KEYS 18 97 3.3.1 INTRODUCTION AND DESCRIPTION 18 98 3.3.2 NEEDS 20 99 3.3.3 ISSUES 20 100 3.3.4 RECOMMENDATIONS 20 102 3.4 KEY MANAGEMENT - PUBLIC AND PRIVATE KEYS 21 103 3.4.1 INTRODUCTION AND DESCRIPTION 21 104 3.4.2 PUBLIC KEYS 22 105 3.4.3 TRUST AND PUBLIC KEYS 23 106 3.4.4 NEEDS 23 107 3.4.5 ISSUES 24 108 3.4.6 RECOMMENDATIONS 24 110 3.5 CONTENT INTEGRITY 25 111 3.5.1 INTRODUCTION AND DESCRIPTION 25 112 3.5.2 NEEDS 26 113 3.5.3 ISSUES 26 114 3.5.4 RECOMMENDATIONS 26 116 3.6 AUTHENTICATION AND NON-REPUDIATION OF ORIGIN 26 117 3.6.1 INTRODUCTION AND DESCRIPTION 27 118 3.6.2 NEEDS 28 119 3.6.3 ISSUES 28 120 3.6.4 RECOMMENDATIONS 28 122 3.7 SIGNED RECEIPT AND NON REPUDIATION OF 29 123 RECEIPT 124 3.7.1 INTRODUCTION AND DESCRIPTION 29 125 3.7.2 NEEDS 30 126 3.7.3 RECOMMENDATIONS 30 128 3.8 SYNTAX AND PROTOCOL FOR SPECIFYING CRYPTOGRAPHIC 31 129 SERVICES 130 3.8.1 INTRODUCTION AND DESCRIPTION 31 131 3.8.2 NEEDS 31 132 3.8.3 ISSUES 31 133 3.8.4 RECOMMENDATIONS 32 135 4.0 TRACKING AND ERROR HANDLING BASICS 33 137 4.1 INTRODUCTION 33 139 4.2 TRANSMISSION SUCCESSFULLY TRANSLATED FROM 34 140 INTERNAL FORMAT TO STANDARD EDI FORMAT 141 4.2.1 NEEDS 34 142 4.2.2 RECOMMENDATIONS 34 144 4.3 TRANSMISSION SUCCESSFULLY ENCODED, ENCRYPTED, SIGNED 34 145 AND SENT 146 4.3.1 NEEDS 34 147 4.3.2 RECOMMENDATIONS 34 149 4.4 TRANSMISSION SUCCESSFULLY DELIVERED TO THE RECIPIENTS 35 150 MAILBOX 151 4.4.1 NEEDS 35 152 4.4.2 RECOMMENDATIONS 35 154 4.5 TRANSMISSION SUCCESSFULLY RECEIVED 35 155 4.5.1 NEEDS 35 156 4.5.2 RECOMMENDATIONS 35 158 4.6 TRANSMISSION SUCCESSFULLY TRANSLATED BY 36 159 RECEIVER 160 4.6.1 NEEDS 36 161 4.6.2 RECOMMENDATIONS 36 163 4.7 DETECTION AND RECOVERY OF DELAYED OR LOST 36 164 TRANSMISSIONS 165 4.7.1 NEEDS 36 166 4.7.2 RECOMMENDATIONS 36 168 4.8 DETECTION AND HANDLING OF DUPLICATE 37 169 TRANSMISSIONS 170 4.8.1 NEEDS 37 171 4.8.2 RECOMMENDATIONS 37 173 5.0 APPENDIX A - IMPLEMENTATION CONSIDERATIONS, FORMATS, 38 174 AND EXAMPLES 176 6.0 ACKNOWLEDGMENTS 52 178 7.0 REFERENCES 53 180 8.0 AUTHOR'S ADDRESSES 54 181 1.0 Introduction 183 Electronic Data Interchange (EDI) is a set of formats 184 for conducting highly structured inter-organization 185 exchanges, such as for making purchases or initiating 186 loan requests. The initial RFC1767 defined the method 187 for packaging EDI X12 and UN/EDIFACT transaction sets in 188 a MIME envelope. However, several additional 189 requirements for obtaining multi-vendor, inter-operable 190 service, over and above how the EDI transactions are 191 packaged, have come to light since the effort concluded. 192 These currently revolve around security issues such as 193 EDI transaction integrity, confidentiality and non- 194 repudiation in various forms. Standards in these and 195 other areas described later in this document are necessary 196 to insure inter-operability between EDI implementations 197 over the Internet. Various technologies already exist 198 for these additional features, and the primary 199 requirement is to review and select a common set of 200 components for use by the EDI community when it sends 201 EDI over the Internet. In effect, the effort is to 202 provide an EDI over the Internet Requirements Document, 203 and an Applicability Statement Document(s). 205 Additional requirements that mimic many of the header fields 206 found in X.435 EDI messages (e.g., Interchange Sender, Interchange 207 Recipient, Interchange Control Reference, Communications 208 Agreement ID, and Syntax Identifier) are also needed to 209 support efficient EDI exchanges between the Internet, and 210 the Value Added Networks. However, this specification is not 211 intended to cover the EDI VAN and Internet gateway 212 requirements. 214 This document's current focus is on EDI MIME content 215 transported using SMTP (Simple Mail Transport Protocol), 216 the Internet's mail or messaging system. 218 Traditional VAN connectivity is slow and expensive. The 219 Internet promises lower cost usage and is more easily 220 accessible than traditional methods of communications. 221 The predominant problem with the use of the Internet 222 for EDI is inter-operability between vendor products, 223 specifically in the areas of integrity, confidentiality, 224 digital signature, and non-repudiation. The EDIINT working 225 group's focus is to recommend solutions for each of 226 these areas, using existing standards whenever possible. 228 1.1 The Audience 230 The audience for this document consists of persons 231 directly or indirectly involved in EDI communications 232 decisions, companies trading EDI documents today or in 233 the future, and vendors developing and marketing EDI 234 products. Also included in the audience for this 235 document are people providing services and consulting 236 to the EDI community. 238 2.0 The Internet - A Brief History 240 The Internet is a world-wide collection of computers, 241 routers, and networks, connected together using the 242 TCP/IP suite of protocols. The Internet itself is not a 243 network, but a collection of networks. The Internet was 244 designed to be decentralized, with no single authority 245 needed to run it. All hosts on the Internet can 246 communicate with one another as peers, and all of the 247 communications protocols are "open" -- the standards are 248 in the public domain, and the standardization process is 249 open to anyone willing to put in the hard work to help 250 define them. 252 One consequence of this standards "openness" is that the 253 Internet can accommodate many different kinds of 254 machines (toasters for example). Its protocols -- the 255 TCP/IP suite -- have therefore become the de facto 256 standards for heterogeneous computer networking. At one 257 level, the Internet is a physical collection of 258 computers connected by common protocols. At another 259 level though, the Internet can be thought of as a 260 distributed medium, offering some important advantages 261 for doing EDI. For instance, the Internet has hundreds 262 of thousands of connected global hosts, and tens of 263 millions of users. The Internet offers a flat rate, 264 volume and time-of-day independent pricing structure for 265 data transmission. The Internet is highly redundant, 266 offering the ability to route data along alternate 267 paths. The Internet's decentralized structure makes 268 adding new hosts relatively easy -- it scales well, and 269 the Internet supports high bandwidth communications technologies. 271 2.1. The Internet - Myths and Reality 273 The Internet had its beginnings in 1969 as an 274 experimental U.S. Defense Department network called 275 ARPANET. The network was built to facilitate research on 276 how to construct networks that could withstand outages 277 to part of the network, but continue to function. 278 Network reliability was a fundamental design point when 279 developing the architecture and protocols associated 280 with the Internet. From the premise that the network was 281 inherently unreliable (parts of it could be destroyed at 282 any moment) emerged a design that was both robust and 283 reliable. Early on, the networks comprising the 284 Internet were primarily those from government agencies 285 and educational institutions. Access to the Internet was 286 pretty much available only to computer science 287 researchers, and government employees and their contractors. 289 In 1986, the National Science Foundation, in order to 290 provide access to what was then a scarce resource, put 291 together an initiative to link five super-computer 292 centers together using the TCP/IP protocols. Two very 293 important results of the NSFNET initiative were the 294 upgrading of the Internet's infrastructure with 295 more powerful processors and higher speed links, and 296 expansion of access to a larger user community. The 297 1990's has seen the continual upgrading of the Internet 298 infrastructure and its expansion to new constituencies 299 outside the traditional government and university 300 research community. Commercial interests are now the 301 largest as well as the fastest growing segment of the 302 Internet. 304 Commercial Internet providers, such as Performance 305 Systems International (PSI), and UUNET (the Alternet 306 network), have emerged from the collection of 307 intermediate-level networks that came into being as a 308 result of the NSFNET initiative. The national long distance 309 carriers such as MCI, AT&T, and Sprint all 310 provide commercial Internet services. These commercial 311 providers, called Internet Service Providers or ISPs for 312 short, make available Internet connectivity and various 313 other Internet services to their clients. The perception 314 of the Internet as experimental, and primarily used by 315 and for educational and research activities is 316 rooted in the Internet's past, and does not reflect today's 317 situation. The growth in commercial access to the 318 Internet, along with the growth of the ISPs, has 319 radically changed the Internet's network composition. 321 The design and architecture underlying the Internet has 322 proven its robustness by scaling to unprecedented 323 proportions. The Internet is reliable from several 324 perspectives: 326 1). Technologically, the TCP/IP suite of protocols and 327 the architecture underlying the Internet are stable and 328 mature. 330 2). Product implementations based on the TCP/IP suite 331 are also stable and mature. 333 3). Internet routing is dynamic, so packets sent through 334 the Internet get to their destinations even if there are 335 network outages along the way. 337 4). The commercial ISP administered portions of the 338 Internet, provide essentially the same level of network 339 reliability, availability, monitoring, throughput, 340 implementation and support services as existing EDI 341 Value Added Networks (VANS), but at a lower cost and 342 with higher bandwidth. 344 Although the Internet is reliable, low-cost, highly 345 accessible, supports high bandwidth communications, and 346 is technically mature, there are still some valid 347 concerns relating to the use of the Internet for EDI. 348 These concerns revolve primarily around security, 349 message tracking, audit trails, and authentication. Some 350 of the concerns, encryption for instance, are of a 351 general nature and not specific to the Internet -- 352 encryption may be required regardless of what type of 353 network is traversed. Other concerns, such as tracking, 354 arise because they are required by EDI, or are supported by 355 existing EDI Value Added Networks. 357 2.2 Internet Routing and Security Considerations 359 By using a common network trace program called 360 Traceroute, the route traversed by a packet from a 361 source host to a destination host on the Internet may be 362 followed. Tracing routes on the Internet yield some 363 interesting characteristics. As expected, the routes 364 traversed go through the networks administered by the 365 ISPs of each of the trading partners. Each route 366 consists of multiple nodes through each network. The 367 route can vary but that is not the typical case. The IP 368 packets are delivered reliably, and within a specified 369 period of time. When a reputable commercial ISP is used, 370 none of the nodes in the route are administered by 371 government or educational entities. 373 By looking at Internet network traces, we can conclude 374 that the Internet does a very good job of getting 375 packets from a source to destination. However, between 376 the source and the destination, the packets are routed 377 through many intermediate nodes. It is at the 378 intermediate nodes where anyone on one of the machines 379 that handle the packets could re-assemble the packets 380 that make up the EDI Interchange and could therefore read it, 381 copy it, alter it, or delete it. In the case where the EDI 382 Interchange is carried using an e-mail transport (SMTP), 383 the situation could arise where the message cannot be 384 delivered to the final recipient, so the message must 385 be stored at an intermediate node. Once again, the 386 message is susceptible to any number of the above mentioned 387 security threats. 389 The likelihood of any security threat, (especially if going 390 through intermediate nodes administered by a quality 391 ISP) are quite low, and practically speaking, are 392 quite difficult. Nonetheless the possibility exists, and 393 therefore is a concern -- particularly if the packets 394 contain high value or sensitive EDI or electronic 395 commerce transactions. 397 The Internet is being singled out in this discussion because 398 our focus is on EDI over the Internet. Networking is by its 399 very nature prone to security threats. Information can be 400 placed on shared media, and may be routed through nodes 401 not under the sender's administrative control. Whether through 402 malicious hacking or administrative glitches, the threat 403 that information sent over a network is read, copied, altered, 404 or deleted in an unauthorized way, is a possibility that 405 exists even if an EDI Interchange is sent via an EDI VAN. 407 A large component of the "value-added" services provided by 408 EDI VANs is precisely the assurance that EDI Interchanges sent 409 via the VAN are not compromised in any way. There are 410 however, measures that can be taken to defend against security 411 threats when an EDI Interchange is in transit across an 412 "open" network like the Internet. These security measures 413 are essential requirements when doing EDI over the Internet. 415 Each of these security measures is described in Section 3.0 416 of this document, and the issues surrounding each measure is 417 discussed and recommended solutions are given. 419 2.3 EDI VAN Communications and Security 421 This section briefly discusses current VAN security services. 422 The security measures recommended in section 3.0 of this 423 document essentially provide the equivalent of the VAN security 424 services described below. 426 The most prevalent EDI VAN communications service provided to 427 EDI trading partners is an asynchronous mail-boxing service. 428 A trading partner typically dials into a VAN network access 429 point. The trading partner then uses a file transfer protocol 430 to send the EDI Interchanges to the VAN. The VAN then routes 431 the EDI Interchanges to the receiving trading partner's VAN 432 mailbox. The receiving trading partner then dials into the 433 VAN and down-loads the EDI Interchanges from its VAN mailbox. 435 Other than support for a greater number of communications 436 protocols, and typically lower line speeds, connecting to an 437 EDI VAN is not too much different than connecting to an Internet 438 Service Provider. The EDI VANs however, provide a higher level of 439 EDI services to the EDI trading partner than do the ISPs. 440 The most important of these services is that the EDI VAN acts 441 as a trusted third party to insure that EDI Interchanges sent 442 via the VAN are not compromised in any way. 444 EDI VANs provide for EDI Interchange integrity, authentication, 445 and a number of acknowledgments that track the progress of the 446 EDI Interchange through the Value Added Network. EDI Interchange 447 integrity assures the trading partner that once the EDI 448 Interchange has been transferred to the VAN, that it will be 449 routed to the receiving trading partner without modification. 451 VAN authentication of trading partners consist of the guarantee 452 that EDI Interchanges can be sent and received by trading 453 partners only after they have been authenticated by the VAN. VANs 454 authenticate trading partners by having the trading partners 455 log into the network with the proper user-id and password. The 456 VAN has administrative responsibility for maintaining the 457 trading partner accounts and for insuring that the accounts 458 are valid. VANs also provide differing levels of service that 459 allow a trading partner to track the progress of the EDI 460 Interchange through the VAN. Trading partners can subscribe to 461 mailbox delivery notification or mailbox pick-up notification. 463 Mailbox delivery notification is sent by the VAN to the 464 sending trading partner when the EDI Interchange is delivered 465 to the receiving trading partner'. Mailbox pick-up notification 466 is sent by the VAN to the sending trading partner when the 467 EDI Interchange is down-loaded by the receiving trading partner. 469 The issue of tracking is covered in more detail in section 4.0. 471 2.4 EDI Object Boundaries and Transaction Privacy 473 The specification by this work group applies to the EDI 474 Interchange or Bundle (multiple EDI Interchanges) level, 475 and not the group or document level. 477 Any security services, packaging, transport, or non- 478 repudiation services are assumed to be applied to an EDI 479 Interchange(s). Unlike the X12.58 and UN/EDIFACT 9735-5 and 480 9735-6 security standards, the security services cannot 481 be applied at a group or document level. The purpose of 482 the specification is to move these services out of the 483 translator, and into the "communications" subsystem. The 484 "communications" subsystem should know as little about 485 the structure of the EDI data as possible. 487 As specified by this document, the entire EDI Interchange, 488 including the envelope headers (ISA/IEA or UNA/UNB/UNZ) 489 are encrypted, when encryption security services are applied. 490 Since the routing of the EDI Interchange is through 491 the Internet, and not a VAN, the sender/receiver ids are not 492 used in mailbox routing, so the EDI envelops can be 493 encrypted when sending EDI over the Internet. 495 3.0 Functional Requirements 497 3.1 Introduction and Definitions 499 The following sections describe the functional and 500 inter-operability requirements, as well as some of the 501 practical considerations of sending and receiving EDI 502 transactions on the Internet. It is assumed that the 503 reader is generally familiar with EDI. 505 3.2 Standard Encryption Algorithms and World-Wide 506 Encryption 508 3.2.1 Introduction and Description 509 The goal of encryption is to turn otherwise readable 510 text into something that cannot be read, and therefore 511 understood. By making the text unintelligible, 512 encryption discourages anyone from reading or copying 513 the EDI Interchange while it is in transit between the 514 trading partners. Encryption conveys confidentiality to 515 the EDI Interchange. Traffic analysis is always 516 possible, since many times, header information is not 517 encrypted. (Traffic analysis is the analysis of header 518 information in order to derive useful information from 519 them.) 521 Encryption is based on two components: an algorithm and 522 a key. An algorithm is a mathematical transformation 523 that takes plain-text or other intelligible information 524 and changes it into unintelligible cipher text. The 525 inverse mathematical transformation, back to the 526 original from the cipher text is also done, and is 527 called decryption. In order to encrypt the plain text, a 528 key is used as input in conjunction with an encryption 529 algorithm. An algorithm can use one of any of a large 530 number of possible keys. The number of possible keys 531 each algorithm can support depends on the number of bits 532 in the key. For instance, if the key length is 40, then 533 2 to the n, where n is the number of bits in the key, 534 results in 1,000,000,000,000 possible key combinations, 535 with each different key causing the algorithm to produce 536 slightly different cipher output. 538 An encryption algorithm is considered "secure" if its 539 security is dependent only on the length of its key. 540 Security cannot be dependent on the secrecy of the 541 algorithm, the inaccessibility of the cipher or plain 542 text, or anything else -- except the key length. If this 543 were true about a particular algorithm, then the most 544 efficient -- and only -- attack on that algorithm is a 545 brute-force attack, whereby all key combinations must 546 be tried in order to find the one correct key (this is 547 true for symmetric encryption algorithms, asymmetric 548 algorithms work a little differently, and the derivation 549 of the private key is based on mathematical manipulations 550 of large numerical quantities. The security provided 551 by asymmetric algorithms is not quite proportional to 552 the key length. See section 3.4.2 for more details on 553 the RSA public-key encryption algorithm). 555 Regardless of whether a symmetric or asymmetric encryption 556 algorithm is used, by specifying a long enough key length n, 557 even a brute-force attack on a "secure" algorithm can be made 558 completely non-feasible. 560 3.2.2 Symmetric Encryption 562 Encryption algorithms whereby two trading partners must 563 use the identical key to encrypt and decrypt the EDI 564 Interchange are called symmetric encryption algorithms. 565 Put another way, if an EDI Interchange is encrypted with 566 one key, it cannot be decrypted with a different key. 567 The key used in most symmetric encryption algorithms is 568 just a random bit string, n bits long. These keys are 569 often generated from random data derived from the source 570 computer. 572 The use of symmetric encryption simplifies the 573 encryption process, each trading partner does not need 574 to develop and exchange secret encryption algorithms 575 with one another (which incidentally would be a near 576 impossible task). Instead, each trading partner can use 577 the same encryption algorithm, and only exchange the 578 shared, secret key. 580 There are drawbacks however with "pure" symmetric encryption 581 schemes; a shared secret key must be agreed upon by both 582 parties. If a trading partner has n trading 583 partners, then n secret keys must be maintained, 584 one for each trading partner. Symmetric encryption 585 schemes also have the problem that origin or destination 586 authenticity (non-repudiation of origin, and receipt) 587 cannot be proved. Since both parties share the 588 secret encryption key, any EDI Interchange encrypted 589 with a symmetric key, could have been sent by either of 590 the trading partners. 592 By using what is called public key cryptography, 593 management of symmetric keys can be simplified to the point 594 whereby a symmetric key can be used not only for each 595 trading partner, but for each exchange between trading 596 partners. In addition, public key cryptography can 597 be used to unambiguously establish non-repudiation of 598 origin and receipt. 600 3.2.3 Asymmetric Encryption - Public-key Cryptography 602 Public-key cryptography is based on the concept of a key 603 pair. Each half of the pair (one key) can encrypt 604 information that only the other half (one key) can 605 decrypt. The key pair is designated and associated to 606 one, and only one, trading partner. One part of the key 607 pair (the private key) is only known by the designated 608 trading partner; the other part of the key pair (the 609 public key) is published widely but is still 610 associated with the designated trading partner. 612 The keys are used in different ways for confidentiality 613 and digital signature. Both confidentiality and 614 signature depend on each entity having a key pair that 615 is identified only with them and each party keeping one 616 pair of their key pair secret from all others. 618 Signature works as follows: Trading Partner A uses her 619 secret key to encrypt part of a message, then sends the 620 encrypted message to Trading Partner B. B gets Trading 621 partner A's public key (anyone may get it) and attempts 622 to decrypt the encrypted part of Trading partner A's 623 message. If it decrypts, then Trading Partner B knows it 624 is from A -- because only A's public key can decrypt a 625 message encrypted with A's private key, and A is the 626 only one who knows her private key. 628 In most real world applications, asymmetric encryption 629 algorithms are not actually used to encrypt the message 630 or part of the message itself. Instead, they are used in 631 conjunction with a Message Integrity Check (MIC), and it 632 is the MIC that is encrypted using the public key 633 encryption algorithm. See section 3.5.1 for details on 634 how asymmetric encryption algorithms are applied to a 635 MIC. 637 Confidentiality applies the asymmetric key pair, but in 638 a different manner than signature. If Trading partner A 639 wishes to send a confidential message to Trading Partner 640 B, she would apply the key pair as follows: Trading 641 partner A would retrieve Trading partner B's public key, 642 and encrypt the message with it. When Trading Partner B 643 receives the message, she would decrypt the message 644 with her private key. Only her private key can decrypt 645 information that was encrypted with her public key. In 646 other-words, anything encrypted with B's public key can 647 only be decrypted with B's private key. 649 Requirements For Inter-operable Internet EDI 8 July 199 651 Since public-key encryption algorithms are considerably 652 slower than their symmetric key cousins, they are 653 generally not used to do the actual encryption of what 654 could be large EDI Interchanges. For instance, RSA Data 655 Securities, Inc. estimates that software encryption 656 using DES (a symmetric key algorithm) is 100 times 657 faster than software encryption using RSA (a public-key 658 encryption algorithm from RSA Data Securities, Inc.). 659 Hardware encryption using DES is anywhere from 1,000 to 660 10,000 times faster than hardware encryption using the 661 RSA asymmetric encryption algorithm. Instead of being 662 used for bulk encryption, public-key encryption 663 algorithms are used to encrypt symmetric encryption 664 keys. They are also used as an efficient means of 665 exchanging and managing symmetric encryption keys. 667 3.2.4 Needs 669 In order to provide confidentiality for EDI Interchanges 670 on the Internet, a standard encryption algorithm(s) and 671 key length(s) must be specified. For inter-operability 672 to occur between two trading partners, the encryption 673 algorithm and key lengths must be agreed upon either 674 before hand, or within an individual transaction. 676 3.2.5 Issues 678 When choosing an encryption algorithm, the following 679 criteria should be considered; how secure the algorithm 680 is; how fast implementations of the algorithm are; whether 681 the algorithm is available for international as well 682 as domestic use; the availability of APIs and tool kits 683 in order to implement the algorithms; and the frequency 684 of the use of the algorithm in existing implementations. 686 Sufficient key lengths must be chosen with regard to 687 the value of the EDI Interchange so that brute-force 688 attacks are not worth the time or effort compared to the 689 value of the Interchange. 691 3.2.6 Recommendations 693 DES: The most widely used commercial encryption 694 algorithm is DES. It is widely used in the banking 695 industry for Electronic Funds Transfer (EFT). DES is 696 also a U.S. government encryption standard. DES is in 697 the public domain, which means anyone can implement the 698 algorithm, including those in the international 699 community. DES was designed for, and is used for bulk 700 encryption of data. DES is prohibited by the U.S. 701 government for export. 703 The DES algorithm has been analyzed by cryptographers 704 since the mid-1970s, and its security is considered "known": 705 in other words, the security of DES is dependent on the length 706 of its key, and estimates can be provided for the time 707 and effort required to derive the DES key from a known 708 8 byte plain-text/cipher-text pair. DES specifies a 56 bit key, 709 so 2 to the 56th or 10 to the 16th keys are possible. A 710 brute force attack, which means trying every single key 711 to decrypt 8 bytes of known cipher-text into its 712 corresponding 8 bytes of known plain-text is the best 713 attack on the algorithm. 715 The amount of time and money required to mount a 716 successful brute force attack varies with the processing 717 power used -- and how lucky the attacker may be in 718 generating a key that is close to the one used to 719 encrypt the original EDI Interchange. Some estimates 720 which have been put forth claim that a $1 million dollar 721 hardware based, brute-force attack on DES would only take 722 3.6 hours to recover the DES key. A corresponding $1 723 million dollar software based brute-force attack on DES 724 would however take 3 years [14]. As the price/performance of 725 processors decrease, a 56 bit key becomes less and less 726 adequate in protecting EDI Interchanges of extreme 727 value. Triple-DES, an algorithm with longer key length 728 (discussed below) SHOULD be used in such cases. 730 Triple-DES is a variant on DES that encrypts the EDI 731 Interchange 3 times, with 2 independent 56 bit keys, 732 giving it an effective key length of 112 bits. This 733 makes a brute-force attack on Triple-DES not feasible. 734 DES and Triple-DES actually can be implemented in 3 735 different modes. It is RECOMMENDED that DES and Triple- 736 DES be used in Cipher Block Chaining (CBC) mode, which 737 gives added protection by making each cipher-text block 738 depend on each other, so changes in the cipher-text can 739 be detected. 741 RC2 and RC5: RC2 and RC5 are proprietary symmetric 742 algorithms of RSA Data Security, Inc. RC2 and RC5 743 unlike DES, are variable-key length algorithms. By specifying 744 differing key lengths, RC2 and RC5 can be configured to 745 provide greater or lesser security. RC2 and RC5 are 746 alternatives to DES, and RC2 has special export status, 747 whereby 40 bit versions of RC2, and 56 bit versions 748 of RC2 for foreign subsidiaries and overseas offices 749 of U.S. companies, have expedited export approval from 750 the U.S. government. RSA claims that RC2 and RC5 are 751 faster than DES when implemented in software. Several products 752 such as Lotus Notes, Netscape Navigator, Apple's Open 753 Collaboration Environment, Actra's ECXpert, and Premenos' 754 Templar make use of these algorithms. 756 It is RECOMMENDED that key sizes of 40 bits, 75 bits, and 757 128 bits be supported for incoming and outgoing EDI messages, 758 when used domestically. U.S. Government restrictions limit | 759 RC2 implementations to 40 bits when exported outside the 760 United States. RC2 SHOULD be used in CBC mode, 761 and RC5 in CVC Pad mode. A key length of 128 bits would 762 make a brute force attack on RC2 or RC5 not feasible. 764 IDEA: The International Data Encryption Algorithm was 765 published in 1991. The symmetric algorithm is an 766 iterated block cipher with a 64-bit block size and a 128- 767 bit key size. The key length of IDEA is over twice that 768 of DES and is longer than triple-DES. The IDEA algorithm 769 is patented in both the United States and abroad. The 770 IDEA algorithm in CBC mode is used by PGP (Pretty Good 771 Privacy - a popular electronic mail security program) 772 for encryption. Individual users of PGP have a royalty 773 free license to use the IDEA algorithm. 775 There are many encryption algorithms that are secure and 776 can provide confidentiality for an EDI Interchange. For 777 most commercial applications a key length of at least 778 75 bits is RECOMMENDED. See [14] and [15] for additional 779 guidance on choosing key lengths. For EDI 780 Interchanges of minimal value, 40-bit RC2 or 56-bit 781 DES are probably adequate. For more valuable EDI 782 interchanges, use of Triple-DES, IDEA, or 128 bit 783 length RC2 or RC5 is RECOMMENDED. 785 DES is currently in wide-spread use, and Triple-DES is 786 projected to be in wide-spread use, as the 56-bit DES 787 key limitation becomes less and less adequate. The DES 788 algorithm is available for implementation outside the 789 U.S., and the DES algorithm has been studied for a long 790 time, and its security is "known". RC2 and RC5 are 791 useful because they allow the security of the 792 encryption - the key length specification, to be 793 configurable. The RC2 and RC4 algorithms are 794 proprietary, but products incorporating these algorithms, 795 but limiting the key lengths to 40 bits or less, can be 796 exported outside the U.S. 798 IDEA is a newer algorithm and has not been studied as much as 799 DES. IDEA's 128 bit key-length provides more than adequate 800 security. 802 Indications are that IDEA is a secure algorithm and its use 803 in PGP makes it the most widely used encryption algorithm 804 for Internet electronic mail. 806 3.3 Key Management - Symmetric Keys 808 3.3.1 Introduction and Description 810 The use of symmetric encryption is based on a shared 811 secret. Two trading partners using a symmetric 812 encryption algorithm must be able to do the following; 813 generate a random symmetric key and agree upon its use; 814 securely exchange the symmetric key with one another; 815 set up a process to invalidate a symmetric key that has 816 been compromised or needs changing. Each trading partner 817 would then need to do this with each and every one of 818 their trading partners. Management and distribution of 819 symmetric keys can become an insecure and cumbersome 820 process. 822 Pure symmetric key management schemes also have the 823 problem that origin authenticity cannot be proved. Since 824 two parties share a secret encryption key, any EDI 825 Interchange encrypted with a symmetric key, could have 826 been sent by either of the trading partners -- both of whom 827 have knowledge of the key. 829 As previously mentioned, by using public key cryptography, 830 management of symmetric keys can be simplified such that 831 a symmetric key can be used not only for each 832 trading partner, but for each exchange between trading 833 partners. In addition, public key cryptography can 834 be used to unambiguously establish non-repudiation of 835 origin and receipt. 837 The use of public-key cryptography, whereby the symmetric 838 encryption key is encrypted using an asymmetric encryption 839 algorithm, simplifies the management of the symmetric 840 keys and makes their exchange much more secure. Trading 841 partners do not need to agree on secret symmetric keys 842 as part of the trading partner agreement, nor is there 843 the origin authenticity problem that is inherent with pure 844 symmetric key management schemes. 846 A symmetric key can be randomly generated by the 847 software for each EDI transaction between trading 848 partners. Symmetric keys generated on a per 849 transaction basis are sometimes referred to as 850 "session keys". Since a unique symmetric key is 851 generated for each EDI transaction, symmetric key maintenance 852 is no longer required. Trading partners do not need 853 to invalidate compromised or expired keys. Each 854 symmetric or "session" key is used only one time. 856 Additional security is also realized using the method 857 described above; in the unlikely event that one of the 858 symmetric keys is compromised, only one EDI transaction 859 is affected, and not every transaction in the trading 860 partner relationship. Public-key encryption also 861 provides a secure way of distributing symmetric keys 862 between trading partners. Since only the receiving 863 trading partner has knowledge of her private asymmetric 864 key, she is the only one that can decrypt the symmetric 865 key encrypted with her public asymmetric key -- and is 866 thus the only one who can use the symmetric key to 867 decrypt the EDI Interchange. 869 To impart confidentiality to an EDI Interchange using public key 870 cryptography for symmetric key management, the following steps 871 would be performed when trading partner ABC sends to trading 872 partner XYZ: 874 1). The EDI Translator outputs the EDI Interchange. 876 2). A random symmetric key of the specified length 877 is generated. 879 3). The EDI Interchange is encrypted using the 880 randomly generated symmetric key with the chosen 881 encryption algorithm. 883 4). The random symmetric key is then encrypted 884 using XYZ's, the receiving trading partner's, 885 public asymmetric key. 887 5). The encrypted symmetric key and encrypted EDI 888 Interchange are then enveloped and sent to the 889 trading partner. 891 On the receiving side, the following steps would be 892 performed: 894 1). The symmetric key is decrypted using XYZ's 895 private asymmetric key. 897 2). The decrypted symmetric key is then used to 898 decrypt the EDI Interchange. 900 3). The decrypted EDI Interchange is then routed to 901 the EDI translator. 903 3.3.2 Needs 905 A method to manage the symmetric encryption keys used in 906 encrypting EDI Interchanges on a transaction basis. 907 The method should simplify the generation, maintenance, and 908 distribution of the symmetric encryption keys. The method 909 should also provide a secure channel for distributing 910 the symmetric encryption keys between trading partners. 912 3.3.3 Issues 914 Agreement by trading partners to use public-key cryptography 915 to manage symmetric keys, and to generate a symmetric key 916 for each EDI transaction. 918 When choosing public-key encryption algorithms, 919 the following criteria should be considered; how 920 secure the algorithm is; how fast implementations 921 of the algorithm are; whether the algorithm 922 is available for international as well as 923 domestic use; the availability of APIs and 924 tool kits in order to implement the algorithms; 925 and the frequency of the use of the algorithm 926 in existing implementations. 928 Sufficient key lengths must be chosen with 929 regard to the value of the EDI Interchange so that 930 brute-force attacks are not worth the time or 931 effort compared to the value of the Interchange. 933 3.3.4 Recommendations 934 RSA is a public-key encryption algorithm that has 935 become a de facto standard in its use for symmetric key 936 management. Its use is RECOMMENDED in managing and 937 distributing symmetric encryption keys when doing EDI 938 over the Internet. The RSA public-key algorithm is not 939 patented outside the United States, and therefore can be 940 freely used outside the U.S. 942 In the United States, the RSA public-key encryption 943 algorithm is protected by the following patent: 945 R. Rivest, A. Shamir, and L. Adleman 946 "Cryptographic Communications System and Method" 947 U.S. Patent #4,405,829 948 September, 1983 950 At this time, a license to use the RSA encryption 951 algorithm is required within the United States. 953 Both S/MIME and PGP/MIME make use of the RSA 954 encryption algorithm to encrypt/decrypt "session 955 keys". 957 For a recommendation on RSA key lengths, see Section 958 3.4.2, on Public Keys. 960 3.4 Key Management - Public and Private Keys 962 3.4.1 Introduction and Description 964 The use of public-key cryptography to simplify the 965 management of symmetric encryption keys presents the 966 user with two problems; protecting the private key, and 967 binding a trading partner's identity to his public key. 968 Most likely the user will never know what his private 969 key is. The software will generate a random private key, 970 encrypt it, and store it in a file or database. The 971 private key is accessed indirectly by the user through 972 access to the software. User access to the software is 973 generally controlled by a password, pass-phrase, and/or 974 certain access rights. These are internal security 975 policies, and are company specific. It is important to 976 control the access to the private key, since any 977 unauthorized access can lead eventually to the 978 revocation of the corresponding public key. 980 3.4.2 Public Keys 982 A public key is used by an originating trading partner 983 to encrypt a symmetric key, and as will be discuss later, 984 by a receiving trading partner to verify authenticity of 985 the originator. 987 The mathematics of public key cryptography is complicated, 988 but are based on mathematical manipulations of 989 large numerical quantities. In the case of RSA, deriving 990 the private key from the public key is based on the difficulty 991 in factoring large numbers. An RSA public key 992 is generated by multiplying two large prime 993 numbers together, deriving the private key from the 994 public key involves factoring the product of the two large 995 prime number. 997 Unlike the symmetric encryption algorithms discussed above, 998 the RSA asymmetric encryption algorithm's security is based 999 on the size of the number that needs to be factored. The size 1000 or "modulus" of the product of two prime numbers can be 1001 factored using some "fast factoring algorithms" which 1002 currently exist. The computing power required by these 1003 "fast factoring algorithms" can be estimated, and thus 1004 the time and cost to factor a number of any given size can 1005 also be estimated. 1007 Some estimates which have been put forth claim that 1008 a 1 "MIP" computer operating for 1 year would take 1009 74 years to factor a modulus of 100 digits or approximately 1010 332 bits. A 150 (~500 bits) digit modulus would take 1,000,000 MIP 1011 years, a 200 digit modulus (~664 bits) 4,000,000,000 MIP years, and 1012 a 350 digit modulus (~1162 bits) would take 10 to 16th MIP years. 1014 Given a large enough modulus, it becomes an impossible task 1015 to "break" or derive a private key from a public key. 1016 The RSA key length is configurable, but as the cost of computing 1017 power decreases - assume for instance, a decrease in computing 1018 costs by a factor of ten every 5 years -- then by the 1019 year 2030, a 512 bit public key can be "broken" for $10 [14]. 1021 When using the RSA encryption algorithm to encrypt symmetric 1022 keys, support of 512 bit to 1024 bit variable key lengths 1023 is REQUIRED. In general, asymmetric algorithms require longer 1024 keys to provide the same level of security as their symmetric 1025 key cousins. A comparison of asymmetric key lengths (for 1026 algorithms like RSA that are based on the factoring problem), 1027 needed to provide the equivalent "security" against "brute 1028 force" attacks can be found in [15]. For example, a 512 bit RSA 1029 encryption key is equivalent to a 64 bit symmetric key. A 768 bit 1030 RSA encryption key is equivalent to an 80 bit symmetric key. 1032 It is RECOMMENDED that for EDI transactions requiring the 1033 use of RSA encryption to protect "session keys", that at 1034 least a 768 bit RSA encryption key be used. For very "high" 1035 value EDI transactions, at least a 1024 bit or higher key 1036 SHOULD be used. 1038 3.4.3 Trust and Public Keys 1040 When using public key cryptography, there is a "trust" 1041 issue that arises: how can one trading partner be sure 1042 that the public key of another trading partner is bound 1043 to that trading partner, and is valid? 1045 Trading partners must exchange public keys or be able to 1046 access each other's public key in a manner that is acceptable 1047 to each of the trading partners. 1049 One method by which trading partners can exchange public key 1050 information is through the use of public key certificates. 1052 Public key certificates come in many different formats, and 1053 the trust model on which they are based also come with different 1054 underlying assumptions. 1056 Public key certificates based on the X.509 standards 1057 however are becoming prevalent in their use. The X.509 certificate 1058 is a binding of an entity's distinguished name (a formal way 1059 for identifying someone or something in the X.500 world, 1060 in our case it would be a trading partner) to a public key. 1061 A certificate also contains the digital signature of the 1062 issuer of the certificate, the identity of the issuer of the 1063 certificate, and an issuer specific serial number, a 1064 validity period for the certificate, and information to 1065 verify the issuer's digital signature. Certificate 1066 issuers are called certification authorities, and are 1067 trusted by both trading partners. In essence, a 1068 certificate is a digitally notarized binding of a trading 1069 partner to its public key. 1071 3.4.4 Needs 1073 Adoption of a trust model, or the use of certification 1074 authorities for issuing commercial grade/class 3 1076 Requirements For Inter-operable Internet EDI 8 July 199 1078 certificates. Each trading partner must choose a trust 1079 model. For instance, trading partners can self-certify 1080 one another, or they could use certification authorities 1081 acceptable to their other trading partners. 1083 Formats and protocols for requesting, revoking, and exchanging 1084 certificates and certificate revocation lists between 1085 certification authorities and trading partners, as well 1086 as between the trading partners themselves need to be agreed 1087 to and standardized. 1089 3.4.5 Issues 1091 The lack of wide-spread use of certification authorities 1092 in real world commercial applications, and the need to do 1093 additional profiling of X.509v3 certificates and standards 1094 for requesting, revoking, and exchanging certificates and 1095 certificate revocation lists. 1097 3.4.6 Recommendations 1099 3.4.6.1 Near Term Approach 1101 Since there already exists a trust relationship between 1102 EDI trading partners, until use of certification authorities 1103 become more established and better profiling is done 1104 with X.509v3 certificates, it is recommended that the 1105 trading partners "self-certify" each other, if an agreed upon 1106 certification authority is not used. 1108 In the near term, "self-certification" means that the exchange 1109 of public keys and certification of these keys must be 1110 handled as part of the process of establishing a trading 1111 partnership. 1113 The UA and/or EDI application interface must maintain 1114 a database of public keys used for encryption and 1115 authentication, in addition to mapping between the EDI 1116 trading partner ID and the RFC822 e-mail address. The 1117 procedures for establishing a trading partnership and 1118 configuring the secure EDI messaging system might vary 1119 among trading partners and software packages. 1121 It is still highly RECOMMENDED that trading partners 1122 acquire a X.509v3 certificate from a certificate authority 1123 trusted by both trading partners. The process of 1124 acquiring a certificate varies among the various 1125 certificate authorities. It is also RECOMMENDED that trading 1126 partners exchange certificates using the formats 1127 and protocols specified by "certificate-only" PKCS7 when using 1128 S/MIME, and PGP certificate formats and protocols when using 1129 PGP/MIME. 1131 3.4.6.2 Long Term Approach 1133 In the long term, additional Internet-EDI standards 1134 will need to be developed to simplify the process of 1135 establishing a trading partnership, including the 1136 acquisition, revocation, exchange, and third party 1137 authentication of certificates. 1139 PKCS7 and PKCS10 as well as the standards being 1140 developed by the IETF-pkix (public key infrastructure 1141 X.509 work-group) need to be evaluated and adopted 1142 as standards for Internet EDI. 1144 3.5 Content Integrity 1146 3.5.1 Introduction and Description 1148 Encryption guarantees the confidentiality of an EDI 1149 Interchange. Content integrity guarantees that the 1150 receiving trading partner gets the EDI Interchange in 1151 its originally sent state. Content integrity assures 1152 that no modifications -- additions, deletions, or changes 1153 -- have been made to the EDI Interchange when it is in 1154 transit between trading partners. 1156 Content integrity is achieved if the sender includes 1157 with the EDI Interchange, an integrity control value. 1158 This value can be computed by using an appropriate 1159 cryptographic algorithm to "fingerprint" the EDI 1160 Interchange. These cryptographic algorithms are 1161 called one-way hash functions or message integrity 1162 checks. 1164 Unlike encryption algorithms however, one-way hash 1165 functions can't be reversed or "decrypted". One-way hash 1166 functions are constructed so the probability is infinitely small 1167 that some arbitrary length piece of plain-text can be 1168 hashed to a particular value, or that any two pieces of 1169 plain-text can be hashed to the same value. One-way hash 1170 values are usually from 112 to 160 bits long. The 1171 longer the hash value, the more secure it is. 1173 One-way hash functions don't require a key, and the 1174 algorithm used must be agreed upon by the trading 1175 partners. To insure content integrity, the sending 1176 trading partner needs to calculate a one-way hash value 1177 of the EDI Interchange and MIME content headers. This value 1178 is unique and "fingerprints" the transaction. The sending 1179 trading partner sends the hash value along with the EDI 1180 Interchange. The receiving trading partner using the 1181 same one-way hash function calculates the hash value for 1182 the received EDI Interchange and MIME content headers. 1183 If the received hash value matches the calculated hash value, 1184 then the receiving trading partner knows that the EDI 1185 Interchange has not been tampered with. 1187 3.5.2 Needs 1189 Choice of a one-way hash algorithm to calculate the hash 1190 value required to insure content integrity. 1192 3.5.3 Issues 1194 The one-way hash algorithm should be secure, publicly 1195 available, and should produce hash values of at least 1196 128 bits. 1198 3.5.4 Recommendations 1200 SHA-1 is the Secure Hash Algorithm, a one-way hash function 1201 invented by the National Security Agency. SHA-1 produces 1202 a 160-bit hash value that makes a brute-force attack 1203 on it not feasible. It is being recommended by most 1204 e-mail security programs and other security specifications, 1205 as weaknesses are being found in MD5. 1207 MD5 is a one-way hash function that is publicly 1208 available, and produces a 128 bit hash value called a 1209 Message Digest. It is currently widely used by 1210 most e-mail security programs, such as PEM, PGP, and 1211 S/MIME. 1213 It is RECOMMENDED that all new implementations use SHA-1 1214 for outgoing messages, but to continue to accept MD5 1215 incoming (SHA1 as well) as there already exist many MD5 1216 implementations. 1218 3.6 Authentication and Non-Repudiation of Origin 1219 3.6.1 Introduction and Description 1221 Encryption guarantees confidentiality. Applying a one- 1222 way hash function guarantees content integrity. Both 1223 authentication and non-repudiation of origin guarantee 1224 the identity of the sender of the EDI Interchange. Non- 1225 repudiation of origin, identifies the original sender, 1226 and is the same as authentication when the EDI 1227 Interchange is sent point-to-point, i.e. when there is 1228 no forwarding involved. Authentication and non- 1229 repudiation of origin discourages any spoofing attacks 1230 that may occur while the EDI Interchange is in transit 1231 between the trading partners. 1233 Both authentication and non-repudiation of origin are 1234 accomplished using digital signatures. A digital 1235 signature is another application of public-key 1236 cryptography, and is explained in more detail in the 1237 following paragraphs. 1239 Up to this point, a receiving trading partner's public- 1240 key has been used in symmetric key management to encrypt 1241 a symmetric key. This symmetric key could only be decrypted 1242 by the receiving trading partner's private key. However 1243 the roles of the private and public keys can be reversed, 1244 so that encryption is done with the private key, and 1245 decryption is done with the public key. 1246 Again the keys are reciprocal, if encryption 1247 is done with the private key, decryption can only be 1248 done with the public key. 1250 Since only trading partner ABC knows her own private- 1251 key, only trading partner ABC can encrypt something with 1252 that private-key. Encryption with a private key 1253 therefore has the effect of uniquely identifying the 1254 person or entity doing the encryption. It is in effect, 1255 a digital signature. Since ABC's public-key is known to 1256 all her trading partners, they can all decrypt something 1257 encrypted with ABC's private-key. Successful decryption 1258 using ABC's public-key of something encrypted with 1259 ABC's private key has the effect of authenticating 1260 ABC as the trading partner that did the encrypting, 1261 or in other words it identifies ABC as applying the 1262 digital signature. 1264 ABC cannot deny that she applied the encryption, since 1265 she is the only one with knowledge of her private key. In 1266 this way, non-repudiation of origin is achieved. 1268 Requirements For Inter-operable Internet EDI 8 July 199 1270 So what should a trading partner sign or encrypt with 1271 her private-key to guarantee authentication and non- 1272 repudiation of origin? Remember, public-key encryption 1273 algorithms are not meant to encrypt something very 1274 large, they are too slow for that. The symmetric key is 1275 encrypted with a public-key, and encrypting this with a 1276 private-key is not recommended, as this would allow 1277 other than the authorized recipient to decrypt the EDI 1278 Interchange. Since a one-way hash value is pretty small, 1279 usually only between 112-160 bits long, it is a natural 1280 choice for what can be digitally signed. If the message 1281 integrity value is signed with a private key, then not 1282 only is authentication and non-repudiation of origin 1283 guaranteed, but message integrity as well. 1285 3.6.2 Needs 1287 Choice of a digital signature algorithm. 1289 3.6.3 Issues 1291 When choosing a digital signature algorithm, the 1292 following criteria should be considered; how secure the 1293 algorithm is; how fast implementations of the algorithm 1294 are; whether the algorithm is available for 1295 international as well as domestic use; the availability 1296 of APIs and tool kits in order to implement the 1297 algorithms; and the frequency of the use of the 1298 algorithm in existing implementations. 1300 Sufficient key lengths must be chosen with regard to the 1301 value of the EDI Interchange so that brute-force attacks 1302 are not worth the time or effort compared to the value 1303 of the Interchange. 1305 3.6.4 Recommendations 1307 In addition to using the RSA public-key algorithm to 1308 encrypt symmetric keys, it is also RECOMMENDED that RSA be used 1309 for digital signatures as well. 1311 Unlike encryption algorithms, strong digital signature (greater 1312 than 40 bit key lengths) algorithms can be freely exported 1313 outside the U.S. 1315 The RECOMMENDED key lengths when using the RSA encryption 1316 algorithm for signature, are the same as when using RSA 1318 encryption for managing symmetric keys: 1320 For most EDI transactions requiring digital signatures, 1321 a 768 bit RSA encryption key SHOULD be used. For 1322 very "high" value EDI transactions, at least a 1024 bit or 1323 higher key SHOULD be used. 1325 3.7 Signed Receipt or Non Repudiation of Receipt 1327 3.7.1 Introduction and Description 1329 The term used for both the functional activity and message for 1330 acknowledging receipt of an EDI/EC interchange is "receipt", or 1331 "signed receipt". The first term is used if the acknowledgment is 1332 for an interchange resulting in a receipt which is NOT signed. 1333 The second term is used if the acknowledgment is for an interchange 1334 resulting in a receipt which IS signed. 1336 A term often used in combination with receipts is "Non-repudiation 1337 of Receipt (NRR). NRR refers to a legal event which occurs only 1338 when the original sender of an interchange has verified the sender 1339 and content of a "signed receipt". Note that NRR is not possible 1340 without signatures. 1342 The signed receipt is an acknowledgment sent by the 1343 receiving trading partner to the sending trading partner. 1344 The signed receipt is used to address the following 1345 issues when doing Internet EDI: 1347 1). The lack of wide-spread RFC 1894 based mailbox delivery 1348 notification implementations within the Internet mail 1349 infrastructure. 1351 2). It provides the equivalent of VAN mailbox delivery 1352 notification. 1354 3). It provides the equivalent of VAN mailbox pick-up 1355 notification. 1357 4). It provides the equivalent of VAN mailbox 1358 authentication. 1360 5). It can detect the situation where EDI Interchanges are 1361 maliciously deleted, or are not delivered by the 1362 transport. 1364 Receipt by the sender of a signed receipt, is an implicit 1365 acknowledgment of successful mailbox delivery. It is 1366 also an explicit acknowledgment that the Interchange was 1367 retrieved from the mailbox -- pick-up notification. By 1368 having the receiver sign the receipt, it authenticates 1369 that the intended receiver picked up the EDI Interchange -- 1370 mailbox authentication -- and that the intended receiver 1371 verified the integrity of the EDI Interchange, and the 1372 identity of the sender. By returning the original message id 1373 and the one-way hash value of the received contents back in 1374 the signed receipt, the sender can reconcile the acknowledged 1375 EDI Interchange with what was sent. 1377 3.7.2 Needs 1379 Define the format and protocol for the signed receipt 1380 so that it provides the following: 1382 1). Implicit acknowledgment of mailbox delivery of 1383 the EDI Interchange to the recipient. 1385 2). Explicit acknowledgment that the receiver has 1386 authenticated the sender and verified the 1387 integrity of the sent EDI Interchange. 1389 3). Guarantees non-repudiation of receipt when the 1390 signed receipt is digitally signed by the receiving 1391 trading partner, and successfully verified by the 1392 sender. 1394 4). Provide information in the signed receipt so 1395 it can be used for tracking, logging, and 1396 reconciliation purposes. 1398 The re-transmission timer, and retry count to detect 1399 lost Interchanges should be configurable. 1401 3.7.3 Recommendations 1403 The syntax for a signed receipt should not be specific 1404 to EDI content, since many of the uses of a signed receipt 1405 can be broadly applied to other MIME encapsulated objects. 1406 The results of the IETF receipt working group SHALL be 1407 adopted as the basis for implementing signed 1408 receipts. The receipt working group has published an Internet 1409 draft -- draft-ietf-receipt-mdn-04 [5], which can be obtained 1410 off of the IETF World Wide Web site. The EDIINT working 1411 group has taken on the work item to develop the needed 1412 extensions to the MDN draft that is required within an EDI 1413 environment. See Internet Draft: "MIME-based Secure EDI" [10]. 1415 When a signed receipt is used by trading partners, the 1416 message integrity check that is verified by the receiving 1417 trading partner must be returned to the originating trading 1418 partner in the signed receipt. 1420 The time-out and retry values for the signed receipt SHOULD 1421 be configurable. Duplicates SHOULD be checked by the UA 1422 and discarded. 1424 The signed receipt MUST be implemented using a 1425 MIME multipart/signed type/subtype with the message 1426 disposition notification as the first part of the 1427 content of the multipart/signed. A MIC is then 1428 calculated over the message disposition notification, and 1429 this MIC is digitally signed and MUST be returned as the second 1430 part of the multipart/signed content. 1432 3.8 Syntax and Protocol for Specifying Cryptographic 1433 Services 1435 3.8.1 Introduction and Description 1437 Once cryptographic services are applied to EDI 1438 Interchanges, then the formats and protocols must be 1439 specified on how the cryptographic information is 1440 conveyed during the EDI message exchange. Encryption 1441 algorithm information, one-way hash algorithm 1442 information, symmetric keys, initialization vectors, one- 1443 way hash values, and public-key certificates, need to be 1444 enveloped and sent along with the EDI Interchange. 1446 3.8.2 Needs 1448 A syntax and protocol for specifying EDI Interchanges that 1449 have had cryptography applied to them, needs to be specified. 1450 Several suitable standards already exist, so it is preferable 1451 to choose one of these existing standards rather than 1452 specifying a new one. 1454 3.8.3 Issues 1456 The IETF EDIINT work group has put together a matrix 1457 comparing many of the different ways that EDI with 1458 cryptography applied to it can be transmitted. Several 1459 standards appear to fulfill the security requirements 1460 needed by this work group. 1462 S/MIME [8], and PGP/MIME [4] are both viable alternatives. 1463 Each has its strengths and weaknesses: 1465 The S/MIME specification allows "signed and enveloped" 1466 and "signed" to be distinguished. The signatories in an 1467 S/MIME "signed and enveloped" content type can be 1468 distinguished, which in certain EDI and electronic 1469 commerce situations is not acceptable. However, the S/MIME 1470 Implementation Guide, Version 2 [11], does address this 1471 concern by specifying that "signed and enveloped" not be 1472 used, and a two step sign and then encrypt process be used 1473 instead. 1475 S/MIME is very flexible and can accommodate many different security 1476 algorithms and key lengths. 1478 PGP 4.5 supports a set profile of security algorithms 1479 and some user configurable key lengths. PGP/MIME does 1480 not have the signatory problem as described above for 1481 S/MIME. However, PGP 4.5 does not give the user as much 1482 flexibility in choosing algorithms and key lengths, 1483 although the security profile used by PGP 4.5 is more 1484 than adequate to insure confidentiality, non-repudiation 1485 of origin, and message integrity. 1487 The recommended security format should also be transport independent 1488 so it can be used with different Internet transports. The 1489 standard should have broad support, and implementations 1490 should be available. 1492 3.8.4 Recommendations 1494 Either one of S/MIME or PGP/MIME fulfill the 1495 requirements of the EDIINT work group. The S/MIME 1496 Implementation Guide [11], requires the signedData format 1497 be supported, and the multipart/signed, as specified 1498 in RFC 1847 [6], is recommended. For use in Internet 1499 EDI, support of multipart/signed is REQUIRED, and 1500 signedData is RECOMMENDED only when sending EDI through 1501 known gateways that do not honor 7-bit transfer encoding. 1503 PGP/MIME is based on multipart/signed and multipart/encrypted. 1505 The Appendix of this document specifies how S/MIME, and PGP/MIME 1506 are to be applied for use in Internet EDI. See section 5.4 1507 for implementation notes, and examples on S/MIME and PGP/MIME 1508 formats. 1510 4.0 Tracking and Error Handling Basics 1512 4.1 Introduction 1514 It is important to recognize that the Value Added Networks 1515 provide some inherent tracking mechanisms between 1516 EDI trading partners. In Internet EDI, the ISPs provide 1517 a certain level of transmission tracking as does the 1518 TCP/IP protocols themselves. However, not all the 1519 tracking provided by EDI VANs are completely covered 1520 by the current TCP/IP protocol suite or ISP tracking. 1521 The new tracking information associated with the additional 1522 security requirements and support of signed receipts, 1523 must be implemented in the EDI UA, in order for Internet 1524 EDI to be as traceable as VAN EDI. 1526 Aside from the communications between companies, 1527 "tracking" touches many other points within the trading 1528 relationship. This is where the use of 997 functional 1529 acknowledgments come in, the EDIFACT CONTRL message, and 1530 the common translator tracking of sequential group 1531 control numbers. All of this needs to be considered in 1532 Internet EDI tracking. 1534 The following is a list of the common tracking information needed 1535 when sending and receiving EDI Interchanges between trading 1536 partners: 1538 1). Transmission successfully translated from 1539 internal format to EDI standard format. 1541 2). Transmission successfully encoded, signed, 1542 encrypted, and sent. (The equivalence of transmission 1543 successfully received by the VAN.) 1545 3). Transmission successfully delivered to 1546 the recipient's mailbox.(The equivalence of a VAN 1547 delivery acknowledgment that the sent transmission 1548 has been forwarded to the receiver's VAN mailbox.) 1550 4). Transmission successfully picked-up by the 1551 recipient. (The equivalence of a VAN mail-box 1552 pick-up acknowledgment.) 1554 5). Transmission successfully translated by the 1555 receiver. (The EDI Interchange was determined to be 1556 syntactically correct.) 1558 6). Detection and recovery of delayed or lost 1559 transmissions. 1561 7). Detection and handling of duplicate 1562 transmissions. 1564 The following section addresses in what components the 1565 new Internet EDI tracking information must be maintained, 1566 and discusses how this new tracking information relates 1567 to the tracking information kept by the EDI application. 1569 4.2 Transmission Successfully Translated From 1570 Internal Format to Standard EDI Format 1572 4.2.1 Needs 1574 There needs to be a facility by which a sender can 1575 be assured that the EDI transmission was correctly 1576 translated and prepared for outbound transmission. 1578 4.2.2 Recommendations 1580 This is standard functionality for most if not all EDI 1581 translators. This MUST NOT be required functionality 1582 of an EDI UA. 1584 4.3 Transmission Successfully Encoded, Encrypted, Signed and 1585 Sent 1587 4.3.1 Needs 1589 There needs to be a facility by which a sender can be 1590 assured that an EDI transmission was successfully 1591 encoded, encrypted, signed, and sent. 1593 4.3.2 Recommendations 1595 The tracking of the success or failure of the security 1596 services required for Internet EDI MUST be maintained by 1597 the EDI UA. 1599 The EDI UA MUST be able to identify the transmission 1600 by its message id, AND a calculated MIC value if desired. 1602 4.4 Transmission Successfully Delivered to the Recipient's 1603 Mailbox 1605 4.4.1 Needs 1607 There needs to be a facility by which a sender can be 1608 assured that an EDI transmission was successfully 1609 delivered to a recipient's mailbox. 1611 4.4.2 Recommendations 1613 This type of tracking information is kept by the UA and 1614 is returned to the sender as a delivery notification. The 1615 delivery notification is specified in RFC 1894 [12]. 1617 4.5 Transmission Successfully Received 1619 4.5.1 Needs 1621 There needs to be a facility by which a sender of a 1622 transmission can be assured that the transmission was 1623 correctly received by the intended receiver. 1625 4.5.2 Recommendations 1627 This type of tracking information MUST be kept by the EDI UA and 1628 is returned to the sender as a signed receipt. (See section 1629 3.7.3 for a discussion about signed receipts.) 1631 Note: The X12 997 or EDIFACT CONTRL message can also provide 1632 the equivalent of an implicit transmission received 1633 acknowledgment. However, the use of signed receipts 1634 is still RECOMMENDED for the following reasons: 1636 * The implied success of the receiver's decryption 1637 through the receipt of a legible 997, binds the 1638 certificate to a control ID only (997) and not to 1639 the actual data (signed receipt). 1641 * Translators are very different, and the CONTRL 1642 message isn't supported by all EDI translators 1643 or is it in widespread use yet. 1645 4.6 Transmission Successfully Translated by 1646 the Receiver 1648 4.6.1 Needs 1650 There needs to be a facility for the sender to be 1651 assured that the receiver could "understand" (in EDI 1652 terms) the transmission. 1654 4.6.2 Recommendations 1656 This SHOULD NOT be tracked by the EDI UA, following our 1657 recommendation for object boundaries. 1659 The Functional acknowledgment 997, and the EDIFACT 1660 CONTRL serve this exact purpose -- this SHOULD be tracked 1661 by the EDI translator. 1663 4.7 Detection and Recovery of Delayed or Lost Transmissions 1665 4.7.1 Needs 1667 There needs to be a facility by which a sender can 1668 detect sent transmissions that have not been 1669 acknowledged as correctly received, by a specified, 1670 configurable, period of time, and be able to configure 1671 actions accordingly. 1673 4.7.2 Recommendations 1675 1). The sender should specify that a receipt or signed 1676 receipt be returned in response to the sent message. 1677 The way to request that a receipt or message 1678 disposition notification be returned by the recipient 1679 is specified in draft-ietf-receipt-mdn-04.txt [5]. 1680 The way to request that a signed receipt be returned 1681 by the recipient is specified in draft-ietf-ediint- 1682 as1-03.txt [10]. 1684 2). Both the receipt and signed receipt return the 1685 message id that was sent in the original message. 1686 In addition to the original message id, the signed 1687 receipt also returns the message integrity check 1688 calculated on the contents of the received message. 1690 3). The information in the receipt or signed receipt 1691 can then be used to correlate to the originally 1692 signed message. NOTE: A receipt or signed receipt 1693 MUST NOT be requested when sending a receipt or 1694 signed receipt. This is explicitly prohibited by 1695 the standards. 1697 4). If a receipt or signed receipt is not returned 1698 within a configurable time, then actions based 1699 on the failure to receive a receipt or signed 1700 receipt may include: 1702 * Re-transmit: If re-transmitted, the receiving 1703 UA MUST be able to detect the second 1704 transmission as a duplicate and discard it. 1706 * Alert/Report: Operator intervention may be required 1707 to track the cause of the delay in receiving the 1708 receipt or signed receipt. 1710 4.8 Detection and Handling of Duplicate Transmissions 1712 4.8.1 Need 1714 There needs to be a facility by which a receiver of EDI 1715 transmissions is able to detect different types of 1716 duplicate transmissions, and handle them correctly. 1717 First, translator initiated duplicates SHOULD NOT be 1718 halted in any way - it should be assumed that translators 1719 will handle that level of duplication. In other words, there 1720 should be no checking of ISA control numbers by the UA. 1721 Secondly, the use of a re-transmission feature in attempts 1722 to deliver transmissions quickly, should allow for a UA to 1723 identify duplicate transmissions generated by the sending 1724 UA, and discard the duplicate transmissions after the first 1725 has been received. 1727 4.8.2 Recommendations 1729 By applying a signature to the EDI MIME content, 1730 the originator will send a message integrity check 1731 to the recipient of the transmission. The recipient 1732 SHOULD log the received message integrity check 1733 along with the other security related information 1734 associated with the received message. 1736 Duplicate messages can be detected by the recipient 1737 by comparing the message integrity check received 1738 each time, with the log of received message integrity 1739 checks. It is recommended that EDI UAs, in order to 1740 detect duplicate transmissions, agree minimally to 1741 sending and receiving signed content. 1743 EDI related control numbers, such as the ISA 1744 control number, should not be checked by the 1745 EDI UA. A duplicate EDI message can still be 1746 distinguished at the MIME messaging level, since 1747 EDI time stamps will change, even if the EDI control 1748 number or EDI transaction are duplicates. 1750 5. Appendix A - Implementation Considerations, Formats, and Examples 1752 5.1 Introduction 1754 The following appendix describes the structure of EDI MIME 1755 messages, making use of the security features previously 1756 discussed in this requirements document. 1758 The structures shown below represent the use of specifications 1759 outlined in the following RFCs and Internet-drafts. Before 1760 moving into the structures themselves, there is a brief review of 1761 what each document contributes. 1763 NOTE: The examples below are just that - examples. Do not code 1764 according to them. Refer to the RFCs that specify the correct 1765 grammar in each case. 1767 5.2 Referenced RFCs and their contribution 1769 5.2.1 RFC 821 SMTP [7] 1771 This is the core mail transfer standard that all MTAs need to 1772 adhere to. 1774 5.2.2 RFC 822 Text Message Format [3] 1776 Defines message header fields and the parts making up a message. 1778 5.2.3 RFC 1847 MIME Security Multiparts [6] 1780 This document defines security multiparts for MIME: 1781 multipart/encrypted and multipart/signed. 1783 5.2.4 RFC 1892 Multipart/report [10] 1784 This RFC defines the use of Multipart/report content type, 1785 something that the MDN draft (fajman) builds upon to define 1786 the receipts functionality. 1788 5.2.5 RFC 1767 EDI Content [2] 1790 This RFC defines the use of content type "application" for ANSI 1791 X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and 1792 mutually defined EDI (application/EDI-Consent). 1794 5.2.6 RFC 2015 PGP/MIME [4] 1796 This RFC defines the use of content types 1797 "multipart/encrypted", "multipart/signed", "application/pgp 1798 encrypted" and "application/pgp-signature" for defining MIME PGP 1799 content. 1801 5.2.7 RFC 2045, 2046, and 2049 MIME [1] 1803 These are the basic MIME standards, upon which all MIME 1804 related RFCs build, including this one. 1806 Key contributions include definition of 1807 "content type", "sub-type" and "multipart", as well as encoding 1808 guidelines, which establishes 7-bit US-ASCII as the canonical 1809 character set to be used in Internet messaging. 1811 5.2.8 Internet draft (fajman):Message Disposition Notification [5] 1813 This Internet draft defines how a message disposition notification 1814 (MDN) is requested, and the format and syntax of the MDN. The MDN 1815 is the basis upon which receipts and signed receipts are defined 1816 for Internet EDI. 1818 5.2.9 Internet draft (dusse): S/MIME Message Specification [8] 1820 This specification describes how MIME shall carry PKCS7 1821 envelopes. 1823 5.3 Structure of an EDI MIME message - No encryption/No signature 1825 To: 1826 Subject: 1827 From: 1828 Date: 1829 Mime-Version: 1.0 1830 Content-Type: Application/ 1831 Content-Transfer-Encoding: 1833 1835 5.4 Structure of an EDI MIME message - S/MIME 1837 5.4.1 S/MIME Overview 1839 S/MIME or the Secure/Multipurpose Internet Mail Extensions, 1840 specify formats and procedures when the cryptographic security 1841 services of authentication, message integrity, non-repudiation 1842 of origin, and confidentiality are applied to Internet 1843 MIME messages. 1845 S/MIME is specified in Internet draft, draft-dusse-mime-msg- 1846 spec-00.txt [8], and an S/MIME implementation guide [11] 1847 is available from RSA Data Securities, Inc. 1849 This applicability statement sets forth the implementation 1850 requirements and recommendations needed to use S/MIME when 1851 sending EDI on the Internet. These implementation 1852 requirements and recommendations are intended to ensure 1853 a base level of inter-operability among S/MIME EDI 1854 implementations. 1856 NOTE: The S/MIME Implementation Guide, Version 2 specifies a 1857 restricted profile for use for export purposes and an 1858 unrestricted profile for use domestically. These 1859 profiles specify the cryptographic algorithms and key 1860 lengths that a conforming S/MIME implementation must 1861 support. It is RECOMMENDED for Internet EDI, that 1862 these profiles be adhered to. However, cryptographic 1863 algorithms, and key lengths are parameters that need 1864 to be set by the trading partnership, and can vary 1865 from what is specified by the S/MIME implementation 1866 guide, as well as this specification. 1868 Content Types: 1870 The signedAndEnvelopedData content type SHOULD NOT be 1871 used when sending EDI on the Internet. Objections have 1872 been raised concerning the fact that the issuerAndSerialNumber 1873 for each signer of a signedAndEnvelopedData content is 1874 left in the clear. This information could be used to 1875 derive the identity of the signer of the message. The 1876 use of signedAndEnvelopedData also precludes the ability 1877 to sign information that is in addition to, but 1878 separate from the primary signed contents. The use of 1879 S/MIME "authenticated attributes" is not required for 1880 Internet EDI, since it is generally sufficient to sign 1881 the EDI MIME content and headers. 1883 The S/MIME Implementation Guide, Version 2 requires a compliant 1884 S/MIME agent to support the nesting of a signed "message" format 1885 within an enveloped "message", for both incoming and outgoing 1886 messages. For Internet EDI, it is also REQUIRED that implementations 1887 support a nested signed "message" within an enveloped or 1888 encrypted "message". Therefore, when using S/MIME for the 1889 purpose of Internet EDI, a two step process 1890 MUST be used: the user agent first creates a multipart/signed 1891 "content", and uses this multipart/signed "content" as input 1892 to the creation of an application/x-pkcs-7-mime enveloped 1893 "message". 1895 The receiver of an incoming enveloped "message" that is 1896 decrypted and found to contain a multipart/signed 1897 "content", MUST process the multipart/signed "content" 1898 and present the signature status and corresponding 1899 first body part of the multipart/signed to the 1900 receipts processing -- if either a request 1901 for a receipt or signed receipt has been made -- 1902 otherwise, the first body part of the multipart/signed 1903 is passed to a general MIME processor. 1905 For the purpose of Internet EDI, the first body part of the 1906 multipart/signed SHOULD contain RFC 1767 specified MIME 1907 EDI content, or a MIME multipart/mixed content that has 1908 at least one RFC 1767 MIME EDI content as part of the 1909 multipart/mixed content. 1911 Multipart/Signed and signedData: 1913 The S/MIME specification requires support of the signedData 1914 content format, and recommends support of the multipart/signed 1915 format. For use in Internet EDI however, it is REQUIRED that 1916 the multipart/signed format be supported, whenever message authentication, 1917 integrity, and non-repudiation of origin are used. The 1918 great value for support of the multipart/signed format is 1919 the ability of non S/MIME-enabled agents to process the 1920 content of the body that was signed. 1922 The PKCS7 signedData format MAY be used only when it is known 1923 that the EDI data is to pass through non RFC 1847 compliant 1924 gateways. 1926 Some non RFC 1847 compliant gateways do not treat the message 1927 contents as opaque, and may change the content transfer 1928 encoding, thereby invalidating the message integrity check 1929 that was calculated by the sender. 1931 Support of the PKCS7 signedData format for use in Internet EDI 1932 is OPTIONAL, and MUST be agreed upon between trading partners. 1934 5.4.2 Example: S/MIME - Signature Only (Multipart/Signed) 1936 To: 1937 Subject: 1938 From: 1939 Date: 1940 Mime-Version: 1.0 1941 Content-Type: multipart/signed; boundary="separator"; 1942 micalg=rsa-; protocol="application/x-pkcs7-signature" 1944 --separator 1945 &Content-Type: Application/ 1946 &Content-Transfer-Encoding: 1947 & 1948 & 1950 --separator 1951 Content-Type: application/x-pkcs7-signature 1953 fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQer 1954 /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/D 1955 frtFFKFG+GFff= 1956 =ndaj 1958 --separator-- 1960 Notes: 1962 -The lines preceded with "&" is what the signature is calculated 1963 over. 1965 5.4.3 Example: S/MIME - Signature Only (signedData) 1967 To: 1968 Subject: 1969 From: 1970 Date: 1971 Mime-Version: 1.0 1972 Content-Type: application/x-pkcs7-mime 1973 Content-Transfer-Encoding: base64 1975 1977 &Mime-Version: 1.0 1978 &Content-Type: Application/; 1979 &Content-Transfer-Encoding: 1980 & 1981 & 1983 1985 Notes: 1987 -The lines preceded with "&" is what the signature is calculated 1988 over 1990 - consists of (refer to: 1991 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): 1993 ContentType = SignedData 1994 version = Version 1995 digestAlgorithms = DigestAlgorithmIdentifiers 1996 contentType = Data 1997 content = 1999 NOTE: that except for ContentType and Content, the actual object 2000 identifiers or values for the fields are not specified. (See 2001 PKCS9 and the S/MIME Implementation Guide, Version 2 from 2002 RSA Labs, Inc., for these object identifiers.) 2004 - consists of (refer to: 2005 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): 2007 signerInfos = SignerInfo 2009 NOTE: The signerInfo contains the digestAlgorithm, the 2010 digestEncryptionAlgorithm, and the encryptedDigest or the digital 2011 signature. The issuerAndSerialNumber field defined within the 2012 signerInfos identifies a signing trading partner's public-key 2013 certificate. Since Internet EDI allows self-certification, this 2014 field can contain the distinguished name of the sending trading 2015 partner or it can contain an actual issuer's distinguished name. 2017 Requirements For Inter-operable Internet EDI 8 July 199 2019 5.4.4 Example: S/MIME - Encryption Only 2021 To: 2022 Subject: 2023 From: 2024 Date: 2025 Mime-Version: 1.0 2026 Content-Type: application/x-pkcs7-mime 2027 Content-Transfer-Encoding: base64 2029 2031 &Mime-Version: 1.0 2032 &Content-Type: Application/; 2033 &Content-Transfer-Encoding: 2034 & 2035 & 2037 Notes: 2039 -The text preceded by "&" indicates that it is really encrypted, 2040 but presented as text for clarity 2042 - consists of (See 2043 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): 2045 contentType = EnvelopedData 2046 version = Version 2047 recipientInfos = RecipientInfos 2049 contentType = Data 2050 contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier 2052 encryptedContent = 2054 NOTE: Except for contentType, the actual object identifiers or 2055 values for the fields are not specified. (See PKCS9 and the 2056 S/MIME Implementation Guide, Version 2 from RSA Labs, Inc., 2057 for these objects.) 2059 NOTE: The recipientInfos contains the symmetric encryption key 2060 encrypted with the receiver's public key. The 2061 issuerAndSerialNumber field defined within the recipientInfos 2062 identifies a receiving trading partner's public-key 2063 certificate. Since Internet EDI allows self-certification, 2064 this field can contain the distinguished name of the 2065 receiving trading partner or the issuer distinguished name. 2066 NOTE: In general there will be one recipientInfos specified, but 2067 in the case of RFQs, there may be n recipientInfos specified. 2069 5.4.5 Example: S/MIME - Signature and Encryption (Multipart/Signed) 2071 The required support for EDI Internet is to first create a MIME 2072 multipart/signed content, and then to create an 2073 application/x-pkcs7-mime envelopedData message with the 2074 multipart/signed content as the input to the envelopedData message. 2076 To: 2077 Subject: 2078 From: 2079 Date: 2080 Mime-Version: 1.0 2081 Content-Type: application/x-pkcs7-mime 2082 Content-Transfer-Encoding: base64 2084 2086 *Content-Type: multipart/signed; boundary="separator"; 2087 * micalg=rsa-; 2088 * protocol="application/x-pkcs7-signature" 2089 * 2090 *--separator 2091 * &Content-Type: Application/ 2092 * &Content-Transfer-Encoding: 2093 * & 2094 * & 2095 * 2096 *--separator 2097 * Content-Type: application/x-pkcs7-signature 2098 * Content-Transfer-Encoding: 2099 * 2100 * fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553// 2101 * /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88 2102 * frtFFKFG+GFff= 2103 * 2104 *--separator-- 2106 Notes: 2108 - The lines preceded with "&" is what the signature is calculated 2109 over. 2111 - The text preceded by "*" indicates that it is really encrypted, but 2112 presented as text for clarity. 2114 - consists of (See 2115 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): 2117 contentType = EnvelopedData 2118 version = Version 2119 recipientInfos = RecipientInfos 2121 contentType = Data 2122 contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier 2124 encryptedContent = 2126 NOTE: Except for contentType, the actual object identifiers or 2127 values for the fields are not specified. (See PKCS9 and the 2128 S/MIME Implementation Guide, Version 2 from RSA Labs, Inc., 2129 for these objects.) 2131 NOTE: The recipientInfos contains the symmetric encryption key 2132 encrypted with the receiver's public key. The 2133 issuerAndSerialNumber field defined within the recipientInfos 2134 identifies a receiving trading partner's public-key 2135 certificate. Since Internet EDI allows self-certification, 2136 this field can contain the distinguished name of the 2137 receiving trading partner or the issuer distinguished 2138 name. 2140 NOTE: In general there will be one recipientInfos specified, but 2141 in the case of RFQs, there may be n recipientInfos specified. 2143 5.4.6 Example: S/MIME - Signature and Encryption (signedData) 2145 To: 2146 Subject: 2147 From: 2148 Date: 2149 Mime-Version: 1.0 2150 Content-Type: application/x-pkcs7-mime 2151 Content-Transfer-Encoding: base64 2153 2155 *Content-Type: application/x-pkcs7-mime 2156 * 2157 * 2158 *&Content-Type: Application/; 2159 *&Content-Transfer-Encoding: 2160 *& 2161 * 2162 * 2164 Notes: 2166 - The lines preceded with "&" is what the signature is calculated 2167 over. 2169 - The text preceded by "*" indicates that it is really encrypted, but 2170 presented as text for clarity 2172 - consists of (See 2173 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): 2175 contentType = EnvelopedData 2176 version = Version 2177 recipientInfos = RecipientInfos 2179 contentType = Data 2180 contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier 2182 encryptedContent = 2184 NOTE: Except for contentType, the actual object identifiers or 2185 values for the fields are not specified. (See PKCS9 and the 2186 S/MIME Implementation Guide, Version 2 from RSA Labs, Inc., 2187 for these objects.) 2189 NOTE: The recipientInfos contains the symmetric encryption key 2190 encrypted with the receiver's public key. The 2191 issuerAndSerialNumber field defined within the recipientInfos 2192 identifies a receiving trading partner's public-key 2193 certificate. Since Internet EDI allows self-certification, 2194 this field can contain the distinguished name of the 2195 receiving trading partner or an issuer's distinguished 2196 name. 2198 NOTE: In general there will be one recipientInfos specified, but 2199 in the case of RFQs, there may be n recipientInfos specified. 2201 - consists of (refer to: 2202 PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.): 2204 signerInfos = SignerInfo 2205 NOTE: The signerInfo contains the digestAlgorithm, the 2206 digestEncryptionAlgorithm, and the encryptedDigest or the digital 2207 signature. The issuerAndSerialNumber field defined within the 2208 signerInfos identifies a signing trading partner's public-key 2209 certificate. Since Internet EDI allows self-certification, this 2210 field can contain the distinguished name of the sending trading 2211 partner or an issuer's distinguished name. 2213 5.5 Structure of an EDI MIME message - PGP/MIME 2215 5.5.1 Overview 2217 PGP provides two functional services, signature and encryption, 2218 but in reality performs 5 functions in order to do it 2219 effectively. 2221 1) Digital signature (MD5, RSA) 2222 2) Compression (ZIP) 2223 3) Message Encryption (IDEA) 2224 4) ASCII Armor 2225 5) Message segmentation 2227 When sending a message, the services are performed in that 2228 order. 2230 With the exception of item 5), these services are optional, 2231 meaning a user can choose whether to use signature, encryption, 2232 compression and ASCII armor, but commonly, 2) and 4) are always 2233 used, while 1) and 3) are used in three ways: 2235 1) Signature only, in which case ASCII armor can be applied only 2236 to the signature block to keep the message legible. 2238 2) Encryption only 2240 3) Both signature and encryption 2242 Applicability of PGP/MIME and RFC 2015, for use in Internet EDI 2243 dictates the following: 2245 - When both encryption and signature feature is used, the EDI 2246 data is first signed, then encrypted in a two-step process, as 2247 described in the example. 2249 -Compression and ASCII Armor is optional and could be user 2250 configurable. 2252 The following examples describe use of PGP/MIME without 2253 compression and ASCII armor, since those services are managed by 2254 PGP, and are optional per this draft 2256 5.5.2 Example: PGP/MIME - Signature Only 2258 To: 2259 Subject: 2260 From: 2261 Date: 2262 Mime-Version: 1.0 2263 Content-Type: multipart/signed; boundary="separator"; 2264 micalg=pgp-; protocol="application/pgp-signature" 2266 --separator 2267 &Content-Type: Application/ 2268 &Content-Transfer-Encoding: 2269 & 2270 & 2272 --separator 2273 Content-Type: application/pgp-signature 2275 -----BEGIN PGP MESSAGE----- 2276 Version 2.6.2 2278 fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQer 2279 /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/D 2280 frtFFKFG+GFff= 2281 =ndaj 2282 -----END PGP MESSAGE----- 2284 --separator-- 2286 Notes: 2288 -The lines preceded with "&" is what the signature is calculated 2289 over. 2291 5.5.3 Example: PGP/MIME - Encryption Only 2293 To: 2294 Subject: 2296 From: 2297 Date: 2298 Mime-Version: 1.0 2299 Content-Type: multipart/encrypted; boundary="separator"; 2300 protocol="application/pgp-encrypted" 2302 --separator 2303 Content-Type: application/pgp-encrypted 2305 Version: 1 2307 --separator 2308 Content-Type: application/octet-stream 2310 -----BEGIN PGP MESSAGE----- 2311 Version 2.6.2 2313 & 2314 &Content-Type: Application/; 2315 &Content-Transfer-Encoding: 2316 & 2317 & 2318 -----END PGP MESSAGE----- 2320 --separator-- 2322 Notes: 2324 -The text preceded by "&" indicates that it is really encrypted, but 2325 presented as text for clarity 2327 -"pgp control information" contains the following, but refer to PGP 2328 specifications or tool kits for details: 2330 -Key ID of recipient's public key 2331 -Session key (symmetric) 2332 -Timestamp 2333 -Key ID of sender's public key 2334 -Leading two octets of message digest 2335 -Message digest 2336 -Filename 2337 -Timestamp 2339 5.5.4 Example: PGP/MIME - Signature and Encryption 2341 The sequence here is that the EDI data is first signed as a 2342 multipart/signed body, and then the data plus the signature is 2343 encrypted to form the final multipart/encrypted body. 2345 To: 2346 Subject: 2347 From: 2348 Date: 2349 Mime-Version: 1.0 2350 Content-Type: multipart/encrypted; boundary="separator"; 2351 protocol="application/pgp-encrypted" 2353 --separator 2354 Content-Type: application/pgp-encrypted 2356 Version: 1 2358 --separator 2359 Content-Type: application/octet-stream 2361 -----BEGIN PGP MESSAGE----- 2362 Version 2.6.2 2364 * 2365 * Content-Type: multipart/signed; boundary="signed separator"; 2366 * micalg=pgp-; protocol="application/pgp-signature" 2367 * 2368 * --signed separator 2369 * &Content-Type: Application/ 2370 * &Content-Transfer-Encoding: 2371 * & 2372 * & 2373 * 2374 * --signed separator 2375 * Content-Type: application/pgp-signature 2376 * 2377 * -----BEGIN PGP MESSAGE----- 2378 * Version 2.6.2 2379 * 2380 * fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytd 2381 * /GIUIUgsIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF 2382 * frtFFKFG+GFff= 2383 * =ndaj 2384 * -----END PGP MESSAGE----- 2385 * 2386 * --signed separator-- 2387 -----END PGP MESSAGE----- 2389 --separator- 2391 Requirements For Inter-operable Internet EDI 8 July 199 2393 Notes: 2395 - The lines preceded with "&" is what the signature is calculated 2396 over. 2398 - The text preceded by "*" indicates that it is really encrypted, 2399 but presented as text for clarity 2401 - "pgp control information" contains the following, but refer to 2402 PGP specifications or tool kits for details: 2404 -Key ID of recipient's public key 2405 -Session key (symmetric) 2406 -Timestamp 2407 -Key ID of sender's public key 2408 -Leading two octets of message digest 2409 -Message digest 2410 -Filename 2411 -Timestamp 2413 -RFC 2015 allows another way to handle the above in a combined 2414 fashion, However, for the purpose of EDI we require the above method, 2415 which is based on MIME Security Multiparts [4] RFC 1847. This method 2416 performs signature and encryption in a two-step process, first signing 2417 the data, then encrypting it. This is also consistent with PGP's 2418 recommendations. 2420 5.6 Additional Considerations 2422 RFC 1847 [6] and RFC 1848 [13] provide valuable guidance 2423 when implementing the multipart/signed content. In particular, 2424 RFC 1848 provides the canonicalization considerations required 2425 when implementing the multipart/signed content. 2427 6. Acknowledgments 2429 The authors would like to extend special thanks to Lincoln 2430 Yarbrough for his support and championing of these open 2431 Internet EDI standards. 2433 This document is the result of the many contributions of the 2434 members of the IETF EDIINT Working group, including Harald 2435 Alvestrand, Jim Galvin, Karen Rosenthal, Dale Moberg, Carl Hage, 2436 Jun Ding, and Pedro Chiang. 2438 7. References 2440 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 2441 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 2442 December 02, 1996. 2444 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 2445 (MIME) Part Two: Media Types", RFC 2046, December 02, 2446 1996. 2448 N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions 2449 (MIME) Part Five: Conformance Criteria and Examples", RFC 2450 2049, December 02, 1996. 2452 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, 2453 March 2, 1995. 2455 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 2456 Messages", STD 11, RFC 822, August 13, 1982. 2458 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2459 2015, Sept. 1996. 2461 [5] R. Fajman, "An Extensible Message Format for Message Disposition 2462 Notifications", draft-ietf-receipt-mdn-04.txt, April 16, 1997. 2464 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts 2465 for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, 2466 Oct. 3, 1995. 2468 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, 2469 August 1, 1982. 2471 [8] S. Dusse, "S/MIME Message Specification; PKCS Security 2472 Services for MIME", Internet draft: draft-dusse-mime-msg-spec 2473 00.txt 2475 [9] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting 2476 of Mail System Administrative Messages", RFC 1892, January 15, 2477 1996. 2479 [10] M. Jansson, C. Shih, R. Drummond, "MIME-based Secure EDI", 2480 Internet draft: draft-ietf-ediint-as1-04.txt, June 9, 2481 1997. 2483 [11] S/MIME Editor, "S/MIME Implementation Guide, Interoperability 2484 Profiles, Version 2", Draft, Revised October 8, 1996. 2486 [12] K. Moore, G. Vaudreuil, "An Extensible Message Format for 2487 Delivery Status Notification", RFC 1894, January, 1996. 2489 [13] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security 2490 Services", RFC 1848, October, 1995. 2492 [14] B. Schneier, "E-Mail Security", John Wiley & Sons, 1995. 2494 [15] B. Schneier, "Applied Cryptography", 2e. John Wiley & Sons, 1996. 2496 [16] M. Blaze, W. Diffie, R. L. Rivest, B. Schneier, T. Shimomura, 2497 E. Thompson, M. Wiener, "Minimal Key Lengths for 2498 Symmetric Ciphers to Provide Adequate Commercial Security". 2500 8. Author's Address: 2502 Chuck Shih 2503 610 Caribbean Drive 2504 Sunnyvale, CA. 94089 2505 Phone: 408-542-3282 2506 Fax: 408-542-3210 2507 e-mail: chucks@actracorp.com 2509 Mats Jansson 2510 mjansson@agathon.com 2511 LiNK 2512 1026 Wilmington Way 2513 Redwood City, CA 94062 USA 2515 Rik Drummond 2516 drummond@onramp.net 2517 The Drummond Group 2518 5008 Bentwood Ct. 2519 Ft. Worth, TX 76132 USA