EDIINT Working Group                                      Chuck Shih
Internet Draft                                            Mats Jansson
Expires:  6 /98                                           Rik Drummond
                                                          8 July 1997



            Requirements for Inter-operable Internet EDI

                    draft-ietf-ediint-req-05.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 view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (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.

   Shih, Janssen, Drummond                                      Page 1
   Requirements For Inter-operable Internet EDI                 8 July 1997






   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119.

   Feedback Instructions

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

   -Send feedback via e-mail to the ietf-ediint list for discussion,
    with "Requirements" in the Subject field. To enter
    or follow the discussion, you need to subscribe to ietf-
    ediint@imc.org.

  -Be specific as to what section you are referring to, preferably
   quoting the portion that needs modification, after which you state
   your comments.

  -If you are recommending some text to be replaced with your
   suggested text, again, quote the section to be replaced,
   and be clear on the section in question.


                      Table of Contents

SECURITY CONSIDERATIONS                                                  5

1.0 INTRODUCTION                                             6

 1.1 THE AUDIENCE                                            7

2.0 THE INTERNET - A BRIEF HISTORY                           7

 2.1 THE INTERNET - MYTHS AND REALITY                        7

 2.2 INTERNET ROUTING AND SECURITY CONSIDERATIONS            9

 2.3 EDI VAN COMMUNICATIONS AND SECURITY                     11

 2.4 EDI OBJECT BOUNDARIES AND TRANSACTION PRIVACY           12

3.0 FUNCTIONAL REQUIREMENTS                                  12

 3.1  INTRODUCTION AND DEFINITIONS                           12









 Shih, Janssen, Drummond                                      Page 2
 Requirements For Inter-operable Internet EDI                 8 July 1997


 3.2  STANDARD ENCRYPTION ALGORITHMS AND WORLD-WIDE           12
      ENCRYPTION
  3.2.1  INTRODUCTION AND DESCRIPTION                         13
  3.2.2  SYMMETRIC ENCRYPTION                                 14
  3.2.3  ASYMMETRIC ENCRYPTION - PUBLIC-KEY CRYPTOGRAPHY      15
  3.2.4  NEEDS                                                16
  3.2.5  ISSUES                                               16
  3.2.6  RECOMMENDATIONS                                      16

 3.3  KEY MANAGEMENT - SYMMETRIC KEYS                         19
  3.3.1 INTRODUCTION AND DESCRIPTION                          19
  3.3.2 NEEDS                                                 21
  3.3.3 ISSUES                                                21
  3.3.4 RECOMMENDATIONS                                       21

 3.4  KEY MANAGEMENT - PUBLIC AND PRIVATE KEYS                22
  3.4.1 INTRODUCTION AND DESCRIPTION                          22
  3.4.2 PUBLIC KEYS                                           23
  3.4.3 TRUST AND PUBLIC KEYS                                 24
  3.4.4 NEEDS                                                 24
  3.4.5 ISSUES                                                25
  3.4.6 RECOMMENDATIONS                                       25

 3.5  CONTENT INTEGRITY                                       26
  3.5.1 INTRODUCTION AND DESCRIPTION                          26
  3.5.2 NEEDS                                                 27
  3.5.3 ISSUES                                                27
  3.5.4 RECOMMENDATIONS                                       27

 3.6  AUTHENTICATION AND NON-REPUDIATION OF ORIGIN            27
  3.6.1 INTRODUCTION AND DESCRIPTION                          28
  3.6.2 NEEDS                                                 29
  3.6.3 ISSUES                                                29
  3.6.4 RECOMMENDATIONS                                       29

 3.7  SIGNED RECEIPT AND NON REPUDIATION OF                   30
      RECEIPT
  3.7.1  INTRODUCTION AND DESCRIPTION                         30
  3.7.2  NEEDS                                                31
  3.7.3  RECOMMENDATIONS                                      31

 3.8  SYNTAX AND PROTOCOL FOR SPECIFYING CRYPTOGRAPHIC        32
      SERVICES
  3.8.1 INTRODUCTION AND DESCRIPTION                          32
  3.8.2 NEEDS                                                 32
  3.8.3 ISSUES                                                32
  3.8.4 RECOMMENDATIONS                                       33

 Shih, Janssen, Drummond                                      Page 3
 Requirements For Inter-operable Internet EDI                 8 July 1997


4.0 TRACKING AND ERROR HANDLING BASICS                        34

 4.1 INTRODUCTION                                             34

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

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

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

 4.5 TRANSMISSION SUCCESSFULLY RECEIVED                       36
  4.5.1 NEEDS                                                 36
  4.5.2 RECOMMENDATIONS                                       36

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

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

 4.8 DETECTION AND HANDLING OF DUPLICATE                      38
     TRANSMISSIONS
  4.8.1 NEEDS                                                 38
  4.8.2 RECOMMENDATIONS                                       38

5.0 APPENDIX A - IMPLEMENTATION CONSIDERATIONS, FORMATS,      39
    AND EXAMPLES

6.0 ACKNOWLEDGMENTS                                           53

7.0 REFERENCES                                                54

8.0 AUTHOR'S ADDRESSES                                        55

Shih, Janssen, Drummond                                      Page 4
Requirements For Inter-operable Internet EDI                 8 July 1997



Security Considerations

   This document discusses the mechanisms, requirements
   and technologies necessary to conduct secure EDI over
   Internet using either PGP/MIME or S/MIME. It further
   discusses the implementation of encryption, digital
   signature, integrity and signed-receipt for MIME objects
   transported over SMTP or HTTP.



























  Shih, Janssen, Drummond                                      Page 5
  Requirements For Inter-operable Internet EDI                 8 July 1997

1.0  Introduction

   Electronic Data Interchange (EDI) is a set of formats
   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 X12 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. Standards in these and
   other areas described later in this document 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(s).

   Additional requirements that mimic many of the header 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 EDI exchanges between the Internet, and
   the Value Added Networks. However, this specification is not
   intended to cover the EDI VAN and Internet gateway
   requirements.

   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.

  Shih, Janssen, Drummond                                      Page 6
  Requirements For Inter-operable Internet EDI                 8 July 1997


 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
   the Internet supports high bandwidth communications technologies.

 2.1. The Internet - Myths and Reality

   The Internet had its beginnings in 1969 as an

Shih, Janssen, Drummond                                      Page 7
Requirements For Inter-operable Internet EDI                 8 July 1997


   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.

   Shih, Janssen, Drummond                                      Page 8
   Requirements For Inter-operable Internet EDI                 8 July 1997


   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

   Shih, Janssen, Drummond                                      Page 9
   Requirements For Inter-operable Internet EDI                 8 July 1997


   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.

   Shih, Janssen, Drummond                                      Page 10
   Requirements For Inter-operable Internet EDI                 8 July 1997


   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 mail-boxing 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 user-id 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.

   Shih, Janssen, Drummond                                      Page 11
   Requirements For Inter-operable Internet EDI                 8 July 1997


   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.

2.4  EDI Object Boundaries and Transaction Privacy

   The specification by this work group applies to the EDI
   Interchange or Bundle (multiple EDI Interchanges) 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(s). 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.

   As specified by this document, the entire EDI Interchange,
   including the envelope headers (ISA/IEA or UNA/UNB/UNZ)
   are encrypted, when encryption security services are applied.
   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.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

Shih, Janssen, Drummond                                      Page 12
Requirements For Inter-operable Internet EDI                 8 July 1997


     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 the derivation
      of the private key is based on mathematical manipulations
      of large numerical quantities. The security provided
      by asymmetric algorithms is not quite proportional to
      the key length. See section 3.4.2 for more details on
      the RSA public-key encryption algorithm).

      Shih, Janssen, Drummond                                      Page 13
      Requirements For Inter-operable Internet EDI                 8 July 1997


      Regardless of whether a symmetric or asymmetric encryption
      algorithm is used, 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 "pure" symmetric encryption
       schemes; a shared secret key must be agreed upon by both
       parties. If a trading partner has n trading
       partners, 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,
       management of symmetric keys can be simplified to the point
       whereby a symmetric key can be used not only for each
       trading partner, but for each exchange between trading
       partners. In addition, public key cryptography can
       be used to unambiguously establish non-repudiation of
       origin and receipt.

      Shih, Janssen, Drummond                                      Page 14
      Requirements For Inter-operable Internet EDI                 8 July 1997



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.

       In most real world applications, asymmetric encryption
       algorithms are not actually used to encrypt the message
       or part of the message itself. Instead, they are used in
       conjunction with a Message Integrity Check (MIC), and it
       is the MIC that is encrypted using the public key
       encryption algorithm. See section 3.5.1 for details on
       how asymmetric encryption algorithms are applied to a
       MIC.

       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.

      Shih, Janssen, Drummond                                      Page 15
      Requirements For Inter-operable Internet EDI                 8 July 199


       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; whether
       the algorithm is available 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

   Shih, Janssen, Drummond                                      Page 16
   Requirements For Inter-operable Internet EDI                 8 July 1997

   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 its security is considered "known":
   in other words, the security of DES is dependent on the length
   of its key, and estimates can be provided for the time
   and effort required to derive the DES key from a known
   8 byte plain-text/cipher-text pair. 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 [14]. 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 and RC5: RC2 and RC5 are proprietary symmetric
   algorithms of  RSA Data Security, Inc. RC2 and RC5
   unlike DES, are variable-key length algorithms. By specifying
   differing key lengths, RC2 and RC5 can be configured to
   provide greater or lesser security.  RC2 and RC5 are

   Shih, Janssen, Drummond                                      Page 17
   Requirements For Inter-operable Internet EDI                 8 July 1997


   alternatives to DES, and RC2 has special export status,
   whereby 40 bit versions of RC2, and 56 bit versions
   of RC2 for foreign subsidiaries and overseas offices
   of U.S. companies, have expedited export approval from
   the U.S. government. RSA claims that RC2 and RC5 are
   faster than DES when implemented in software. Several products
   such as Lotus Notes, Netscape Navigator, Apple's Open
   Collaboration Environment, Actra's ECXpert, and Premenos'
   Templar make use of these algorithms.

   It is RECOMMENDED that key sizes of 40 bits, 75 bits, and
   128 bits be supported for incoming and outgoing EDI messages,
   when used domestically. U.S. Government restrictions limit |
   RC2 implementations to 40 bits when exported outside the
   United States. RC2 SHOULD be used in CBC mode,
   and RC5 in CVC Pad mode. A key length of 128 bits would
   make a brute force attack on RC2 or RC5 not feasible.

   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
   most commercial applications a key length of at least
   75 bits is RECOMMENDED. See [14] and [15] for additional
   guidance on choosing key lengths. For EDI
   Interchanges of minimal value, 40-bit RC2 or 56-bit
   DES are probably adequate. For more valuable EDI
   interchanges, use of Triple-DES, IDEA, or 128 bit
   length RC2 or RC5 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 its security is "known". RC2 and RC5 are
   useful because they allow the security of the
   encryption - the key length specification, to be

   Shih, Janssen, Drummond                                      Page 18
   Requirements For Inter-operable Internet EDI                 8 July 1997


   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. IDEA's 128 bit key-length provides more than adequate
   security.

   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.

   As previously mentioned, by using public key cryptography,
   management of symmetric keys can be simplified such that
   a symmetric key can be used not only for each
   trading partner, but for each exchange between trading
   partners. In addition, public key cryptography can
   be used to unambiguously establish non-repudiation of
   origin and receipt.

   The use of public-key cryptography, whereby the symmetric
   encryption key is encrypted using an asymmetric encryption
   algorithm, simplifies the management of the symmetric

   Shih, Janssen, Drummond                                      Page 19
   Requirements For Inter-operable Internet EDI                 8 July 1997


   keys and makes their exchange much more secure. Trading
   partners do not need to agree on secret symmetric keys
   as part of the trading partner agreement, nor is there
   the origin authenticity problem that is inherent with pure
   symmetric key management schemes.

   A symmetric key can be randomly generated by the
   software for each EDI transaction between trading
   partners. Symmetric keys generated on a per
   transaction basis are sometimes referred to as
   "session keys". Since a unique symmetric key is
   generated for each EDI transaction, symmetric key maintenance
   is no longer required. Trading partners do not need
   to invalidate compromised or expired keys. Each
   symmetric or "session" 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 using public key
   cryptography for symmetric key management, the following steps
   would be performed when trading partner ABC sends to trading
   partner XYZ:

          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.

   Shih, Janssen, Drummond                                      Page 20
   Requirements For Inter-operable Internet EDI                 8 July 1997


          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 on a transaction basis.
   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

   Agreement by trading partners to use public-key cryptography
   to manage symmetric keys, and to generate a symmetric key
   for each EDI transaction.

   When choosing public-key encryption algorithms,
   the following criteria should be considered; how
   secure the algorithm is; how fast implementations
   of the algorithm are; whether the algorithm
   is available 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

Shih, Janssen, Drummond                                      Page 21
Requirements For Inter-operable Internet EDI                 8 July 1997


   RSA is a public-key encryption algorithm that has
   become a de facto standard in its use for symmetric key
   management. Its use is RECOMMENDED in managing and
   distributing symmetric encryption keys when doing EDI
   over the Internet. The RSA public-key algorithm is not
   patented outside the United States, and therefore can be
   freely used outside the U.S.

   In the United States, the RSA public-key encryption
   algorithm is protected by the following patent:

   R. Rivest, A. Shamir, and L. Adleman
   "Cryptographic Communications System and Method"
   U.S. Patent #4,405,829
   September, 1983

   At this time, a license to use the RSA encryption
   algorithm is required within the United States.

   Both S/MIME and PGP/MIME make use of the RSA
   encryption algorithm to encrypt/decrypt "session
   keys".

   For a recommendation on RSA key lengths, see Section
   3.4.2, on Public Keys.

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 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.

   Shih, Janssen, Drummond                                      Page 22
   Requirements For Inter-operable Internet EDI                 8 July 1997


3.4.2 Public Keys

   A public key is used by an originating trading partner
   to encrypt a symmetric key, and as will be discuss later,
   by a receiving trading partner to verify authenticity of
   the originator.

   The mathematics of public key cryptography is complicated,
   but are based on mathematical manipulations of
   large numerical quantities. In the case of RSA, deriving
   the private key from the public key is based on the difficulty
   in factoring large numbers. An RSA public key
   is generated by multiplying two large prime
   numbers together, deriving the private key from the
   public key involves factoring the product of the two large
   prime number.

   Unlike the symmetric encryption algorithms discussed above,
   the RSA asymmetric encryption algorithm's security is based
   on the size of the number that needs to be factored. The size
   or "modulus" of the product of two prime numbers can be
   factored using some "fast factoring algorithms" which
   currently exist. The computing power required by these
   "fast factoring algorithms" can be estimated, and thus
   the time and cost to factor a number of any given size can
   also be estimated.

   Some estimates which have been put forth claim that
   a 1 "MIP" computer operating for 1 year would take
   74 years to factor a modulus of 100 digits or approximately
   332 bits. A 150 (~500 bits) digit modulus would take 1,000,000 MIP
   years, a 200 digit modulus (~664 bits) 4,000,000,000 MIP years, and
   a 350 digit modulus (~1162 bits) would take 10 to 16th MIP years.

   Given a large enough modulus, it becomes an impossible task
   to "break" or derive a private key from a public key.
   The RSA key length is configurable, but as the cost of computing
   power decreases - assume for instance, a decrease in computing
   costs by a factor of ten every 5 years -- then by the
   year 2030, a 512 bit public key can be "broken" for $10 [14].

   When using the RSA encryption algorithm to encrypt symmetric
   keys, support of 512 bit to 1024 bit variable key lengths
   is REQUIRED. In general, asymmetric algorithms require longer
   keys to provide the same level of security as their symmetric
   key cousins. A comparison of asymmetric key lengths (for
   algorithms like RSA that are based on the factoring problem),

   Shih, Janssen, Drummond                                      Page 23
   Requirements For Inter-operable Internet EDI                 8 July 1997


   needed to provide the equivalent "security" against "brute
   force" attacks can be found in [15]. For example, a 512 bit RSA
   encryption key is equivalent to a 64 bit symmetric key. A 768 bit
   RSA encryption key is equivalent to an 80 bit symmetric key.

   It is RECOMMENDED that for EDI transactions requiring the
   use of RSA encryption to protect "session keys", that at
   least a 768 bit RSA encryption key be used. For very "high"
   value EDI transactions, at least a 1024 bit or higher key
   SHOULD be used.

3.4.3 Trust and Public Keys

   When using public key cryptography, there is a "trust"
   issue that arises: how can one trading partner be sure
   that the public key of another trading partner is bound
   to that trading partner, and is valid?

   Trading partners must exchange public keys or be able to
   access each other's public key in a manner that is acceptable
   to each of the trading partners.

   One method by which trading partners can exchange public key
   information is through the use of public key certificates.

   Public key certificates come in many different formats, and
   the trust model on which they are based also come with different
   underlying assumptions.

   Public key certificates based on the X.509 standards
   however are becoming prevalent in their use. The X.509 certificate
   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.4 Needs

   Adoption of a trust model, or the use of certification
   authorities for issuing commercial grade/class 3

   Shih, Janssen, Drummond                                      Page 24
   Requirements For Inter-operable Internet EDI                 8 July 199


   certificates. Each trading partner must choose a trust
   model. For instance, trading partners can self-certify
   one another, or they could use certification authorities
   acceptable to their other trading partners.

   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 need to be agreed
   to and standardized.

3.4.5 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.6  Recommendations

3.4.6.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, "self-certification" means that 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

   Shih, Janssen, Drummond                                      Page 25
   Requirements For Inter-operable Internet EDI                 8 July 1997


   certificate authorities. It is also RECOMMENDED that trading
   partners exchange certificates using the formats
   and protocols specified by "certificate-only" PKCS7 when using
   S/MIME, and PGP certificate formats and protocols when using
   PGP/MIME.

3.4.6.2 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.

   PKCS7 and PKCS10 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.

   Unlike encryption algorithms however, one-way hash
   functions can't be reversed or "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.

   Shih, Janssen, Drummond                                      Page 26
   Requirements For Inter-operable Internet EDI                 8 July 1997



   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 and MIME content headers. This value
   is unique and "fingerprints" the transaction. 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 and MIME content headers.
   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.

   It is RECOMMENDED that all new implementations use SHA-1
   for outgoing messages, but to continue to accept MD5
   incoming (SHA1 as well) as there already exist many MD5
   implementations.

3.6  Authentication and Non-Repudiation of Origin

Shih, Janssen, Drummond                                      Page 27
Requirements For Inter-operable Internet EDI                 8 July 1997


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 in symmetric key management to encrypt
   a symmetric key. 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 encryption is done with the private key, and
   decryption is done 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 applied the encryption, since
   she is the only one with knowledge of her private key. In
   this way, non-repudiation of origin is achieved.

  Shih, Janssen, Drummond                                      Page 28
  Requirements For Inter-operable Internet EDI                 8 July 199


   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 is authentication and non-repudiation of origin
   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; whether the algorithm is available 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 symmetric 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.

   The RECOMMENDED key lengths when using the RSA encryption
   algorithm for signature, are the same as when using RSA

  Shih, Janssen, Drummond                                      Page 29
  Requirements For Inter-operable Internet EDI                 8 July 1997



  encryption for managing symmetric keys:

   For most EDI transactions requiring digital signatures,
   a 768 bit RSA encryption key SHOULD be used. For
   very "high" value EDI transactions, at least a 1024 bit or
   higher key SHOULD be used.

3.7  Signed Receipt or Non Repudiation of Receipt

3.7.1  Introduction and Description

   The term used for both the functional activity and message for
   acknowledging receipt of an EDI/EC interchange is "receipt", or
   "signed receipt".  The first term is used if the acknowledgment is
   for an interchange resulting in a receipt which is NOT signed.
   The second term is used if the acknowledgment is for an interchange
   resulting in a receipt which IS signed.

   A term often used in combination with receipts is "Non-repudiation
   of Receipt (NRR).  NRR refers to a legal event which occurs only
   when the original sender of an interchange has verified the sender
   and content of a "signed receipt".  Note that NRR is not possible
   without signatures.

   The signed receipt is an acknowledgment sent by the
   receiving trading partner to the sending trading partner.
   The signed receipt is used to address the following
   issues when doing Internet EDI:

          1). The lack of wide-spread RFC 1894 based mailbox delivery
          notification implementations within the Internet mail
          infrastructure.

          2). It provides the equivalent of VAN mailbox delivery
          notification.

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

          4). It provides the equivalent of VAN mailbox
          authentication.

          5). It can 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

   Shih, Janssen, Drummond                                      Page 30
   Requirements For Inter-operable Internet EDI                 8 July 1997


   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 contents 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, and successfully verified by the
          sender.

          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 configurable.

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.
   The results of the IETF receipt working group SHALL be
   adopted as the basis for implementing signed
   receipts. The receipt working group has published an Internet
   RFC 2298 [5], which can be obtained
   off of the IETF World Wide Web site. The EDIINT working
   group has taken on the work item to develop the needed

   Shih, Janssen, Drummond                                      Page 31
   Requirements For Inter-operable Internet EDI                 8 July 1997



   extensions to the MDN RFC that is required within an EDI
   environment. See Internet Draft draft-ietf-ediint-as1-04.txt:
   "MIME-based Secure EDI" [10].

   When a signed receipt is used by trading partners, the
   message integrity check that is verified by the receiving
   trading partner must be returned to the originating trading
   partner in the signed receipt.

   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 MUST be implemented using a
   MIME multipart/signed type/subtype with the message
   disposition notification as the first part of the
   content of the multipart/signed. A MIC is then
   calculated over the message disposition notification, and
   this MIC is digitally signed and MUST be returned as the second
   part of the multipart/signed content.


3.8  Syntax and Protocol for Specifying Cryptographic
       Services

3.8.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, and public-key certificates, need to be
   enveloped and sent along with the EDI Interchange.

3.8.2 Needs

   A syntax and protocol for specifying EDI Interchanges that
   have had cryptography applied to them, 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.8.3 Issues

   The IETF EDIINT work group has put together a matrix
   comparing many of the different ways that EDI with

   Shih, Janssen, Drummond                                      Page 32
   Requirements For Inter-operable Internet EDI                 8 July 1997


   cryptography applied to it can be transmitted. Several
   standards appear to fulfill the security requirements
   needed by this work group.

   S/MIME [8], and PGP/MIME [4] are both viable alternatives.
   Each has its strengths and weaknesses:

   The S/MIME specification allows "signed and enveloped"
   and "signed" to be distinguished. The signatories in an
   S/MIME "signed and enveloped" content type can be
   distinguished, which in certain EDI and electronic
   commerce situations is not acceptable. However, the S/MIME
   Implementation Guide, Version 2 [11], does address this
   concern by specifying that "signed and enveloped" not be
   used, and a two step sign and then encrypt process be used
   instead.

   S/MIME is very flexible and can accommodate many different security
   algorithms and key lengths.

   PGP 4.5 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 4.5 does not give the user as much
   flexibility in choosing algorithms and key lengths,
   although the security profile used by PGP 4.5 is more
   than adequate to insure confidentiality, non-repudiation
   of origin, and message integrity.

   The recommended security format should also be transport independent
   so it can be used with different Internet transports. The
   standard should have broad support, and implementations
   should be available.

3.8.4  Recommendations

   Either one of S/MIME or PGP/MIME fulfill the
   requirements of the EDIINT work group. The S/MIME
   Implementation Guide [11], requires the signedData format
   be supported, and the multipart/signed, as specified
   in RFC 1847 [6], is recommended. For use in Internet
   EDI, support of multipart/signed is REQUIRED, and
   signedData is RECOMMENDED only when sending EDI through
   known gateways that do not honor 7-bit transfer encoding.

   PGP/MIME is based on multipart/signed and multipart/encrypted.

   Shih, Janssen, Drummond                                      Page 33
   Requirements For Inter-operable Internet EDI                 8 July 1997


   The Appendix of this document specifies how S/MIME, and PGP/MIME
   are to be applied for use in Internet EDI. See section 5.4
   for implementation notes, and examples on S/MIME and PGP/MIME
   formats.

4.0 Tracking and Error Handling Basics

4.1 Introduction

   It is 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.

   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

         Shih, Janssen, Drummond                                      Page 34
         Requirements For Inter-operable Internet EDI                 8 July 1997


          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
   be assured 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 MUST 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.

   Shih, Janssen, Drummond                                      Page 35
   Requirements For Inter-operable Internet EDI                 8 July 1997


   The EDI UA MUST be able to identify the transmission
   by its message id, AND a calculated MIC 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 RFC 1894 [12].

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 MUST be 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 X12 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 (signed receipt).

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


   Shih, Janssen, Drummond                                      Page 36
   Requirements For Inter-operable Internet EDI                 8 July 1997



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 sender should specify that a receipt or signed
       receipt be returned in response to the sent message.
       The way to request that a receipt or message
       disposition notification be returned by the recipient
       is specified in RFC 2298 [5].
       The way to request that a signed receipt be returned
       by the recipient is specified in draft-ietf-ediint-
       as1-04.txt [10].

   2). Both the receipt and signed receipt return the
       message id that was sent in the original message.
       In addition to the original message id, the signed
       receipt also returns the message integrity check
       calculated on the contents of the received message.

   3). The information in the receipt or signed receipt
       can then be used to correlate to the originally

   Shih, Janssen, Drummond                                      Page 37
   Requirements For Inter-operable Internet EDI                 8 July 1997


       signed message. NOTE: A receipt or signed receipt
       MUST NOT be requested when sending a receipt or
       signed receipt. This is explicitly prohibited by
       the standards.

   4). If a receipt or signed receipt is not returned
       within a configurable time, then actions based
       on the failure to receive a receipt or signed
       receipt may include:

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

          * Alert/Report: Operator intervention may be required
            to track the cause of the delay in receiving the
            receipt or signed receipt.

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 correctly.
   First, translator initiated duplicates SHOULD NOT be
   halted in any way - it should be assumed that translators
   will handle that level of duplication. 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 the duplicate transmissions after the first
   has been received.

4.8.2  Recommendations

   By applying a signature to the EDI MIME content,
   the originator will send a message integrity check
   to the recipient of the transmission. The recipient
   SHOULD log the received message integrity check
   along with the other security related information
   associated with the received message.

   Duplicate messages can be detected by the recipient
   by comparing the message integrity check received
   each time, with the log of received message integrity

   Shih, Janssen, Drummond                                      Page 38
   Requirements For Inter-operable Internet EDI                 8 July 1997


   checks. It is recommended that EDI UAs, in order to
   detect duplicate transmissions, agree minimally to
   sending and receiving signed content.

   EDI related control numbers, such as the ISA
   control number, should not be checked by the
   EDI UA. A duplicate EDI message can still be
   distinguished at the MIME messaging level, since
   EDI time stamps will change, even if the EDI control
   number or EDI transaction are duplicates.

5. Appendix A - Implementation Considerations, Formats, and Examples

5.1  Introduction

     The following appendix describes the structure of EDI MIME
     messages, making use of the security features previously
     discussed in this requirements document.

     The structures shown below represent the use of specifications
     outlined in the following RFCs. Before moving into the structures
     themselves, there is a brief review of what each document
     contributes.

     NOTE: The examples below are just that - examples.  Do not code
     according to them.  Refer to the RFCs that specify the correct
     grammar in each case.

5.2  Referenced RFCs and their contribution

     5.2.1 RFC 821 SMTP [7]

     This is the core mail transfer standard that all MTAs need to
     adhere to.


     5.2.2 RFC 822 Text Message Format [3]

     Defines message header fields and the parts making up a message.

     5.2.3 RFC 1847 MIME Security Multiparts [6]

     This document defines security multiparts for MIME:
     multipart/encrypted and multipart/signed.

     5.2.4 RFC 1892 Multipart/report [10]

    Shih, Janssen, Drummond                                      Page 39
    Requirements For Inter-operable Internet EDI                 8 July 1997


     This RFC defines the use of Multipart/report content type,
     something that the MDN RFC 2298 builds upon to define
     the receipts functionality.


     5.2.5 RFC 1767 EDI Content [2]

     This RFC defines the use of content type "application" for ANSI
     X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and
     mutually defined EDI (application/EDI-Consent).


     5.2.6 RFC 2015 PGP/MIME [4]

     This RFC defines the use of content types
     "multipart/encrypted", "multipart/signed", "application/pgp
     encrypted" and "application/pgp-signature" for defining MIME PGP
     content.

     5.2.7 RFC 2045, 2046, and 2049 MIME [1]

     These are the basic MIME standards, upon which all MIME
     related RFCs build, including this one.

     Key contributions include definition of
     "content type", "sub-type" and "multipart", as well as encoding
     guidelines,  which establishes 7-bit US-ASCII as the canonical
     character set to be used in Internet messaging.

     5.2.8 RFC2298 - Message Disposition Notification [5]

     This RFC defines how a message disposition notification
     (MDN) is requested, and the format and syntax of the MDN. The MDN
     is the basis upon which receipts and signed receipts are defined
     for Internet EDI.

     5.2.9 RFC2311 and RFC2312 -- S/MIME Message Specification [8]

     These specifications describes how MIME shall carry PKCS7
     envelopes.

5.3  Structure of an EDI MIME message - No encryption/No signature

To:             <recipient email>
Subject:
From:           <sender email>
Date:           <date>

Shih, Janssen, Drummond                                      Page 40
Requirements For Inter-operable Internet EDI                 8 July 1997


Mime-Version:   1.0
Content-Type: Application/<EDI standard>
Content-Transfer-Encoding: <encoding>

<EDI object>

5.4  Structure of an EDI MIME message - S/MIME

      5.4.1 S/MIME Overview

      S/MIME or the Secure/Multipurpose Internet Mail Extensions,
      specify formats and procedures when the cryptographic security
      services of authentication, message integrity, non-repudiation
      of origin, and confidentiality are applied to Internet
      MIME messages.

      S/MIME is specified in Internet RFC 2311 and RFC 2312 [8], and
      an S/MIME implementation guide [11]is available from RSA
      Data Securities, Inc.

      This applicability statement sets forth the implementation
      requirements and recommendations needed to use S/MIME when
      sending EDI on the Internet. These implementation
      requirements and recommendations are intended to ensure
      a base level of inter-operability among S/MIME EDI
      implementations.

      NOTE: The S/MIME Implementation Guide, Version 2 specifies a
      restricted profile for use for export purposes and an
      unrestricted profile for use domestically. These
      profiles specify the cryptographic algorithms and key
      lengths that a conforming S/MIME implementation must
      support. It is RECOMMENDED for Internet EDI, that
      these profiles be adhered to. However, cryptographic
      algorithms, and key lengths are parameters that need
      to be set by the trading partnership, and can vary
      from what is specified by the S/MIME implementation
      guide, as well as this specification.

      Content Types:

      The signedAndEnvelopedData content type SHOULD NOT be
      used when sending EDI on the Internet. Objections have
      been raised concerning the fact that the issuerAndSerialNumber
      for each signer of a signedAndEnvelopedData content is
      left in the clear. This information could be used to
      derive the identity of the signer of the message. The

     Shih, Janssen, Drummond                                      Page 41
     Requirements For Inter-operable Internet EDI                 8 July 1997


      use of signedAndEnvelopedData also precludes the ability
      to sign information that is in addition to, but
      separate from the primary signed contents. The use of
      S/MIME "authenticated attributes" is not required for
      Internet EDI, since it is generally sufficient to sign
      the EDI MIME content and headers.

      The S/MIME Implementation Guide, Version 2 requires a compliant
      S/MIME agent to support the nesting of a signed "message" format
      within an enveloped "message", for both incoming and outgoing
      messages. For Internet EDI, it is also REQUIRED that implementations
      support a nested signed "message" within an enveloped or
      encrypted "message". Therefore, when using S/MIME for the
      purpose of Internet EDI, a two step process
      MUST be used: the user agent first creates a multipart/signed
      "content", and uses this multipart/signed "content" as input
      to the creation of an application/pkcs-7-mime enveloped
      "message".

      The receiver of an incoming enveloped "message" that is
      decrypted and found to contain a multipart/signed
      "content", MUST process the multipart/signed "content"
      and present the signature status and corresponding
      first body part of the multipart/signed to the
      receipts processing -- if either a request
      for a receipt or signed receipt has been made --
      otherwise, the first body part of the multipart/signed
      is passed to a general MIME processor.

      For the purpose of Internet EDI, the first body part of the
      multipart/signed SHOULD contain RFC 1767 specified MIME
      EDI content, or a MIME multipart/mixed content that has
      at least one RFC 1767 MIME EDI content as part of the
      multipart/mixed content.

      Multipart/Signed and signedData:

      The S/MIME specification requires support of the signedData
      content format, and recommends support of the multipart/signed
      format. For use in Internet EDI however, it is REQUIRED that
      the multipart/signed format be supported, whenever message authentication,
      integrity, and non-repudiation of origin are used. The
      great value for support of the multipart/signed format is
      the ability of non S/MIME-enabled agents to process the
      content of the body that was signed.

      The PKCS7 signedData format MAY be used only when it is known

     Shih, Janssen, Drummond                                      Page 42
     Requirements For Inter-operable Internet EDI                 8 July 1997



      that the EDI data is to pass through non RFC 1847 compliant
      gateways.

      Some non RFC 1847 compliant gateways do not treat the message
      contents as opaque, and may change the content transfer
      encoding, thereby invalidating the message integrity check
      that was calculated by the sender.

      Support of the PKCS7 signedData format for use in Internet EDI
      is OPTIONAL, and MUST be agreed upon between trading partners.

5.4.2 Example: S/MIME - Signature Only (Multipart/Signed)

To:             <recipient email>
Subject:
From:           <sender email>
Date:           <date>
Mime-Version:   1.0
Content-Type: multipart/signed; boundary="separator";
    micalg=rsa-<hash symbol>; protocol="application/pkcs7-signature"

--separator
    &Content-Type: Application/<EDI standard>
    &Content-Transfer-Encoding: <encoding>
    &
    &<EDI object>

--separator
    Content-Type: application/pkcs7-signature

    fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQer
    /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/D
    frtFFKFG+GFff=
    =ndaj

--separator--

Notes:

-The lines preceded with "&" is what the signature is calculated
 over.

5.4.3 Example: S/MIME - Signature Only (signedData)

To:             <recipient email>
Subject:
From:          <sender email>

Shih, Janssen, Drummond                                      Page 43
Requirements For Inter-operable Internet EDI                 8 July 1997


Date:           <date>
Mime-Version:   1.0
Content-Type: application/pkcs7-mime
Content-Transfer-Encoding: base64

<PKCS7 control information - signed>

      &Mime-Version:   1.0
      &Content-Type: Application/<EDI standard>;
      &Content-Transfer-Encoding: <encoding>
      &
      &<EDI object>

<PKCS7 signature information>


Notes:

-The lines preceded with "&" is what the signature is calculated
 over

- <PKCS7 control information - signed> consists of (refer to:
   PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):

    ContentType = SignedData
    version = Version
    digestAlgorithms = DigestAlgorithmIdentifiers
    contentType = Data
    content =

    NOTE: that except for ContentType and Content, the actual object
    identifiers or values for the fields are not specified. (See
    PKCS9 and the S/MIME Implementation Guide, Version 2 from
    RSA Labs, Inc., for these object identifiers.)

- <PKCS7 signature information> consists of (refer to:
   PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):

    signerInfos = SignerInfo

    NOTE: The signerInfo contains the digestAlgorithm, the
    digestEncryptionAlgorithm, and the encryptedDigest or the digital
    signature. The issuerAndSerialNumber field defined within the
    signerInfos identifies a signing trading partner's public-key
    certificate. Since Internet EDI allows self-certification, this
    field can contain the distinguished name of the sending trading
    partner or it can contain an actual issuer's distinguished name.


   Shih, Janssen, Drummond                                      Page 44
   Requirements For Inter-operable Internet EDI                 8 July 199


5.4.4 Example: S/MIME - Encryption Only

To:             <recipient email>
Subject:
From:         <sender email>
Date:          <date>
Mime-Version: 1.0
Content-Type: application/pkcs7-mime
Content-Transfer-Encoding: base64

<PKCS7 control information - enveloped>

      &Mime-Version:   1.0
      &Content-Type: Application/<EDI standard>;
      &Content-Transfer-Encoding: <encoding>
      &
      &<EDI object>


Notes:

-The text preceded by "&" indicates that it is really encrypted,
 but presented as text for clarity

- <PKCS7 control information - enveloped> consists of (See
  PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):

    contentType = EnvelopedData
    version = Version
    recipientInfos = RecipientInfos

    contentType = Data
    contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier

    encryptedContent =

    NOTE: Except for contentType, the actual object identifiers or
    values for the fields are not specified. (See PKCS9 and the
    S/MIME Implementation Guide, Version 2 from RSA Labs, Inc.,
    for these objects.)

    NOTE: The recipientInfos contains the symmetric encryption key
    encrypted with the receiver's public key. The
    issuerAndSerialNumber field defined within the recipientInfos
    identifies a receiving trading partner's public-key
    certificate. Since Internet EDI allows self-certification,
    this field can contain the distinguished name of the

   Shih, Janssen, Drummond                                      Page 45
   Requirements For Inter-operable Internet EDI                 8 July 1997


    receiving trading partner or the issuer distinguished name.
    NOTE: In general there will be one recipientInfos specified, but
    in the case of RFQs, there may be n recipientInfos specified.

5.4.5 Example: S/MIME - Signature and Encryption (Multipart/Signed)

The required support for EDI Internet is to first create a MIME
multipart/signed content, and then to create an
application/pkcs7-mime envelopedData message with the
multipart/signed content as the input to the envelopedData message.

To:           <recipient email>
Subject:
From:         <sender email>
Date:          <date>
Mime-Version: 1.0
Content-Type: application/pkcs7-mime
Content-Transfer-Encoding: base64

<PKCS7 control information - enveloped>

    *Content-Type: multipart/signed; boundary="separator";
    *              micalg=rsa-<hash symbol>;
    *              protocol="application/pkcs7-signature"
    *
    *--separator
    *   &Content-Type: Application/<EDI standard>
    *   &Content-Transfer-Encoding: <encoding>
    *   &
    *   &<EDI object>
    *
    *--separator
    *   Content-Type: application/pkcs7-signature
    *   Content-Transfer-Encoding: <encoding>
    *
    *   fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//
    *   /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88
    *   frtFFKFG+GFff=
    *
    *--separator--

Notes:

- The lines preceded with "&" is what the signature is calculated
  over.

- The text preceded by  "*" indicates that it is really encrypted, but

 Shih, Janssen, Drummond                                      Page 46
 Requirements For Inter-operable Internet EDI                 8 July 1997


  presented as text for clarity.

- <PKCS7 control information - enveloped> consists of (See
  PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):

    contentType = EnvelopedData
    version = Version
    recipientInfos = RecipientInfos

    contentType = Data
    contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier

    encryptedContent =

    NOTE: Except for contentType, the actual object identifiers or
    values for the fields are not specified. (See PKCS9 and the
    S/MIME Implementation Guide, Version 2 from RSA Labs, Inc.,
    for these objects.)

    NOTE: The recipientInfos contains the symmetric encryption key
    encrypted with the receiver's public key. The
    issuerAndSerialNumber field defined within the recipientInfos
    identifies a receiving trading partner's public-key
    certificate. Since Internet EDI allows self-certification,
    this field can contain the distinguished name of the
    receiving trading partner or the issuer distinguished
    name.

    NOTE: In general there will be one recipientInfos specified, but
    in the case of RFQs, there may be n recipientInfos specified.

5.4.6 Example: S/MIME - Signature and Encryption (signedData)

To:             <recipient email>
Subject:
From:         <sender email>
Date:          <date>
Mime-Version: 1.0
Content-Type: application/pkcs7-mime
Content-Transfer-Encoding: base64

<PKCS7 control information - enveloped>

         *Content-Type: application/pkcs7-mime
         *<PKCS7 control information - signed>
         *
         *&Content-Type: Application/<EDI standard>;

Shih, Janssen, Drummond                                      Page 47
Requirements For Inter-operable Internet EDI                 8 July 1997


         *&Content-Transfer-Encoding: <encoding>
         *&<EDI object>
         *
         *<PKCS7 signature information>


Notes:

- The lines preceded with "&" is what the signature is calculated
  over.

- The text preceded by "*" indicates that it is really encrypted, but
  presented as text for clarity

- <PKCS7 control information - enveloped> consists of (See
  PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):

    contentType = EnvelopedData
    version = Version
    recipientInfos = RecipientInfos

    contentType = Data
    contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier

    encryptedContent =

    NOTE: Except for contentType, the actual object identifiers or
    values for the fields are not specified. (See PKCS9 and the
    S/MIME Implementation Guide, Version 2 from RSA Labs, Inc.,
    for these objects.)

    NOTE: The recipientInfos contains the symmetric encryption key
    encrypted with the receiver's public key. The
    issuerAndSerialNumber field defined within the recipientInfos
    identifies a receiving trading partner's public-key
    certificate. Since Internet EDI allows self-certification,
    this field can contain the distinguished name of the
    receiving trading partner or an issuer's distinguished
    name.

    NOTE: In general there will be one recipientInfos specified, but
    in the case of RFQs, there may be n recipientInfos specified.

- <PKCS7 signature information> consists of (refer to:
   PKCS7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):

    signerInfos = SignerInfo

Shih, Janssen, Drummond                                      Page 48
Requirements For Inter-operable Internet EDI                 8 July 1997


    NOTE: The signerInfo contains the digestAlgorithm, the
    digestEncryptionAlgorithm, and the encryptedDigest or the digital
    signature. The issuerAndSerialNumber field defined within the
    signerInfos identifies a signing trading partner's public-key
    certificate. Since Internet EDI allows self-certification, this
    field can contain the distinguished name of the sending trading
    partner or an issuer's distinguished name.


5.5 Structure of an EDI MIME message - PGP/MIME

5.5.1 Overview

      PGP provides two functional services, signature and encryption,
      but in reality performs 5 functions in order to do it
      effectively.

      1) Digital signature (MD5, RSA)
      2) Compression (ZIP)
      3) Message Encryption (IDEA)
      4) ASCII Armor
      5) Message segmentation

      When sending a message, the services are performed in that
      order.

      With the exception of item 5), these services are optional,
      meaning a user can choose whether to use signature, encryption,
      compression and ASCII armor, but commonly, 2) and 4) are always
      used, while 1) and 3) are used in three ways:

      1) Signature only, in which case ASCII armor can be applied only
         to the signature block to keep the message legible.

      2) Encryption only

      3) Both signature and encryption


      Applicability of PGP/MIME and RFC 2015, for use in Internet EDI
      dictates the following:

      - When both encryption and signature feature is used, the EDI
      data is first signed, then encrypted in a two-step process, as
      described in the example.

      -Compression and ASCII Armor is optional and could be user

Shih, Janssen, Drummond                                      Page 49
Requirements For Inter-operable Internet EDI                 8 July 1997


      configurable.

      The following examples describe use of PGP/MIME without
      compression and ASCII armor, since those services are managed by
      PGP, and are optional per this draft


5.5.2 Example: PGP/MIME - Signature Only

To:             <recipient email>
Subject:
From:           <sender email>
Date:           <date>
Mime-Version:   1.0
Content-Type: multipart/signed; boundary="separator";
    micalg=pgp-<hash symbol>; protocol="application/pgp-signature"

--separator
    &Content-Type: Application/<EDI standard>
    &Content-Transfer-Encoding: <encoding>
    &
    &<EDI object>

--separator
    Content-Type: application/pgp-signature

    -----BEGIN PGP MESSAGE-----
    Version 2.6.2

    fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQer
    /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/D
    frtFFKFG+GFff=
    =ndaj
    -----END PGP MESSAGE-----

--separator--

Notes:

-The lines preceded with "&" is what the signature is calculated
 over.


5.5.3 Example: PGP/MIME - Encryption Only

To:             <recipient email>
Subject:

Shih, Janssen, Drummond                                      Page 50
Requirements For Inter-operable Internet EDI                 8 July 1997


From:           <sender email>
Date:           <date>
Mime-Version:   1.0
Content-Type: multipart/encrypted; boundary="separator";
    protocol="application/pgp-encrypted"

--separator
    Content-Type: application/pgp-encrypted

    Version: 1

--separator
    Content-Type: application/octet-stream

    -----BEGIN PGP MESSAGE-----
    Version 2.6.2

    &<pgp control information>
    &Content-Type: Application/<EDI standard>;
    &Content-Transfer-Encoding: <encoding>
    &
    &<EDI object>
    -----END PGP MESSAGE-----

--separator--

Notes:

-The text preceded by "&" indicates that it is really encrypted, but
 presented as text for clarity

-"pgp control information" contains the following, but refer to PGP
 specifications or tool kits for details:

    -Key ID of recipient's public key
    -Session key (symmetric)
    -Timestamp
    -Key ID of sender's public key
    -Leading two octets of message digest
    -Message digest
    -Filename
    -Timestamp


5.5.4 Example: PGP/MIME - Signature and Encryption

The sequence here is that the EDI data is first signed as a

Shih, Janssen, Drummond                                      Page 51
Requirements For Inter-operable Internet EDI                 8 July 1997


multipart/signed body, and then the data plus the signature is
encrypted to form the final multipart/encrypted body.

To:             <recipient email>
Subject:
From:           <sender email>
Date:           <date>
Mime-Version:   1.0
Content-Type: multipart/encrypted; boundary="separator";
    protocol="application/pgp-encrypted"

--separator
    Content-Type: application/pgp-encrypted

    Version: 1

--separator
    Content-Type: application/octet-stream

    -----BEGIN PGP MESSAGE-----
    Version 2.6.2

*    <pgp control information>
*    Content-Type: multipart/signed; boundary="signed separator";
*       micalg=pgp-<hash symbol>; protocol="application/pgp-signature"
*
*    --signed separator
*        &Content-Type: Application/<EDI standard>
*        &Content-Transfer-Encoding: <encoding>
*        &
*        &<EDI object>
*
*    --signed separator
*        Content-Type: application/pgp-signature
*
*        -----BEGIN PGP MESSAGE-----
*        Version 2.6.2
*
*        fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytd
*        /GIUIUgsIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF
*        frtFFKFG+GFff=
*        =ndaj
*        -----END PGP MESSAGE-----
*
*    --signed separator--
     -----END PGP MESSAGE-----

--separator-

Shih, Janssen, Drummond                                      Page 52
Requirements For Inter-operable Internet EDI                 8 July 199


Notes:

- The lines preceded with "&" is what the signature is calculated
 over.

- The text preceded by "*" indicates that it is really encrypted,
  but presented as text for clarity

- "pgp control information" contains the following, but refer to
  PGP specifications or tool kits for details:

    -Key ID of recipient's public key
    -Session key (symmetric)
    -Timestamp
    -Key ID of sender's public key
    -Leading two octets of message digest
    -Message digest
    -Filename
    -Timestamp

-RFC 2015 allows another way to handle the above in a combined
fashion,  However, for the purpose of EDI we require the above method,
which is based on MIME Security Multiparts [4] RFC 1847. This method
performs signature and encryption in a two-step process, first signing
the data, then encrypting it.  This is also consistent with PGP's
recommendations.

5.6 Additional Considerations

RFC 1847 [6] and RFC 1848 [13] provide valuable guidance
when implementing the multipart/signed content. In particular,
RFC 1848 provides the canonicalization considerations required
when implementing the multipart/signed content.

6. Acknowledgments

   The authors would like to extend special thanks to Lincoln
   Yarbrough for his support and championing of these open
   Internet EDI standards.

   This document is the result of the many contributions of the
   members of the IETF EDIINT Working group, including Harald
   Alvestrand, Jim Galvin, Karen Rosenthal, Dale Moberg, Carl Hage,
   Jun Ding, and Pedro Chiang.


Shih, Janssen, Drummond                                      Page 53
Requirements For Inter-operable Internet EDI                 8 July 1997


7. References

[1]  N. Borenstein,  N.Freed, "Multipurpose Internet Mail Extensions
     (MIME) Part One: Format of Internet Message Bodies", RFC 2045,
     December 02, 1996.

     N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions
     (MIME) Part Two: Media Types", RFC 2046, December 02,
     1996.

     N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions
     (MIME) Part Five: Conformance Criteria and Examples", RFC
     2049, December 02, 1996.

[2]  D. Crocker, "MIME Encapsulation of EDI Objects",  RFC 1767,
     March 2, 1995.

[3]  D. Crocker, "Standard for the Format of ARPA Internet Text
     Messages", STD 11,  RFC 822,  August 13, 1982.

[4]  M. Elkins, "MIME Security With Pretty Good Privacy (PGP)",  RFC
     2015, Sept. 1996.

[5]  R. Fajman, "An Extensible Message Format for Message Disposition
     Notifications", RFC 2298, March 1998.

[6]  J. Galvin, S. Murphy, S. Crocker, N. Freed,  "Security Multiparts
     for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847,
     Oct. 3, 1995.

[7]  J. Postel, "Simple Mail Transfer Protocol",  STD 10, RFC 821,
     August 1, 1982.

[8]  S. Dusse, "S/MIME Version 2 Message Specification; PKCS Security
     Services for MIME", RFC 2311 RFC 2312, March 1998.

[9] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting
    of Mail System Administrative Messages",  RFC 1892,  January 15,
    1996.

[10] M. Jansson, C. Shih, R. Drummond, "MIME-based Secure EDI",
     Internet draft: draft-ietf-ediint-as1-04.txt, June 9,
     1997.


Shih, Janssen, Drummond                                      Page 54
Requirements For Inter-operable Internet EDI                 8 July 1997


[11] S/MIME Editor, "S/MIME Implementation Guide, Interoperability
     Profiles, Version 2", Draft, Revised October 8, 1996.

[12] K. Moore, G. Vaudreuil, "An Extensible Message Format for
     Delivery Status Notification", RFC 1894, January, 1996.

[13] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security
     Services", RFC 1848, October, 1995.

[14] B. Schneier, "E-Mail Security", John Wiley & Sons, 1995.

[15] B. Schneier, "Applied Cryptography", 2e. John Wiley & Sons, 1996.

[16] M. Blaze, W. Diffie, R. L. Rivest, B. Schneier, T. Shimomura,
     E. Thompson, M. Wiener, "Minimal Key Lengths for
     Symmetric Ciphers to Provide Adequate Commercial Security".


8. Author's Address:

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

Mats Jansson
mjansson@agathon.com
LiNK
1026 Wilmington Way
Redwood City, CA 94062 USA

Rik Drummond
drummond@onramp.net
The Drummond Group
5008 Bentwood Ct.
Ft. Worth, TX 76132 USA

Shih, Janssen, Drummond                                      Page 55
Requirements For Inter-operable Internet EDI                 8 July 1997