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

Versions: 00 01 02 03 04 RFC 4823

EDIINT Working Group                                     Terry Harding
Internet draft                                           Richard Scott
Expires: August 2006

                                                          January 2006

                FTP Transport for Secure Peer-to-Peer
              Business Data Interchange over the Internet

                     draft-ietf-ediint-as3-04.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Harding, Scott                                                 [Page 1]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006



Abstract

  This Applicability Statement (AS) describes how to exchange structured
  business data securely using the File Transfer Protocol (FTP) for XML,
  Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or
  other data used for business-to-business data interchange for which
  MIME packaging can be accomplished using standard MIME content-types.
  Authentication and data confidentiality are obtained by using
  Cryptographic Message Syntax (S/MIME) security body parts.
  Authenticated acknowledgements employ multipart/signed replies to the
  original message.


Table of Contents

1.  Introduction
2.  Overview
   2.1  Overall operations
   2.2  Purpose of a security guideline for MIME EDI
   2.3  Definitions
   2.4  Operational assumptions and options
     2.4.1  EDI process assumptions
     2.4.2  Process options
     2.4.2.1  Security options
     2.4.2.2  Compression options
3.  Referenced RFCs
   3.1  RFC 959 File Transfer Protocol
   3.2  RFC 2228 FTP Security Extensions
   3.3  RFC 1847 MIME Security Multiparts
   3.4  RFC 1892 Multipart/report
   3.5  RFC 1767 EDI Content
   3.6  RFC 2045, 2046, 2049: MIME
   3.7  RFC 2298 Message Disposition Notification
   3.8  RFC 2633, 2630: S/MIME Version 3 Message Specifications
   3.9  RFC 2632 S/MIME Version 3 Certificate Handling
   3.10 RFC 3274 Compressed Data Content for Cryptographic Message
                 Syntax
   3.11 RFC 3023 XML Media Types
4.  Structure of an AS3 message
   4.1  Introduction
   4.2  Structure of EDI MIME message
5. AS3-specific headers
5.1 AS3-From and AS3-To headers
5.2 AS3-Version header
6. FTP Considerations
   6.1  FTP Security Requirements
   6.2  Large File Transfers
   6.3  MIME Considerations for FTP
     6.3.1  Required/Optional Headers
     6.3.2  Content-Transfer-Encoding Not Used
     6.3.3  Epilogue Must be Empty
   6.3  Modification of MIME or other headers or parameters used
     6.3.1  Required/Optional Headers
     6.3.2  Content-Transfer-Encoding Not Used

Harding, Scott                                                 [Page 2]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

     6.3.3  Epilogue Must Be Empty
     6.3.4  Message-Id and Original-Message-Id
7.  Structure and Processing of an MDN Message
   7.1  Introduction
   7.2  Message Disposition Notifications (MDN)
   7.3  Requesting a signed receipt
     7.3.1  Signed receipt considerations
   7.4  MDN Format
     7.4.1  AS3-MDN General Formats
     7.4.2  AS3-MDN Construction
     7.4.3  AS3-MDN Fields
     7.4.4  Additional AS3-MDN Programming Notes
   7.5  Disposition Mode, Type, and Modifier
     7.5.1  Disposition Mode Overview
     7.5.2  Successful Processing Status Indications
     7.5.3  Unsuccessful Processed Content
     7.5.4  Unsuccessful Non-Content Processing
     7.5.5  Processing Warnings
8.  Public key certificate handling
9.  Security Considerations
10. Acknowledgements
11. References
12. Authors' Addresses

Appendix
A.  Message Examples

1.   Introduction

  Previous work on Internet EDI focused on specifying MIME content types
  for EDI data [2] and extending this work to support secure EC/EDI
  transport over SMTP [5].  This document expands on RFC 1767 to specify
  a comprehensive set of data security features, specifically data
  privacy, data integrity, authenticity, non-repudiation of origin and
  non-repudiation of receipt over FTP.  This document also recognizes
  contemporary RFCs and is attempting to "re-invent" as little as
  possible. While this document focuses on EDI data, any other data type
  describable in a MIME format are also supported.

  Internet MIME based EDI can be accomplished by using and complying
  with the following RFC's and Internet drafts:

         -RFC 959  File Transfer Protocol
         -RFC 2228 FTP Security Extensions
         -RFC 1767 EDI Content Type
         -RFC 3023 XML Media Types
         -RFC 1847 Security Multiparts for MIME
         -RFC 1892 Multipart/Report
         -RFC 2045 to 2049 MIME RFC's
         -RFC 2298 Message Disposition Notification
         -RFC 2630, 2632, 2633: S/MIME v3 Specifications
         -RFC 3274 Compressed Data Content for Cryptographic Message
                   Syntax
         -draft-murray-auth-ftp-ssl-16.txt
         -draft-ietf-ediint-compression-02.txt


Harding, Scott                                                 [Page 3]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

  Our intent here is to define clearly and precisely how these are used
  together, and what is required by user agents to be compliant with
  this document.

  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.

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

Harding, Scott                                                 [Page 4]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006


  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.

  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

Harding, Scott                                                 [Page 5]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

       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

   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

Harding, Scott                                                 [Page 6]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

     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

     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.

Harding, Scott                                                 [Page 7]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006


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

3.   Referenced RFC's and their contribution

3.1  RFC 959: File Transfer Protocol [3]

   RFC 959 specifies how data is transferred using the File Transfer
   Protocol (FTP)

3.2  RFC 2228: FTP Security Extensions [4]

Harding, Scott                                                 [Page 8]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006


   This RFC describes a framework for providing security services to
   FTP.

3.3  RFC 1847: MIME Security Multiparts [7]

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

3.4  RFC 1892: Multipart/report [12]

   RFC 1892 defines the use of the multipart/report content type, upon
   which RFC 2298 builds to define the Message Disposition Notification.

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

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


3.7  RFC 2298: Message Disposition Notification [6]

   This Internet RFC defines how a Message Disposition Notification
   (MDN)is requested, as well as the format and syntax of the MDN. The
   MDN is the vehicle used by this specification to provide both signed
   and unsigned receipts.

3.8  RFC 2630:CMS[9] and 2633 S/MIME Version 3 Message
     Specifications[10].

   This specification describes how MIME shall carry Cryptographic
   Message Syntax (CMS) Objects.

3.9 RFC 2632: S/MIME Version 3 Certificate Handling [11]

   RFC 2632 describes certificate handling in the context of CMS and
   S/MIME.

3.10  RFC 3274: Compressed Data Content Type for Cryptographic Message
      Syntax (CMS) [17]

   This specification provides a mechanism to wrap compressed data
   within a CMS object.

3.11  RFC 3023:  XML Media Types [16]

   This RFC defines the use of content type "application" for XML.  Note

Harding, Scott                                                 [Page 9]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

   that while conforming implementations SHOULD support the expanded
   syntax that RFC 3023 introduces for the "+xml" suffix, no support for
   external parsed entity types is anticipated (as it adds significant
   complexity to signature processing).

4.  Structure of an AS3 message

4.1 Introduction

   The basic structure of AS3 messages comprises MIME encapsulated data
   with both customary MIME headers and a few additional AS3-specific
   outer headers. The structures below are described hierarchically in
   terms of which RFCs have been applied to form the specific structure.
   The reader is referred directly to the referenced RFCs for
   implementation details.
   Any additional restrictions imposed by this AS are specifically
   discussed in the sections which follow.

4.2   Structure of an Internet EDI MIME message

   No encryption, no signature

     -RFC822/2045
       -RFC1767/RFC2376 (application/EDIxxxx or /xml)

   No encryption, signature

     -RFC822/2045
       -RFC1847 (multipart/signed)
         -RFC1767/RFC2376 (application/EDIxxxx or /xml)
         -RFC2633 (application/pkcs7-signature)

   Encryption, no signature

     -RFC822/2045
       -RFC2633 (application/pkcs7-mime)
         -RFC1767/RFC2376  (application/EDIxxxx or /xml)(encrypted)

   Encryption, signature

     -RFC822/2045
       -RFC2633 (application/pkcs7-mime)
         -RFC1847 (multipart/signed)(encrypted)
           -RFC1767/RFC2376  (application/EDIxxxx or /xml)(encrypted)
           -RFC2633 (application/pkcs7-signature)(encrypted)

   MDN, no signature

     -RFC822/2045
       -RFC2298 (message/disposition-notification)

   MDN, signature

     -RFC822/2045
       -RFC1847 (multipart/signed)
         -RFC2298 (message/disposition-notification)

Harding, Scott                                                 [Page 10]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

         -RFC2633 (application/pkcs7-signature)

   While all MIME content types SHOULD be supported.
   The following MIME content types MUST be supported:

     Content-type: multipart/signed
     Content-Type: multipart/report
     Content-type: message/disposition-notification
     Content-Type: application/PKCS7-signature
     Content-Type: application/PKCS7-mime
     Content-Type: application/EDI-X12
     Content-Type: application/EDIFACT
     Content-Type: application/edi-consent
     Content-Type: application/XML

5. AS3-specific Headers

5.1 AS3-From and AS3-To headers

   The AS3-From and AS3-To headers have been provided to assist the
   sender and the recipient of an EC document to identify each other:

       AS3-From: < AS3-name >
       AS3-To:   < AS3-name >

   These headers contain textual values, described by the ABNF below,
   identifying the sender/receiver of a data exchange. A value may
   be company specific (e.g., a DUNS number), or it may be simply some
   string mutually acceptable to both trading partners used to identify
   each to the other.

       AS3-text = "!" /           ; printable ASCII characters
                  %d35-91 /       ; except double-quote (%d34)
                  %d93-126        ; or backslash (%d92)

       AS3-qtext = AS3-text / SP  ; allow space only in quoted text

       AS3-quoted-pair = "\" DQUOTE /  ; \" or
                         "\" "\"       ; \\

       AS3-quoted-name = DQUOTE 1*128( AS3-qtext /
                         AS3-quoted-pair) DQUOTE

       AS3-atomic-name = 1*128AS3-text

       AS3-name = AS3-atomic-name / AS3-quoted-name

   The AS3-From header value and the AS3-To header value MUST each be an
   AS3-name comprising 1 to 128 printable ASCII characters.  The header
   MUST NOT be folded, and the value for each of these headers
   is case-sensitive.

   The AS3-quoted-name SHOULD be used only if the AS3-name does not
   conform to AS3-atomic-name.

   The AS3-To and AS3-From header fields MUST be present in all AS3

Harding, Scott                                                 [Page 11]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

   messages and AS3 MDN's.

   Implementations which map entities such as EDI identifiers/qualifiers
   to AS3 identifiers may choose to constrain the set of AS3-To/AS3-From
   text values to a subset of the full set defined above but may not
   extend that set.

   If either the AS3-From or the AS3-To or the association of the two
   header values is determined to be invalid or unknown to the receiving
   system, the receiving system MAY respond with an unsigned MDN
   containing an explanation of the error if the sending system
   requested an MDN, but it is not required to return an MDN under those
   circumstances.

5.2 AS3-Version header

    The AS3-Version header is a header which is required only if the
    value of the header is not "1.0".  Its purpose is to allow systems
    to determine which version of this specification, should the
    specification evolve over time, the sender of a document has used to
    package the document. A user agent MUST NOT reject a message if the
    version header is missing.

    AS3-Version: 1*DIGIT . 1*DIGIT

    A version header value of "1.1" indicates an implementation can
    support EDIINT data compression [18]. A user agent MUST NOT send
    compressed messages to trading partners who do not use a version
    header of "1.1" or greater.

6.  FTP Considerations

6.1 FTP Security Requirements

    FTP has long been viewed as an insecure protocol primarily because
    of its use of cleartext authentication [FTP].  This is addressed by
    RFC 2228, and the use of one of the security mechanisms described
    therein is strongly encouraged.  Specifically, conforming
    implementations of AS3 SHALL employ FTP client/servers that support
    the AUTH command described within [SFTP]. While any authentication
    mechanism based upon [SFTP] MAY be utilized, AUTH TLS (as described
    in [MURRAY]) MUST be supported.

6.2 Large file transfers

   Large files are handled correctly by the TCP layer.  However, there
   is the mechanism for compressing data referenced in section 2.4.2.2
   above which efficiently reduces transmission requirements for many
   data types (including both XML and traditional EDI data.)
   Additionally, some FTP implementations support compression as well.

6.3 MIME Considerations for FTP

6.3.1 Required/Optional Headers

    An AS3 message MUST contain the following outer headers:

Harding, Scott                                                 [Page 12]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006


         AS3-To
         AS3-From
         Date
         Message-ID
         Content-Type

    An AS3 message OPTIONALLY MAY contain the following outer headers:

         Subject
         AS3-Version (assumed to be 1.0 if not present)
         Content-Length

    An AS3 message requesting a receipt MUST contain a
    Disposition-Notification-To header and MAY contain a
    Disposition-Notification-Options header(if the receipt is to be
    signed)

    Additional headers MAY be present but are ignored.

6.3.2 Content-Transfer-Encoding Not Used

   FTP defines several data structures and character encodings via the
   STRU[cture] and TYPE commands.  AS3 requires the file-structure
   (default) and the image type.  The Content-Transfer-Encoding header
   SHOULD NOT be used; if the header is present, it MUST have a value of
   binary or 8-bit, and the absence of this header MUST NOT result in
   transaction failure. Content transfer encoding of MIME parts within
   the AS3 message are similarly constrained.

6.3.3 Epilogue Must Be Empty

    A MIME message containing an epilogue [MIME] SHALL NOT be used.

6.3.4 Message-Id and Original-Message-Id

   Message-Id and Original-Message-Id are formatted as defined in
   section 3.6.4 of RFC2822 [15]: "<" id-left "@" id-right ">".
   Message-Id length is a maximum of 998 characters. Message-Id
   SHOULD be globally unique, id-right should be something unique
   to the sending host environment (e.g. a host name).  When sending
   a message, always include the angle brackets.  Angle brackets are
   not part of the Message-Id value.

   NOTE:  When creating the Original-Message-Id header in an MDN,
          always use the exact syntax contained in the original
          message: do not strip or add "angle brackets".

7. Structure and Processing of an MDN Message

7.1 Introduction

   In order to support non-repudiation of receipt, a signed receipt,
   based on digitally signing a message disposition notification, is to
   be implemented by a receiving trading partner's UA. The message
   disposition notification specified by RFC 2298 is digitally signed by

Harding, Scott                                                 [Page 13]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

   a receiving trading partner as part of a multipart/signed MIME
   message.

   The following support for signed receipts is REQUIRED:

   1) The ability to create a multipart/report;
      where the report-type = disposition-notification.

   2) The ability to calculate a message integrity check (MIC) on the
      received message. The calculated MIC value will be returned to the
      sender of the message inside the signed receipt.

   3) The ability to create a multipart/signed content with the message
      disposition notification as the first body part, and the signature
      as the second body part.

   4) The ability to return the signed receipt to the sending trading
      partner.

   The signed receipt is used to notify a sending trading partner that
   requested the signed receipt that:

   1) The receiving trading partner acknowledges receipt of the sent EC
      Interchange.

   2) If the sent message was signed, then the receiving trading partner
      has authenticated the sender of the EC Interchange.

   3) If the sent message was signed, then the receiving trading partner
      has verified the integrity of the sent EC Interchange.

   Regardless of whether the EDI/EC Interchange was sent in S/MIME
   format or not, the receiving trading partner's UA MUST provide the
   following basic processing:

   1) If the sent EDI/EC Interchange is encrypted, then the encrypted
      symmetric key and initialization vector (if applicable) is
      decrypted using the receiver's private key.

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

   3) The receiving trading partner authenticates signatures in a
      message using the sender's public key.

      The authentication algorithm performs the following:

      a) The message integrity check (MIC or Message Digest), is
         decrypted using the sender's public key.

      b) A MIC on the signed contents (the MIME header and encoded EDI
         object, as per RFC 1767) in the message received is calculated
         using the same one-way hash function that the sending trading
         partner used.

      c) The MIC extracted from the message that was sent, and the MIC

Harding, Scott                                                 [Page 14]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

         calculated using the same one-way hash function that the
         sending trading partner used is compared for equality.

   4) The receiving trading partner formats the MDN and sets the
      calculated MIC into the "Received-content-MIC" extension field.

   5) The receiving trading partner creates a multipart/signed MIME
      message according to RFC 1847.

   6) The MDN is the first part of the multipart/signed message, and the
      digital signature is created over this MDN, including its MIME
      headers.

   7) The second part of the multipart/signed message contains the
      digital signature. The "protocol" option specified in the second
      part of the multipart/signed is as follows: S/MIME:
      protocol = "application/pkcs7-signature"

   8) The signature information is formatted according to S/MIME
      specifications. The EC Interchange and the RFC 1767 MIME EDI
      content header can actually be part of a multi-part MIME
      content-type.  When the EDI Interchange is part of a multi-part
      MIME content-type, the MIC MUST be calculated across the entire
      multi-part content, including the MIME headers.

   The signed MDN, when received by the sender of the EDI Interchange
   can be used by the sender:

   1) As an acknowledgment that the EDI Interchange sent, was delivered
      and acknowledged by the receiving trading partner. The receiver
      does this by returning the original-message-id of the sent message
      in the MDN portion of the signed receipt.

   2) As an acknowledgment that the integrity of the EDI Interchange was
      verified by the receiving trading partner.  The receiver does this
      by returning the calculated MIC of the received EC Interchange
      (and 1767 MIME headers) in the "Received-content-MIC" field of the
      signed MDN.

   3) As an acknowledgment that the receiving trading partner has
      authenticated the sender of the EDI Interchange.

   4) As a non-repudiation of receipt when the signed MDN is
      successfully verified by the sender with the receiving trading
      partner's public key and the returned MIC value inside the MDN is
      the same as the digest of the original message.

7.2  Message Disposition Notifications (MDN)

   The AS3-MDNs are returned on a separate FTP TCP/IP
   connection and are a response to an AS3 message.

   The following diagram illustrates the delivery of an
   AS3-MDN delivery:

          AS3-MDN

Harding, Scott                                                 [Page 15]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

         [S] ----( connect )----> [R]   [FTP Server]
         [S] ----( send )-------> [R]   [AS3-Message]
         [S] ----( disconnect )-> [R]   [FTP Server]

         [S] <---( connect )----- [R]   [FTP Server]
         [S] <---( send )-------- [R]   [AS3-MDN]]
         [S] <---( disconnect )-- [R]   [FTP Server]

         Note:  Refer to Section 7.4.4 for additional
                programming notes.

7.3 Requesting a signed receipt

   Message Disposition Notifications are requested as per RFC 2298.  A
   request that the receiving user agent issue a message disposition
   notification is made by placing the following header into the message
   to be sent:

   MDN-request-header = "Disposition-notification-to" ":" ftp-url

   This syntax is a residual of the use of MDN's in a SMTP transfer.
   Since this specification is adjusting the functionality from SMTP to
   FTP and retaining as much as possible from the [5] functionality, the
   ftp-url must be present.

   The ftp-url field is specified as an RFC 1738
   <URL:ftp://host.com:port/url-path>, and while it MUST be present,
   it may be ignored if the ftp-url points to an unknown location. If
   the ftp-url points to an unknown location it is RECOMMENDED that the
   mdn is returned back to a known ftp-url for the sender of the
   received message.

   For requesting MDN based receipts, the originator supplies the
   required extension headers that precede the message body.

   The header "tags" are as follows:

   A Disposition-notification-to header is added to indicate that a
   message disposition notification is requested. This header is
   specified in [6].

   A Message-ID header is added to support message reconciliation, so
   that an Original-Message-Id value can be returned in the body part of
   MDN.

   Other headers, especially "Date", SHOULD be supplied; the
   values of these headers are often mentioned in the human-readable
   section of a MDN to aid in identifying the original message.

   Disposition-notification-options identifies characteristics of
   message

   Disposition notification in accordance with  [6].

       EXAMPLE:
         Disposition-notification-to:       // Requests the MDN

Harding, Scott                                                 [Page 16]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

           ftp://host:port/inbox            // Location to return MDN
         Disposition-notification-options:  // The signing options for
                                               MDN
           signed-receipt-protocol=optional, pkcs7-signature;
           signed-receipt-micalg=optional, sha1, md5

   Disposition-notification-options syntax:

   Disposition-notification-options =
          "Disposition-Notification-Options" ":"
           disposition-notification-parameters

   where

   disposition-notification-parameters =
               parameter *(";" parameter)

   where

   parameter = attribute "=" importance ", " 1#value"

   where

   importance = "required" | "optional"

   So the Disposition-notification-options string could be:

   signed-receipt-protocol=optional, <protocol symbol>;
   signed-receipt-micalg=optional, <micalg1>, <micalg2>,...;

   The currently supported value for <protocol symbol> is
   "pkcs7-signature" for the S/MIME detached signature format.

   The currently supported values for MIC algorithm <micalg>
   values are:
          Algorithm   Value
           Used
        --------   -------
           MD5         md5
           SHA-1       sha1

   Receiving agents SHOULD be able to recover gracefully from a <micalg>
   parameter value that they do not recognize.


   The semantics of the "signed-receipt-protocol" parameter is as
   follows:

   1) The "signed-receipt-protocol" parameter is used to request a
      signed receipt from the recipient trading partner. The
      "signed-receipt-protocol" parameter also specifies the format in
      which the signed receipt should be returned to the requester.

      The "signed-receipt-micalg" parameter is a list of MIC algorithms
      preferred by the requester for use in signing the returned receipt
      and calculating the micalg in the Received-content-MIC header.

Harding, Scott                                                 [Page 17]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006


      The list of MIC algorithms should be honored by the recipient from
      left to right. Both the "signed-receipt-protocol" and the
      "signed-receipt-micalg" option parameters are REQUIRED when
      requesting a signed receipt.

   2) The "importance" attribute of "Optional" is defined in the
      RFC 2298 section 2.2 and has the following meaning:

      Parameters with an importance of "Optional" permit a UA that does
      not understand the particular options parameter to still generate
      a MDN in response to a request for a MDN. A UA that does not
      understand the "signed-receipt-protocol" parameter,  or the
      "signed-receipt-micalg" will obviously not return a signed
      receipt.

      The importance of "Optional" is used for the signed receipt
      parameters because it is RECOMMENDED that an MDN be returned to
      the requesting trading partner even if the recipient could not
      sign it.

      The returned MDN will contain information on the disposition of
      the message as well as why the MDN could not be signed. See the
      Disposition field in section 7.5 for more information.

   Within an EDI trading relationship, if a signed receipt is expected
   and is not returned, then the validity of the transaction must be
   determined by the trading partners.  Typically, if a signed receipt
   is required by the trading relationship and is not received, the
   transaction will likely not be considered valid.

7.3.1 Signed Receipt Considerations

   The method used to request a receipt or a signed receipt is defined
   in RFC 2298, "An Extensible Message Format for Message Disposition
   Notifications".

   The "rules" for processing a receipt-request follow:

1) When a receipt is requested, explicitly specifying that the receipt
   be signed, then the receipt MUST be returned with a signature unless
   conditions (2) or (3) below are applicable.

2) When a receipt is requested, explicitly specifying that the receipt
   be signed, but the recipient cannot support either the requested
   protocol format, or requested MIC algorithms, then either a signed or
   unsigned receipt SHOULD be returned.

3) When a receipt is requested, explicitly specifying that the receipt
   be signed, but the recipient is unable to compute the digest (e.g.,
   message was encrypted and recipient unable to decrypt), then the
   recipient SHOULD NOT return "Received-Content-MIC" in the MDN to the
   requestor.  If the MDN sets the disposition (e.g., "processed/error:
   decryption-failed") appropriately, then the "Received-Content-MIC"
   may be returned but the value must be discarded.


Harding, Scott                                                 [Page 18]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

4) When a signature is not explicitly requested, or if the signed
   receipt request parameter is not recognized by the UA, then no
   receipt, an unsigned receipt, or a signed receipt MAY  be returned
   by the recipient.

5) If a message is received without a request for a receipt, then a
   receipt (signed or unsigned) MAY be returned.

   The "Received-content-MIC" MUST be calculated as follows:

   - For any signed messages, the MIC to be returned is calculated on
     the RFC1767 MIME header and content. Canonicalization as specified
     in RFC 1848 MUST be performed before the MIC is calculated, since
     the sender requesting the signed receipt was also REQUIRED to
     canonicalize.

   - For encrypted, unsigned messages, the MIC to be returned is
     calculated on the decrypted RFC 1767 MIME header and content. The
     content after decryption MUST be canonicalized before the MIC is
     calculated.

   - For unsigned, unencrypted messages, the MIC MUST be calculated
     over the message contents prior to Content-Tranfer-Encoding and
     without the MIME or any other RFC 822 headers, since these are
     sometimes altered or reordered by MTAs.

7.4  MDN Format and value

     This section defines the format of the AS3 Message Disposition
     Notification (AS3-MDN).

7.4.1  AS3-MDN General Formats

     The AS3-MDN follows the MDN specification [6] except where noted in
     this section. The modified entity definitions in this document use
     the vertical-bar character, '|', to denote a logical "OR"
     construction. Refer to RFC 2045 for format of MIME-message-headers.

     The format of the AS3-MDN is

          AS3-MDN = *(( MIME-message-headers | entity-headers )CRLF)
                CRLF
                AS3-MDN-body

          AS3-MDN-body =
                AS3-signed-MDN-body | AS3-unsigned-MDN-body

7.4.2  AS3-MDN Construction

     The AS3-MDN-body is formatted as a MIME multipart/report with a
     report-type of "disposition-notification".

     When unsigned, the transfer-layer ( "outermost" ) entity-headers of
     the AS3-MDN contain the content-type header that specifies a
     content-type of "multipart/report" and parameters indicating the
     report-type, and the value of the outermost multipart boundary.

Harding, Scott                                                 [Page 19]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006


     When the AS3-MDN is signed, the transfer-layer ( "outermost" )
     entity-headers of the AS3-MDN contain a content-type header that
     specifies a content-type of "multipart/signed" and parameters
     indicating the algorithm used to compute the message digest, the
     signature formatting protocol ( e.g. pkcs7-signature ), and the
     value of the outermost multipart boundary. The first part of the
     MIME multipart/signed message is an embedded MIME multipart/report
     of type "disposition-notification". The second part of the
     multipart/signed message contains a MIME
     application/pkcs7-signature message.

     The first part of the MIME multipart/report is a "human-readable"
     portion that contains a general description of the message
     disposition. The second part of the MIME multipart/report is a
     "machine-readable" portion that is defined as

     AS3-disposition-notification-content =
               [ reporting-ua-field CRLF ]
               [ mdn-gateway-field CRLF ]
               [ original-recipient-field CRLF ]
               final-recipient-field CRLF
               [ original-message-id-field CRLF ]
               AS3-disposition-field CRLF
               *( failure-field CRLF )
               *( error-field CRLF )
               *( warning-field CRLF )
               *( extension-field CRLF )
               [ AS3-received-content-MIC-field CRLF ]

     It is noted that several of the optional fields defined by RFC 2298
     and shown above are not relevant to a point-to-point transport such
     as FTP and would not normally appear in an AS3 MDN.

7.4.3  AS3-MDN Fields

     The rules for constructing the AS3-disposition-notification-content
     are identical to the rules for constructing the
     disposition-notification-content as defined in section 7 of RFC
     2298 [6] except that the RFC 2298 disposition-field has
     been replaced with the AS3-disposition-field and that the
     AS3-received-content-MIC field has been added. The differences
     between the RFC 2298 disposition-field and the
     AS3-disposition-field are described below. Where
     there are differences between this document and RFC 2298, those
     entity names have been changed by prepending "AS3-". Entities below
     that do not differ from RFC 2298 are not necessarily further
     defined in this document.

     Refer to RFC 2298 for AS3-MDN entities that are not further defined
     in this document.

     AS3-disposition-field = "Disposition" ":" disposition-mode ";"
                    AS3-disposition-type [ '/' AS3-disposition-modifier]

     disposition-mode = action-mode "/" sending-mode

Harding, Scott                                                 [Page 20]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006


     action-mode = "manual-action" | "automatic-action"

     sending-mode = "MDN-sent-manually" | "MDN-sent-automatically"

     AS3-disposition-type = "processed" | "failed"

     AS3-disposition-modifier = ( "error" | "warning" ) |
                                AS3-disposition-modifier-extension

     AS3-disposition-modifier-extension =
                "error: authentication-failed" |
                "error: decompression-failed" |
                "error: decryption-failed" |
                "error: insufficient-message-security" |
                "error: integrity-check-failed" |
                "error: unexpected-processing-error" |
                "warning: " AS3-MDN-warning-description |
                "failure: " AS3-MDN-failure-description

     AS3-MDN-warning-description = *( TEXT )

     AS3-MDN-failure-description = *( TEXT )

     AS3-received-content-MIC-field =
                 "Received-content-MIC" ":" encoded-message-digest
                 "," digest-alg-id CRLF

     encoded-message-digest =
                1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' ) 0*3( '=' )
                ( i.e. base64( message-digest ) )

     digest-alg-id = "sha1" | "md5"

     The "Received-content-MIC" extension field is set after the
     integrity of the received message is verified. The MIC is the
     base64-encoded message-digest computed over the received message
     with a hash function.  This field is required for signed receipts
     but optional for unsigned receipts. For details defining the
     specific content over which the message-digest is to be computed,
     see Section 7.3.1 of this document.

     The algorithm used to calculate the message digest MUST be the
     same as the "micalg" value used by the sender in the
     multipart/signed message. When no signature is received the
     message-digest MUST be calculated using the algorithm specified
     by the "micalg" value in the Disposition-Notification-Options
     header. When no signature is received and no micalg parameter is
     provided, then the SHA-1 algorithm MUST be used to calculate the
     digest. This field is set only when the contents of the message are
     processed successfully. This field is used in conjunction with
     the recipient's signature on the MDN in order for the sender to
     verify non-repudiation of receipt.

     AS3-MDN field names ( e.g. "Disposition:", "Final-Recipient:")
     are case-insensitive ( cf. RFC 2298, 3.1.1 ).

Harding, Scott                                                 [Page 21]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006


     AS3-MDN action-modes, sending-modes, AS3-disposition-types, and
     AS3-disposition-modifier values that are defined above, and
     user-supplied *( TEXT ) values are also case-insensitive. AS3
     implementations MUST NOT make assumptions regarding the values
     supplied for AS3-MDN-warning-description,
     AS3-MDN-failure-description nor for the values of any (optional)
     error, warning, or failure fields.

7.4.4  Additional AS3-MDN Programming Notes

     1. Unlike SMTP, for FTP transactions, Original-Recipient and
        Final Recipient SHOULD NOT be different. The value in
        Original-Message-ID MUST match the original Message-ID
        header value.

     2. Refer to RFC 1892 and RFC 2298 for the formatting of the
        content-type entity-headers for the MDN.

     3. Use an action-mode of "automatic-action" when the disposition
        described by the disposition type was a result of an automatic
        action, rather than an explicit instruction by the user for
        this message.

     4. Use an action-mode of "manual-action" when the disposition
        described by the disposition type was a result of an explicit
        instruction by the user rather than some sort of automatically
        performed action.

     5. Use a sending-mode of "MDN-sent-automatically" when the MDN is
        sent because the UA had previously been configured to do so.

     6. Use a sending-mode of "MDN-sent-manually" when the user
        explicitly gave permission for this particular MDN to be sent.

     7. The sending-mode "MDN-sent-manually" is ONLY meaningful with
        "manual-action", not with "automatic-action".

     8. The "failed" disposition type MAY NOT be used for the
        situation in which there is some problem in processing the
        message other than interpreting the request for an MDN.
        The "processed" or other disposition type with appropriate
        disposition modifiers is to be used in such situations.

     9. An AS3 implementation MUST present to its trading partners
        an ftp compliant server interface where inbound documents
        and mdns are received.

    10. An AS3 implementation MUST be able to retrieve inbound
        messages from it's currently configured ftp server interface.

    Note: Programming Notes 9 and 10 do not imply any specific method
          for supplying the ftp server interface. But, does allow for
          several different types of implementations.  Some vendors may
          choose to imbed an ftp compliant server interface within their
          product and others may choose to utilize off-the-shelf ftp

Harding, Scott                                                 [Page 22]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

          servers to supply the required ftp server interface. Some may
          choose to utilize hosting services provide by their trading
          partner or by a third party hosting service. Whichever method
          is utilized, an AS3 implementation MUST support rules 9 and
          10.

    11. AS3 implementations MAY imbed an ftp server interface within
        their product.

    12. AS3 implementations MUST be configurable to allow the use of
        an external ftp hosting service.

    Note: An external ftp hosting service may be hosted by a third-party
          Or possibly hosted by your trading partner.

    13. An AS3 implementation MUST be able to send business documents
        and mdns to a trading partner's currently configured ftp server
        interface.

    14. An AS3 implementation may imbed ftp client code into their
        product or use an third-party ftp client.

    15.  Example Configurations

         1. Peer to Peer
            TPA is using a local ftp server and TPB is using an imbedded
            ftp server.

         [A Client] ----( connect )----> [B Server]
         [A Client] ----( send )-------> [B Server] [AS3-Message]
         [A Client] ----( disconnect )-> [B Server]

         [A Server] <---( connect )----- [B Client]
         [A Server] <---( send )-------- [B Client] [AS3-MDN]]
         [A Server] <---( disconnect )-- [B Server]
         [A Client] <---( GET )--------- [A Server]

         2. Third Party Hosting
            Both parties are using the same third-party hosted ftp
            server.

         [A Client] ----( connect )----> [Hosted Server]
         [A Client] ----( send )-------> [Hosted Server] [AS3-Message]
         [A Client] ----( disconnect )-> [Hosted Server]
         [Hosted Server]( GET )--------> [B Client]

         [Hosted Server] <---( connect )----- [B Client]
         [Hosted Server] <---( send )-------- [B Client] [AS3-MDN]]
         [Hosted Server] <---( disconnect )-- [B Client]
         [A Client]      <---( GET )--------- [Hosted Server]

         3. Trading Partner Hosting
            TPA is using the imbedded ftp server hosted by TPB.

         [A Client] ----( connect )----> [B Server]
         [A Client] ----( send )-------> [B Server] [AS3-Message]

Harding, Scott                                                 [Page 23]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

         [A Client] ----( disconnect )-> [B Server]

         [B Server] <---( connect )----- [B Client]
         [B Server] <---( send )-------- [B Client] [AS3-MDN]]
         [B Server] <---( disconnect )-- [B Client]
         [A Client] <---( GET )--------- [B Server]

7.5   Disposition Mode, Type, and Modifier

7.5.1  Disposition Mode Overview

     This section will provide a brief overview of how processed,
     error, failure, and warnings are used.

7.5.2 Successful Processing status indication

     When the request for a receipt or signed receipt, and the received
     message contents are successfully processed by the receiving EDI
     UA, a receipt or MDN SHOULD be returned with the
     "disposition-type" set to 'processed'. When the MDN is sent
     automatically by the EDI UA, and there is no explicit
     way for a user to control the sending of the MDN, then the first
     part of the "disposition-mode" should be set to "automatic-action".

     When the MDN is being sent under user configurable control, then
     the first part of the "disposition-mode" should be set to
     "manual-action". Since a request for a signed receipt should always
     be honored, the user MUST not be allowed to configure the UA to not
     send a signed receipt when the sender requests one.

     The second part of the "disposition-mode" is set to
     "MDN-sent-manually" if the user gave explicit permission for the
     MDN to be sent. Again, the user MUST not be allowed to explicitly
     refuse to send a signed receipt when the sender requests one. The
     second part of the "disposition-mode" is set to
     "MDN-sent-automatically" whenever the EDI UA sends the MDN
     automatically, regardless of whether the sending was under a
     user's, administrator's, or under software control.

     Since EDI content is generally handled automatically by the EDI UA,
     a request for a receipt or signed receipt will generally return the
     following in the "disposition-field":

     Disposition: automatic-action/MDN-sent-automatically; processed

     Note this specification does not restrict the use of the
     "disposition-mode" to just automatic actions. Manual actions are
     valid as long as it is kept in mind that a request for a signed
     receipt MUST be honored.

7.5.3  Unsuccessful processed Content

     The request for a signed receipt requires the use of two
     "disposition-notification-options", which specify the protocol
     format of the returned signed receipt, and the MIC algorithm used
     to calculate the MIC over the message contents. The

Harding, Scott                                                 [Page 24]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

     "disposition-field" values that should be used in the case where
     the message content is being rejected or ignored, for instance if
     the EDI UA determines that a signed receipt cannot be returned
     because it does not support the requested protocol format, so the
     EDI UA chooses not to process the message contents itself, should
     be specified in the MDN "disposition-field" as follows:

     Disposition: "disposition-mode"; failed/Failure: unsupported Format

     The "failed" AS3-disposition-type should be used when a failure
     occurs that prevents the proper generation of an MDN.

     For example, this disposition-type would apply if the sender of the
     message requested the application of an unsupported
     message-integrity-check (MIC) algorithm.

     The "failure:" AS3-disposition-modifier-extension should be used
     with an implementation-defined description of the failure.

     Further information about the failure may be contained in a
     failure-field. The syntax of the "failed" "disposition-type" is
     general, allowing the sending of any textual information along with
     the "failed"  "disposition-type". Implementations WILL support any
     printable textual characters after the Failure disposition-type.

     For use in Internet EDI, the following "failed" values are
     pre-defined and MUST be supported:

          "Failure: unsupported format"
          "Failure: unsupported MIC-algorithms"

7.5.4  Unsuccessful Non-Content Processing

     When errors occur processing the received message other than
     content, the "disposition-field" should be set to the "processed"
     "disposition-type" value and the "error" "disposition-modifier"  \
     value.

     The "error" AS3-disposition-modifier with the "processed"
     disposition-type should be used to indicate that an error of some
     sort occurred that prevented successful processing of the message.

     Further information may be contained in an error-field.

     An "error:" AS3-disposition-modifier-extension should be used to
     combine the indication of an error with a pre-defined description
     of a specific, well-known error. Further information about the
     error may be contained in an error-field.

     For use in Internet EDI, the following "error"
     "disposition-modifier" values are defined:

     "Error: decryption-failed" - the receiver could not decrypt the
                                  message contents.

     "Error: authentication-failed" - the receiver could not

Harding, Scott                                                 [Page 25]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

                                      authenticate the sender.

     "Error: integrity-check-failed" - the receiver could not verify
                                       content integrity.

     "Error: insufficient-message-security" - the security level of the
                                              message did not match the
                                              agreed level between TPs.

     "Error: decompression-failed" - the receiver could not decompress
                                     the message contents.

     "Error: unexpected-processing-error" - a catch-all for any
                                            additional processing
                                            errors.

     An example of how the "disposition-field" would look when other
     than content processing errors are detected is as follows:

     EXAMPLE
          Disposition: "disposition-mode";
            processed/Error: decryption-failed

7.5.5   Processing Warnings

     Situations arise in EDI where even if a trading partner cannot be
     authenticated correctly, the trading partners still agree to
     continue processing the EDI transactions. Transaction
     reconciliation is done between the trading partners at a later
     time. In the content processing warning situations as described
     above, the "disposition-field' SHOULD be set to the "processed"
     "disposition-type" value, and the "warning" "disposition-modifier"
     value.

     The "warning" AS3-disposition-modifier should be used with the
     "processed" disposition-type to indicate that the message was
     successfully processed but that an exceptional condition occurred.

     Further information may be contained in a warning-field.

     A "warning:" AS3-disposition-modifier-extension should be used to
     combine the indication of a warning with an implementation-defined
     description of the warning. Further information about the warning
     may be contained in an warning-field.

     For use in Internet EDI, the following "warning"
     "disposition-modifier" values are defined:

     "Warning: authentication-failed, processing continued"

     An example of how the "disposition-field" would look when other
     than content processing warnings are detected is as follows:

     EXAMPLE
         Disposition: "disposition-mode"; processed/Warning:
           authentication-failed, processing continued

Harding, Scott                                                 [Page 26]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006


8.  Public key certificate handling

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

     X.509 certificates are REQUIRED. It is RECOMMENDED that trading
     partners self-certify each other if an agreed upon certification
     authority is not used. This applicability statement does NOT
     require the use of a certification authority.

     The use of a certification authority is therefore OPTIONAL.
     Certificates may be self-signed. It is RECOMMENDED that when
     trading partners are using S/MIME, that they also exchange public
     key certificates using the recommendations specified in the S/MIME
     Version 3 Message Specification.

     The message formats and S/MIME conformance requirements for
     certificate exchange are specified in this document. In the long
     term, additional Internet-EDI standards may be developed to
     simplify the process of establishing a trading partnership,
     including the third party authentication of trading partners,
     as well as attributes of the trading relationship.

9.  Security Considerations

     This entire document is concerned with secure transport of business
     to business data, and considers both privacy and authentication
     issues.

     Extracted from S/MIME Version 2 Message Specification:  40-bit
     encryption is considered weak by most cryptographers. Using weak
     cryptography offers little actual security over sending plaintext.

     However, other features of S/MIME, such as the specification of
     tripleDES or AES and the ability to announce stronger cryptographic
     capabilities to parties with whom you communicate, allow senders to
     create messages that use strong encryption. Using weak cryptography
     is never recommended unless the only alternative is no
     cryptography. When feasible, sending and receiving agents should
     inform senders and recipients the relative cryptographic strength
     of messages.

     Extracted from S/MIME Version 3 Certificate Handling (ref [11]):

     When processing certificates, there are many situations where the
     processing might fail. Because the processing may be done by a user
     agent, a security gateway, or other program, there is no single way
     to handle such failures. Just because the methods to handle the
     failures have not been listed, however, the reader should not

Harding, Scott                                                 [Page 27]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

     assume that they are not important.  The opposite is true: if a
     certificate is not provably valid and associated with the message,
     the processing software should take immediate and noticeable steps
     to inform the end user about it.

     Some of the many places where signature and certificate checking
     might fail include:

          - no certificate chain leads to a trusted CA
          - no ability to check the CRL for a certificate
          - an invalid CRL was received
          - the CRL being checked is expired
          - the certificate is expired
          - the certificate has been revoked

     There are certainly other instances where a certificate may be
     invalid, and it is the responsibility of the processing software to
     check them all thoroughly, and to decide what to do if the check
     fails.

     The following certificate types MUST be supported.
            With URL
            Without URL
            Self Certified
            Certification Authority Certified

     The complete certification chain MUST be included in all
     certificates.  All certificate verifications MUST "chain to root".
     Additionally, the certificate hash should match the hash recomputed
     by the receiver.

10. IANA Considerations

   This document has no actions for IANA.


11.   References

      Normative 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,

Harding, Scott                                                 [Page 28]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

        March 2, 1995.

  [3]   J. Postel, J. Reynolds,
        "FILE TRANSFER PROTOCOL (FTP)", RFC 959,   October 1985.

  [4]   M. Horowitz, S. Lunt, "FTP Security Extensions", RFC 2228,
        October, 1997

  [5]   T. Harding, R. Drummond, C. Shih, "Peer-to-Peer MIME-based
        Secure Business Data Interchange", RFC 3335, September 2002.

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

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

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

  [9]   R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999.

  [10]  B. Ramsdell, "S/MIME Version 3 Message Specification;
        RFC 2633  June 1999.

  [11]  B. Ramsdell, "S/MIME Version 3 Certificate Handling", RFC 2632,
        June 1999

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

  [13]  T. Dierks,C. Allen, "The TLS Protocol Version 1.0" RFC 2246,
        March 1999.

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

  [15]  P. Resnick, "Internet Message Format", RFC 2822, April 2001.

  [16]  E. Whitehead, M. Murata, "XML Media Types", RFC 2376, July 1998.

  [17]  P. Gutmann, "Compressed Data Content Type for Cryptographic
        Message Syntax (CMS)", RFC 3274, June 2002

  [18]  T. Harding, "Compressed Data for EDIINT", EDIINT Internet Draft,
        Feb, 2005, draft-ietf-ediint-compression-03.txt

  [MURRAY] Paul Ford-Hutchinson, "Securing FTP with TLS", IETF Draft,
        Feb, 2005, draft-murray-auth-ftp-ssl-16.txt

12.  Authors' Addresses

    Terry Harding

Harding, Scott                                                 [Page 29]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

    tharding@cyclonecommerce.com
    Cyclone Commerce
    8388 E. Hartford Drive, Suite 100
    Scottsdale, AZ  85255 USA

    Richard Scott
    rscott@cyclonecommerce.com
    Cyclone Commerce
    8388 E. Hartford Drive, Suite 100
    Scottsdale, AZ  85255 USA

Appendices

A.   Message Examples

NOTE: All examples are provided as an illustration only, and are not
      considered part of the protocol specification. If an example
      conflicts with the protocol definitions specified above or with
      that of a referenced RFC, the example is wrong.

A.1  Signed message requesting a signed receipt

      Date: Wed, 31 Jul 2002 13:34:50 GMT
      AS3-Version: 1.0
      AS3-From:  cyclone
      AS3-To: "trading partner"
      Message-Id: <200207310834482A70BF63@host.com>
      Disposition-Notification-To: ftp://host:port/mdnbox
      Disposition-Notification-Options: signed-receipt-
        protocol=optional,pkcs7-signature;
        signed-receipt-micalg=optional,sha1
      Content-Type: multipart/signed; boundary="as3BouNdary1as3";
         protocol="application/pkcs7-signature"; micalg=sha1
      Content-Length: 3075

      --as3BouNdary1as3
      Content-Type: application/edi-x12
      Content-Disposition: Attachment; filename=rfc1767.dat

      [ISA ...EDI transaction data...IEA...]

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

        [omitted binary pkcs7 signature data]
      --as3BouNdary1as3--

A.2   MDN for Message A.1 Above

      Date: Wed, 31 Jul 2002 13:34:50 GMT
      From: "trading partner"
      AS3-To: cyclone
      AS3-Version: 1.0
      Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
      Content-Type: multipart/signed; micalg=sha1;
        protocol="application/pkcs7-signature";

Harding, Scott                                                 [Page 30]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

        boundary="----=_Part_57_648441049.1028122454671"
      Content-Length: 1024

      ------=_Part_57_648441049.1028122454671

     & Content-Type: multipart/report;
     &   Report-Type=disposition-notification;
     &   boundary="----=_Part_56_1672293592.1028122454656"
     &
     &------=_Part_56_1672293592.1028122454656
     &Content-Type: text/plain
     &Content-Transfer-Encoding: 7bit
     &
     &MDN for -
     & Message ID: <200207310834482A70BF63@host.com>
     &  From: cyclone
     &  To: "trading partner"
     &  Received on: 2002-07-31 at 09:34:14 (EDT)
     &  Status: processed
     &  Comment: This is not a guarantee that the message has been
     &  completely processed or understood by the receiving translator
     &
     &------=_Part_56_1672293592.1028122454656
     &   Content-Type: message/disposition-notification
     &   Content-Transfer-Encoding: 7bit
     &
     &   Reporting-UA: AS3 Server
     &   Original-Recipient: rfc822; "trading partner"
     &   Final-Recipient: rfc822; "trading partner"
     &   Original-Message-ID: <200207310834482A70BF63@host.com>
     &   Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1
     &   Disposition: automatic-action/MDN-sent-automatically; processed
     &
     &------=_Part_56_1672293592.1028122454656--

      ------=_Part_57_648441049.1028122454671
     Content-Type: application/pkcs7-signature; name=smime.p7s
     Content-Transfer-Encoding: base64
     Content-Disposition: attachment; filename=smime.p7s

     MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ
     cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA
     ------=_Part_57_648441049.1028122454671--

Notes:

  1. The lines proceeded with "&" is what the signature is calculated
     over.

  2. For details on how to prepare the multipart/signed with protocol =
     "application/pkcs7-signature" see the "S/MIME  Message
     Specification, PKCS Security Services for MIME".)

  3. Note that the textual first body part of the multipart/report can
     be used to include a more detailed explanation of the error
     conditions reported by the disposition headers. The first body part

Harding, Scott                                                 [Page 31]

INTERNET DRAFT        AS3 Data Interchange for EDIINT        August 2006

     of the multipart/report when used in this way, allows a person to
     better diagnose a problem in detail.

  4. As specified by RFC 1892 [10], returning the original or portions
     of the original message in the third body part of the
     multipart/report is not required. This is an optional body part.
     However, it is RECOMMENDED that this body part be omitted or left
     blank.

Disclaimer

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Expires August 2006

Harding, Scott                                                 [Page 32]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/