[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09

EDIINT Functional Specification          November 1996


EDIINT Working Group                     Chuck Shih
Internet Draft                           Mats Jansson
Expires:  05/97                          Rik Drummond
                                         Lincoln Yarbrough




      Requirements for Inter-operable Internet EDI
           <draft-ietf-ediint-req-01.txt>

Status of this Memo


   This document is an Internet-Draft. Internet-Drafts are
   working documents of the Internet Engineering Task Force
   (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts. Internet-Drafts are draft documents
   valid for a maximum of six months and may be updated,
   replaced, or made obsolete by other documents at any
   time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work
   in progress."

   To learn the current status of any Internet-Draft,
   please check the "1id-abstracts.txt" listing contained
   in the Internet-Drafts Shadow Directories on
   ftp.is.co.za (Africa), nic.nordu.net (Europe),
   unnari.oz.au (Pacific Rim), ds.internic.net (US East
   Coast), or ftp.isi.edu (US West Coast).

   Any questions, comments, and reports of defects or
   ambiguities in this specification may be sent to the
   mailing list for the EDIINT working group of the IETF,
   using the address <ietf-ediint@imc.org>. Requests to
   subscribe to the mailing list should be addressed to
   <ietf-ediint-request@imc.org>.



Abstract

   This document is a functional specification, discussing
   the requirements for inter-operable EDI, with sufficient
   background material to give an explanation for the EDI
   community of the Internet, and security related issues.

Feedback Instructions

   If you want to provide feedback on this draft, follow these
   guidelines:

   - Send feedback via e-mail to chucks@actracorp.com, with EDIINT
     Requirements in the subject field.

   - Be specific as to what section you are referring to, preferably
     quoting the portion that needs clarification or modification.
     Your comments would then follow the identified section.

   - If you are recommending some text be replaced with your suggested
     text, again, quote the section to be replaced, and be clear on
     how you think the text should read.

   - If you are questioning fundamental assumptions, make it clear
     what is being questioned and the editor will bring the issue
     to the EDIINT list for discussion. To follow the discussion,
     the reader needs to subscribe to the ietf-ediint@imc.org
     discussion list.



                      Table of Contents


1.0 INTRODUCTION                                           4

 1.1 THE AUDIENCE                                          4

2.0 THE INTERNET - A BRIEF HISTORY                         5

 2.1 THE INTERNET - MYTHS AND REALITY                      6

 2.2 INTERNET ROUTING AND SECURITY CONSIDERATIONS          7

 2.3 EDI VAN COMMUNICATIONS AND SECURITY                   8

3.0 FUNCTIONAL REQUIREMENTS                                8

 3.1  INTRODUCTION AND DEFINITIONS                         8

 3.2  STANDARD ENCRYPTION ALGORITHMS AND WORLD-WIDE
      ENCRYPTION                                           9
  3.2.1  INTRODUCTION AND DESCRIPTION                      9
  3.2.2  SYMMETRIC ENCRYPTION                              9
  3.2.3  ASYMMETRIC ENCRYPTION - PUBLIC-KEY CRYPTOGRAPHY   9
  3.2.4  NEEDS                                            10
  3.2.5  ISSUES                                           10
  3.2.6  RECOMMENDATIONS                                  10

 3.3  KEY MANAGEMENT - SYMMETRIC KEYS                     12
  3.3.1 INTRODUCTION AND DESCRIPTION                      12
  3.3.2 NEEDS                                             13
  3.3.3 ISSUES                                            14
  3.3.4 RECOMMENDATIONS                                   14

 3.4  KEY MANAGEMENT - PUBLIC AND PRIVATE KEYS            14
  3.4.1 INTRODUCTION AND DESCRIPTION                      14
  3.4.2 PUBLIC KEYS                                       15
  3.4.3 NEEDS                                             15
  3.4.4 ISSUES                                            15
  3.4.5 RECOMMENDATIONS                                   16

 3.5  CONTENT INTEGRITY                                   16
  3.5.1 INTRODUCTION AND DESCRIPTION                      16
  3.5.2 NEEDS                                             17
  3.5.3 ISSUES                                            17
  3.5.4 RECOMMENDATIONS                                   17

 3.6  AUTHENTICATION AND NON-REPUDIATION OF ORIGIN        17
  3.6.1 INTRODUCTION AND DESCRIPTION                      18
  3.6.2 NEEDS                                             18
  3.6.4 RECOMMENDATIONS                                   19

 3.7  SIGNED RECEIPT OR NON REPUDIATION OF                19
      RECEIPT
  3.7.1  INTRODUCTION AND DESCRIPTION                     19
  3.7.2  NEEDS                                            20
  3.7.3  RECOMMENDATIONS                                  20

 3.8  EDI OBJECT BOUNDARIES AND TRANSACTION PRIVACY       21
  3.8.1 INTRODUCTION AND DESCRIPTION                      21
  3.8.2 GATEWAY FUNCTIONS                                 21

 3.9  SYNTAX AND PROTOCOL FOR SPECIFYING CRYPTOGRAPHIC
      SERVICES                                            21
  3.9.1 INTRODUCTION AND DESCRIPTION                      21
  3.9.2 NEEDS                                             21
  3.9.3 ISSUES                                            21
  3.9.4 RECOMMENDATIONS                                   22

4.0 TRACKING AND ERROR HANDLING BASICS                    22

 4.1 INTRODUCTION                                         22

 4.2 TRANSMISSION SUCCESSFULLY TRANSLATED FROM
     INTERNAL FORMAT TO STANDARD EDI FORMAT               23
  4.2.1 NEEDS                                             23
  4.2.2 RECOMMENDATIONS                                   23

 4.3 TRANSMISSION SUCCESSFULLY ENCODED, ENCRYPTED, SIGNED
     AND SENT                                             23
  4.3.1 NEEDS                                             23
  4.3.2 RECOMMENDATIONS                                   24

 4.4 TRANSMISSION SUCCESSFULLY DELIVERED TO THE RECIPIENTS
     MAILBOX                                              24
  4.4.1 NEEDS                                             24
  4.4.2 RECOMMENDATIONS                                   24

 4.5 TRANSMISSION SUCCESSFULLY RECEIVED                   24
  4.5.1 NEEDS                                             24
  4.5.2 RECOMMENDATIONS                                   25

 4.6 TRANSMISSION SUCCESSFULLY TRANSLATED BY
     RECEIVER                                             25
  4.6.1 NEEDS                                             25
  4.6.2 RECOMMENDATIONS                                   25

 4.7 DETECTION AND RECOVERY OF DELAYED OR LOST
     TRANSMISSIONS                                        25
  4.7.1 NEEDS                                             25
  4.7.2 RECOMMENDATIONS                                   25

 4.8 DETECTION AND HANDLING OF DUPLICATE
     TRANSMISSIONS                                        25
  4.8.1 NEEDS                                             26
  4.8.2 RECOMMENDATIONS                                   26

APPENDIX A - A COMPARISON OF SECURITY FORMATS AND
             PROTOCOLS                                    26




1.0  Introduction

   Electronic Data Interchange (EDI) is a set of protocols
   for conducting highly structured inter-organization
   exchanges, such as for making purchases or initiating
   loan requests.  The initial RFC1767 defined the method
   for packaging EDI X.12 and UN/EDIFACT transaction sets in
   a MIME envelope. However, several additional
   requirements for obtaining multi-vendor, inter-operable
   service, over and above how the EDI transactions are
   packaged, have come to light since the effort concluded.
   These currently revolve around security issues such as
   EDI transaction integrity, confidentiality and non-
   repudiation in various forms. Additional requirements
   that mimic many of the heading fields found in X.435 EDI
   messages (e.g., Interchange Sender, Interchange
   Recipient, Interchange Control Reference, Communications
   Agreement ID, and Syntax Identifier) are also needed to
   support efficient exchanges by gateways and Value Added
   Networks. Standards in these and other areas are
   necessary to insure inter-operability between EDI
   implementations over the Internet. Various technologies
   already exist for these additional features, and the primary
   requirement is to review and select a common set of
   components for use by the EDI community when it sends
   EDI over the Internet. In effect, the effort is to
   provide an EDI over the Internet Requirements Document
   and an Applicability Statement Document.

   This document's current focus is on EDI MIME content
   transported using SMTP (Simple Mail Transport Protocol),
   the Internet's mail or messaging system.

   Traditional VAN connectivity is slow and expensive. The
   Internet promises lower cost usage and is more easily
   accessible than traditional methods of communications.
   The predominant problem with the use of  the Internet
   for EDI is inter-operability between vendor products,
   specifically in the areas of integrity, confidentiality,
   digital signature, and non-repudiation. The EDIINT working
   group's focus is to recommend solutions for each of
   these areas using existing standards whenever possible.


1.1  The Audience

   The audience for this document consists of persons
   directly or indirectly involved in EDI communications
   decisions, companies trading EDI documents today or in
   the future, and  vendors developing and marketing EDI
   products. Also included in the audience for this
   document are people providing services and consulting
   to the EDI community.


2.0 The Internet - A Brief History

   The Internet is a world-wide collection of computers,
   routers, and networks, connected together using the
   TCP/IP suite of protocols. The Internet itself is not a
   network, but a collection of networks. The Internet was
   designed to be decentralized, with no single authority
   needed to run it. All hosts on the Internet can
   communicate with one another as peers, and all of the
   communications protocols are "open" -- the standards are
   in the public domain, and the standardization process is
   open to anyone willing to put in the hard work to help
   define them.

   One consequence of this standards "openness" is that the
   Internet can accommodate many different kinds of
   machines (toasters for example). Its protocols -- the
   TCP/IP suite -- have therefore become the de facto
   standards for heterogeneous computer networking. At one
   level, the Internet is a physical collection of
   computers connected by common protocols. At another
   level though, the Internet can be thought of as a
   distributed medium, offering  some important advantages
   for doing EDI. For instance, the Internet has hundreds
   of thousands of connected global hosts, and tens of
   millions of users. The Internet offers a flat rate,
   volume and time-of-day independent pricing structure for
   data transmission. The Internet is highly redundant,
   offering  the ability to route data along alternate
   paths. The Internet's decentralized structure makes
   adding new hosts relatively easy -- it scales well, and
   supports high bandwidth communications technologies.

2.1. The Internet - Myths and Reality

   The Internet had its beginnings in 1969 as an
   experimental U.S. Defense Department network called
   ARPANET. The network was built to facilitate research on
   how to construct networks that could withstand outages
   to part of the network, but continue to function.
   Network reliability was a fundamental design point when
   developing the architecture and protocols associated
   with the Internet. From the premise that the network was
   inherently unreliable (parts of it could be destroyed at
   any moment) emerged a design that was both robust and
   reliable.  Early on, the networks comprising the
   Internet were primarily those from government agencies
   and educational institutions. Access to the Internet was
   pretty much available only to computer science
   researchers, and government employees and their contractors.

   In 1986, the National Science Foundation, in order to
   provide access to what was then a scarce resource, put
   together an initiative to link five super-computer
   centers together using the TCP/IP protocols. Two very
   important results of the NSFNET initiative were the
   upgrading of the Internet's infrastructure with
   more powerful processors and higher speed links, and
   expansion of access to a larger user community. The
   1990's has seen the continual upgrading of the Internet
   infrastructure and its expansion to new constituencies
   outside the traditional government and university
   research community. Commercial interests are now the
   largest as well as the fastest growing segment of the
   Internet.

   Commercial Internet providers, such as Performance
   Systems International (PSI), and UUNET (the Alternet
   network), have emerged from the collection of
   intermediate-level networks that came into being as a
   result of the NSFNET initiative. The national long distance
   carriers such as MCI, AT&T, and Sprint all
   provide commercial Internet services. These commercial
   providers, called Internet Service Providers or ISPs for
   short, make available Internet connectivity and various
   other Internet services to their clients. The perception
   of the Internet as experimental, and primarily used by
   and for educational and research activities is
   rooted in the Internet's past, and does not reflect today's
   situation. The growth in commercial access to the
   Internet, along with the growth of the ISPs, has
   radically changed the Internet's network composition.

   The design and architecture underlying the Internet has
   proven its robustness by scaling to unprecedented
   proportions. The Internet is reliable from several
   perspectives:

   1). Technologically, the TCP/IP suite of protocols and
       the architecture underlying the Internet are stable and
       mature.

   2). Product implementations based on the TCP/IP suite
       are also stable and mature.

   3). Internet routing is dynamic, so packets sent through
       the Internet get to their destinations even if there are
       network outages along the way.

   4). The commercial ISP administered portions of the
       Internet, provide essentially the same level of network
       reliability, availability, monitoring, throughput,
       implementation and support services as existing EDI
       Value Added Networks (VANS), but at a lower cost and
       with higher bandwidth.

   Although the Internet is reliable, low-cost, highly
   accessible, supports high bandwidth communications, and
   is technically mature, there are still some valid
   concerns relating to the use of the Internet for EDI.
   These concerns revolve primarily around security,
   message tracking, audit trails, and authentication. Some
   of the concerns, encryption for instance, are of a
   general nature and not specific to the Internet --
   encryption may be required regardless of what type of
   network is traversed. Other concerns, such as tracking,
   arise because they are required by EDI, or are supported by
   existing EDI Value Added Networks.


2.2 Internet Routing and Security Considerations

   By using a common network trace program called
   Traceroute, the route traversed by a packet from a
   source host to a destination host on the Internet may be
   followed. Tracing routes on the Internet yield some
   interesting characteristics. As expected, the routes
   traversed go through the networks administered by the
   ISPs of each of the trading partners. Each route
   consists of multiple nodes through each network. The
   route can vary but that is not the typical case. The IP
   packets are delivered reliably, and within a specified
   period of time. When a reputable commercial ISP is used,
   none of the nodes in the route are administered by
   government or educational entities.

   By looking at Internet network traces, we can conclude
   that the  Internet does a very  good job of getting
   packets from a source to destination. However, between
   the source and the destination, the packets are routed
   through many intermediate nodes. It is at the
   intermediate nodes where anyone on one of the machines
   that handle the packets could re-assemble the packets
   that make up the EDI Interchange and could therefore read it,
   copy it, alter it, or delete it. In the case where the EDI
   Interchange is carried using an e-mail transport (SMTP),
   the situation could arise where the message cannot be
   delivered to the final recipient, so the message must
   be stored at an intermediate node. Once again, the
   message is susceptible to any number of the above mentioned
   security threats.

   The likelihood of any security threat, (especially if going
   through intermediate nodes administered by a quality
   ISP) are quite low, and practically speaking, are
   quite difficult. Nonetheless the possibility exists, and
   therefore is a concern -- particularly if the packets
   contain high value or sensitive EDI or electronic
   commerce transactions.

   The Internet is being singled out in this discussion because
   our focus is on EDI over the Internet. Networking is by its
   very nature prone to security threats. Information can be
   placed on shared media, and may be routed through nodes
   not under the sender's administrative control. Whether through
   malicious hacking or administrative glitches, the threat
   that information sent over a network is read, copied, altered,
   or deleted in an unauthorized way, is a possibility that
   exists even if an EDI Interchange is sent via an EDI VAN.

   A large component of the "value-added" services provided by
   EDI VANs is precisely the assurance that EDI Interchanges sent
   via the VAN are not compromised in any way. There are
   however, measures that can be taken to defend against security
   threats when an EDI Interchange is in transit across an
   "open" network like the Internet. These security measures
   are essential requirements when doing EDI over the Internet.

   Each of these security measures is described in Section 3.0
   of this document, and the issues surrounding each measure is
   discussed, and recommended solutions are given.

2.3  EDI VAN Communications and Security

   This section briefly discusses current VAN security services.
   The security measures recommended in section 3.0 of this
   document essentially provide the equivalent of the VAN security
   services described below.

   The most prevalent EDI VAN communications service provided to
   EDI trading partners is an asynchronous mailboxing service.
   A trading partner typically dials into a VAN network access
   point. The trading partner then uses a file transfer protocol
   to send the EDI Interchanges to the VAN. The VAN then routes
   the EDI Interchanges to the receiving trading partner's VAN
   mailbox. The receiving trading partner then dials into the
   VAN and down-loads the EDI Interchanges from its VAN mailbox.

   Other than support for a greater number of communications
   protocols, and typically lower line speeds, connecting to an
   EDI VAN is not too much different than connecting to an Internet
   Service Provider. The EDI VANs however, provide a higher level of
   EDI services to the EDI trading partner than do the ISPs.
   The most important of these services is that the EDI VAN acts
   as a trusted third party to insure that EDI Interchanges sent
   via the VAN are not compromised in any way.

   EDI VANs provide for EDI Interchange integrity, authentication,
   and a number of acknowledgments that track the progress of the
   EDI Interchange through the Value Added Network. EDI Interchange
   integrity assures the trading partner that once the EDI
   Interchange has been transferred to the VAN, that it will be
   routed to the receiving trading partner without modification.

   VAN authentication of trading partners consist of the guarantee
   that EDI Interchanges can be sent and received by trading
   partners only after they have been authenticated by the VAN. VANs
   authenticate trading partners by having the trading partners
   log into the network with the proper userid and password. The
   VAN has administrative responsibility for maintaining the
   trading partner accounts and for insuring that the accounts
   are valid. VANs also provide differing levels of service that
   allow a trading partner to track the progress of the EDI
   Interchange through the VAN. Trading partners can subscribe to
   mailbox delivery notification or mailbox pick-up notification.
   Mailbox delivery notification is sent by the VAN to the
   sending trading partner when the EDI Interchange is delivered
   to the receiving trading partner. Mailbox pick-up notification
   is sent by the VAN to the sending trading partner when the
   EDI Interchange is down-loaded by the receiving trading partner.

   The issue of tracking is covered in more detail in section 4.0.

3.0 Functional Requirements

3.1 Introduction and Definitions

    The following sections describe the functional and
    inter-operability requirements, as well as some of the
    practical considerations of sending and receiving EDI
    transactions on the Internet. It is assumed that the
    reader is generally familiar with EDI.

3.2  Standard Encryption Algorithms and World-Wide
     Encryption

3.2.1 Introduction and Description

      The goal of encryption is to turn otherwise readable
      text into something that cannot be read, and therefore
      understood. By making the text unintelligible,
      encryption discourages anyone from reading or copying
      the EDI Interchange while it is in transit between the
      trading partners. Encryption conveys confidentiality to
      the EDI Interchange. Traffic analysis is always
      possible, since many times, header information is not
      encrypted. (Traffic analysis is the analysis of header
      information in order to derive useful information from
      them.)

      Encryption is based on two components: an algorithm and
      a key. An algorithm is a mathematical transformation
      that takes plain-text or other intelligible information
      and changes it into unintelligible cipher text. The
      inverse mathematical transformation, back to the
      original from the cipher text is also done, and  is
      called decryption. In order to encrypt the plain text, a
      key is used as input in conjunction with an encryption
      algorithm. An algorithm can use one of any of a large
      number of possible keys. The number of possible keys
      each algorithm can support depends on the number of bits
      in the key. For instance, if the key length is 40, then
      2 to the n, where n is the number of bits in the key,
      results in 1,000,000,000,000 possible key combinations,
      with each different key causing the algorithm to produce
      slightly different cipher output.

      An encryption algorithm is considered secure if its
      security is dependent only on the length of its key.
      Security cannot be dependent on the secrecy of the
      algorithm, the inaccessibility of the cipher or plain
      text, or anything else -- except the key length. If this
      were true about a particular algorithm, then the most
      efficient -- and only -- attack on that algorithm is a
      brute-force attack, whereby all key combinations must
      be tried in order to find the one correct key (this is
      true for symmetric encryption algorithms, asymmetric
      algorithms work a little differently, and are explained
      in greater detail later).  So by specifying a long
      enough key length n, even a brute-force attack on a
      secure algorithm can be made completely non-feasible.

3.2.2  Symmetric Encryption

       Encryption algorithms whereby two trading partners must
       use the identical key to encrypt and decrypt the EDI
       Interchange are called symmetric encryption algorithms.
       Put another way, if an EDI Interchange is encrypted with
       one key, it cannot be decrypted with a different key.
       The key used in most symmetric encryption algorithms is
       just a random bit string, n bits long. These keys are
       often generated from random data derived from the source
       computer.

       The use of symmetric encryption simplifies the
       encryption process, each trading partner does not need
       to develop and exchange secret encryption algorithms
       with one another (which incidentally would be a near
       impossible task). Instead, each trading partner can use
       the same encryption algorithm, and only exchange the
       shared, secret key.

       There are drawbacks however with symmetric encryption
       schemes; a shared secret key must be agreed upon by both
       parties. If a trading partner has n trading
       relationships, then n secret keys must be  maintained,
       one for each trading partner. Symmetric encryption
       schemes also have the problem that origin or destination
       authenticity (non-repudiation of origin, and receipt)
       cannot be proved. Since both parties share the
       secret encryption key, any EDI Interchange encrypted
       with a symmetric key, could have been sent by either of
       the trading partners. By using what is called public key
       cryptography, which makes use of asymmetric encryption
       algorithms, non-repudiation of origin and receipt,
       can be unambiguously established.

3.2.3  Asymmetric Encryption - Public-key Cryptography

       Public-key cryptography is based on the concept of a key
       pair. Each half of the pair (one key) can encrypt
       information that only the other half (one key) can
       decrypt. The key pair is designated and associated to
       one, and only one, trading partner. One part of the key
       pair (the private key) is only known by the designated
       trading partner; the other part of the key pair (the
       public key) is published widely but is still
       associated with the designated trading partner.

       The keys are used in different ways for confidentiality
       and digital signature. Both confidentiality and
       signature depend on each entity having a key pair that
       is identified only with them and each party keeping one
       pair of their key pair secret from all others.

       Signature  works as follows: Trading Partner A uses her
       secret key to encrypt part of a message, then sends the
       encrypted message to Trading Partner B. B gets Trading
       partner A's public key (anyone may get it) and attempts
       to decrypt the encrypted part of Trading partner A's
       message. If it decrypts, then Trading Partner B knows it
       is from A -- because only A's public key can decrypt a
       message encrypted with  A's private key, and A is the
       only one who knows her private key.

       Confidentiality applies the asymmetric key pair, but in
       a different manner than signature. If Trading partner A
       wishes to send a confidential message to Trading Partner
       B she would apply the key pair as follows: Trading
       partner A would retrieve Trading partner B's public key,
       and encrypt the message with it. When Trading Partner B
       receives the message, she would decrypt the message
       with her private key. Only her private key can decrypt
       information that was encrypted with her public key. In
       other-words, anything encrypted with B's public key can
       only be decrypted with B's private key.

       Since public-key encryption algorithms are considerably
       slower than their symmetric key cousins, they are
       generally not used to do the actual encryption of what
       could be large EDI Interchanges. For instance, RSA Data
       Securities, Inc. estimates that software encryption
       using DES (a symmetric key algorithm) is 100 times
       faster than software encryption using RSA (a public-key
       encryption algorithm from RSA Data Securities, Inc.).
       Hardware encryption using DES is anywhere from 1,000 to
       10,000 times faster than hardware encryption using the
       RSA asymmetric encryption algorithm.  Instead of being
       used for bulk encryption, public-key encryption
       algorithms are used to encrypt symmetric encryption
       keys. They are also used as an efficient means of
       exchanging and managing symmetric encryption keys.

3.2.4  Needs

       In order to provide confidentiality for EDI Interchanges
       on the Internet, a standard encryption algorithm(s) and
       key length(s) must be specified. For inter-operability
       to occur between two trading partners, the encryption
       algorithm and key lengths must be agreed upon either
       before hand or within an individual transaction.

3.2.5  Issues

       When choosing an encryption algorithm, the following
       criteria should be considered; how secure the algorithm
       is; how fast implementations of the algorithm are; the
       availability of the algorithms for international as well
       as domestic use; the availability of APIs and tool kits
       in order to implement the algorithms; and the frequency
       of the use of  the algorithm in existing implementations.

       Sufficient key lengths must be chosen with regard to
       the value of the EDI Interchange so that brute-force
       attacks are not worth the time or effort compared to the
       value of the Interchange.

3.2.6  Recommendations

   DES: The most widely used commercial encryption
   algorithm is DES. It is widely used in the banking
   industry for Electronic Funds Transfer (EFT). DES is
   also a U.S. government encryption standard. DES is in
   the public domain, which means anyone can implement the
   algorithm, including  those in the international
   community. DES was designed for, and is used for bulk
   encryption of  data. DES is prohibited by the U.S.
   government for export.

   The DES algorithm has been analyzed by cryptographers
   since the mid-1970s, and is considered secure: in other
   words, the security of DES is completely dependent on
   the length of its key. DES specifies a 56 bit key, so 2
   to the 56th or 10 to the 16th keys are possible.  A
   brute force attack, which means trying every single key
   to decrypt 8 bytes of known cipher-text into its
   corresponding 8 bytes of known plain-text is the best
   attack on the algorithm.

   The amount of time and money required to mount a
   successful brute force attack varies with the processing
   power used -- and how lucky the attacker may be in
   generating a key that is close to the one used to
   encrypt the original EDI Interchange. Some estimates
   which have been put forth claim that a $1 million dollar
   hardware based, brute-force attack on DES would only take 3.6
   hours to recover the DES key. A corresponding $1
   million dollar software based brute-force attack on DES
   would however take 3 years. As the price/performance of
   processors decrease, a 56 bit key becomes less and less
   adequate in protecting EDI Interchanges of extreme
   value. Triple-DES, an algorithm with longer key length
   (discussed below) should be used in such cases.

   Triple-DES is a variant on DES that encrypts the EDI
   Interchange 3 times, with 2 independent 56 bit keys,
   giving it an effective key length of 112 bits. This
   makes a brute-force attack on Triple-DES not feasible.
   DES and Triple-DES actually can be implemented in 3
   different modes. It is recommended that DES and Triple-
   DES be used in Cipher Block Chaining (CBC) mode, which
   gives added protection by making each cipher-text block
   depend on each other, so changes in the cipher-text can
   be detected.

   RC2, RC4, and RC5: RC2, RC4, and RC5 are proprietary symmetric
   algorithms of  RSA Data Security, Inc. RC2 and RC4
   unlike DES, are variable-key length algorithms. By specifying
   differing key lengths, RC2 and RC4 can be configured to
   provide greater or lesser security.  RC2 and RC4 are
   alternatives to DES and have special export status,
   whereby 40 bit versions of RC2 and RC4, and 56 bit
   versions for foreign subsidiaries and overseas offices
   of U.S. companies have expedited export approval from
   the U.S. government. RSA claims that RC2 and RC4 are
   faster than DES when implemented in software. Several products
   such as Lotus Notes, Netscape Navigator, and Apple's Open
   Collaboration Environment make use of these algorithms.
   It is recommended that a key length of at least 128 bits
   be used when using  RC2 and RC4. A key length of 128
   bits would  make a brute-force attack impossible now and
   for the foreseeable future.

   IDEA: The International Data Encryption Algorithm was
   published in 1991. The symmetric algorithm is an
   iterated block cipher with a 64-bit block size and a 128-
   bit key size. The key length of IDEA is over twice that
   of DES and is longer than triple-DES. The IDEA algorithm
   is patented in both the United States and abroad. The
   IDEA algorithm in CBC mode is used by PGP (Pretty Good
   Privacy - a popular  electronic mail security program)
   for encryption. Individual users of PGP have a royalty
   free license to use the IDEA algorithm.

   There are many encryption algorithms that are secure and
   can provide confidentiality for an EDI Interchange. For
   interchanges that carry less value, 40-bit RC2 or 56-bit
   DES are probably adequate. For more valuable
   interchanges, use of Triple-DES, IDEA, or longer key
   length RC2 or RC4 is recommended.

   DES is currently in wide-spread use, and Triple-DES is
   projected to be in wide-spread use, as the 56-bit DES
   key limitation becomes less and less adequate.  The DES
   algorithm is available  for implementation outside the
   U.S., and the DES algorithm has been studied for a long
   time, and has been found to be secure.  RC2 and RC4 are
   useful because they allow the security of  the
   encryption - the key length specification, to be
   configurable. The RC2 and RC4  algorithms are
   proprietary, but products incorporating these algorithms,
   but limiting the key lengths to 40 bits or less, can be
   exported outside the U.S.

   IDEA is a newer algorithm and has not been studied as much as
   DES. It has an adequate key-length, though it is not
   configurable. Indications are that IDEA is a secure
   algorithm and its use in PGP makes it the most widely
   used encryption algorithm for Internet electronic mail.


3.3  Key Management - Symmetric Keys

3.3.1 Introduction and Description

   The use of symmetric encryption is based on a shared
   secret. Two trading partners using a symmetric
   encryption algorithm must be able to do the following;
   generate a random symmetric key and agree upon its use;
   securely exchange the symmetric key with one another;
   set up a process to invalidate a symmetric key that has
   been compromised or needs changing. Each trading partner
   would then need to do this with each and every one of
   their trading partners. Management and distribution of
   symmetric keys can become an  insecure and cumbersome
   process.

   Pure symmetric key management schemes also have the
   problem that origin authenticity cannot be proved. Since
   two parties share a secret encryption key, any EDI
   Interchange encrypted with a symmetric key, could have
   been sent by either of the trading partners both of whom
   have knowledge of the key.

   Using public-key cryptography, the management of
   symmetric keys is simplified and made more secure.
   Trading partners do not need to agree on secret
   symmetric keys as part of the trading partner
   relationship. Public-key cryptography also solves the
   origin authenticity problem that are inherent with pure
   symmetric key management schemes.

   By generating a unique symmetric encryption key for each
   EDI Interchange, and using public key cryptography,
   trading partners no longer need to secretly agree on a
   shared symmetric key in the trading partner
   relationship. A symmetric key can be randomly generated
   by the software for each EDI Interchange between trading
   partners.  Since a unique symmetric key is generated for
   each EDI Interchange, key maintenance is not needed.
   Trading partners do not need to invalidate compromised
   or expired keys. Each symmetric key is  used only one
   time.

   Additional security is also realized using  the method
   described above; in the unlikely event that one of the
   symmetric keys is compromised, only one EDI transaction
   is affected, and not every transaction in the trading
   partner relationship.  Public-key encryption also
   provides a secure way of distributing symmetric keys
   between trading partners. Since only the receiving
   trading partner has knowledge of her private asymmetric
   key, she is the only one that can decrypt the symmetric
   key encrypted with her public asymmetric key -- and is
   thus the only one who can use the symmetric key to
   decrypt the EDI Interchange.

   To impart confidentiality to an EDI Interchange which
   trading partner ABC sends to trading partner XYZ, the
   following steps would be performed:

          1). The EDI Translator outputs the EDI Interchange.

          2). A random symmetric key of the specified length
          is generated.

          3). The EDI Interchange is encrypted using the
          randomly generated symmetric key with the chosen
          encryption algorithm.

          4). The random symmetric key is then encrypted
          using XYZ's, the receiving trading partner's,
          public asymmetric key.

          5). The encrypted symmetric key and encrypted EDI
          Interchange are then enveloped and sent to the
          trading partner.


   On the receiving side, the following steps would be
   performed:

          1). The symmetric key is decrypted using XYZ's
          private asymmetric key.

          2). The decrypted symmetric key is then used to
          decrypt the EDI Interchange.

          3). The decrypted EDI Interchange is then routed to
          the EDI translator.

3.3.2  Needs

   A method to manage the symmetric encryption keys used in
   encrypting EDI Interchanges. The method should simplify
   the generation, maintenance, and distribution of the
   symmetric encryption keys. The method should also
   provide a secure channel for distributing the symmetric
   encryption keys between trading partners.

3.3.3  Issues

   Choose a public-key encryption algorithm that
   facilitates key management of the symmetric
   encryption keys. The symmetric encryption keys
   should be generated on the fly for each EDI
   Interchange.

   When choosing a public-key encryption algorithm,
   the following criteria should be considered; how
   secure the algorithm is;  how fast implementations
   of the algorithm are; the availability of the
   algorithms for international as well as domestic
   use; the availability of APIs and tool kits in
   order to implement the algorithms; and the
   frequency  of the use of  the algorithm in
   existing implementations.

   Sufficient key lengths must be chosen with
   regard to the value of the EDI Interchange so that
   brute-force attacks are not worth the time or
   effort compared to the value of the Interchange.

3.3.4   Recommendations

   RSA is a public-key encryption algorithm that has
   become a de facto standard in its use for key
   management. Its use is recommended in managing and
   distributing symmetric encryption keys when doing EDI
   over the Internet. The RSA public-key algorithm also
   has the advantage that it can be used freely outside the
   U.S.

   The mathematics of RSA are complicated, but is based
   on the difficulty in factoring large prime numbers. A
   public-key is generated by multiplying two large prime
   numbers together, deriving the private key from the
   public key involves factoring the large prime number. If
   the prime is large enough, this becomes an impossible
   task. The RSA key length is configurable, and is
   recommended to be at least 512 bits (154 digits long),
   and preferably 1024 bits (or 308 digits long) or longer.


3.4  Key Management - Public and Private Keys

3.4.1 Introduction and Description

   The use of public-key cryptography to simplify the
   management of the symmetric encryption keys presents the
   user with two problems; protecting the private key, and
   binding a trading partner's identity to his public key.
   Most likely the user will never know what his private
   key is. The software will generate a random private key,
   encrypt it, and store it in a file or database. The
   private key is accessed indirectly by the user through
   access to the software. User access to the software is
   generally controlled by a password, pass-phrase, and/or
   certain access rights. These are internal security
   policies, and are company specific. It is important to
   control the access to the private key, since any
   unauthorized access can lead eventually to the
   revocation of the corresponding public key.


3.4.2 Public Keys

   A public key is used by an originating trading partner
   to encrypt a symmetric key, and as we'll discuss later,
   by a receiving trading partner to verify authenticity of
   the originator. Trading partners exchange public keys
   using a public key certificate.

   A public key certificate is defined in the X.509
   standards, and is a binding of  an entity's
   distinguished name (a formal way for identifying someone
   or something in the X.500 world, in our case it would be
   a trading partner) to a public key. A certificate also
   contains the digital signature of the issuer of the
   certificate, the identity of the issuer of the
   certificate, and an issuer specific serial number, a
   validity period for the certificate, and information to
   verify the issuer's digital signature. Certificate
   issuers are called certification authorities, and are
   trusted by both trading partners. In essence, a
   certificate is a digitally notarized binding of a trading
   partner to its public key.

3.4.3 Needs

   Adoption of a trust model and use of certification
   authorities for issuing commercial grade/class 3
   certificates. Each trading partner must choose a certification
   authority that the other trading partner trusts.

   Formats and protocols for requesting, revoking, and exchanging
   certificates and certificate revocation lists between
   certification authorities and trading partners, as well
   as between the trading partners themselves.

3.4.4 Issues

   The lack of wide-spread use of certification authorities
   in real world commercial applications, and the need to do
   additional profiling of X.509v3 certificates and standards
   for requesting, revoking, and exchanging certificates and
   certificate revocation lists.

3.4.5  Recommendations

3.4.5.1 Near Term Approach

   Since there already exists a trust relationship between
   EDI trading partners, until use of certification authorities
   become more established and better profiling is done
   with X.509v3 certificates, it is recommended that the
   trading partners self-certify each other if an agreed upon
   certification authority is not used.

   In the near term, the exchange of public keys and
   certification of these keys must be handled as part of
   the process of establishing a trading partnership.
   The UA and/or EDI application interface must maintain
   a database of public keys used for encryption and
   authentication, in addition to mapping between the EDI
   trading partner ID and the RFC822 e-mail address. The
   procedures for establishing a trading partnership and
   configuring the secure EDI messaging system might vary
   among trading partners and software packages.

   It is still highly recommended that trading partners
   acquire a X.509v3 certificate from a certificate authority
   trusted by both trading partners. The process of
   acquiring a certificate varies among the various
   certificate authorities. It is recommended that trading
   partners exchange certificates using the formats
   and protocols specified by PKCS#7 and S/MIME.

3.4.5.1 Long Term Approach

   In the long term, additional Internet-EDI standards
   will need to be developed to simplify the process of
   establishing a trading partnership, including the
   acquisition, revocation, exchange, and third party
   authentication of certificates.

   PKCS#7 and PKCS#10 as well as the standards being
   developed by the IETF-pkix (public key infrastructure
   X.509 work-group) need to be evaluated and adopted
   as standards for Internet EDI.

3.5  Content Integrity

3.5.1  Introduction and Description

   Encryption guarantees the confidentiality of an EDI
   Interchange. Content integrity guarantees that the
   receiving trading partner gets the EDI Interchange in
   its originally sent state. Content integrity assures
   that no modifications -- additions, deletions, or changes
   -- have been made to the EDI Interchange when it is in
   transit between trading partners.

   Content integrity is achieved if the sender includes
   with the EDI Interchange, an integrity control value.
   This value can be computed by using an appropriate
   cryptographic algorithm to "fingerprint" the EDI
   Interchange. These cryptographic algorithms are called
   one-way hash functions or message integrity checks.
   Similar to encryption, a one-way hash function turns the
   intelligible EDI plain-text into something unintelligible.

   Unlike encryption algorithms however, one-way hash
   functions can't be decrypted.  One-way hash functions
   are constructed so the probability is infinitely small
   that some arbitrary length piece of plain-text can be
   hashed to a particular value, or that any two pieces of
   plain-text can be hashed to the same value. One-way hash
   values are usually  from 112 to 160 bits long. The
   longer the hash value, the more secure it is.

   One-way hash functions don't require a key, and the
   algorithm used must be agreed upon by the trading
   partners. To insure content integrity, the sending
   trading partner needs to calculate a one-way hash value
   of the EDI Interchange.  This value is unique and
   "fingerprints" the EDI Interchange. The sending trading
   partner sends the hash value along with the EDI
   Interchange. The receiving trading partner using the
   same one-way hash function calculates the hash value for
   the received EDI Interchange. If the received hash value
   matches the calculated hash value, then the receiving
   trading partner knows that the EDI Interchange has not
   been tampered with.

3.5.2  Needs

   Choice of a one-way hash algorithm to calculate the hash
   value required to insure content integrity.

3.5.3 Issues

   The one-way hash algorithm should be secure, publicly
   available, and should produce hash values of at least
   128 bits.

3.5.4  Recommendations

   SHA-1 is the Secure Hash Algorithm, a one-way hash function
   invented by the National Security Agency. SHA-1 produces
   a 160-bit hash value that makes a brute-force attack
   on it not feasible. It is being recommended by most
   e-mail security programs and other security specifications,
   as weaknesses are being found in MD5.

   MD5 is a one-way hash function that is publicly
   available, and produces a 128 bit hash value called a
   Message Digest. It is currently widely used by
   most e-mail security programs, such as PEM, PGP, and
   S/MIME.

   The recommendation is for all new implementations to
   use SHA-1 outgoing, but to continue to accept MD5
   incoming, since there already exist many MD5
   implementations.

3.6  Authentication and Non-Repudiation of Origin

3.6.1  Introduction and Description

   Encryption guarantees confidentiality. Applying a one-
   way hash function guarantees content integrity. Both
   authentication and non-repudiation of origin guarantee
   the identity of the sender of the EDI Interchange. Non-
   repudiation of origin, identifies the original sender,
   and is the same as authentication when the EDI
   Interchange is sent point-to-point, i.e. when there is
   no forwarding involved. Authentication and non-
   repudiation of origin discourages any spoofing attacks
   that may occur while the EDI Interchange is in transit
   between the trading partners.

   Both authentication and non-repudiation of origin are
   accomplished using digital signatures. A digital
   signature is another application of public-key
   cryptography, and is explained in more detail in the
   following paragraphs.

   Up to this point, a receiving trading partner's public-
   key has been used to encrypt a symmetric key, and this
   symmetric key could only be decrypted by the receiving
   trading partner's private key.  However the roles of the
   private and public keys can be reversed, so that you
   encrypt with the private key, and decrypt with the
   public key. Again the keys are reciprocal, if encryption
   is done with the private key, decryption can only be
   done with the public key.

   Since only trading partner ABC knows her own private-
   key, only trading partner ABC can encrypt something with
   that private-key. Encryption with a private key
   therefore has the effect of uniquely identifying the
   person or entity doing the encryption. It is in effect,
   a digital signature. Since ABC's public-key is known to
   all her trading partners, they can all decrypt something
   encrypted with ABC's private-key. Successful decryption
   using ABC's public-key of something encrypted with
   ABC's private key has the effect of authenticating
   ABC as the trading partner that did the encrypting,
   or in other words it identifies ABC as applying the
   digital signature.

   ABC cannot deny that she did not do the encryption, since
   she is the only one with knowledge of her private key. In
   this way, non-repudiation of origin is achieved.

   So what should a trading partner sign or encrypt with
   her private-key to guarantee authentication and non-
   repudiation of origin? Remember, public-key encryption
   algorithms are not meant to encrypt something very
   large, they are too slow for that. The symmetric key is
   encrypted with a public-key, and encrypting this with a
   private-key is not recommended, as this would allow
   other than the authorized recipient to decrypt the EDI
   Interchange. Since a one-way hash value is pretty small,
   usually only between 112-160 bits long, it is a natural
   choice for what can be digitally signed. If the message
   integrity value is signed with a private key, then not
   only could authentication and non-repudiation of origin
   be guaranteed, but message integrity as well.

3.6.2 Needs

   Choice of a digital signature algorithm.

   3.6.3  Issues

   When choosing a digital signature algorithm, the
   following criteria should be considered; how secure the
   algorithm is;  how fast implementations of the algorithm
   are; the availability of the algorithms for
   international as well as domestic use; the availability
   of APIs and tool kits in order to implement the
   algorithms; and the frequency  of the use of the
   algorithm in existing implementations.

   Sufficient key lengths must be chosen with regard to the
   value of the EDI Interchange so that brute-force attacks
   are not worth the time or effort compared to the value
   of the Interchange.

3.6.4 Recommendations

   In addition to using the RSA public-key algorithm to
   encrypt keys, it is also recommended that RSA be used
   for digital signatures as well.

   Unlike encryption algorithms, strong digital signature (greater
   than 40 bit key lengths) algorithms can be freely exported
   outside the U.S.

3.7  Signed Receipt or Non Repudiation of Receipt

3.7.1  Introduction and Description

   The signed receipt (or the Non Repudiation of
   Receipt), is a receipt acknowledgment sent by the
   receiving trading partner to the sending trading partner.
   The signed receipt is used to solve the following
   issues when doing EDI over the Internet:

          1). Lack of mailbox delivery notification within the
          Internet standards, though these are currently
          being addressed within RFCs 1891-1894.

          2). Provide the equivalent of VAN mailbox delivery
          notification.

          3). Provide the equivalent of VAN mailbox pick-up
          notification.

          4). Provide the equivalent of VAN mailbox
          authentication.

          5). Detect the situation where EDI Interchanges are
          maliciously deleted, or are not delivered by the
          transport.

   Receipt by the sender of a signed receipt, is an implicit
   acknowledgment of successful mailbox delivery. It is
   also an explicit acknowledgment that the Interchange was
   retrieved from the mailbox -- pick-up notification. By
   having the receiver sign the receipt, it authenticates
   that the intended receiver picked up the EDI Interchange --
   mailbox authentication -- and that the intended receiver
   verified the integrity of the EDI Interchange, and the
   identity of the sender. By returning the original message id
   and the one-way hash value of the received message back in
   the signed receipt, the sender can reconcile the acknowledged
   EDI Interchange with what was sent.

3.7.2  Needs

   Define the format and protocol for the signed receipt
   so that it provides the following:

          1). Implicit acknowledgment of mailbox delivery of
          the EDI Interchange to the recipient.

          2). Explicit acknowledgment that the receiver has
          authenticated the sender and verified the
          integrity of the sent EDI Interchange.

          3). Guarantees non-repudiation of receipt when the
          signed receipt is digitally signed by the receiving
          trading partner.

          4). Provide  information in the signed receipt so
          it can be used for tracking, logging, and
          reconciliation purposes.

   The re-transmission timer, and retry count to detect
   lost Interchanges should be recommended, but needs to be
   configurable. Additionally, it should be specified what
   the receiver should do when it receives duplicate
   Interchanges, and what the sender should do when it
   receives duplicate receipt acknowledgments.

3.7.3  Recommendations

   The syntax for a signed receipt should not be specific
   to EDI content, since many of the uses of a signed receipt
   can be broadly applied to other MIME encapsulated objects.
   It is recommended that the results of the IETF receipt
   working group be adopted for use in implementing a signed
   receipt. The receipt working group has published an Internet
   draft -- draft-ietf-receipt-mdn-01, which can be obtained
   off of the IETF World Wide Web site. The EDIINT working
   group is working with the receipt working group to
   specify additional disposition-field values, as well as
   specification of  how the MDN (message disposition
   notification) should be used within an EDI environment.
   Specifically, within an EDI environment, requests for
   message disposition requests cannot be silently
   ignored. In addition, if non-repudiation of receipt is
   agreed to by the trading partners, the message integrity
   check that is verified by the receiving trading partner
   must be returned to the originating trading partner
   in the MDN.

   The time-out and retry values for the signed receipt should
   be configurable. Duplicates should be checked by the UA
   and discarded.

   The signed receipt should be implemented using a
   MIME multipart/signed with the MDN as the first part
   of the multipart/signed, and with the digital signature
   signed over the MDN.


3.8  EDI Object Boundaries and Transaction Privacy

3.8.1 Introduction and Description

   The specification by this work group applies to the EDI
   Interchange level, and not the group  or document level.
   Any security services, packaging, transport, or non-
   repudiation services are assumed to be applied to an EDI
   Interchange. Unlike the X12.58 and UN/EDIFACT 9735-5 and
   9735-6 security standards, the security services cannot
   be applied at a group or document level. The purpose of
   the specification is to move these services out of the
   translator, and into the "communications" subsystem. The
   "communications" subsystem should know as little about
   the structure of the EDI data as possible.

   The entire EDI Interchange including the enveloping
   headers (ISA/IEA or UNA/UNB/UNZ) are also encrypted.
   Since the routing of the EDI Interchange is through the
   Internet, and not a VAN, the sender/receiver ids are not
   used in mailbox routing, so the EDI envelops can be
   encrypted when sending EDI over the Internet.


3.8.2   Gateway Functions

   Situations exist whereby a VAN, or internal gateway, in
   order to route an EDI Interchange received on the
   Internet, will need to be able to access the information
   in the EDI envelope. The enveloping information as well
   as other information useful to gateways may need to be
   copied and sent as a separate MIME body part. A new
   MIME content should be defined for this type of information.

3.9  Syntax and Protocol for Specifying Cryptographic
     Services

3.9.1  Introduction and Description

   Once cryptographic services are applied to EDI
   Interchanges, then the formats and protocols must be
   specified on how the cryptographic information is
   conveyed during the EDI message exchange. Encryption
   algorithm information, one-way hash algorithm
   information, symmetric keys, initialization vectors, one-
   way hash values, public-key certificates, need to be
   enveloped and sent along with the EDI Interchange.

3.9.2 Needs

   A syntax and protocol for specifying EDI Interchanges that
   have had cryptography applied to it needs to be specified.
   Several suitable standards already exist, so it is preferable
   to choose one of these existing standards rather than
   specifying a new one.

3.9.3 Issues

   The syntax should be transport independent so it can be
   used with different Internet transports. The standard
   should have broad support, and implementations should be
   available. Finally it should be international in nature.

3.9.4  Recommendations

   The  IETF EDIINT working group has put together a matrix
   comparing many of the different ways that EDI with
   cryptography applied to it can be transmitted. The use
   of S/MIME and PGP/MIME (version 3.0 with the elkins
   draft) are both viable alternatives. Each has its
   strengths and weaknesses as the comparison matrix brings
   out.

   The S/MIME specification allows signed and encrypted
   and signed to be distinguished. The signatories in an
   S/MIME signed and encrypted content type can be
   distinguished, which in certain EDI and electronic
   commerce situations is not acceptable. S/MIME specifies
   40 bit RC2 as the default encryption algorithm and key
   length. In some applications neither this default
   algorithm or key length are acceptable. S/MIME can
   accommodate other security algorithms and key lengths
   such as those recommended in section 3.3.2 however.

   PGP/MIME supports a set profile of security algorithms
   and some user configurable key lengths. PGP/MIME  does
   not have the signatory problem as described above for
   S/MIME. However, PGP/MIME does not give the user as much
   flexibility in choosing algorithms and key lengths,
   although the security profile used by PGP/MIME is more
   than adequate to insure confidentiality, non-repudiation
   of origin, and message integrity.



4.0 Tracking and Error Handling Basics

4.1 Introduction

   It's important to recognize that the Value Added Networks
   provide some inherent tracking mechanisms between
   EDI trading partners. In Internet EDI, the ISPs provide
   a certain level of transmission tracking as does the
   TCP/IP protocols themselves. However, not all the
   tracking provided by EDI VANs are completely covered
   by the current TCP/IP protocol suite or ISP tracking.
   The new tracking information associated with the additional
   security requirements and support of signed receipts,
   must be implemented in the EDI UA, in order for Internet
   EDI to be as traceable as VAN EDI.

   Aside from the communications between companies,
   "tracking" touches many other points within the trading
   relationship.  This is where the use of 997 functional
   acknowledgments come in, the EDIFACT CONTRL message, and
   the common translator tracking of sequential group
   control numbers. All of this needs to be considered in
   Internet EDI tracking. In addition, some recent
   developments within S/MIME warrant some analysis --
   "positive acknowledgment", which refers to mail response
   not just if the delivery failed, but also if it
   succeeded.

   The following is a list of the common tracking information needed
   when sending and receiving EDI Interchanges between trading partners:

          1). Transmission successfully translated from
          internal format to EDI standard format.

          2). Transmission successfully encoded, signed,
          encrypted, and sent.(The equivalence of transmission
          successfully received by the VAN.)

          3). Transmission successfully delivered to
          the recipient's mailbox.(The equivalence of a VAN
          delivery acknowledgment that the sent transmission
          has been forwarded to the receiver's VAN mailbox.)

          4). Transmission successfully picked-up by the
          recipient. (The equivalence of a VAN mail-box
          pick-up acknowledgment.)

          5). Transmission successfully translated by the
          receiver. (The EDI Interchange was determined to be
          syntactically correct.)

          6). Detection and recovery of delayed or lost
          transmissions.

          7). Detection and handling of duplicate
          transmissions.

   The following section addresses in what components the
   new Internet EDI tracking information must be maintained,
   and discusses how this new tracking information relates
   to the tracking information kept by the EDI application.


4.2 Transmission Successfully Translated From
    Internal Format to Standard EDI Format

4.2.1 Needs

   There needs to be a facility by which a sender can
   assure that the EDI transmission was correctly
   translated and prepared for outbound transmission.

4.2.2 Recommendations

   This is standard functionality for most if not all EDI
   translators. This should NOT be required functionality
   of an EDI UA.


4.3 Transmission Successfully Encoded, Encrypted, Signed and
    Sent

4.3.1 Needs

   There needs to be a facility by which a sender can be
   assured that an EDI transmission was successfully
   encoded, encrypted, signed, and sent.

4.3.2 Recommendations

   The tracking of the success or failure of the security
   services required for Internet EDI must be maintained by
   the EDI UA.

   The EDI UA needs to be able to identify the transmission
   by its interchange control #, AND a user defined value,
   if desired.

4.4 Transmission Successfully Delivered to the Recipient's
    Mailbox

4.4.1 Needs

   There needs to be a facility by which a sender can be
   assured that an EDI transmission was successfully
   delivered to a recipient's mailbox.

4.4.2 Recommendations

   This type of tracking information is kept by the UA and
   is returned to the sender as a delivery notification. The
   delivery notification is specified in RFC1891-1894.

4.5 Transmission Successfully Received

4.5.1 Needs

   There needs to be a facility by which a sender of a
   transmission can be assured that the transmission was
   correctly received by the intended receiver.

4.5.2  Recommendations

   This type of tracking information is kept by the EDI UA and
   is returned to the sender as a signed receipt. (See section
   3.7.3 for a discussion about signed receipts.)

   Note: The X.12 997 or EDIFACT CONTRL message can also provide
         the equivalent of an implicit transmission received
         acknowledgment. However, the use of signed receipts
         is still recommended for the following reasons:

          * The implied success of the receiver's decryption
            through the receipt of a legible 997, binds the
            certificate to a control ID only (997) and not to
            the actual data (NRR).

          * Translators are very different, and the CONTRL
            message isn't supported by all EDI translators
            or is it in widespread use yet.

4.6 Transmission Successfully Translated by
    the Receiver

4.6.1 Needs

   There needs to be a facility for the sender to be
   assured that the receiver could "understand" (in EDI
   terms) the transmission.

4.6.2 Recommendations

   This should NOT be tracked by the EDI UA, following our
   recommendation for object boundaries.

   The Functional acknowledgment 997, and the EDIFACT
   CONTRL serve this exact purpose - this should be tracked
   by the EDI translator.


4.7  Detection and Recovery of Delayed or Lost Transmissions

4.7.1  Needs

   There needs to be a facility by which a sender can
   detect sent transmissions that have not been
   acknowledged as correctly received, by a specified,
   configurable, period of time, and be able to configure
   actions accordingly.

4.7.2  Recommendations

   1). The use of time stamps for each of the two events:

          * MIME message sent.

          * Signed Receipt received.

   2). The ability to automatically detect transmissions
   that have failed the time trigger.

   3). The ability to configure automatic actions based on
   failure. Actions may include:

          * Re-transmit:  If re-transmitted, the receiving
            UA needs to be able to detect the second
            transmission as a duplicate and discard it.

          * Alert/Report.

          * Ignore/delete - this option may be chosen by
            someone that has decided to track only at the EDI
            translator level through 997/CNTRL.


4.8  Detection and Handling of Duplicate Transmissions

4.8.1  Need

   There needs to be a facility by which a receiver of EDI
   transmissions is able to detect different types of
   duplicate transmissions, and handle them the way they
   should be handled.  First, translator initiated
   duplicates should NOT be halted in any way - we should
   assume that translators will handle that level.  In
   other words, there should be no checking of ISA control
   numbers by the UA.  Secondly, the use of a re-
   transmission feature in attempts to deliver
   transmissions quickly, should allow for a UA to identify
   duplicate transmissions generated by the sending UA, and
   discard of duplicate transmissions after the first has
   been received.

4.8.2  Recommendations

   The ability to pass through translator initiated re-
   transmissions to the receiving translator without a
   hitch.  This means EDI related control numbers, such as
   the ISA control number, should not be checked by the EDI UA.



Appendix A - A Comparison of Security Protocols


                         Version: 3.0

                     Date: July 18, 1996

Sources:

EDIINT- EDI over Internet, Internet Mail Consortium Workshop
data, Chuck Shih, Steve Dusse, David Darnell, Kent
Landfield, David Chia, Rik Drummond, Jeff Cook, Alan Cox,
Ralph Levien, Russ Housley, and many others.



1) Exportable Out Side Of The USA
------------------------------------
PGP V3.0
    * PGP is already outside the USA and except for
      countries that prohibit encrypted messages with long
      key lengths (instead of just restricting the import of
      long key length algorithms) PGP long key length
      messages can be read. This is included in the PGP
      ViaCrypt documentation.

    * No since the encryption algorithm specified is IDEA.

S/MIME
    * Has the 40 and 56 bit export restrictions if RC2 or
      RC4 is used for encryption.

MOSS
    * Not with full key length
    * Depends on the data encryption algorithm used. RFC
      1423 specifies DES in CBC mode, which is not
      exportable. Moss however allows the use of variety of
      cryptographic algorithms.

MSP
    * Depends on the key management and data encryption
      algorithm used. MSP allows the use of variety of
      cryptographic algorithms.


2) Easily Integrated Into Products In A User Transparent
   Manner
------------------------------------------------------------
PGP V3.0
    * Maybe in V.30. Not in earlier versions.
    * There seems to be general disagreement on this one.

S/MIME
    * Yes.

MOSS
    * Do not know.

MSP
    * Yes. Support for signed receipts may require GUI
      enhancements.


3) Fully Compatible With Like Versions World Wide
-----------------------------------------------------
PGP V3.0
    * PGP version 2.6 is compatible with any earlier
      versions. Version 3.0 should be also.

S/MIME
    * RSA has an active interoperability program in place
    * Implementations to the spec should guarantee
      interoperability.

MOSS
    * Moss does not require any particular security
      algorithm. Moss provides the means to identify which
      algorithms are used for each message. A suite of
      algorithms is defined in RFC 1423.

MSP
    * Implementations to the spec should guarantee
      interoperability when the same cryptography is used.


4) Current Implementation Status
----------------------------------
PGP V3.0
    * Version 3.0 is due out 4Q96.
    * Version 2.6 is available.
    * Qualcomm.
    * Premail.
    * Michael's PGPMIME.

S/MIME
    * Two companies have implemented several others have
      committed. Twelve companies currently committed to
      implementing in a pilot sponsored by Commercenet.
    * Products and development tool-kits currently shipping.

MOSS
    * TIS, Innosoft and SupplyTech.

MSP
    * SPYRUS, Nortel, Xerox, LJL, BBN, and J. G. Van Dyke
      all have implementations.
    * Product is shipping.
    * In use for military messages.


5) Confidentiality
------------------
PGP V3.0
    * Yes

S/MIME
    * Yes

MOSS
    * Yes

MSP
    * Yes


6) Signature
------------
PGP V3.0
    * Yes

S/MIME
    * Yes

MOSS
    * Yes

MSP
    * Yes


7) Return Receipt
------------------
PGP V3.0
    * No

S/MIME
    * No

MOSS
    * No

MSP
    * Yes - supports non-repudiation with proof of delivery.


8) Delivery Notification
-------------------------
PGP V3.0
    * Via MIME extensions RFC1891-94.

S/MIME
    * Via MIME extensions RFC1891-94.


MOSS
    * Via MIME extensions RFC1891-94.

MSP
    * Via MIME extensions RFC1891-94.


9) Authentication
-----------------
PGP V3.0
    * Yes

S/MIME
    * Yes

MOSS
    * Yes

MSP
    * Yes


10) Multimedia
--------------
PGP V3.0
    * Yes

S/MIME
    * Yes

MOSS
    * Yes

MSP
    * Yes


11) Integrity
-------------
PGP V3.0
    * Yes

S/MIME
    * Yes

MOSS
    * Yes

MSP
    * Yes


12) Trust Model (Key  Management & Revocation)
-------------------------------------------------
PGP V3.0
    * PGP 3.0 will have hierarchical model of public-key
      certificates.
    * RSA used for key management in current versions.
    * Ad hoc key revocation.

S/MIME
    * RSA based using X.509 all versions.
    * NT's Entrust will be usable with this product very
      soon.

MOSS
    * Both RSA and DES based key management.

MSP
    * X.509 all versions.


13) Certificate (Information, Format, Distribution)
------------------------------------------------------
PGP V3.0
    * Yes using proprietary "Key rings". Not clear what V3
      will use.

S/MIME
    * Yes using X.509 - all versions.

MOSS
    * Yes with optional X.509.

MSP
    * Yes using X.509.


14) Infrastructure Overhead
----------------------------
PGP V3.0
    * Base 64 encoding.

S/MIME
    * ASN.1 - BER and DER encoding.
    * Base 64 encoding.

MOSS
    * Base 64 encoding.

MSP
    * Base64 encoding and ASN.1 encoding.


15) Envelope Type
------------------
PGP V3.0
    * MIME/ ASCII

S/MIME
    * PKCS #7 and MIME

MOSS
    * MIME/ ASCII

MSP
    * MIME /ASN.1


16) Envelope / Structure Specification (ASN1 or ASCII)
-------------------------------------------------------
PGP V3.0
    * ASCII

S/MIME
    * ASN.1 and ASCII

MOSS
    * ASCII

MSP
    * ASN.1


17) Algorithms Supported (List Them: Encryption, Key
    Management, One Way Hash, Digital Signature, Key Lengths
    For Encryption)
------------------------------------------------------------
     -
PGP V3.0
    * RSA and IDEA in pre 3.0.
    * Diffie Hellman and DSA in Ver. 3.0.
    * IDEA in CBC.
    * MD5 & RSA.
    * A 128 for casual grade, 512 commercial grade, 2048
      military grade.
    * A 128 bit IDEA key length.

S/MIME
    * RSA.
    * RC2, RC4 and RC5.
    * MD5 & RSA.
    * SHA-1.
    * Note: S/MIME like Moss is a format and allows any type
      of algorithm to be specified. RSA of course specifies
      their own algorithms.
    * Triple-DES/RC5.

MOSS
    * DES in CBC.
    * RSA or DES.
    * MD2/MD5 and RSA.
    * A 56 bit key lengths for DES.
    * FORTEZZA.
    * Note: Moss like S/MIME allows a variety of
      cryptographic algorithms to be used. The suite of
      algorithms defined above are found in RFC 1423.

MSP
    * Algorithm independent.  Implementations exist  using:
    * RSA & DES.
    * FORTEZZA (DSS SHA-1, KEA, Skipjack).


18) Common Algorithms With EDIFACT AUTACK List Of Codes
-----------------------------------------------------------
PGP V3.0
    * RSA (yes).
    * IDEA (yes).
    * DSA (yes).
    * MD5 (yes).

S/MIME
    * RSA (yes).
    * RC2 and RC4 (yes).
    * DES (yes).
    * MD5 (yes).

MOSS
    * RSA (yes).
    * DES (yes).
    * MD5 (yes).

MSP
    * RSA (yes).
    * DES (yes).
    * MD5 (yes).
    * DSS (yes).
    * SHA-1 (yes).


19) Coexistence With Others For Reception (signature not
    readable) of MIME Multipart/Signed Data
------------------------------------------------------------
PGP V3.0
    * Yes V3.0.

S/MIME
    * Yes, but user selectable.

MOSS
    * Yes.

MSP
    * Yes, if used with MIME encapsulation (see  <draft-
      housley-msp-mime-01.txt>.



20) Signed Message  Body Readable By RFC822/ MIME Readers
------------------------------------------------------------
     -
PGP V3.0
    * Should be in V3.0.

S/MIME
    * Yes -  if one of the options multipart/signed is used.

MOSS
    * Yes.

MSP
    * Yes, if used with MIME encapsulation.


21) Signature Separate From Signed Document
----------------------------------------------
PGP V3.0
    * Yes.

S/MIME
    * No.

MOSS
    * Yes

MSP
    * Yes


22) Backward Compatibility
---------------------------
PGP V3.0
    * To PGP.

S/MIME
    * To PEM.

MOSS
    * To PEM.

MSP
    * No.


23) Uses Proprietary Algorithms?
---------------------------------
PGP V3.0
    * Ver 3.0 will use Diffie-Hellman with expiring patents
      in 1997.  Ver 3.0 will use DSA (Digital Signature
      Algorithm invented at the NSA).


S/MIME
    * Yes, but it supports different options.

MOSS
    * YES, but it supports different.

MSP
    * It supports both standard (FIPS and X9) as well as
      proprietary algorithms.


24) Adequate Security For EDI Purposes
-----------------------------------------
PGP V3.0
    * Yes.

S/MIME
    * Yes.

MOSS
    * Yes.

MSP
    * Yes.


25) Scaleable
-------------
PGP V3.0
    * Not enough experience to tell. The current trust model
      will not scale well.

S/MIME
    * Not enough experience to tell.

MOSS
    * Not enough experience to tell.

MSP
    * Yes.


26) Solid MIME Integration
---------------------------
PGP V3.0
    * V3.0 - yes.

S/MIME
    * Yes - but it mixes PKCS technology with MIME.

MOSS
    * Yes.

MSP
    * Yes  (see  <draft-housley-msp-mime-01.txt>.


27) Variable Key Sizes Supported
----------------------------------
PGP V3.0
    * No.

S/MIME
    * Yes, 40- 128 bit.
    * Symmetric 512-2048 bit RSA.

MOSS
    * Yes.

MSP
    * Yes.
    * Symmetric (DES = 56 bits; SKIPJACK = 80 bits)..
    * Signature (DSS = 512 .. 1024 bits; RSA = 512 .. 2048
      bits).
    * Key Management (KEA = 1024 bits; RSA = 512 .. 2048
      bits).


28) Only X.509 Or Other Certificate Distribution Methods
------------------------------------------------------------
PGP V3.0

S/MIME
    * X.509 any version.

MOSS

MSP
    * X.509 any version.


29) Very Solid API And Took Kit
---------------------------------
PGP V3.0
    * V3.0 Yes - anticipated.

S/MIME
    * Yes.

MOSS
    * No.

MSP
    * Yes. DISA is submitting an API to X/Open.
    * At least two tookkits for sale.


30) Tool Kits Can Be Made Available To All Countries Not
    Under UN Embargo
------------------------------------------------------------
     -
PGP V3.0
    * Probably from alternate sources.

S/MIME
    * Export version probably to most countries.

MOSS
    * Export version probably to most countries .

MSP
    * Export version probably to most countries. Toolkits
      exported to many countries, including France.
    * Alternate source likely.


31) Fit With Future Direction Of EDI
---------------------------------------
PGP V3.0
    * Unknown.

S/MIME
    * Unknown.

MOSS
    * Unknown.

MSP
    * Unknown.


Primary Author's Address:

Chuck Shih
610 Caribbean Drive
Sunnyvale, CA. 94089
Phone: 408-542-3282
Fax:   408-542-3210
e-mail: chucks@actracorp.com


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/