idnits 2.17.1 draft-ietf-ediint-req-01.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-25) 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 2179 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 212 has weird spacing: '... use of the I...' == Line 224 has weird spacing: '...re, and vendo...' == Line 251 has weird spacing: '...ffering some ...' == Line 257 has weird spacing: '...ffering the a...' == Line 365 has weird spacing: '... a very good ...' == (21 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 10023 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EDIINT Functional Specification November 1996 3 EDIINT Working Group Chuck Shih 4 Internet Draft Mats Jansson 5 Expires: 05/97 Rik Drummond 6 Lincoln Yarbrough 8 Requirements for Inter-operable Internet EDI 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. Internet-Drafts are draft documents 18 valid for a maximum of six months and may be updated, 19 replaced, or made obsolete by other documents at any 20 time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work 22 in progress." 24 To learn the current status of any Internet-Draft, 25 please check the "1id-abstracts.txt" listing contained 26 in the Internet-Drafts Shadow Directories on 27 ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 unnari.oz.au (Pacific Rim), ds.internic.net (US East 29 Coast), or ftp.isi.edu (US West Coast). 31 Any questions, comments, and reports of defects or 32 ambiguities in this specification may be sent to the 33 mailing list for the EDIINT working group of the IETF, 34 using the address . Requests to 35 subscribe to the mailing list should be addressed to 36 . 38 Abstract 40 This document is a functional specification, discussing 41 the requirements for inter-operable EDI, with sufficient 42 background material to give an explanation for the EDI 43 community of the Internet, and security related issues. 45 Feedback Instructions 47 If you want to provide feedback on this draft, follow these 48 guidelines: 50 - Send feedback via e-mail to chucks@actracorp.com, with EDIINT 51 Requirements in the subject field. 53 - Be specific as to what section you are referring to, preferably 54 quoting the portion that needs clarification or modification. 55 Your comments would then follow the identified section. 57 - If you are recommending some text be replaced with your suggested 58 text, again, quote the section to be replaced, and be clear on 59 how you think the text should read. 61 - If you are questioning fundamental assumptions, make it clear 62 what is being questioned and the editor will bring the issue 63 to the EDIINT list for discussion. To follow the discussion, 64 the reader needs to subscribe to the ietf-ediint@imc.org 65 discussion list. 67 Table of Contents 69 1.0 INTRODUCTION 4 71 1.1 THE AUDIENCE 4 73 2.0 THE INTERNET - A BRIEF HISTORY 5 75 2.1 THE INTERNET - MYTHS AND REALITY 6 77 2.2 INTERNET ROUTING AND SECURITY CONSIDERATIONS 7 79 2.3 EDI VAN COMMUNICATIONS AND SECURITY 8 81 3.0 FUNCTIONAL REQUIREMENTS 8 83 3.1 INTRODUCTION AND DEFINITIONS 8 85 3.2 STANDARD ENCRYPTION ALGORITHMS AND WORLD-WIDE 86 ENCRYPTION 9 87 3.2.1 INTRODUCTION AND DESCRIPTION 9 88 3.2.2 SYMMETRIC ENCRYPTION 9 89 3.2.3 ASYMMETRIC ENCRYPTION - PUBLIC-KEY CRYPTOGRAPHY 9 90 3.2.4 NEEDS 10 91 3.2.5 ISSUES 10 92 3.2.6 RECOMMENDATIONS 10 94 3.3 KEY MANAGEMENT - SYMMETRIC KEYS 12 95 3.3.1 INTRODUCTION AND DESCRIPTION 12 96 3.3.2 NEEDS 13 97 3.3.3 ISSUES 14 98 3.3.4 RECOMMENDATIONS 14 100 3.4 KEY MANAGEMENT - PUBLIC AND PRIVATE KEYS 14 101 3.4.1 INTRODUCTION AND DESCRIPTION 14 102 3.4.2 PUBLIC KEYS 15 103 3.4.3 NEEDS 15 104 3.4.4 ISSUES 15 105 3.4.5 RECOMMENDATIONS 16 107 3.5 CONTENT INTEGRITY 16 108 3.5.1 INTRODUCTION AND DESCRIPTION 16 109 3.5.2 NEEDS 17 110 3.5.3 ISSUES 17 111 3.5.4 RECOMMENDATIONS 17 113 3.6 AUTHENTICATION AND NON-REPUDIATION OF ORIGIN 17 114 3.6.1 INTRODUCTION AND DESCRIPTION 18 115 3.6.2 NEEDS 18 116 3.6.4 RECOMMENDATIONS 19 118 3.7 SIGNED RECEIPT OR NON REPUDIATION OF 19 119 RECEIPT 120 3.7.1 INTRODUCTION AND DESCRIPTION 19 121 3.7.2 NEEDS 20 122 3.7.3 RECOMMENDATIONS 20 124 3.8 EDI OBJECT BOUNDARIES AND TRANSACTION PRIVACY 21 125 3.8.1 INTRODUCTION AND DESCRIPTION 21 126 3.8.2 GATEWAY FUNCTIONS 21 128 3.9 SYNTAX AND PROTOCOL FOR SPECIFYING CRYPTOGRAPHIC 129 SERVICES 21 130 3.9.1 INTRODUCTION AND DESCRIPTION 21 131 3.9.2 NEEDS 21 132 3.9.3 ISSUES 21 133 3.9.4 RECOMMENDATIONS 22 135 4.0 TRACKING AND ERROR HANDLING BASICS 22 137 4.1 INTRODUCTION 22 139 4.2 TRANSMISSION SUCCESSFULLY TRANSLATED FROM 140 INTERNAL FORMAT TO STANDARD EDI FORMAT 23 141 4.2.1 NEEDS 23 142 4.2.2 RECOMMENDATIONS 23 144 4.3 TRANSMISSION SUCCESSFULLY ENCODED, ENCRYPTED, SIGNED 145 AND SENT 23 146 4.3.1 NEEDS 23 147 4.3.2 RECOMMENDATIONS 24 149 4.4 TRANSMISSION SUCCESSFULLY DELIVERED TO THE RECIPIENTS 150 MAILBOX 24 151 4.4.1 NEEDS 24 152 4.4.2 RECOMMENDATIONS 24 154 4.5 TRANSMISSION SUCCESSFULLY RECEIVED 24 155 4.5.1 NEEDS 24 156 4.5.2 RECOMMENDATIONS 25 158 4.6 TRANSMISSION SUCCESSFULLY TRANSLATED BY 159 RECEIVER 25 160 4.6.1 NEEDS 25 161 4.6.2 RECOMMENDATIONS 25 163 4.7 DETECTION AND RECOVERY OF DELAYED OR LOST 164 TRANSMISSIONS 25 165 4.7.1 NEEDS 25 166 4.7.2 RECOMMENDATIONS 25 168 4.8 DETECTION AND HANDLING OF DUPLICATE 169 TRANSMISSIONS 25 170 4.8.1 NEEDS 26 171 4.8.2 RECOMMENDATIONS 26 173 APPENDIX A - A COMPARISON OF SECURITY FORMATS AND 174 PROTOCOLS 26 176 1.0 Introduction 178 Electronic Data Interchange (EDI) is a set of protocols 179 for conducting highly structured inter-organization 180 exchanges, such as for making purchases or initiating 181 loan requests. The initial RFC1767 defined the method 182 for packaging EDI X.12 and UN/EDIFACT transaction sets in 183 a MIME envelope. However, several additional 184 requirements for obtaining multi-vendor, inter-operable 185 service, over and above how the EDI transactions are 186 packaged, have come to light since the effort concluded. 187 These currently revolve around security issues such as 188 EDI transaction integrity, confidentiality and non- 189 repudiation in various forms. Additional requirements 190 that mimic many of the heading fields found in X.435 EDI 191 messages (e.g., Interchange Sender, Interchange 192 Recipient, Interchange Control Reference, Communications 193 Agreement ID, and Syntax Identifier) are also needed to 194 support efficient exchanges by gateways and Value Added 195 Networks. Standards in these and other areas are 196 necessary to insure inter-operability between EDI 197 implementations over the Internet. Various technologies 198 already exist for these additional features, and the primary 199 requirement is to review and select a common set of 200 components for use by the EDI community when it sends 201 EDI over the Internet. In effect, the effort is to 202 provide an EDI over the Internet Requirements Document 203 and an Applicability Statement Document. 205 This document's current focus is on EDI MIME content 206 transported using SMTP (Simple Mail Transport Protocol), 207 the Internet's mail or messaging system. 209 Traditional VAN connectivity is slow and expensive. The 210 Internet promises lower cost usage and is more easily 211 accessible than traditional methods of communications. 212 The predominant problem with the use of the Internet 213 for EDI is inter-operability between vendor products, 214 specifically in the areas of integrity, confidentiality, 215 digital signature, and non-repudiation. The EDIINT working 216 group's focus is to recommend solutions for each of 217 these areas using existing standards whenever possible. 219 1.1 The Audience 221 The audience for this document consists of persons 222 directly or indirectly involved in EDI communications 223 decisions, companies trading EDI documents today or in 224 the future, and vendors developing and marketing EDI 225 products. Also included in the audience for this 226 document are people providing services and consulting 227 to the EDI community. 229 2.0 The Internet - A Brief History 231 The Internet is a world-wide collection of computers, 232 routers, and networks, connected together using the 233 TCP/IP suite of protocols. The Internet itself is not a 234 network, but a collection of networks. The Internet was 235 designed to be decentralized, with no single authority 236 needed to run it. All hosts on the Internet can 237 communicate with one another as peers, and all of the 238 communications protocols are "open" -- the standards are 239 in the public domain, and the standardization process is 240 open to anyone willing to put in the hard work to help 241 define them. 243 One consequence of this standards "openness" is that the 244 Internet can accommodate many different kinds of 245 machines (toasters for example). Its protocols -- the 246 TCP/IP suite -- have therefore become the de facto 247 standards for heterogeneous computer networking. At one 248 level, the Internet is a physical collection of 249 computers connected by common protocols. At another 250 level though, the Internet can be thought of as a 251 distributed medium, offering some important advantages 252 for doing EDI. For instance, the Internet has hundreds 253 of thousands of connected global hosts, and tens of 254 millions of users. The Internet offers a flat rate, 255 volume and time-of-day independent pricing structure for 256 data transmission. The Internet is highly redundant, 257 offering the ability to route data along alternate 258 paths. The Internet's decentralized structure makes 259 adding new hosts relatively easy -- it scales well, and 260 supports high bandwidth communications technologies. 262 2.1. The Internet - Myths and Reality 264 The Internet had its beginnings in 1969 as an 265 experimental U.S. Defense Department network called 266 ARPANET. The network was built to facilitate research on 267 how to construct networks that could withstand outages 268 to part of the network, but continue to function. 269 Network reliability was a fundamental design point when 270 developing the architecture and protocols associated 271 with the Internet. From the premise that the network was 272 inherently unreliable (parts of it could be destroyed at 273 any moment) emerged a design that was both robust and 274 reliable. Early on, the networks comprising the 275 Internet were primarily those from government agencies 276 and educational institutions. Access to the Internet was 277 pretty much available only to computer science 278 researchers, and government employees and their contractors. 280 In 1986, the National Science Foundation, in order to 281 provide access to what was then a scarce resource, put 282 together an initiative to link five super-computer 283 centers together using the TCP/IP protocols. Two very 284 important results of the NSFNET initiative were the 285 upgrading of the Internet's infrastructure with 286 more powerful processors and higher speed links, and 287 expansion of access to a larger user community. The 288 1990's has seen the continual upgrading of the Internet 289 infrastructure and its expansion to new constituencies 290 outside the traditional government and university 291 research community. Commercial interests are now the 292 largest as well as the fastest growing segment of the 293 Internet. 295 Commercial Internet providers, such as Performance 296 Systems International (PSI), and UUNET (the Alternet 297 network), have emerged from the collection of 298 intermediate-level networks that came into being as a 299 result of the NSFNET initiative. The national long distance 300 carriers such as MCI, AT&T, and Sprint all 301 provide commercial Internet services. These commercial 302 providers, called Internet Service Providers or ISPs for 303 short, make available Internet connectivity and various 304 other Internet services to their clients. The perception 305 of the Internet as experimental, and primarily used by 306 and for educational and research activities is 307 rooted in the Internet's past, and does not reflect today's 308 situation. The growth in commercial access to the 309 Internet, along with the growth of the ISPs, has 310 radically changed the Internet's network composition. 312 The design and architecture underlying the Internet has 313 proven its robustness by scaling to unprecedented 314 proportions. The Internet is reliable from several 315 perspectives: 317 1). Technologically, the TCP/IP suite of protocols and 318 the architecture underlying the Internet are stable and 319 mature. 321 2). Product implementations based on the TCP/IP suite 322 are also stable and mature. 324 3). Internet routing is dynamic, so packets sent through 325 the Internet get to their destinations even if there are 326 network outages along the way. 328 4). The commercial ISP administered portions of the 329 Internet, provide essentially the same level of network 330 reliability, availability, monitoring, throughput, 331 implementation and support services as existing EDI 332 Value Added Networks (VANS), but at a lower cost and 333 with higher bandwidth. 335 Although the Internet is reliable, low-cost, highly 336 accessible, supports high bandwidth communications, and 337 is technically mature, there are still some valid 338 concerns relating to the use of the Internet for EDI. 339 These concerns revolve primarily around security, 340 message tracking, audit trails, and authentication. Some 341 of the concerns, encryption for instance, are of a 342 general nature and not specific to the Internet -- 343 encryption may be required regardless of what type of 344 network is traversed. Other concerns, such as tracking, 345 arise because they are required by EDI, or are supported by 346 existing EDI Value Added Networks. 348 2.2 Internet Routing and Security Considerations 350 By using a common network trace program called 351 Traceroute, the route traversed by a packet from a 352 source host to a destination host on the Internet may be 353 followed. Tracing routes on the Internet yield some 354 interesting characteristics. As expected, the routes 355 traversed go through the networks administered by the 356 ISPs of each of the trading partners. Each route 357 consists of multiple nodes through each network. The 358 route can vary but that is not the typical case. The IP 359 packets are delivered reliably, and within a specified 360 period of time. When a reputable commercial ISP is used, 361 none of the nodes in the route are administered by 362 government or educational entities. 364 By looking at Internet network traces, we can conclude 365 that the Internet does a very good job of getting 366 packets from a source to destination. However, between 367 the source and the destination, the packets are routed 368 through many intermediate nodes. It is at the 369 intermediate nodes where anyone on one of the machines 370 that handle the packets could re-assemble the packets 371 that make up the EDI Interchange and could therefore read it, 372 copy it, alter it, or delete it. In the case where the EDI 373 Interchange is carried using an e-mail transport (SMTP), 374 the situation could arise where the message cannot be 375 delivered to the final recipient, so the message must 376 be stored at an intermediate node. Once again, the 377 message is susceptible to any number of the above mentioned 378 security threats. 380 The likelihood of any security threat, (especially if going 381 through intermediate nodes administered by a quality 382 ISP) are quite low, and practically speaking, are 383 quite difficult. Nonetheless the possibility exists, and 384 therefore is a concern -- particularly if the packets 385 contain high value or sensitive EDI or electronic 386 commerce transactions. 388 The Internet is being singled out in this discussion because 389 our focus is on EDI over the Internet. Networking is by its 390 very nature prone to security threats. Information can be 391 placed on shared media, and may be routed through nodes 392 not under the sender's administrative control. Whether through 393 malicious hacking or administrative glitches, the threat 394 that information sent over a network is read, copied, altered, 395 or deleted in an unauthorized way, is a possibility that 396 exists even if an EDI Interchange is sent via an EDI VAN. 398 A large component of the "value-added" services provided by 399 EDI VANs is precisely the assurance that EDI Interchanges sent 400 via the VAN are not compromised in any way. There are 401 however, measures that can be taken to defend against security 402 threats when an EDI Interchange is in transit across an 403 "open" network like the Internet. These security measures 404 are essential requirements when doing EDI over the Internet. 406 Each of these security measures is described in Section 3.0 407 of this document, and the issues surrounding each measure is 408 discussed, and recommended solutions are given. 410 2.3 EDI VAN Communications and Security 412 This section briefly discusses current VAN security services. 413 The security measures recommended in section 3.0 of this 414 document essentially provide the equivalent of the VAN security 415 services described below. 417 The most prevalent EDI VAN communications service provided to 418 EDI trading partners is an asynchronous mailboxing service. 419 A trading partner typically dials into a VAN network access 420 point. The trading partner then uses a file transfer protocol 421 to send the EDI Interchanges to the VAN. The VAN then routes 422 the EDI Interchanges to the receiving trading partner's VAN 423 mailbox. The receiving trading partner then dials into the 424 VAN and down-loads the EDI Interchanges from its VAN mailbox. 426 Other than support for a greater number of communications 427 protocols, and typically lower line speeds, connecting to an 428 EDI VAN is not too much different than connecting to an Internet 429 Service Provider. The EDI VANs however, provide a higher level of 430 EDI services to the EDI trading partner than do the ISPs. 431 The most important of these services is that the EDI VAN acts 432 as a trusted third party to insure that EDI Interchanges sent 433 via the VAN are not compromised in any way. 435 EDI VANs provide for EDI Interchange integrity, authentication, 436 and a number of acknowledgments that track the progress of the 437 EDI Interchange through the Value Added Network. EDI Interchange 438 integrity assures the trading partner that once the EDI 439 Interchange has been transferred to the VAN, that it will be 440 routed to the receiving trading partner without modification. 442 VAN authentication of trading partners consist of the guarantee 443 that EDI Interchanges can be sent and received by trading 444 partners only after they have been authenticated by the VAN. VANs 445 authenticate trading partners by having the trading partners 446 log into the network with the proper userid and password. The 447 VAN has administrative responsibility for maintaining the 448 trading partner accounts and for insuring that the accounts 449 are valid. VANs also provide differing levels of service that 450 allow a trading partner to track the progress of the EDI 451 Interchange through the VAN. Trading partners can subscribe to 452 mailbox delivery notification or mailbox pick-up notification. 453 Mailbox delivery notification is sent by the VAN to the 454 sending trading partner when the EDI Interchange is delivered 455 to the receiving trading partner. Mailbox pick-up notification 456 is sent by the VAN to the sending trading partner when the 457 EDI Interchange is down-loaded by the receiving trading partner. 459 The issue of tracking is covered in more detail in section 4.0. 461 3.0 Functional Requirements 463 3.1 Introduction and Definitions 465 The following sections describe the functional and 466 inter-operability requirements, as well as some of the 467 practical considerations of sending and receiving EDI 468 transactions on the Internet. It is assumed that the 469 reader is generally familiar with EDI. 471 3.2 Standard Encryption Algorithms and World-Wide 472 Encryption 474 3.2.1 Introduction and Description 476 The goal of encryption is to turn otherwise readable 477 text into something that cannot be read, and therefore 478 understood. By making the text unintelligible, 479 encryption discourages anyone from reading or copying 480 the EDI Interchange while it is in transit between the 481 trading partners. Encryption conveys confidentiality to 482 the EDI Interchange. Traffic analysis is always 483 possible, since many times, header information is not 484 encrypted. (Traffic analysis is the analysis of header 485 information in order to derive useful information from 486 them.) 488 Encryption is based on two components: an algorithm and 489 a key. An algorithm is a mathematical transformation 490 that takes plain-text or other intelligible information 491 and changes it into unintelligible cipher text. The 492 inverse mathematical transformation, back to the 493 original from the cipher text is also done, and is 494 called decryption. In order to encrypt the plain text, a 495 key is used as input in conjunction with an encryption 496 algorithm. An algorithm can use one of any of a large 497 number of possible keys. The number of possible keys 498 each algorithm can support depends on the number of bits 499 in the key. For instance, if the key length is 40, then 500 2 to the n, where n is the number of bits in the key, 501 results in 1,000,000,000,000 possible key combinations, 502 with each different key causing the algorithm to produce 503 slightly different cipher output. 505 An encryption algorithm is considered secure if its 506 security is dependent only on the length of its key. 507 Security cannot be dependent on the secrecy of the 508 algorithm, the inaccessibility of the cipher or plain 509 text, or anything else -- except the key length. If this 510 were true about a particular algorithm, then the most 511 efficient -- and only -- attack on that algorithm is a 512 brute-force attack, whereby all key combinations must 513 be tried in order to find the one correct key (this is 514 true for symmetric encryption algorithms, asymmetric 515 algorithms work a little differently, and are explained 516 in greater detail later). So by specifying a long 517 enough key length n, even a brute-force attack on a 518 secure algorithm can be made completely non-feasible. 520 3.2.2 Symmetric Encryption 522 Encryption algorithms whereby two trading partners must 523 use the identical key to encrypt and decrypt the EDI 524 Interchange are called symmetric encryption algorithms. 525 Put another way, if an EDI Interchange is encrypted with 526 one key, it cannot be decrypted with a different key. 527 The key used in most symmetric encryption algorithms is 528 just a random bit string, n bits long. These keys are 529 often generated from random data derived from the source 530 computer. 532 The use of symmetric encryption simplifies the 533 encryption process, each trading partner does not need 534 to develop and exchange secret encryption algorithms 535 with one another (which incidentally would be a near 536 impossible task). Instead, each trading partner can use 537 the same encryption algorithm, and only exchange the 538 shared, secret key. 540 There are drawbacks however with symmetric encryption 541 schemes; a shared secret key must be agreed upon by both 542 parties. If a trading partner has n trading 543 relationships, then n secret keys must be maintained, 544 one for each trading partner. Symmetric encryption 545 schemes also have the problem that origin or destination 546 authenticity (non-repudiation of origin, and receipt) 547 cannot be proved. Since both parties share the 548 secret encryption key, any EDI Interchange encrypted 549 with a symmetric key, could have been sent by either of 550 the trading partners. By using what is called public key 551 cryptography, which makes use of asymmetric encryption 552 algorithms, non-repudiation of origin and receipt, 553 can be unambiguously established. 555 3.2.3 Asymmetric Encryption - Public-key Cryptography 557 Public-key cryptography is based on the concept of a key 558 pair. Each half of the pair (one key) can encrypt 559 information that only the other half (one key) can 560 decrypt. The key pair is designated and associated to 561 one, and only one, trading partner. One part of the key 562 pair (the private key) is only known by the designated 563 trading partner; the other part of the key pair (the 564 public key) is published widely but is still 565 associated with the designated trading partner. 567 The keys are used in different ways for confidentiality 568 and digital signature. Both confidentiality and 569 signature depend on each entity having a key pair that 570 is identified only with them and each party keeping one 571 pair of their key pair secret from all others. 573 Signature works as follows: Trading Partner A uses her 574 secret key to encrypt part of a message, then sends the 575 encrypted message to Trading Partner B. B gets Trading 576 partner A's public key (anyone may get it) and attempts 577 to decrypt the encrypted part of Trading partner A's 578 message. If it decrypts, then Trading Partner B knows it 579 is from A -- because only A's public key can decrypt a 580 message encrypted with A's private key, and A is the 581 only one who knows her private key. 583 Confidentiality applies the asymmetric key pair, but in 584 a different manner than signature. If Trading partner A 585 wishes to send a confidential message to Trading Partner 586 B she would apply the key pair as follows: Trading 587 partner A would retrieve Trading partner B's public key, 588 and encrypt the message with it. When Trading Partner B 589 receives the message, she would decrypt the message 590 with her private key. Only her private key can decrypt 591 information that was encrypted with her public key. In 592 other-words, anything encrypted with B's public key can 593 only be decrypted with B's private key. 595 Since public-key encryption algorithms are considerably 596 slower than their symmetric key cousins, they are 597 generally not used to do the actual encryption of what 598 could be large EDI Interchanges. For instance, RSA Data 599 Securities, Inc. estimates that software encryption 600 using DES (a symmetric key algorithm) is 100 times 601 faster than software encryption using RSA (a public-key 602 encryption algorithm from RSA Data Securities, Inc.). 603 Hardware encryption using DES is anywhere from 1,000 to 604 10,000 times faster than hardware encryption using the 605 RSA asymmetric encryption algorithm. Instead of being 606 used for bulk encryption, public-key encryption 607 algorithms are used to encrypt symmetric encryption 608 keys. They are also used as an efficient means of 609 exchanging and managing symmetric encryption keys. 611 3.2.4 Needs 613 In order to provide confidentiality for EDI Interchanges 614 on the Internet, a standard encryption algorithm(s) and 615 key length(s) must be specified. For inter-operability 616 to occur between two trading partners, the encryption 617 algorithm and key lengths must be agreed upon either 618 before hand or within an individual transaction. 620 3.2.5 Issues 622 When choosing an encryption algorithm, the following 623 criteria should be considered; how secure the algorithm 624 is; how fast implementations of the algorithm are; the 625 availability of the algorithms for international as well 626 as domestic use; the availability of APIs and tool kits 627 in order to implement the algorithms; and the frequency 628 of the use of the algorithm in existing implementations. 630 Sufficient key lengths must be chosen with regard to 631 the value of the EDI Interchange so that brute-force 632 attacks are not worth the time or effort compared to the 633 value of the Interchange. 635 3.2.6 Recommendations 637 DES: The most widely used commercial encryption 638 algorithm is DES. It is widely used in the banking 639 industry for Electronic Funds Transfer (EFT). DES is 640 also a U.S. government encryption standard. DES is in 641 the public domain, which means anyone can implement the 642 algorithm, including those in the international 643 community. DES was designed for, and is used for bulk 644 encryption of data. DES is prohibited by the U.S. 645 government for export. 647 The DES algorithm has been analyzed by cryptographers 648 since the mid-1970s, and is considered secure: in other 649 words, the security of DES is completely dependent on 650 the length of its key. DES specifies a 56 bit key, so 2 651 to the 56th or 10 to the 16th keys are possible. A 652 brute force attack, which means trying every single key 653 to decrypt 8 bytes of known cipher-text into its 654 corresponding 8 bytes of known plain-text is the best 655 attack on the algorithm. 657 The amount of time and money required to mount a 658 successful brute force attack varies with the processing 659 power used -- and how lucky the attacker may be in 660 generating a key that is close to the one used to 661 encrypt the original EDI Interchange. Some estimates 662 which have been put forth claim that a $1 million dollar 663 hardware based, brute-force attack on DES would only take 3.6 664 hours to recover the DES key. A corresponding $1 665 million dollar software based brute-force attack on DES 666 would however take 3 years. As the price/performance of 667 processors decrease, a 56 bit key becomes less and less 668 adequate in protecting EDI Interchanges of extreme 669 value. Triple-DES, an algorithm with longer key length 670 (discussed below) should be used in such cases. 672 Triple-DES is a variant on DES that encrypts the EDI 673 Interchange 3 times, with 2 independent 56 bit keys, 674 giving it an effective key length of 112 bits. This 675 makes a brute-force attack on Triple-DES not feasible. 676 DES and Triple-DES actually can be implemented in 3 677 different modes. It is recommended that DES and Triple- 678 DES be used in Cipher Block Chaining (CBC) mode, which 679 gives added protection by making each cipher-text block 680 depend on each other, so changes in the cipher-text can 681 be detected. 683 RC2, RC4, and RC5: RC2, RC4, and RC5 are proprietary symmetric 684 algorithms of RSA Data Security, Inc. RC2 and RC4 685 unlike DES, are variable-key length algorithms. By specifying 686 differing key lengths, RC2 and RC4 can be configured to 687 provide greater or lesser security. RC2 and RC4 are 688 alternatives to DES and have special export status, 689 whereby 40 bit versions of RC2 and RC4, and 56 bit 690 versions for foreign subsidiaries and overseas offices 691 of U.S. companies have expedited export approval from 692 the U.S. government. RSA claims that RC2 and RC4 are 693 faster than DES when implemented in software. Several products 694 such as Lotus Notes, Netscape Navigator, and Apple's Open 695 Collaboration Environment make use of these algorithms. 696 It is recommended that a key length of at least 128 bits 697 be used when using RC2 and RC4. A key length of 128 698 bits would make a brute-force attack impossible now and 699 for the foreseeable future. 701 IDEA: The International Data Encryption Algorithm was 702 published in 1991. The symmetric algorithm is an 703 iterated block cipher with a 64-bit block size and a 128- 704 bit key size. The key length of IDEA is over twice that 705 of DES and is longer than triple-DES. The IDEA algorithm 706 is patented in both the United States and abroad. The 707 IDEA algorithm in CBC mode is used by PGP (Pretty Good 708 Privacy - a popular electronic mail security program) 709 for encryption. Individual users of PGP have a royalty 710 free license to use the IDEA algorithm. 712 There are many encryption algorithms that are secure and 713 can provide confidentiality for an EDI Interchange. For 714 interchanges that carry less value, 40-bit RC2 or 56-bit 715 DES are probably adequate. For more valuable 716 interchanges, use of Triple-DES, IDEA, or longer key 717 length RC2 or RC4 is recommended. 719 DES is currently in wide-spread use, and Triple-DES is 720 projected to be in wide-spread use, as the 56-bit DES 721 key limitation becomes less and less adequate. The DES 722 algorithm is available for implementation outside the 723 U.S., and the DES algorithm has been studied for a long 724 time, and has been found to be secure. RC2 and RC4 are 725 useful because they allow the security of the 726 encryption - the key length specification, to be 727 configurable. The RC2 and RC4 algorithms are 728 proprietary, but products incorporating these algorithms, 729 but limiting the key lengths to 40 bits or less, can be 730 exported outside the U.S. 732 IDEA is a newer algorithm and has not been studied as much as 733 DES. It has an adequate key-length, though it is not 734 configurable. Indications are that IDEA is a secure 735 algorithm and its use in PGP makes it the most widely 736 used encryption algorithm for Internet electronic mail. 738 3.3 Key Management - Symmetric Keys 740 3.3.1 Introduction and Description 742 The use of symmetric encryption is based on a shared 743 secret. Two trading partners using a symmetric 744 encryption algorithm must be able to do the following; 745 generate a random symmetric key and agree upon its use; 746 securely exchange the symmetric key with one another; 747 set up a process to invalidate a symmetric key that has 748 been compromised or needs changing. Each trading partner 749 would then need to do this with each and every one of 750 their trading partners. Management and distribution of 751 symmetric keys can become an insecure and cumbersome 752 process. 754 Pure symmetric key management schemes also have the 755 problem that origin authenticity cannot be proved. Since 756 two parties share a secret encryption key, any EDI 757 Interchange encrypted with a symmetric key, could have 758 been sent by either of the trading partners both of whom 759 have knowledge of the key. 761 Using public-key cryptography, the management of 762 symmetric keys is simplified and made more secure. 763 Trading partners do not need to agree on secret 764 symmetric keys as part of the trading partner 765 relationship. Public-key cryptography also solves the 766 origin authenticity problem that are inherent with pure 767 symmetric key management schemes. 769 By generating a unique symmetric encryption key for each 770 EDI Interchange, and using public key cryptography, 771 trading partners no longer need to secretly agree on a 772 shared symmetric key in the trading partner 773 relationship. A symmetric key can be randomly generated 774 by the software for each EDI Interchange between trading 775 partners. Since a unique symmetric key is generated for 776 each EDI Interchange, key maintenance is not needed. 777 Trading partners do not need to invalidate compromised 778 or expired keys. Each symmetric key is used only one 779 time. 781 Additional security is also realized using the method 782 described above; in the unlikely event that one of the 783 symmetric keys is compromised, only one EDI transaction 784 is affected, and not every transaction in the trading 785 partner relationship. Public-key encryption also 786 provides a secure way of distributing symmetric keys 787 between trading partners. Since only the receiving 788 trading partner has knowledge of her private asymmetric 789 key, she is the only one that can decrypt the symmetric 790 key encrypted with her public asymmetric key -- and is 791 thus the only one who can use the symmetric key to 792 decrypt the EDI Interchange. 794 To impart confidentiality to an EDI Interchange which 795 trading partner ABC sends to trading partner XYZ, the 796 following steps would be performed: 798 1). The EDI Translator outputs the EDI Interchange. 800 2). A random symmetric key of the specified length 801 is generated. 803 3). The EDI Interchange is encrypted using the 804 randomly generated symmetric key with the chosen 805 encryption algorithm. 807 4). The random symmetric key is then encrypted 808 using XYZ's, the receiving trading partner's, 809 public asymmetric key. 811 5). The encrypted symmetric key and encrypted EDI 812 Interchange are then enveloped and sent to the 813 trading partner. 815 On the receiving side, the following steps would be 816 performed: 818 1). The symmetric key is decrypted using XYZ's 819 private asymmetric key. 821 2). The decrypted symmetric key is then used to 822 decrypt the EDI Interchange. 824 3). The decrypted EDI Interchange is then routed to 825 the EDI translator. 827 3.3.2 Needs 829 A method to manage the symmetric encryption keys used in 830 encrypting EDI Interchanges. The method should simplify 831 the generation, maintenance, and distribution of the 832 symmetric encryption keys. The method should also 833 provide a secure channel for distributing the symmetric 834 encryption keys between trading partners. 836 3.3.3 Issues 838 Choose a public-key encryption algorithm that 839 facilitates key management of the symmetric 840 encryption keys. The symmetric encryption keys 841 should be generated on the fly for each EDI 842 Interchange. 844 When choosing a public-key encryption algorithm, 845 the following criteria should be considered; how 846 secure the algorithm is; how fast implementations 847 of the algorithm are; the availability of the 848 algorithms for international as well as domestic 849 use; the availability of APIs and tool kits in 850 order to implement the algorithms; and the 851 frequency of the use of the algorithm in 852 existing implementations. 854 Sufficient key lengths must be chosen with 855 regard to the value of the EDI Interchange so that 856 brute-force attacks are not worth the time or 857 effort compared to the value of the Interchange. 859 3.3.4 Recommendations 861 RSA is a public-key encryption algorithm that has 862 become a de facto standard in its use for key 863 management. Its use is recommended in managing and 864 distributing symmetric encryption keys when doing EDI 865 over the Internet. The RSA public-key algorithm also 866 has the advantage that it can be used freely outside the 867 U.S. 869 The mathematics of RSA are complicated, but is based 870 on the difficulty in factoring large prime numbers. A 871 public-key is generated by multiplying two large prime 872 numbers together, deriving the private key from the 873 public key involves factoring the large prime number. If 874 the prime is large enough, this becomes an impossible 875 task. The RSA key length is configurable, and is 876 recommended to be at least 512 bits (154 digits long), 877 and preferably 1024 bits (or 308 digits long) or longer. 879 3.4 Key Management - Public and Private Keys 881 3.4.1 Introduction and Description 883 The use of public-key cryptography to simplify the 884 management of the symmetric encryption keys presents the 885 user with two problems; protecting the private key, and 886 binding a trading partner's identity to his public key. 887 Most likely the user will never know what his private 888 key is. The software will generate a random private key, 889 encrypt it, and store it in a file or database. The 890 private key is accessed indirectly by the user through 891 access to the software. User access to the software is 892 generally controlled by a password, pass-phrase, and/or 893 certain access rights. These are internal security 894 policies, and are company specific. It is important to 895 control the access to the private key, since any 896 unauthorized access can lead eventually to the 897 revocation of the corresponding public key. 899 3.4.2 Public Keys 901 A public key is used by an originating trading partner 902 to encrypt a symmetric key, and as we'll discuss later, 903 by a receiving trading partner to verify authenticity of 904 the originator. Trading partners exchange public keys 905 using a public key certificate. 907 A public key certificate is defined in the X.509 908 standards, and is a binding of an entity's 909 distinguished name (a formal way for identifying someone 910 or something in the X.500 world, in our case it would be 911 a trading partner) to a public key. A certificate also 912 contains the digital signature of the issuer of the 913 certificate, the identity of the issuer of the 914 certificate, and an issuer specific serial number, a 915 validity period for the certificate, and information to 916 verify the issuer's digital signature. Certificate 917 issuers are called certification authorities, and are 918 trusted by both trading partners. In essence, a 919 certificate is a digitally notarized binding of a trading 920 partner to its public key. 922 3.4.3 Needs 924 Adoption of a trust model and use of certification 925 authorities for issuing commercial grade/class 3 926 certificates. Each trading partner must choose a certification 927 authority that the other trading partner trusts. 929 Formats and protocols for requesting, revoking, and exchanging 930 certificates and certificate revocation lists between 931 certification authorities and trading partners, as well 932 as between the trading partners themselves. 934 3.4.4 Issues 936 The lack of wide-spread use of certification authorities 937 in real world commercial applications, and the need to do 938 additional profiling of X.509v3 certificates and standards 939 for requesting, revoking, and exchanging certificates and 940 certificate revocation lists. 942 3.4.5 Recommendations 944 3.4.5.1 Near Term Approach 946 Since there already exists a trust relationship between 947 EDI trading partners, until use of certification authorities 948 become more established and better profiling is done 949 with X.509v3 certificates, it is recommended that the 950 trading partners self-certify each other if an agreed upon 951 certification authority is not used. 953 In the near term, the exchange of public keys and 954 certification of these keys must be handled as part of 955 the process of establishing a trading partnership. 956 The UA and/or EDI application interface must maintain 957 a database of public keys used for encryption and 958 authentication, in addition to mapping between the EDI 959 trading partner ID and the RFC822 e-mail address. The 960 procedures for establishing a trading partnership and 961 configuring the secure EDI messaging system might vary 962 among trading partners and software packages. 964 It is still highly recommended that trading partners 965 acquire a X.509v3 certificate from a certificate authority 966 trusted by both trading partners. The process of 967 acquiring a certificate varies among the various 968 certificate authorities. It is recommended that trading 969 partners exchange certificates using the formats 970 and protocols specified by PKCS#7 and S/MIME. 972 3.4.5.1 Long Term Approach 974 In the long term, additional Internet-EDI standards 975 will need to be developed to simplify the process of 976 establishing a trading partnership, including the 977 acquisition, revocation, exchange, and third party 978 authentication of certificates. 980 PKCS#7 and PKCS#10 as well as the standards being 981 developed by the IETF-pkix (public key infrastructure 982 X.509 work-group) need to be evaluated and adopted 983 as standards for Internet EDI. 985 3.5 Content Integrity 987 3.5.1 Introduction and Description 989 Encryption guarantees the confidentiality of an EDI 990 Interchange. Content integrity guarantees that the 991 receiving trading partner gets the EDI Interchange in 992 its originally sent state. Content integrity assures 993 that no modifications -- additions, deletions, or changes 994 -- have been made to the EDI Interchange when it is in 995 transit between trading partners. 997 Content integrity is achieved if the sender includes 998 with the EDI Interchange, an integrity control value. 999 This value can be computed by using an appropriate 1000 cryptographic algorithm to "fingerprint" the EDI 1001 Interchange. These cryptographic algorithms are called 1002 one-way hash functions or message integrity checks. 1003 Similar to encryption, a one-way hash function turns the 1004 intelligible EDI plain-text into something unintelligible. 1006 Unlike encryption algorithms however, one-way hash 1007 functions can't be decrypted. One-way hash functions 1008 are constructed so the probability is infinitely small 1009 that some arbitrary length piece of plain-text can be 1010 hashed to a particular value, or that any two pieces of 1011 plain-text can be hashed to the same value. One-way hash 1012 values are usually from 112 to 160 bits long. The 1013 longer the hash value, the more secure it is. 1015 One-way hash functions don't require a key, and the 1016 algorithm used must be agreed upon by the trading 1017 partners. To insure content integrity, the sending 1018 trading partner needs to calculate a one-way hash value 1019 of the EDI Interchange. This value is unique and 1020 "fingerprints" the EDI Interchange. The sending trading 1021 partner sends the hash value along with the EDI 1022 Interchange. The receiving trading partner using the 1023 same one-way hash function calculates the hash value for 1024 the received EDI Interchange. If the received hash value 1025 matches the calculated hash value, then the receiving 1026 trading partner knows that the EDI Interchange has not 1027 been tampered with. 1029 3.5.2 Needs 1031 Choice of a one-way hash algorithm to calculate the hash 1032 value required to insure content integrity. 1034 3.5.3 Issues 1036 The one-way hash algorithm should be secure, publicly 1037 available, and should produce hash values of at least 1038 128 bits. 1040 3.5.4 Recommendations 1042 SHA-1 is the Secure Hash Algorithm, a one-way hash function 1043 invented by the National Security Agency. SHA-1 produces 1044 a 160-bit hash value that makes a brute-force attack 1045 on it not feasible. It is being recommended by most 1046 e-mail security programs and other security specifications, 1047 as weaknesses are being found in MD5. 1049 MD5 is a one-way hash function that is publicly 1050 available, and produces a 128 bit hash value called a 1051 Message Digest. It is currently widely used by 1052 most e-mail security programs, such as PEM, PGP, and 1053 S/MIME. 1055 The recommendation is for all new implementations to 1056 use SHA-1 outgoing, but to continue to accept MD5 1057 incoming, since there already exist many MD5 1058 implementations. 1060 3.6 Authentication and Non-Repudiation of Origin 1062 3.6.1 Introduction and Description 1064 Encryption guarantees confidentiality. Applying a one- 1065 way hash function guarantees content integrity. Both 1066 authentication and non-repudiation of origin guarantee 1067 the identity of the sender of the EDI Interchange. Non- 1068 repudiation of origin, identifies the original sender, 1069 and is the same as authentication when the EDI 1070 Interchange is sent point-to-point, i.e. when there is 1071 no forwarding involved. Authentication and non- 1072 repudiation of origin discourages any spoofing attacks 1073 that may occur while the EDI Interchange is in transit 1074 between the trading partners. 1076 Both authentication and non-repudiation of origin are 1077 accomplished using digital signatures. A digital 1078 signature is another application of public-key 1079 cryptography, and is explained in more detail in the 1080 following paragraphs. 1082 Up to this point, a receiving trading partner's public- 1083 key has been used to encrypt a symmetric key, and this 1084 symmetric key could only be decrypted by the receiving 1085 trading partner's private key. However the roles of the 1086 private and public keys can be reversed, so that you 1087 encrypt with the private key, and decrypt with the 1088 public key. Again the keys are reciprocal, if encryption 1089 is done with the private key, decryption can only be 1090 done with the public key. 1092 Since only trading partner ABC knows her own private- 1093 key, only trading partner ABC can encrypt something with 1094 that private-key. Encryption with a private key 1095 therefore has the effect of uniquely identifying the 1096 person or entity doing the encryption. It is in effect, 1097 a digital signature. Since ABC's public-key is known to 1098 all her trading partners, they can all decrypt something 1099 encrypted with ABC's private-key. Successful decryption 1100 using ABC's public-key of something encrypted with 1101 ABC's private key has the effect of authenticating 1102 ABC as the trading partner that did the encrypting, 1103 or in other words it identifies ABC as applying the 1104 digital signature. 1106 ABC cannot deny that she did not do the encryption, since 1107 she is the only one with knowledge of her private key. In 1108 this way, non-repudiation of origin is achieved. 1110 So what should a trading partner sign or encrypt with 1111 her private-key to guarantee authentication and non- 1112 repudiation of origin? Remember, public-key encryption 1113 algorithms are not meant to encrypt something very 1114 large, they are too slow for that. The symmetric key is 1115 encrypted with a public-key, and encrypting this with a 1116 private-key is not recommended, as this would allow 1117 other than the authorized recipient to decrypt the EDI 1118 Interchange. Since a one-way hash value is pretty small, 1119 usually only between 112-160 bits long, it is a natural 1120 choice for what can be digitally signed. If the message 1121 integrity value is signed with a private key, then not 1122 only could authentication and non-repudiation of origin 1123 be guaranteed, but message integrity as well. 1125 3.6.2 Needs 1127 Choice of a digital signature algorithm. 1129 3.6.3 Issues 1131 When choosing a digital signature algorithm, the 1132 following criteria should be considered; how secure the 1133 algorithm is; how fast implementations of the algorithm 1134 are; the availability of the algorithms for 1135 international as well as domestic use; the availability 1136 of APIs and tool kits in order to implement the 1137 algorithms; and the frequency of the use of the 1138 algorithm in existing implementations. 1140 Sufficient key lengths must be chosen with regard to the 1141 value of the EDI Interchange so that brute-force attacks 1142 are not worth the time or effort compared to the value 1143 of the Interchange. 1145 3.6.4 Recommendations 1147 In addition to using the RSA public-key algorithm to 1148 encrypt keys, it is also recommended that RSA be used 1149 for digital signatures as well. 1151 Unlike encryption algorithms, strong digital signature (greater 1152 than 40 bit key lengths) algorithms can be freely exported 1153 outside the U.S. 1155 3.7 Signed Receipt or Non Repudiation of Receipt 1157 3.7.1 Introduction and Description 1159 The signed receipt (or the Non Repudiation of 1160 Receipt), is a receipt acknowledgment sent by the 1161 receiving trading partner to the sending trading partner. 1162 The signed receipt is used to solve the following 1163 issues when doing EDI over the Internet: 1165 1). Lack of mailbox delivery notification within the 1166 Internet standards, though these are currently 1167 being addressed within RFCs 1891-1894. 1169 2). Provide the equivalent of VAN mailbox delivery 1170 notification. 1172 3). Provide the equivalent of VAN mailbox pick-up 1173 notification. 1175 4). Provide the equivalent of VAN mailbox 1176 authentication. 1178 5). Detect the situation where EDI Interchanges are 1179 maliciously deleted, or are not delivered by the 1180 transport. 1182 Receipt by the sender of a signed receipt, is an implicit 1183 acknowledgment of successful mailbox delivery. It is 1184 also an explicit acknowledgment that the Interchange was 1185 retrieved from the mailbox -- pick-up notification. By 1186 having the receiver sign the receipt, it authenticates 1187 that the intended receiver picked up the EDI Interchange -- 1188 mailbox authentication -- and that the intended receiver 1189 verified the integrity of the EDI Interchange, and the 1190 identity of the sender. By returning the original message id 1191 and the one-way hash value of the received message back in 1192 the signed receipt, the sender can reconcile the acknowledged 1193 EDI Interchange with what was sent. 1195 3.7.2 Needs 1197 Define the format and protocol for the signed receipt 1198 so that it provides the following: 1200 1). Implicit acknowledgment of mailbox delivery of 1201 the EDI Interchange to the recipient. 1203 2). Explicit acknowledgment that the receiver has 1204 authenticated the sender and verified the 1205 integrity of the sent EDI Interchange. 1207 3). Guarantees non-repudiation of receipt when the 1208 signed receipt is digitally signed by the receiving 1209 trading partner. 1211 4). Provide information in the signed receipt so 1212 it can be used for tracking, logging, and 1213 reconciliation purposes. 1215 The re-transmission timer, and retry count to detect 1216 lost Interchanges should be recommended, but needs to be 1217 configurable. Additionally, it should be specified what 1218 the receiver should do when it receives duplicate 1219 Interchanges, and what the sender should do when it 1220 receives duplicate receipt acknowledgments. 1222 3.7.3 Recommendations 1224 The syntax for a signed receipt should not be specific 1225 to EDI content, since many of the uses of a signed receipt 1226 can be broadly applied to other MIME encapsulated objects. 1227 It is recommended that the results of the IETF receipt 1228 working group be adopted for use in implementing a signed 1229 receipt. The receipt working group has published an Internet 1230 draft -- draft-ietf-receipt-mdn-01, which can be obtained 1231 off of the IETF World Wide Web site. The EDIINT working 1232 group is working with the receipt working group to 1233 specify additional disposition-field values, as well as 1234 specification of how the MDN (message disposition 1235 notification) should be used within an EDI environment. 1236 Specifically, within an EDI environment, requests for 1237 message disposition requests cannot be silently 1238 ignored. In addition, if non-repudiation of receipt is 1239 agreed to by the trading partners, the message integrity 1240 check that is verified by the receiving trading partner 1241 must be returned to the originating trading partner 1242 in the MDN. 1244 The time-out and retry values for the signed receipt should 1245 be configurable. Duplicates should be checked by the UA 1246 and discarded. 1248 The signed receipt should be implemented using a 1249 MIME multipart/signed with the MDN as the first part 1250 of the multipart/signed, and with the digital signature 1251 signed over the MDN. 1253 3.8 EDI Object Boundaries and Transaction Privacy 1255 3.8.1 Introduction and Description 1257 The specification by this work group applies to the EDI 1258 Interchange level, and not the group or document level. 1259 Any security services, packaging, transport, or non- 1260 repudiation services are assumed to be applied to an EDI 1261 Interchange. Unlike the X12.58 and UN/EDIFACT 9735-5 and 1262 9735-6 security standards, the security services cannot 1263 be applied at a group or document level. The purpose of 1264 the specification is to move these services out of the 1265 translator, and into the "communications" subsystem. The 1266 "communications" subsystem should know as little about 1267 the structure of the EDI data as possible. 1269 The entire EDI Interchange including the enveloping 1270 headers (ISA/IEA or UNA/UNB/UNZ) are also encrypted. 1271 Since the routing of the EDI Interchange is through the 1272 Internet, and not a VAN, the sender/receiver ids are not 1273 used in mailbox routing, so the EDI envelops can be 1274 encrypted when sending EDI over the Internet. 1276 3.8.2 Gateway Functions 1278 Situations exist whereby a VAN, or internal gateway, in 1279 order to route an EDI Interchange received on the 1280 Internet, will need to be able to access the information 1281 in the EDI envelope. The enveloping information as well 1282 as other information useful to gateways may need to be 1283 copied and sent as a separate MIME body part. A new 1284 MIME content should be defined for this type of information. 1286 3.9 Syntax and Protocol for Specifying Cryptographic 1287 Services 1289 3.9.1 Introduction and Description 1291 Once cryptographic services are applied to EDI 1292 Interchanges, then the formats and protocols must be 1293 specified on how the cryptographic information is 1294 conveyed during the EDI message exchange. Encryption 1295 algorithm information, one-way hash algorithm 1296 information, symmetric keys, initialization vectors, one- 1297 way hash values, public-key certificates, need to be 1298 enveloped and sent along with the EDI Interchange. 1300 3.9.2 Needs 1302 A syntax and protocol for specifying EDI Interchanges that 1303 have had cryptography applied to it needs to be specified. 1304 Several suitable standards already exist, so it is preferable 1305 to choose one of these existing standards rather than 1306 specifying a new one. 1308 3.9.3 Issues 1310 The syntax should be transport independent so it can be 1311 used with different Internet transports. The standard 1312 should have broad support, and implementations should be 1313 available. Finally it should be international in nature. 1315 3.9.4 Recommendations 1317 The IETF EDIINT working group has put together a matrix 1318 comparing many of the different ways that EDI with 1319 cryptography applied to it can be transmitted. The use 1320 of S/MIME and PGP/MIME (version 3.0 with the elkins 1321 draft) are both viable alternatives. Each has its 1322 strengths and weaknesses as the comparison matrix brings 1323 out. 1325 The S/MIME specification allows signed and encrypted 1326 and signed to be distinguished. The signatories in an 1327 S/MIME signed and encrypted content type can be 1328 distinguished, which in certain EDI and electronic 1329 commerce situations is not acceptable. S/MIME specifies 1330 40 bit RC2 as the default encryption algorithm and key 1331 length. In some applications neither this default 1332 algorithm or key length are acceptable. S/MIME can 1333 accommodate other security algorithms and key lengths 1334 such as those recommended in section 3.3.2 however. 1336 PGP/MIME supports a set profile of security algorithms 1337 and some user configurable key lengths. PGP/MIME does 1338 not have the signatory problem as described above for 1339 S/MIME. However, PGP/MIME does not give the user as much 1340 flexibility in choosing algorithms and key lengths, 1341 although the security profile used by PGP/MIME is more 1342 than adequate to insure confidentiality, non-repudiation 1343 of origin, and message integrity. 1345 4.0 Tracking and Error Handling Basics 1347 4.1 Introduction 1349 It's important to recognize that the Value Added Networks 1350 provide some inherent tracking mechanisms between 1351 EDI trading partners. In Internet EDI, the ISPs provide 1352 a certain level of transmission tracking as does the 1353 TCP/IP protocols themselves. However, not all the 1354 tracking provided by EDI VANs are completely covered 1355 by the current TCP/IP protocol suite or ISP tracking. 1356 The new tracking information associated with the additional 1357 security requirements and support of signed receipts, 1358 must be implemented in the EDI UA, in order for Internet 1359 EDI to be as traceable as VAN EDI. 1361 Aside from the communications between companies, 1362 "tracking" touches many other points within the trading 1363 relationship. This is where the use of 997 functional 1364 acknowledgments come in, the EDIFACT CONTRL message, and 1365 the common translator tracking of sequential group 1366 control numbers. All of this needs to be considered in 1367 Internet EDI tracking. In addition, some recent 1368 developments within S/MIME warrant some analysis -- 1369 "positive acknowledgment", which refers to mail response 1370 not just if the delivery failed, but also if it 1371 succeeded. 1373 The following is a list of the common tracking information needed 1374 when sending and receiving EDI Interchanges between trading partners: 1376 1). Transmission successfully translated from 1377 internal format to EDI standard format. 1379 2). Transmission successfully encoded, signed, 1380 encrypted, and sent.(The equivalence of transmission 1381 successfully received by the VAN.) 1383 3). Transmission successfully delivered to 1384 the recipient's mailbox.(The equivalence of a VAN 1385 delivery acknowledgment that the sent transmission 1386 has been forwarded to the receiver's VAN mailbox.) 1388 4). Transmission successfully picked-up by the 1389 recipient. (The equivalence of a VAN mail-box 1390 pick-up acknowledgment.) 1392 5). Transmission successfully translated by the 1393 receiver. (The EDI Interchange was determined to be 1394 syntactically correct.) 1396 6). Detection and recovery of delayed or lost 1397 transmissions. 1399 7). Detection and handling of duplicate 1400 transmissions. 1402 The following section addresses in what components the 1403 new Internet EDI tracking information must be maintained, 1404 and discusses how this new tracking information relates 1405 to the tracking information kept by the EDI application. 1407 4.2 Transmission Successfully Translated From 1408 Internal Format to Standard EDI Format 1410 4.2.1 Needs 1412 There needs to be a facility by which a sender can 1413 assure that the EDI transmission was correctly 1414 translated and prepared for outbound transmission. 1416 4.2.2 Recommendations 1418 This is standard functionality for most if not all EDI 1419 translators. This should NOT be required functionality 1420 of an EDI UA. 1422 4.3 Transmission Successfully Encoded, Encrypted, Signed and 1423 Sent 1425 4.3.1 Needs 1427 There needs to be a facility by which a sender can be 1428 assured that an EDI transmission was successfully 1429 encoded, encrypted, signed, and sent. 1431 4.3.2 Recommendations 1433 The tracking of the success or failure of the security 1434 services required for Internet EDI must be maintained by 1435 the EDI UA. 1437 The EDI UA needs to be able to identify the transmission 1438 by its interchange control #, AND a user defined value, 1439 if desired. 1441 4.4 Transmission Successfully Delivered to the Recipient's 1442 Mailbox 1444 4.4.1 Needs 1446 There needs to be a facility by which a sender can be 1447 assured that an EDI transmission was successfully 1448 delivered to a recipient's mailbox. 1450 4.4.2 Recommendations 1452 This type of tracking information is kept by the UA and 1453 is returned to the sender as a delivery notification. The 1454 delivery notification is specified in RFC1891-1894. 1456 4.5 Transmission Successfully Received 1458 4.5.1 Needs 1460 There needs to be a facility by which a sender of a 1461 transmission can be assured that the transmission was 1462 correctly received by the intended receiver. 1464 4.5.2 Recommendations 1466 This type of tracking information is kept by the EDI UA and 1467 is returned to the sender as a signed receipt. (See section 1468 3.7.3 for a discussion about signed receipts.) 1470 Note: The X.12 997 or EDIFACT CONTRL message can also provide 1471 the equivalent of an implicit transmission received 1472 acknowledgment. However, the use of signed receipts 1473 is still recommended for the following reasons: 1475 * The implied success of the receiver's decryption 1476 through the receipt of a legible 997, binds the 1477 certificate to a control ID only (997) and not to 1478 the actual data (NRR). 1480 * Translators are very different, and the CONTRL 1481 message isn't supported by all EDI translators 1482 or is it in widespread use yet. 1484 4.6 Transmission Successfully Translated by 1485 the Receiver 1487 4.6.1 Needs 1489 There needs to be a facility for the sender to be 1490 assured that the receiver could "understand" (in EDI 1491 terms) the transmission. 1493 4.6.2 Recommendations 1495 This should NOT be tracked by the EDI UA, following our 1496 recommendation for object boundaries. 1498 The Functional acknowledgment 997, and the EDIFACT 1499 CONTRL serve this exact purpose - this should be tracked 1500 by the EDI translator. 1502 4.7 Detection and Recovery of Delayed or Lost Transmissions 1504 4.7.1 Needs 1506 There needs to be a facility by which a sender can 1507 detect sent transmissions that have not been 1508 acknowledged as correctly received, by a specified, 1509 configurable, period of time, and be able to configure 1510 actions accordingly. 1512 4.7.2 Recommendations 1514 1). The use of time stamps for each of the two events: 1516 * MIME message sent. 1518 * Signed Receipt received. 1520 2). The ability to automatically detect transmissions 1521 that have failed the time trigger. 1523 3). The ability to configure automatic actions based on 1524 failure. Actions may include: 1526 * Re-transmit: If re-transmitted, the receiving 1527 UA needs to be able to detect the second 1528 transmission as a duplicate and discard it. 1530 * Alert/Report. 1532 * Ignore/delete - this option may be chosen by 1533 someone that has decided to track only at the EDI 1534 translator level through 997/CNTRL. 1536 4.8 Detection and Handling of Duplicate Transmissions 1538 4.8.1 Need 1540 There needs to be a facility by which a receiver of EDI 1541 transmissions is able to detect different types of 1542 duplicate transmissions, and handle them the way they 1543 should be handled. First, translator initiated 1544 duplicates should NOT be halted in any way - we should 1545 assume that translators will handle that level. In 1546 other words, there should be no checking of ISA control 1547 numbers by the UA. Secondly, the use of a re- 1548 transmission feature in attempts to deliver 1549 transmissions quickly, should allow for a UA to identify 1550 duplicate transmissions generated by the sending UA, and 1551 discard of duplicate transmissions after the first has 1552 been received. 1554 4.8.2 Recommendations 1556 The ability to pass through translator initiated re- 1557 transmissions to the receiving translator without a 1558 hitch. This means EDI related control numbers, such as 1559 the ISA control number, should not be checked by the EDI UA. 1561 Appendix A - A Comparison of Security Protocols 1563 Version: 3.0 1565 Date: July 18, 1996 1567 Sources: 1569 EDIINT- EDI over Internet, Internet Mail Consortium Workshop 1570 data, Chuck Shih, Steve Dusse, David Darnell, Kent 1571 Landfield, David Chia, Rik Drummond, Jeff Cook, Alan Cox, 1572 Ralph Levien, Russ Housley, and many others. 1574 1) Exportable Out Side Of The USA 1575 ------------------------------------ 1576 PGP V3.0 1577 * PGP is already outside the USA and except for 1578 countries that prohibit encrypted messages with long 1579 key lengths (instead of just restricting the import of 1580 long key length algorithms) PGP long key length 1581 messages can be read. This is included in the PGP 1582 ViaCrypt documentation. 1584 * No since the encryption algorithm specified is IDEA. 1586 S/MIME 1587 * Has the 40 and 56 bit export restrictions if RC2 or 1588 RC4 is used for encryption. 1590 MOSS 1591 * Not with full key length 1592 * Depends on the data encryption algorithm used. RFC 1593 1423 specifies DES in CBC mode, which is not 1594 exportable. Moss however allows the use of variety of 1595 cryptographic algorithms. 1597 MSP 1598 * Depends on the key management and data encryption 1599 algorithm used. MSP allows the use of variety of 1600 cryptographic algorithms. 1602 2) Easily Integrated Into Products In A User Transparent 1603 Manner 1604 ------------------------------------------------------------ 1605 PGP V3.0 1606 * Maybe in V.30. Not in earlier versions. 1607 * There seems to be general disagreement on this one. 1609 S/MIME 1610 * Yes. 1612 MOSS 1613 * Do not know. 1615 MSP 1616 * Yes. Support for signed receipts may require GUI 1617 enhancements. 1619 3) Fully Compatible With Like Versions World Wide 1620 ----------------------------------------------------- 1621 PGP V3.0 1622 * PGP version 2.6 is compatible with any earlier 1623 versions. Version 3.0 should be also. 1625 S/MIME 1626 * RSA has an active interoperability program in place 1627 * Implementations to the spec should guarantee 1628 interoperability. 1630 MOSS 1631 * Moss does not require any particular security 1632 algorithm. Moss provides the means to identify which 1633 algorithms are used for each message. A suite of 1634 algorithms is defined in RFC 1423. 1636 MSP 1637 * Implementations to the spec should guarantee 1638 interoperability when the same cryptography is used. 1640 4) Current Implementation Status 1641 ---------------------------------- 1642 PGP V3.0 1643 * Version 3.0 is due out 4Q96. 1644 * Version 2.6 is available. 1645 * Qualcomm. 1646 * Premail. 1647 * Michael's PGPMIME. 1649 S/MIME 1650 * Two companies have implemented several others have 1651 committed. Twelve companies currently committed to 1652 implementing in a pilot sponsored by Commercenet. 1653 * Products and development tool-kits currently shipping. 1655 MOSS 1656 * TIS, Innosoft and SupplyTech. 1658 MSP 1659 * SPYRUS, Nortel, Xerox, LJL, BBN, and J. G. Van Dyke 1660 all have implementations. 1661 * Product is shipping. 1662 * In use for military messages. 1664 5) Confidentiality 1665 ------------------ 1666 PGP V3.0 1667 * Yes 1669 S/MIME 1670 * Yes 1672 MOSS 1673 * Yes 1675 MSP 1676 * Yes 1678 6) Signature 1679 ------------ 1680 PGP V3.0 1681 * Yes 1683 S/MIME 1684 * Yes 1686 MOSS 1687 * Yes 1689 MSP 1690 * Yes 1692 7) Return Receipt 1693 ------------------ 1694 PGP V3.0 1695 * No 1697 S/MIME 1698 * No 1700 MOSS 1701 * No 1703 MSP 1704 * Yes - supports non-repudiation with proof of delivery. 1706 8) Delivery Notification 1707 ------------------------- 1708 PGP V3.0 1709 * Via MIME extensions RFC1891-94. 1711 S/MIME 1712 * Via MIME extensions RFC1891-94. 1714 MOSS 1715 * Via MIME extensions RFC1891-94. 1717 MSP 1718 * Via MIME extensions RFC1891-94. 1720 9) Authentication 1721 ----------------- 1722 PGP V3.0 1723 * Yes 1725 S/MIME 1726 * Yes 1728 MOSS 1729 * Yes 1731 MSP 1732 * Yes 1734 10) Multimedia 1735 -------------- 1736 PGP V3.0 1737 * Yes 1739 S/MIME 1740 * Yes 1742 MOSS 1743 * Yes 1745 MSP 1746 * Yes 1748 11) Integrity 1749 ------------- 1750 PGP V3.0 1751 * Yes 1753 S/MIME 1754 * Yes 1756 MOSS 1757 * Yes 1759 MSP 1760 * Yes 1762 12) Trust Model (Key Management & Revocation) 1763 ------------------------------------------------- 1764 PGP V3.0 1765 * PGP 3.0 will have hierarchical model of public-key 1766 certificates. 1767 * RSA used for key management in current versions. 1768 * Ad hoc key revocation. 1770 S/MIME 1771 * RSA based using X.509 all versions. 1772 * NT's Entrust will be usable with this product very 1773 soon. 1775 MOSS 1776 * Both RSA and DES based key management. 1778 MSP 1779 * X.509 all versions. 1781 13) Certificate (Information, Format, Distribution) 1782 ------------------------------------------------------ 1783 PGP V3.0 1784 * Yes using proprietary "Key rings". Not clear what V3 1785 will use. 1787 S/MIME 1788 * Yes using X.509 - all versions. 1790 MOSS 1791 * Yes with optional X.509. 1793 MSP 1794 * Yes using X.509. 1796 14) Infrastructure Overhead 1797 ---------------------------- 1798 PGP V3.0 1799 * Base 64 encoding. 1801 S/MIME 1802 * ASN.1 - BER and DER encoding. 1803 * Base 64 encoding. 1805 MOSS 1806 * Base 64 encoding. 1808 MSP 1809 * Base64 encoding and ASN.1 encoding. 1811 15) Envelope Type 1812 ------------------ 1813 PGP V3.0 1814 * MIME/ ASCII 1816 S/MIME 1817 * PKCS #7 and MIME 1819 MOSS 1820 * MIME/ ASCII 1822 MSP 1823 * MIME /ASN.1 1825 16) Envelope / Structure Specification (ASN1 or ASCII) 1826 ------------------------------------------------------- 1827 PGP V3.0 1828 * ASCII 1830 S/MIME 1831 * ASN.1 and ASCII 1833 MOSS 1834 * ASCII 1836 MSP 1837 * ASN.1 1839 17) Algorithms Supported (List Them: Encryption, Key 1840 Management, One Way Hash, Digital Signature, Key Lengths 1841 For Encryption) 1842 ------------------------------------------------------------ 1843 - 1844 PGP V3.0 1845 * RSA and IDEA in pre 3.0. 1846 * Diffie Hellman and DSA in Ver. 3.0. 1847 * IDEA in CBC. 1848 * MD5 & RSA. 1849 * A 128 for casual grade, 512 commercial grade, 2048 1850 military grade. 1851 * A 128 bit IDEA key length. 1853 S/MIME 1854 * RSA. 1855 * RC2, RC4 and RC5. 1856 * MD5 & RSA. 1857 * SHA-1. 1858 * Note: S/MIME like Moss is a format and allows any type 1859 of algorithm to be specified. RSA of course specifies 1860 their own algorithms. 1861 * Triple-DES/RC5. 1863 MOSS 1864 * DES in CBC. 1865 * RSA or DES. 1866 * MD2/MD5 and RSA. 1867 * A 56 bit key lengths for DES. 1868 * FORTEZZA. 1869 * Note: Moss like S/MIME allows a variety of 1870 cryptographic algorithms to be used. The suite of 1871 algorithms defined above are found in RFC 1423. 1873 MSP 1874 * Algorithm independent. Implementations exist using: 1875 * RSA & DES. 1876 * FORTEZZA (DSS SHA-1, KEA, Skipjack). 1878 18) Common Algorithms With EDIFACT AUTACK List Of Codes 1879 ----------------------------------------------------------- 1880 PGP V3.0 1881 * RSA (yes). 1882 * IDEA (yes). 1883 * DSA (yes). 1884 * MD5 (yes). 1886 S/MIME 1887 * RSA (yes). 1888 * RC2 and RC4 (yes). 1889 * DES (yes). 1890 * MD5 (yes). 1892 MOSS 1893 * RSA (yes). 1894 * DES (yes). 1895 * MD5 (yes). 1897 MSP 1898 * RSA (yes). 1899 * DES (yes). 1900 * MD5 (yes). 1901 * DSS (yes). 1902 * SHA-1 (yes). 1904 19) Coexistence With Others For Reception (signature not 1905 readable) of MIME Multipart/Signed Data 1906 ------------------------------------------------------------ 1907 PGP V3.0 1908 * Yes V3.0. 1910 S/MIME 1911 * Yes, but user selectable. 1913 MOSS 1914 * Yes. 1916 MSP 1917 * Yes, if used with MIME encapsulation (see . 1920 20) Signed Message Body Readable By RFC822/ MIME Readers 1921 ------------------------------------------------------------ 1922 - 1923 PGP V3.0 1924 * Should be in V3.0. 1926 S/MIME 1927 * Yes - if one of the options multipart/signed is used. 1929 MOSS 1930 * Yes. 1932 MSP 1933 * Yes, if used with MIME encapsulation. 1935 21) Signature Separate From Signed Document 1936 ---------------------------------------------- 1937 PGP V3.0 1938 * Yes. 1940 S/MIME 1941 * No. 1943 MOSS 1944 * Yes 1946 MSP 1947 * Yes 1949 22) Backward Compatibility 1950 --------------------------- 1951 PGP V3.0 1952 * To PGP. 1954 S/MIME 1955 * To PEM. 1957 MOSS 1958 * To PEM. 1960 MSP 1961 * No. 1963 23) Uses Proprietary Algorithms? 1964 --------------------------------- 1965 PGP V3.0 1966 * Ver 3.0 will use Diffie-Hellman with expiring patents 1967 in 1997. Ver 3.0 will use DSA (Digital Signature 1968 Algorithm invented at the NSA). 1970 S/MIME 1971 * Yes, but it supports different options. 1973 MOSS 1974 * YES, but it supports different. 1976 MSP 1977 * It supports both standard (FIPS and X9) as well as 1978 proprietary algorithms. 1980 24) Adequate Security For EDI Purposes 1981 ----------------------------------------- 1982 PGP V3.0 1983 * Yes. 1985 S/MIME 1986 * Yes. 1988 MOSS 1989 * Yes. 1991 MSP 1992 * Yes. 1994 25) Scaleable 1995 ------------- 1996 PGP V3.0 1997 * Not enough experience to tell. The current trust model 1998 will not scale well. 2000 S/MIME 2001 * Not enough experience to tell. 2003 MOSS 2004 * Not enough experience to tell. 2006 MSP 2007 * Yes. 2009 26) Solid MIME Integration 2010 --------------------------- 2011 PGP V3.0 2012 * V3.0 - yes. 2014 S/MIME 2015 * Yes - but it mixes PKCS technology with MIME. 2017 MOSS 2018 * Yes. 2020 MSP 2021 * Yes (see . 2023 27) Variable Key Sizes Supported 2024 ---------------------------------- 2025 PGP V3.0 2026 * No. 2028 S/MIME 2029 * Yes, 40- 128 bit. 2030 * Symmetric 512-2048 bit RSA. 2032 MOSS 2033 * Yes. 2035 MSP 2036 * Yes. 2037 * Symmetric (DES = 56 bits; SKIPJACK = 80 bits).. 2038 * Signature (DSS = 512 .. 1024 bits; RSA = 512 .. 2048 2039 bits). 2040 * Key Management (KEA = 1024 bits; RSA = 512 .. 2048 2041 bits). 2043 28) Only X.509 Or Other Certificate Distribution Methods 2044 ------------------------------------------------------------ 2045 PGP V3.0 2047 S/MIME 2048 * X.509 any version. 2050 MOSS 2052 MSP 2053 * X.509 any version. 2055 29) Very Solid API And Took Kit 2056 --------------------------------- 2057 PGP V3.0 2058 * V3.0 Yes - anticipated. 2060 S/MIME 2061 * Yes. 2063 MOSS 2064 * No. 2066 MSP 2067 * Yes. DISA is submitting an API to X/Open. 2068 * At least two tookkits for sale. 2070 30) Tool Kits Can Be Made Available To All Countries Not 2071 Under UN Embargo 2072 ------------------------------------------------------------ 2073 - 2074 PGP V3.0 2075 * Probably from alternate sources. 2077 S/MIME 2078 * Export version probably to most countries. 2080 MOSS 2081 * Export version probably to most countries . 2083 MSP 2084 * Export version probably to most countries. Toolkits 2085 exported to many countries, including France. 2086 * Alternate source likely. 2088 31) Fit With Future Direction Of EDI 2089 --------------------------------------- 2090 PGP V3.0 2091 * Unknown. 2093 S/MIME 2094 * Unknown. 2096 MOSS 2097 * Unknown. 2099 MSP 2100 * Unknown. 2102 Primary Author's Address: 2104 Chuck Shih 2105 610 Caribbean Drive 2106 Sunnyvale, CA. 94089 2107 Phone: 408-542-3282 2108 Fax: 408-542-3210 2109 e-mail: chucks@actracorp.com