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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 3335

INTERNET DRAFT                                        Mats Jansson, LiNK
draft-ietf-ediint-as1-01.txt                           Chuck Shih, Actra
                                                Nancy Turaj, Mitre Corp.
                                            Rik Drummond, Drummond Group

19 October, 1996

                        MIME-based Secure EDI


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

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

Abstract

     This document describes how to securely exchange EDI documents
     using MIME and public key cryptography.


Feedback Instructions:

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

  -Send feedback via e-mail to mjansson@agathon.com, with "AS#1" in the
  Subject field.

  -Be specific as to what section you are referring to, preferrably
  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.

  -If you are questioning fundamental methods, make it clear to us and we
  will bring the issue to the ediint list for discussion.  To follow the
  discussion, you need to subscribe at ietf-ediint@imc.org.


Table of Contents

1.  Introduction

2.   Overview
   2.1  Purpose of a security guideline for MIME EDI
   2.2 Definitions
      2.2.1 Terms
      2.2.2 The secure transmission loop
      2.2.3 Definition of receipts
   2.3  Assumptions
      2.3.1 EDI process assumptions
      2.3.2 Flexibility assumptions

3. Structure of an EDI MIME message
   3.1  Referenced RFC's and their contribution
      3.1.1 RFC 821 SMTP [7]
      3.1.2 RFC 822 Text Message Format [3]
      3.1.3 RFC 1521 MIME [1]
      3.1.4 RFC 1847 MIME Security Multiparts [6]
      3.1.5 RFC 1892 Multipart/report [9]
      3.1.6 RFC 1767 EDI Content [2]
      3.1.7 RFC 2015 PGP/MIME [4]
      3.1.8 Internet draft (fajman): Message Disposition Notification [5]
      3.1.9 RSA Specifications - S/MIME (RSA Security, Inc.) [8]
   3.2  Vocabulary
   3.3  Structure of an EDI MIME message - No encryption/No signature
   3.4  Structure of an EDI MIME message - Encryption/No signature
      3.4.1 S/MIME
      3.4.2 PGP/MIME
   3.5 Structure of an EDI MIME message - No encryption/Signature
      3.5.1 S/MIME
      3.5.2 PGP/MIME
   3.6 Structure of an EDI MIME message - Encryption/Signature
      3.6.1 S/MIME
      3.6.2 PGP/MIME

4. Receipts
   4.1 Introduction
   4.2 Requesting a signed receipt
   4.3 Message Disposition Notification Format
   4.4 Message Disposition Notification Processing
      4.4.1 Large File Processing
      4.4.2 Example

5.   Public key certificate handling
   5.1 Near term approach
   5.2 Long term approach

6.  Authors' Addresses

7. References



1.  Introduction

     Previous work on internet EDI focussed on specifying MIME content
     types for EDI data ([2] RFC 1767).  This Applicability Statement
     expands on RFC 1767 to specify use of a comprehensive set of data
     security features, specifically data privacy, data
     integrity/authenticity, non-repudiation of origin and non-repudiation
     of receipt.  This draft recognizes contemporary RFCs and internet
     drafts and is attempting to "re-invent" as little as possible.

     With an enhancements in the area of "receipts", as described below
     (3.1.8), secure internet MIME based EDI can be accomplished by using
     and complying with the following RFC's and drafts:

        -RFC 821 SMTP
        -RFC 822 Text Message Formats
        -RFC 1521 MIME
        -RFC 1767 EDI Content Type
        -RFC 1847 Security Multiparts for MIME
        -RFC 1892 Multipart/Report
        -Internet draft: Message Disposition Notification (fajman)
        -RFC 2015 MIME/PGP (elkins)
        -S/MIME Specification (RSA)

     Our intent here is to define clearly and precisely how these
     are pieced together and what is required by user agents to be
     compliant with this Applicability Statement.


2.   Overview

2.1  Purpose of a security guideline for MIME EDI

     The purpose of these specifications is to ensure interoperability
     between EDI user agents, invoking some or all of the commonly
     expected security features. This standard 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.2 Definitions

    2.2.1. Terms

    EDI                    Electronic Data Interchange

    EC                     Electronic Commerce

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

    Signed Receipt         Same as above, but with a digital signature

    Message Disposition    The way by which a receipt or a signed
    Notification (MDN)     receipt is accomplished within Internet
                           Messaging.

    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.

    PGP/MIME               Digital envelope security based on the Pretty
                           Good Privacy (PGP) standard (Zimmerman),
                           integrated with MIME Security Multiparts [6].

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


    2.2.2 The secure transmission loop

    The functional requirements document, [9] "Requirements for Inter-
    operable Internet EDI" (can be found at www.ietf.org),provides
    extensive information on EDI security and the user/business related
    processes surrounding the need for and use of EDI security.  In
    this document, it is assumed that the reader is familiar with the
    requirements document.

    This document's focus is on the formats and protocols for
    exchanging EDI content that has had security applied to it using
    the Internet's messaging transport.

    The "secure transmission loop" for EDI involves one organization
    sending a signed and encrypted EDI interchange to another
    organization, requesting a "signed receipt", followed later by the
    receiving organization sending this "signed receipt" back to the
    sending organization.  In other words, the following transpires:

       -The organization sending EDI/EC data encrypts the data and
       provides a digital signature, using either PGP/MIME or S/MIME.
       In addition, they request a "signed receipt".

       -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 sends a "signed receipt" in the
       form of a signature over the hash from the previous step.

    The above describes functionality which if implemented, would
    satisfy all security requirements. This specification, however,
    leaves full flexibility for users to decide the degree to which they
    want to deploy those features with their EDI trading partners.


    2.2.3 Definition of receipts

    The term used for the 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 that was not signed, thereby resulting in a
    receipt which is also not signed.  The second term is used if the
    acknowledgment is for an interchange which was signed, resulting in
    a receipt which is also signed.  The rule is:  If a receipt is
    requested, it will be signed only if the original interchange was
    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.


2.3  Assumptions

     2.3.1 EDI process assumptions

        -Encrypted object is an EDI Interchange

        This specification assumes that a typical EDI interchange is the
        lowest level object that will be subject to security features.
        In ANSI X12, this means anything between, and including
        segments ISA and IEA.  In EDIFACT, this means anything between,
        and including, segments UNA/UNB and UNZ.  In other words, the
        EDI 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 VAN-to-
        Internet routing, work may need to be done in the future to
        define ways to pull out some of the envelope information to make
        them visible, however, this specification does not go into any
        detail on that.

        -X12.58 and UN/EDIFACT security considerations

        The most common EDI standards, 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.3.2 Flexibility assumptions

        -Encrypted or un-encrypted data

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

        -Signed or un-signed data

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

        -Use of receipt or not (signature required for "Signed Receipt")

        This specification allows for EDI message transmission with or
        without a request for receipt notification.  If receipt
        notification is requested, however, a signature is required as
        part of both the original EDI transmission and the returned
        receipt.

        -Formatting choices

        This specification defines use of two methods for formatting EDI
        contents that have security applied to it:

           -PGP/MIME
           -S/MIME

        This specification relies on the guidelines set forth in the
        internet draft on PGP/MIME, as reflected in [4] MIME Security
        with Pretty Good Privacy (PGP), and [8] S/MIME Specification
        from RSA Security, Inc.  Compliance with this specification
        dictates that AT LEAST one of these methods is supported.

        -Hash function, message digest choices

        When signature is used, unless specified otherwise by the chosen
        method (PGP/MIME or S/MIME), the MD5 checksum hash function is
        recommended.


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

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

        (2) Sender sends unencrypted data, requests a receipt. Receiver
            sends back a receipt.

        (3) Sender sends encrypted data, does NOT request a receipt.

        (4) Sender sends encrypted data, requests a receipt. Receiver
            sends back a receipt.

        (5) Sender sends signed data, does NOT request a signed receipt.

        (6) Sender sends signed data, requests a signed receipt.
            Receiver sends back a signed receipt.

        (7) Sender sends encrypted and signed data, does NOT request a
            signed receipt.

        (8) Sender sends encrypted and signed data, requests a signed
            receipt.  Receiver sends back a signed receipt.

        NOTE: Users can choose any of the eight possibilities, but only
        example (8) offers the whole suite of security features described
        in the "Secure transmission loop" above.

        NOTE: A request for receipt that is signed, MUST result in a
        signed receipt.  A request for receipt without signature MUST
        result in an un-signed receipt.


3.   Structure of an EDI MIME message

     The following sub chapters describe the structure of EDI MIME
     messages, making use of security features in different ways.
     Please note that if a signed receipt is to be returned, the
     original EDI transmission also had to have been signed.

     The structures shown below represent the use of specifications
     outlined in the following RFCs and Internet-drafts, and before
     moving into the sructures 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 RFC's that specify the correct
     grammar in each case.


3.1  Referenced RFC's and their contribution

     3.1.1 RFC 821 SMTP [7]

     This is the core mail transfer standard that all MTA's need to adhere
     to.


     3.1.2 RFC 822 Text Message Format [3]

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


     3.1.3 RFC 1521 MIME [1]

     This is  the basic MIME standard, upon which all MIME related RFCs
     build, including this one.  Key contributions include definition of
     "content type" and sub-type "multipart", in addition to encoding
     guidelines,  which establish 7-bit US-ASCII as the lowest common
     denominator used.


     3.1.4 RFC 1847 MIME Security Multiparts [6]

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


     3.1.5 RFC 1892 Multipart/report [10]

     This RFC defines the use of Multipart/report content type,
     something that the MDN draft (fajman) relies on for the receipt
     functionality.


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


     3.1.8 Internet draft (fajman): Message Disposition Notification [5]

     This Internet draft defines how a "signed receipt" is requested,
     and the structure of the signed receipt, also called message
     disposition notification.

     NOTE: This is the only specification we were not able to take
     "as is". Extension field-names beginning with "X-" will not be defined
     as a standard field. MDN field names not beginning with "X-" need to
     be registered with the Internet Assigned Numbers Authority (IANA)
     and described in an RFC. The X-Received-MIC field described in this
     document will be registered with IANA.


     3.1.9 RSA Specifications - S/MIME (RSA Security, Inc.) [8]

     This specification describes how MIME shall carry PKCS7
     envelope information.


3.2  Vocabulary

     <recipient email>         The email address of the receiving
                                organization's EDI processing system.

     <sender email>            The email address of the sending organi-
                               zation's EDI processing system.

     <date>                    Transmission date

     <EDI standard>            "EDI-FACT" or "EDI-X12" or "EDI-consent"

     <encoding>                "Quoted-printable" or "Base64"

     <EDI Object>              ANSI X12 or EDIFACT EDI Interchange, or
                               mutually agreed electronic commerce file

     <char set>                "us-ascii" or "iso-8859-1" (note that if
                               iso-8859-1 is used, in most cases
                               encoding will be required "Quoted
                               printable" or "Base 64"

     <hash symbol>             "md5" or "sha1"


     NOTE: The examples below are just that - examples. They are provided
     for illustration purposes only. Refer to the RFCs or drafts under
     "7. References" for the actual grammar and protocol definitions


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

To:             <recipient email>
Subject:
From:           <sender email>
Date:           <date>
Mime-Version:   1.0
Content-Type: Application/<EDI standard>
Content-Transfer-Encoding: <encoding>

<EDI object>


3.4  Structure of an EDI MIME message - Encryption/No signature

     3.4.1 S/MIME

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

ContentType = EnvelopedData

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


Notes:

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


     3.4.2 PGP/MIME

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

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

--separator--

Notes:

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


3.5 Structure of an EDI MIME message - No encryption/Signature

     3.5.1 S/MIME

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

ContentType = SignedData

        MIME-Version:   1.0
        Content-Type: multipart/signed; boundary="separator";
        micalg=rsa-<hash-symbol>; protocol="application/x-pkcs7-signature"

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

       --separator
             Content-Type: application/x-pkcs7-signature
             Content-Transfer-Encoding: base64

             <encoded signature>

       --separator--

Notes:

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


    3.5.2 PGP/MIME

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//YRytdhfFFQere
    /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF
    frtFFKFG+GFff=
    =ndaj
    -----END PGP MESSAGE-----

--separator--

Notes:

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


3.6 Structure of an EDI MIME message - Encryption/Signature

    3.6.1 S/MIME

The sequence here is that the EDI data is first signed as a
multipart/signature body.  Then the data plus the signature
are encrypted to form the final multipart/encrypted body.  In other words, the multipart/signed body part is nested within the multipart/encrypted body part.

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

Version: 1.5
Content-Type: application/x-pkcs7-mime
Content-Transfer-Encoding: base64

ContentType = SignedAndEnvelopedData

*MIME-Version:   1.0
*Content-Type: multipart/encrypted; boundary="separator";
*protocol="application/x-pkcs7-mime"
*
*--separator

*      Content-Type: multipart/signed; boundary="signed separator";
*      micalg=rsa-<hash-symbol>;  protocol="application/x-pkcs7-signature"
*
*      --signed separator
*      &Content-Type: Application/<EDI standard>
*      &Content-Transfer-Encoding: <encoding>
*      &
*      &<EDI object>
*
*      --signed separator
*         Content-Type: application/x-pkcs7-signature
*         Content-Transfer-Encoding: base64
*
*          <encrypted signature>
*
*      --signed separator--

--separator--

Notes:

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

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


    3.6.2 PGP/MIME

The sequence here is that the EDI data is first signed as a
multipart/signature body, and then the data plus the signature
is encrypted to form the final multipart/encrypted body. Here
goes:

To:             <receipient 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

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

Notes:

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

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

-Elkins draft 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 [4] RFC 1847.


4. Receipts

4.1   Introduction

In order to provide a non-repudiation of receipt (NRR) or signed
receipt, a message disposition notification as specified by draft-
ietf-receipt-mdn-01 is to be implemented by a receiving trading
partner's UA (User Agent). The  MDN is used to notify a sending
trading partner that sent a signed, or signed and encrypted EDI
Interchange that:

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

     2). The receiving trading partner has authenticated the sender of
         the EDI Interchange.

     3). The receiving trading partner has verified the integrity of the
         received EDI Interchange.

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

     1). If the sent EDI 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 Interchange.

     3). The sender's public key is then used to decrypt the received
         message integrity check  (MIC or Message Digest) calculated by
         the sender using a one-way hash function, and digitally signed
         by the sender. The decryption of the MIC authenticates the
         sender of the EDI Interchange to the receiving trading partner.

     4). The receiving trading partner, using  the same one-way hash
         function that the sending trading partner used, then calculates
         a MIC value on the received EDI Interchange and the RFC 1767
         MIME content header information.

     5). The receiving trading partner compares the received  MIC from
         the sending trading partner with the MIC that the receiving
         trading partner independently calculated. If the two MIC
         values are equal, then the receiving trading partner knows that
         the EDI Interchange that was received was not altered in
         transit from the sending trading partner. The receiving trading
         partner has verified the integrity of the sent EDI Interchange.

     6). The receiving trading partner then digitally signs the MIC that
         was calculated on the received EDI Interchange and the RFC 1767
         MIME content header information.

     7). The receiving trading partner formats the MDN and returns the
         digitally signed MIC back to the sending trading partner in the
         MDN.

The EDI 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 is
calculated across the entire multi-part content, including the  MIME
headers. The multi-part MIME content that contains the EDI Interchange
is then enveloped in either PKCS #7 or PGP format. The signed MIC
returned in the MDN is then a signed receipt for the entire multi-part
MIME content

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

     1). As an acknowledgment that the EDI Interchange sent, was
         delivered and acknowledged by the receiving trading partner.

     2). As an acknowledgment that the integrity of the EDI Interchange
         was verified by the receiving trading partner.

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

     4). As a non-repudiation of receipt, since the returned MIC signed
         by the receiving trading partner could only be signed by the
         receiving trading partner.


4.2 Requesting a signed receipt

Message Disposition Notifications are requested as per the draft-ietf-
receipt-mdn-01.txt. 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"   ":"   address

The address field is specified as an RFC 822 user@domain address, and is
the return address for the message disposition notification.


4.3 Message Disposition Notification Format

The format of a message disposition notification is as specified in draft-
ietf-receipt-mdn-01.txt. For use in EDI over the Internet the following
format will be used:

   - content-type - per  RFC1892 and the ietf-receipt-mdn specification

   - reporting-ua-field - per ietf-receipt-mdn specification

   - mdn-gateway-field - per ietf-receipt-mdn specification

   - original-recipient-field - per ietf-receipt-mdn specification

   - final-recipient-field - per ietf-receipt-mdn specification

   - original-message-id-field - per ietf-receipt-mdn specification

   - disposition-field - for EDI use:

       * autoprocessed - when the received content(s) are
         successfully processed

       * decryption_failed - when the receiver could not decrypt the
         contents

       * authentication_failed - when the receiver could not
         authenticate the sender

       * integrity_check_failed - when the receiver could not verify
         content integrity

   - extension field - the following extension field will be added in
     order to support signed-receipts for RFC 1767 specified content
     types and multi-part specified content types which includes RFC
     1767 content types. The extension field is sent only when the
     received contents are successfully processed.

   - extension field = "X-"  "Received-MIC"  ":"  MIC

MIC or message integrity check, is defined as the result of a one-way
hash function applied to the received EDI Interchange and RFC 1767 MIME
content type information, or the multi-part MIME content containing
RFC 1767 MIME EDI content information. The MIC is also referred to as a
MD5 or message digest. The MIC that is returned in this message
disposition notification extension field is signed with the receiving
trading partner's private key.


4.4 Message Disposition Notification Processing

     4.4.1  Large File Processing

     Large EDI Interchanges sent via SMTP can be automatically
     fragmented by some message transfer agents. A subtype of message,
     "partial", is defined in RFC 1521 to allow large objects to be
     delivered as separate pieces of mail and to be automatically
     reassembled by the receiving user agent. Using message, "partial",
     can help alleviate fragmentation of large messages by different
     message transfer agents, but does not completely eliminate the
     problem. It is still possible that a piece of a partial message,
     upon re-assembly, may prove themselves to contain a partial
     message. This is allowed by the Internet  standards, and it is
     the responsibility of the user agent to reassemble the fragmented
     pieces.

     It is recommended that the size of the EDI Interchange sent via
     SMTP be configurable so that if fragmentation does occur, then
     message, "partial" can be used to send the large EDI Interchange
     in smaller pieces. RFC 1521 defines the use of Content-Type:
     message/partial.

     It is also recommended that very large EDI files not be sent via
     SMTP and a file transfer protocol be used instead.

     The receiving UA is required to  re-assemble the original message
     before sending the message disposition notification to the
     original sender of the message. A message disposition notification
     is used to specify the disposition of the entire message that was
     sent, and should not be returned by a processing UA until the
     entire message is received, even if the received message requires
     re-assembling.


     4.4.2 Example

     The following is an example of an MDN returned by a UA after
     processing a MIME EDI content type that was signed and encrypted:

     NOTE: This example is provided as an illustration only, and is
     not considered part of the protocol specification. If an example
     conflicts with the protocol definitions specified above or in the
     other referenced RFCs, the example is wrong.


Date: Thur, 19 Sep 1996 00:16:55  (EDT)   -0400
From:  Edi  Recipient <Edi_Recipient@edicorp.com>
Message-ID:  <17759920005.12345@edicorp.com>
Subject:   Signed Receipt
To:  Edi Sender  <Edi_Sender@othercorp.com>
MIME-Version 1.0
Content-Type:  multipart/report;  report-type=disposition-notification;
                          boundary = "xxxxx"

--xxxxx

    The message sent to Edi Recipient <Edi_Recipient@edicorp.com>  has
    been received, the EDI Interchange was succesfully decrypted and
    its integrity was verified. In addition, the sender of the message,
    Edi Sender <Edi_Sender@othercorp.com> was authenticated as the
    originator of the message. There is no guarantee however that the
    EDI Interchange was syntactically correct, or was received by the
    EDI application.

--xxxxx
    content-type:  message/disposition-notification

    Reporting-UA:  good-edi-internet-ua.edicorp.com  (ediua 1.0)
    Original-Recipient:  rfc822;  Edi_Recipient@edicorp.com
    Final-Recipient:  rfc822;  Edi_Recipient@edicorp.com
    Original-Message-ID:  <17759920005.12345@edicorp.com>
    Disposition:  autoprocessed
    X-Received-MIC:   Q2hlY2sgSW50XwdyaXRIQ……

--xxxxx
    content-type:   message/rfc822

--xxxxx--


As specified by RFC 1892. Returning the original message is not
necessary. This is an optional body part.


5.   Public key certificate handling

     5.1 Near term approach

     In the near term, and compliant with this Applicability Statement,
     self certification according to guidelines described in the functional
     requirements document, "Requirements for Inter-operable Internet EDI"
     [9] (can be found at www.ietf.org).

     5.2 Long term approach

     Long term, certifying authorities such as Verisign may be used in
     compliance with X.509 guidelines, however, this Applicability
     Statement does NOT require use of a certifying authority (CA).


6.  Authors' Addresses

Mats Jansson
mjansson@agathon.com
LiNK
2317 Broadway, Suite 330
Redwood City, CA 94063 USA

Chuck Shih
chucks@actracorp.com
Actra Corp.
610 East Caribbean Drive
Sunnyvale, CA XXXXX USA

Nancy Turaj
nturaj@mail04.mitre.org
MITRE Corporation
Mailstop: W657
1820 Dolley Madison Blvd.
McLean, VA 22102-3481 USA

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


7. References

[1]  N. Borenstein,  N.Freed, "MIME (Multipurpose Internet Mail Extensions)
     Part One: Mechanisms for Specifying and Describing the Format of
     Internet Message Bodies",  RFC 1521, September 23, 1993.

[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", draft-ietf-receipt-mdn-01.txt, May 13, 1996.

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

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

[8]  RSA Laboratories, "S/MIME Message Specification; PKCS Security
     Services for MIME", Version of February 23, 1996.

[9] C. Shih, "Requirements for Inter-operable Internet EDI", July 1996.

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


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