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