Subject: RE: AS3 Discusion - Overview

From: "Terry Harding" <[email-masked]>
Date: Fri, 21 Oct 2005 11:01:29 -0700

Open for discussion

2.0  Overview

2.1  Overall Operations
    
   A FTP upload operation is used to send appropriately-packaged EDI, 
   XML, or other business data. The receiving application will poll
   the FTP server for inbound messages, unpackage and handle the message
   data and generate a reply for the originator that contains a 
   message disposition acknowledgement within a multipart/report that is
   signed or unsigned. This request/reply transactional interchange 
   provides secure, reliable, and authenticated transport for EDI or   
   other business data using FTP. The security protocols and structures 

Harding, Scott                                                 [Page 3]

INTERNET DRAFT       FTP Transport Data for EDIINT           April 2005

   used also support auditable records of these transmissions.

2.2  Purpose of a security guideline for MIME EDI
    
   The purpose of these specifications is to ensure interoperability
   between B2B Electronic Commerce user agents, invoking some or all of 
   the commonly expected security features. This document is also NOT
   limited to strict EDI use, but applies to any electronic commerce 
   application where business data needs to be exchanged over the 
   Internet in a secure manner.

2.3   Definitions

2.3.1.  Terms

  EDI                  Electronic Data Interchange

  EC                   Business to Business Electronic Commerce

  B2B                  Business to Business

  Receipt              The functional message that is sent from a 
                       receiver to a sender to acknowledge receipt of 
                       an EDI/EC interchange. 

  Signed Receipt       A receipt containing a digital signature.

  Message Disposition  The Internet messaging format used to convey a 
  Notification (MDN)   receipt. This term is used interchangeably with 
                       receipt. A MDN is a receipt.

  Non-repudiation of   NRR is a "legal event" that occurs when the 
  receipt (NRR)        original sender of an EDI/EC interchange has 
                       verified the signed receipt coming back from the 
                       receiver. NRR IS NOT a functional or a technical 
                       message.

  S/MIME               A format and protocol for adding Cryptographic 
                       signature and/or encryption services to Internet 
                       MIME messages.

                       NOTE: While the S/MIME specification describes
                             more than one format for a signed message,
                             all signed messages or receipts used with
                             AS3 MUST utilize the multipart/signed
                             format.

  SHA-1                A secure, one-way hash algorithm used in 
                       conjunction with digital signature. SHA-1 is the
                       recommend algorithm for AS3.

  MD5                  A secure, one-way hash algorithm used in 
                       conjunction with digital signature. This 
                       algorithm is acceptable but not recommended 
                       due to its short key length and known weaknesses.

Harding, Scott                                                 [Page 4]

INTERNET DRAFT       FTP Transport Data for EDIINT           April 2005

  MIC                  The message integrity check (MIC) is a 
                       representation of the message digest, which
                       results from the application of the selected hash
                       algorithm to the content to be signed.  Of 
                       particular interest is the the digital signature,
                       which includes an encrypted copy of the digest.
                       Additionally, an MDN containing a 
                       Received-Content-MIC" header will also contain 
                       (as that header's value) a base-64 encoded
                       representation of the digest.

  User Agent (UA)      The application that handles and processes the 
                       AS3 request.

  STL                  Secure Transmission Loop, described in the next
                       section

2.3.2  The Secure Transmission Loop
   
   This document's focus is on the formats and protocols for exchanging 
   EDI/EC content to which security services have been applied using
   the File Transmission Protocol (FTP) as the transport.

   The "Secure Transmission Loop" (STL) comprises the following two
   steps:
  
     a) The originator sends a signed and encrypted document with a 
        request for a signed receipt.

     b) The recipient decrypts the document, verifies the signature,
        and returns a signed receipt to the sender.
          
   In other words, the following events occur during the execution of
the
   STL:

     - The organization sending EDI/EC data signs and encrypts the data 
       using S/MIME. In addition, the message will request a signed
       receipt to be returned to the sender of the message.

     - The receiving organization decrypts the message and verifies the 
       signature, resulting in verified integrity of the data and
       authenticity of the sender.

     - The receiving organization then returns a signed receipt, as 
       requested to the sending organization in the form of a message
       disposition notification. This signed receipt will contain the
       hash of the signature from the received message, indicating to 
       the sender that the received message was verified and/or
       decrypted properly. 
             
   The above describes functionality which, if implemented, will 
   satisfy all security requirements and provide non-repudiation of 
   receipt for the exchange.  While trading partners will usually want
   to utilize the STL, this specification does not require it.

2.3.3  Definition of Receipts 

Harding, Scott                                                 [Page 5]

INTERNET DRAFT       FTP Transport Data for EDIINT           April 2005

   The term used for both the functional activity and the message for 
   acknowledging delivery of an EDI/EC interchange is "receipt" or 
   "signed receipt".  The term receipt is used if the acknowledgment
   is for an interchange resulting in a receipt which is NOT signed.
   The term signed receipt 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 refers to a legal event which occurs only when the original 
   sender of an interchange has verified the signed receipt coming back
   from the recipient of the message. Note that NRR is not possible 
   without signatures.

   For additional information on formatting and processing receipts
   in AS3, refer to section 7.

2.4  Operational assumptions and options

2.4.1 EDI/EC process assumptions

   - Encrypted object is an EDI/EC Interchange

     This specification assumes that a typical EDI/EC interchange is the
     lowest level object that will be subject to the application of
     security services. 
     
     Specifically, for EDI ANSI X12, the entire document (including
     the ISA and IEA segments) is the atom to which security is applied.
     For EDIFACT, the corresponding definition includes segments UNA/UNB
     and UNZ. In other words, EDI/EC interchanges including envelope 
     segments remain intact and unreadable during secure transport. 
     
   - EDI envelope headers are encrypted

     Congruent with the above statement, EDI envelope headers are 
     NOT visible in the MIME package. In order to optimize routing 
     from existing commercial EDI networks (called Value Added Networks
     or VANs) to the Internet, work may need to be done in the future to
     define ways to extract some elements of the envelope to make
     them visible; however, that is beyond the scope of this
     specification.

   - X12.58 and UN/EDIFACT security considerations

     The most common EDI standards bodies, ANSI X12 and EDIFACT, have
     defined internal provisions for security.  X12.58 is the security
     mechanism for ANSI X12 and AUTACK provides security for EDIFACT.
     This specification DOES NOT dictate use or non-use of these
security
     standards. They are both fully compatible, though possibly 
     redundant, with this specification.

2.4.2  Process options

2.4.2.1 Security options
   
   - Encrypted or un-encrypted data

Harding, Scott                                                 [Page 6]

INTERNET DRAFT       FTP Transport Data for EDIINT           April 2005

     This specification allows for EDI/EC message exchange where the
     EDI/EC data can be either un-protected or protected by means of 
     encryption.

   - Signed or unsigned data

     This specification allows for EDI/EC message exchange with or 
     without digital signature of the original EDI transmission.

   - Use of receipt or not

     This specification allows for EDI/EC message transmission with or 
     without a request for receipt notification.  If a signed receipt
     notification is requested  however, a MIC value is REQUIRED as
     part of the returned receipt, unless an error condition occurs
which
     results in the inability to compute a valid digest.  (Such a case
     would result, for instance, if an encrypted message could not be
     decrypted.) Under such circumstances, an unsigned receipt (MDN) 
     SHOULD be returned with the correct "disposition modifier" error
     value.

   - Security Formatting 

     This specification relies on the guidelines set forth in 
     RFCs 2630 [9] and 2633 [10].  The first of these RFCs describes the
     Cryptograpic Message Syntax (CMS) and the second contains the
S/MIME 
     Version 3 Message Specification describing a MIME container for 
     CMS objects.  Whenever the term S/MIME is used in this document,
     it refers to Version 3 as described therein.

   - Hash function, message digest choices

     When a signature is used, it is RECOMMENDED that the SHA-1 hash
     algorithm be used for all outgoing messages; however, both MD5
     and SHA-1 MUST be supported for incoming messages.

   - Permutation Summary

     In summary, the following twelve security permutations are possible
     in any given trading relationship:

     1.  Sender sends un-encrypted data, does NOT request a receipt.

     2.  Sender sends un-encrypted data, requests an unsigned receipt.
         The receiver sends back the unsigned receipt.

     3.  Sender sends un-encrypted data, requests a signed receipt. The
         receiver sends back the signed receipt.

     4.  Sender sends encrypted data, does NOT request a receipt. 

     5.  Sender sends encrypted data, requests an unsigned receipt. The
         receiver sends back the unsigned receipt. 

     6.  Sender sends encrypted data, requests a signed receipt. The 

Harding, Scott                                                 [Page 7]

INTERNET DRAFT       FTP Transport Data for EDIINT           April 2005

         receiver sends back the signed receipt.

     7.  Sender sends signed data, does NOT request a receipt.

     8.  Sender sends signed data, requests an unsigned receipt.
Receiver
         sends back the unsigned receipt.

     9.  Sender sends signed data, requests a signed receipt. Receiver
         sends back the signed receipt.

     10. Sender sends encrypted and signed data, does NOT request a
         receipt.

     11. Sender sends encrypted and signed data, requests an unsigned
         receipt. Receiver sends back the unsigned receipt.

     12. Sender sends encrypted and signed data, requests a signed
         receipt. Receiver sends back the signed receipt.  This case
         represents the Secure Transmission Loop described above.

2.4.2.2 Compression options

    The AS3 specification supports compression of transmitted data
directly
    through the application of RFC 3274.  Implementation details may be 
    found in that RFC and in Harding's draft, "Compressed Data for
EDIINT",
    currently on a parallel standards track.

Terry Harding
Cyclone Commerce Inc.