view Side-By-Side changes

INTERNET DRAFT                        Mats Jansson, LiNK
draft-ietf-ediint-as1-02.txt
draft-ietf-ediint-as1-03.txt          Chuck Shih, Actra
                                                Nancy Turaj, Mitre Corp.
Expire in six months                  Rik Drummond, Drummond Group

19 November, 1996

7 March, 1997

                        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, the ietf-ediint list for discussion, with "AS#1" 
   in the Subject field. To enter/follow the discussion, you need
   to subscribe at ietf-ediint@imc.org.

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

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

  -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 RFCs and their contribution
      3.1.1
   3.1 RFC 821 SMTP [7]
      3.1.2
   3.2 RFC 822 Text Message Format [3]
      3.1.3 RFC 1521 MIME [1]
      3.1.4
   3.3 RFC 1847 MIME Security Multiparts [6]
      3.1.5
   3.4 RFC 1892 Multipart/report [9]
      3.1.6
   3.5 RFC 1767 EDI Content [2]
      3.1.7
   3.6 RFC 2015 PGP/MIME [4]
      3.1.8
   3.7 RFC 2045,2046, and 2049 MIME [1]
   3.8 Internet draft (fajman): Message Disposition Notification
       [5]
      3.1.9 RSA Specifications
   3.9 Internet draft (dusse): - S/MIME (RSA Security, Inc.) Specification [8]
   3.2  Vocabulary
   3.3

4. Structure of an EDI MIME message - No encryption/No signature
   3.4 Applicability
   4.1 Introduction
   4.2 Structure of an EDI MIME message - S/MIME
      3.4.1 S/MIME Overview
      3.4.2 Example: S/MIME - Signature Only
      3.4.3 Example: S/MIME - Encryption Only
      3.4.4 Example: S/MIME - Signature and Encryption
   3.5 PGP/MIME
      4.2.1 No encryption, no signature
      4.2.2 No encryption, signature
      4.2.3 Encryption, no signature
      4.2.4 Encryption, signature
   4.3 Structure of an EDI MIME message - PGP/MIME
      3.5.1.PGP/MIME Overview
      3.5.2 Example: PGP/MIME - Signature Only
      3.5.3 Example: PGP/MIME - Encryption Only
      3.5.4 Example: PGP/MIME - Signature and Encryption

4. S/MIME
      4.3.1 No encryption, no signature
      4.3.2 No encryption, signature
      4.3.3 Encryption, no signature
      4.3.4 Encryption, signature

5. Receipts
   4.1
   5.1 Introduction
   4.2
   5.2 Requesting a signed receipt
   4.3
      5.2.1 Additional signed receipt considerations
   5.3 Message Disposition Notification Format
   4.4
      5.3.1 Message Disposition Notification Extension Fields
   5.4 Message Disposition Notification Processing
      4.4.1
      5.4.1 Large File Processing
      4.4.2
      5.4.2 Example

5.

6. Public key certificate handling
   5.1
   6.1 Near term approach
   5.2
   6.2 Long term approach

6.

7.  Authors' Addresses

7.

8. References



1.  Introduction

     The authors would like to extend special thanks to Carl Hage 
     Dale Moberg and Karen Rosenthal for providing the team with 
     valuable, and very thorough feedback.  Without participants like Carl, these, 
     these efforts become hard to complete in a way useful to the users 
     of the technology.

     The authors would also like to thank Nancy Turaj for her help
     in editing portions of this document.
     
     Previous work on Internet EDI focused 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 enhancement 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 RFCs 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
        -RFC 2015 MIME/PGP (elkins)
        -RFC 2045 to 2049 MIME RFCs
        -Internet draft: Message Disposition Notification (fajman)
        -RFC 2015 MIME/PGP (elkins)
        -Internet draft: S/MIME Specification (dusse)

     Our intent here is to define clearly and precisely how these
     are pieced together used 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 format and 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 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 NOT signed.
    The second term is used if the acknowledgment is for an interchange which was signed,
    resulting in a receipt which is also IS signed.  The rule "rule" is:  If a receipt            
    is requested, it will explicitly specifying that the receipt be signed only if                          
    signed, then the original interchange was
    signed.  A term often used in combination with receipts is "Non-
    repudiation of Receipt (NRR).  NRR refers receipt indeed has to be returned with a legal event which
    occurs only when the original sender of an interchange has verified
    the sender and content of signature.             
    If a "signed receipt".  Note that NRR receipt is not
    possible without signatures.


2.3  Assumptions requested, explicitly specifying that the receipt                
    be signed, but the recipient cannot support the requested                        
    signature format, then a receipt, either signed or unsigned should be returned.  
    If a signature is not explicitly requested, or if the signed receipt             
    request parameter is not recognized by the UA, all bets are off. This is         
    consistent with the MDN draft.                                                   

    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 a signed receipt
        notification is requested, however, a signature is required as
        part of both the original EDI transmission and the returned
        receipt. receipt, unless an error condition occurs
        in which a signed-receipt cannot be returned. In these cases an
        un-signed receipt or MDN should be returned with the correct
        "signed-receipt-disposition" value.

        -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,
        RFC 2015, as reflected in [4] MIME Security with Pretty Good
        Privacy (PGP), and Internet draft [8] S/MIME Specification
        from RSA Security, Inc. (dusse) 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 SHA1 checksum hash function is
        recommended.


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

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

        (2) Sender sends unencrypted un-encrypted 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 or 
            un-signed receipt.

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

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

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

        NOTE: Users can choose any of the eight possibilities, but only
        example (8) (8), when a signed receipt is requested, 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 Referenced RFCs and their contribution

     3.1 RFC 821 SMTP [7]

     This is to be returned, the
     original EDI transmission also had core mail transfer standard that all MTAs need 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 structures themselves, there is a brief review of
     what each document contributes.

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


3.1  Referenced RFCs and their contribution

     3.1.1 RFC 821 SMTP [7]

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


     3.1.2 RFC 822 Text Message Format [3]

     Defines message header fields and
     adhere to.


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


     3.3 RFC 1847 MIME Security Multiparts [6]

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


\     3.1.5


     3.4 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


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


     3.6 RFC 2015 PGP/MIME [4]

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


     3.1.8

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

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


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

     This Internet draft defines how a message disposition notification
     (MDN) is requested, and the structure of the MDN.

     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 "X-" extension fields
     described in this document will be registered with IANA.


     3.1.9


     3.9 Internet draft (dusse): S/MIME Message Specification [8]

     This specification describes how MIME shall carry PKCS7
     signature and envelope information.


3.2  Vocabulary

     <recipient email>         The email address


4. Structure of the receiving
                               organization's an EDI processing system.

     <sender email> MIME message - Applicability

   4.1 Introduction

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

     <date>                    Transmission date

     <EDI standard>            "EDIFACT" 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, structures below are described hierarchically in most cases
                               encoding will be required "Quoted
                               printable" or "Base 64"

     <hash symbol>             "md5" or "sha1"

     <pgp control information> -Key ID of recipient's public key
                               -Session key (symmetric)
                               -Timestamp
                               -Key ID terms of sender's public key
                               -Leading two octets which
   RFC's are applied to form the specific structure.  For details of message digest
                               -Message digest
                               -Filename
                               -Timestamp

     <PKCS#7 control information - enveloped>
                               -contentType = EnvelopedData
                               -version = Version
                               -recipientInfos = RecipientInfos

                               -contentType = Data
                               -contentEncryptionAlgorithm =
                                ContentEncryptionAlgorithmIdentifier

                               -encryptedContent =

     <PKCS#7 control information - signed>
                               -ContentType = SignedData
                               -version = Version
                               -digestAlgorithms =
                                DigestAlgorithmIdentifiers
                               -contentType = Data
                               -content =

     <PKCS#7 signature information>
                               -signerInfos = SignerInfo

     NOTE: The examples below are just that - examples. They are
     provided for illustration purposes only. Refer
   how to code in compliance with all RFC's involved, turn directly to
   the RFCs or
     drafts under "7. References" RFC's referenced.  The "requirements document" has several
   examples described in an Appendix for those interested.

   Also, these structures describe the actual grammar initial transmission only.
   Receipts, and protocol
     definitions.


3.3 requests for receipts are handled in section 5.


   4.2 Structure of an EDI MIME message - PGP/MIME

      4.2.1 No encryption/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

      -RFC822/2045
          -RFC1767 (application/EDIxxxx)


	4.2.2 No encryption, signature

      -RFC822/2045
          -RFC1847 (multipart/signed)
              -RFC1767 (application/EDIxxxx)
              -RFC2015 (application/pgp-signature)


	4.2.3 Encryption, no signature

      -RFC822/2045
          -RFC1847 (multipart/encrypted)
              -RFC2015 (application/pgp-encrypted)
                  -"Version 1"
                  -RFC1767 (application/EDIxxxx) (encrypted)


	4.2.4 Encryption, signature

      -RFC822/2045
          -RFC1847 (multipart/encrypted)
              -RFC2015 (application/pgp-encrypted)
                  -"Version 1"
                  -RFC1767 (application/EDIxxxx) (encrypted)
                  -RFC2015 (application/pgp-signature) (encrypted)
                      

   4.3 Structure of an EDI MIME message - S/MIME

      3.4.1 S/MIME Overview

      S/MIME or the Secure/Multipurpose Internet Mail Extensions,
      specify formats and procedures when the cryptographic security
      services of authentication, message integrity,

      4.3.1 No encryption, no signature

      -RFC822/2045
          -RFC1767 (application/EDIxxxx)


	4.3.2 No encryption, signature

      -RFC822/2045
          -RFC1847 (multipart/signed)
                  -RFC1767 (application/EDIxxxx)
                  -Draft (dusse) (application/x-pkcs7-signature)


	4.3.3 Encryption, no signature

      -RFC822/2045
          -Draft (dusse) (application/x-pkcs7-mime)
              -RFC1767 (application/EDIxxxx) (encrypted)


	4.3.4 Encryption, signature

      -RFC822/2045
          -Draft (dusse) (application/x-pkcs7-mime)
              -RFC1847 (multipart/signed) (encrypted)
                      -RFC1767 (application/EDIxxxx) (encrypted)
                      -Draft (dusse) (application/x-pkcs7-signature) (encrypted)



5. Receipts

5.1   Introduction

In order to support non-repudiation of
      origin, and confidentiality are applied to Internet MIME messages.

      S/MIME is specified in draft draft-dusse-mime-msg-spec-00.txt, and
      an S/MIME implementation guide is available from RSA Data
      Securities, Inc.

      This applicability statement sets forth the implementation
      requirements and recommendations needed to use S/MIME when sending
      EDI receipt (NRR), a signed
receipt, based on the Internet. These implementation requirements and
      recommendations are intended digitally signing a message disposition notification,
is to ensure be implemented by a base level of inter-
      operability among S/MIME EDI implementations.

      NOTE: receiving trading partner's UA (User Agent).
The S/MIME Implementation Guide, Version 2 specifies message disposition notification, specified by draft-ietf-receipt-mdn-02.txt
is digitally signed by a
      restricted profile for use for export purposes receiving trading partner and an unrestricted
      profile for use domestically.  These profiles specify returned to the
      cryptographic algorithms and key lengths that 
sending trading partner as part of a conformant S/MIME
      implementation must support. It is recommended that multipart/signed MIME message.

The required support for signed receipts when doing Internet
      EDI, these profiles be adhered to. However, cryptographic
      algorithms, and key lengths are parameters that need to be set by
      the trading partnership, and can vary from what EDI is specified by as
follows:

    1). Create a multipart/report; report-type = disposition-notification.
    2). Calculate the S/MIME standards.

      Content Types:

      signedAndEnvelopedData content type should not be
      used when sending EDI MIC on the Internet. Objections have been raised
      concerning the fact that message disposition notification.
    3). Digitally sign the issuerAndSerialNumber for each signer
      of MIC.
    4). Create a signedAndEnvelopedData multipart/signed content is left in with the clear. This
      information could be used to derive message disposition
        notification as the identity of first body part, and the signer
      of signed MIC
        calculated on the message. The use of signedAndEnvelopedData also precludes message disposition notification as the ability to sign information that is in addition to, but
      separate from
        second body part.
    5). Return the primary signed contents. The use of the S/MIME
      "authenticated attributes" is not required for Internet EDI, since
      it is generally sufficient receipt to sign the EDI MIME content. sending trading partner.


The S/MIME Implementation Guide, Version 2 requires a compliant
      S/MIME agent signed receipt is used to support the nesting of notify a sending trading partner that requested 
the signed message format
      within an enveloped message, for both incoming and outgoing
      messages. This receipt that:

     1). The receiving trading partner acknowledges receipt of
         the sent EDI AS#1 specification also requires Interchange.

     2). If the support of
      a nested signed sent message within an enveloped message. Therefore,
      when using S/MIME for was signed, then the purpose receiving trading 
         partner has authenticated the sender of sending EDI on the Internet,
      a two step process will be used: EDI Interchange.
         
     3). If the user agent first creates an
      application/x-pkcs7-mime signed message, and uses this sent message as
      input to was signed, then the receiving trading
         partner has verified the creation integrity of an application/x-pkcs7-mime enveloped
      message.

      The receiver the received EDI Interchange.
         
Regardless of an incoming enveloped message that 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 decrypted encrypted, then the encrypted
         symmetric key and found initialization vector (if applicable) is
         decrypted using the receiver's private key.

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

     3). The receiving trading partner authenticates signatures in a signed application/x-pkcs-7-mime type,
      should process
         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 present encoded
             EDI object, as per RFC 1767) in the signature
      status and corresponding "data" content to message disposition
      notification processing -- if a request for a message disposition
      notification has been made -- otherwise the "data" content received is
      passed to a general MIME processor.
             calculated using the same one-way hash function that the
             sending trading partner used.

         c). The "data" content type MIC extracted from the signature is used as compared with the content within
             MIC calculated using the same one-way hash function that
             the sending trading partner used.

     4). The receiving trading partner formats the
      signedData MDN and sets the envelopedData content types, to indicate
         calculated MIC into the "X-Received-content-MIC" extension field.
        
     5). The receiving trading partner creates a multipart/signed MIME
         message content which has had security services applied according to
      it. For the purpose of Internet EDI, this "data" content type will
      contain RFC 1767 specified MIME EDI content, or a MIME multipart
      content that has a RFC 1767 MIME EDI content as 1847.
 
     6). The MDN is the first part of the
      multipart content.

      Signed Message Type:

      The S/MIME specification requires support of the signedData
      content format, multipart/signed message, and recommends support of
         the multipart/signed
      format. For use in Internet EDI, support digital signature is required for the
      signedData content format if message authentication, integrity,
      and non-repudiation of origin are required. created over this MDN, including its
         MIME headers.

     7). The great value for
      support second part of the multipart/signed format is message contains the ability of non-
      S/MIME-enabled agents to process
         digital signature. The "protocol" option specified in the content
         second part of the body that was
      signed.

      The multipart/signed format is recommended when a signed message as follows:

                  S/MIME: protocol = "application/pkcs-7-signature"
         
                  PGP/MIME: protocol = "application/pgp-signature"
 
     8). The signature information is being sent to a set of recipients, not all of which are known formatted according to have S/MIME enabled agents. Since trading partners using S/MIME
      to transact
         or PGP/MIME specifications.  
         
The EDI on the Internet will by definition have S/MIME-
      enabled agents, Interchange and the multipart/signed loses much of its utility.
      Support RFC 1767 MIME EDI content header, can
actually be part of a multi-part MIME content-type.  When the multipart/signed format for use in Internet EDI
Interchange is
      therefore optional.


      3.4.2 Example: S/MIME - Signature Only

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

<PKCS#7 control information - signed>

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

<PKCS#7 signature information>


Notes:

-The lines preceded with "&" is what part of a multi-part MIME content-type, the signature MIC is
calculated
over

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

    ContentType = SignedData
    version = Version
    digestAlgorithms = DigestAlgorithmIdentifiers
    contentType = Data across the entire multi-part content, including the  MIME
headers. The multi-part MIME content =

    NOTE: that except for ContentType and Content, contains the actual object
    identifiers EDI Interchange
is then enveloped in either S/MIME or values for PGP/MIME format.

The signed MDN, when received by the fields are not specified. (See PKCS#9
    and sender of the S/MIME Implementation Guide, Version 2 from RSA Labs, Inc.,
    for these object identifiers.)

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

    signerInfos = SignerInfo

    NOTE: The signerInfo contains EDI Interchange can then
be used by the digestAlgorithm, sender:

     1). As an acknowledgment that the
    digestEncryptionAlgorithm, EDI Interchange sent, was
         delivered and acknowledged by the encryptedDigest or the digital
    signature. The issuerAndSerialNumber field defined within the
    signerInfos identifies a signing receiving trading partner's public-key
    certificate. Since Internet EDI allows self-certification, partner.
         The receiver does this
    field can contain by returning the distinguished name original message
         id of the sending trading
    partner for sent message in the issuer distinguished name.


      3.4.3 Example: S/MIME - Encryption Only

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

<PKCS#7 control information - enveloped>

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


Notes:

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

- <PKCS#7 control information - enveloped> consists MDN portion of (See
PKCS#7:Cryptographic Message Syntax Standard from RSA Labs, Inc.):

    contentType = EnvelopedData
    version = Version
    recipientInfos = RecipientInfos

    contentType = Data
    contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier

    encryptedContent =

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

    NOTE: The recipientInfos contains signed receipt. 

     2). As an acknowledgment that the symmetric encryption key
    encrypted with integrity of the receiver's public key. The issuerAndSerialNumber
    field defined within EDI Interchange
         was verified by the recipientInfos identifies a receiving trading partner's public-key certificate. Since Internet EDI allows
    self-certification, partner. The receiver
         does this field can contain by returning the distinguished name calculated MIC of the receiving trading partner for the issuer distinguished name.

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


      3.4.4 Example: S/MIME - Signature and Encryption

The required support for EDI Internet is to first create an
application/x-pkcs7-mime signedData message, and then to create an
application/x-pkcs7-mime envelopedData message with the application/x-
pkcs7-mime signedData message as input to the application/x-pkcs7-mime
envelopedData message.

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

<PKCS#7 control information - enveloped>

         *Mime-Version:  1.0
         *Content-Type: application/x-pkcs7-mime

         *<PKCS#7 control information - signed>
         
              *&MIME-Version:   1.0
              *&Content-Type: Application/<EDI standard>;
              *&Content-Transfer-Encoding: <encoding>

              *&<EDI object>

         *<PKCS#7 signature information>


Notes:

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

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

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

    contentType = EnvelopedData
    version = Version
    recipientInfos = RecipientInfos

    contentType = Data
    contentEncryptionAlgorithm = ContentEncryptionAlgorithmIdentifier

    encryptedContent =

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

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

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

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

    signerInfos = SignerInfo

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


   3.5 Structure of an received EDI
         Interchange (and 1767 MIME message - PGP/MIME

      3.5.1 Overview

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

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

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

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

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

      2) Encryption only

      3) Both signature and encryption

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

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

      -Compression and ASCII Armor is optional and could be user
      configurable.

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

      3.5.2 Example: PGP/MIME - Signature Only

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

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

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

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

    fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQere
    /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF
    frtFFKFG+GFff=
    =ndaj
    -----END PGP MESSAGE-----

--separator--

Notes:

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


      3.5.3 Example: PGP/MIME - Encryption Only

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

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

    Version: 1

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

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

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

--separator--

Notes:

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

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

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


      3.5.4 Example: PGP/MIME - Signature and Encryption

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

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

    Version: 1

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

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

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

--separator--

Notes:

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

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

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

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

-RFC 2015 allows another way to handle the above headers) in a combined
fashion,  However, for the purpose "X-Received-content-MIC"
         field of EDI we require the above method,
which is based on MIME Security Multiparts [4] RFC 1847. This method
performs signature and encryption in a two-step process, first signing signed MDN.

     3). As an acknowledgment that the data, then encrypting it.  This is also consistent with PGP's
recommendations.


4. Receipts

4.1   Introduction

In order to provide receiving trading partner has
         authenticated the sender of the EDI Interchange.

     4). As a non-repudiation of receipt (NRR) or when the signed
receipt, a message disposition notification (MDN) as specified by draft-
ietf-receipt-mdn-01 MIC calculated
         over the MDN, is to be implemented successfully decrypted by a the sender with the
         receiving trading partner's UA (User Agent). The public key.

5.2 Requesting a signed receipt

Message Disposition Notifications are requested as per draft-ietf-
receipt-mdn-02.txt, "An Extensible Message Format for Message Disposition
Notification". A request that the receiving user agent issue a
message disposition notification is then digitally signed and returned to made by placing the sending trading partner
as part of a multipart/signed content. following header
into the message to be sent:

     mdn-request-header = "Disposition-notification-to"   ":"  mail-address

The required support for signed receipts when doing EDI Internet mail-address field is specified as follows:

    1). Create a multipart/report; report-type=disposition-notification.
    2). Calculate an RFC 822 user@domain address, and is
the MIC on return address for the message disposition notification.
    3). Digitally sign the MIC.
    4). Create

In addition to requesting a message disposition notification, a multipart/signed content with the message
disposition notification that is digitally signed, or what has been referred 
to as the first body part, and the a signed MIC
        calculated on receipt, can be requested by placing the following in the message disposition notification as 
header following the
        second body part.
    5). Return "Disposition-notification-to" line:

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

Where disposition-notification-parameters = signed-receipt-protocol=O, <protocol symbol>; 
    
The currently supported values for <protocol symbol> are "x-pkcs7-signature", for the signed receipt to
S/MIME detached signature format, or "pgp-signature", for the sending trading partner. pgp signature format.
  
An example of a formatted options line would be as follows:

    Disposition-notification-options: signed-receipt-protocol=O, x-pkcs7-signature; 
        
The  MDN semantics of the "signed-receipt-protocol" parameter is as follows:

1). The "signed-receipt-protocol" parameter is used to notify a sending trading partner that sent request a signed, 
or signed and encrypted EDI Interchange that:

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

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

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

Regardless of whether "signed-receipt-protocol" parameter
    also specifies the EDI Interchange was sent format 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 which the encrypted
         symmetric key and initialization vector (if applicable) is
         decrypted using signed receipt should be returned to
    the receiver's private key.

     2). requester.

    The decrypted symmetric encryption key is then MIC algorithm and signature algorithm used in formulating the signed receipt
    are agreed to decrypt in the EDI Interchange.

     3). The receiving trading partner authenticates signatures relationship. The actual algorithms
    used in a 
         message using the sender's public key. The authentication 
         algorithm performs signed receipt are always returned as part of the following:
         
         a). signed receipt.  

2). The message integrity check (MIC or Message Digest)
             contained within the signature "importance" attribute of "O" is decrypted using the
             sender's public key.
         
         b). A MIC on defined in the signed contents (the MIME header MDN draft and encoded
             EDI object, as per RFC1767) in has the message received is
             calculated using
    following meaning:

    Parameters with an importance of "O" permit a UA that does not understand the same one-way hash function
    "signed-receipt-protocol" parameter to still generate a MDN in response to
    a request for a MDN. A UA that does not understand the
             sending trading partner used. 

         c). "signed-receipt-protocol"
    parameter, will obviously not return a signed receipt.
    
    The MIC extracted from the signature importance of "O" is compared with the
             MIC calculated using used for the same one-way hash function signed receipt parameters because it
    is desirable that an MDN be returned to the sending trading partner used. 

     4). The receiving requesting trading partner formats even
    if the recipient could not sign it. The returned MDN and sets will contain information
    on the
         calculated MIC into disposition of the message as well as why the MDN could not be signed.
    See the disposition and extension field. 
         
     5). The receiving fields in section 5.3 for more information.

    Within an EDI trading partner creates relationship, if a multipart/signed MIME
         message according to RFC 1847.
  
     6). The MDN signed-receipt is expected and is
    not returned, then the first part validity of the multipart/signed message, and transaction is up to the digital signature trading
    partners to resolve. In general, if a signed-receipt is created over this MDN, including its
         MIME headers. 

     7). The second part of required in the multipart/signed message contains
    trading relationship and is not received, the
         digital signature. transaction will likely  
    not be considered valid.

5.2.1 Additional Signed Receipt Considerations                                      

    The "protocol" option specified "rules" stated in the
         multipart/signed is Section 2.2.3 for signed receipts are as follows:

                  S/MIME: protocol = "application/pkcs-7-mime"
          
                  PGP/MIME: protocol = "application/pgp-signature"  
          

The EDI Interchange and      
    
    1). When a receipt is requested, explicitly specifying that the RFC 1767 MIME EDI content header, can
actually receipt       
        be part of signed, then the receipt indeed has to be returned with a multi-part MIME content-type. signature.   
      
    2). When the EDI
Interchange is part of a multi-part MIME content-type, the MIC receipt is
calculated across requested, explicitly specifying that the entire multi-part content, including receipt             
        be signed, but the  MIME
headers. The multi-part MIME content that contains recipient cannot support the EDI Interchange
is requested                 
        signature format, then enveloped in either PKCS #7 a signed or PGP format. 

The unsigned receipt should be      
        returned. 
         
    3). When a signature is not explicitly requested, or if the signed MDN, when received receipt    
        request parameter is not recognized by the sender of the EDI Interchange can UA, then all bets are off.     
        In this situation, no receipt, an unsigned receipt, or a signed receipt   
        may be used returned by the sender:

     1). As an acknowledgment recipient.                                                   
        
NOTE: For Internet EDI, it is recommended that when a signature is not            
      explicitly requested, or if parameters are not recognized, that the EDI Interchange sent, UA      
      send back at a minimum, an unsigned receipt. If a signed receipt however    
      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 always returned as a policy, whether requested or not, then any false   
      unsigned receipts can be repudiated.                                               

    When a request for a signed MDN.  
 
     2). As receipt is made, but there is an acknowledgment that error in processing
    the integrity contents of the EDI Interchange
         was verified by the receiving trading partner. message, a signed receipt should still be returned. 
    The receiver
         does this by returning request for a signed receipt should still be honored, though the calculated MIC of transaction
    itself may not be valid. The reason for why the received EDI
         Interchange (and 1767 MIME headers) contents could not be processed
    should still be set in the X-Received-MIC
         field "disposition-field". 

    When a request for a signed receipt is made, then the calculation of the            
    "X-Received-content-MIC" should be as follows:                                      
   
    - For any signed MDN. 
         
     3). As an acknowledgment that the receiving trading partner has
         authenticated messages, the sender of MIC to be returned is calculated on the EDI Interchange. 

     4). As a non-repudiation of receipt when RFC 1767     
      MIME header and content, or multipart MIME header and content.                    
    
    - For encrypted, unsigned messages, the signed MIC to be returned is calculated
         over on the MDN, is successfully     
      decrypted by RFC 1767 MIME header and content, or multipart MIME header and content. 

    - For unsigned, unencrypted messages, the sender with MIC should be calculated over the
         receiver's public key. 

4.2 Requesting a signed receipt

Message Disposition Notifications are requested as per message 
      body prior to Content-Transfer-Encoding or Content-Encoding, and without the draft-ietf-
receipt-mdn-01.txt. MIME 
      or any other RFC 822 headers, since these are sometimes altered or reordered by   
      MTAs. 
       
    A request new extension field that further qualifies the receiving user agent issue a
message disposition notification "disposition-field" is made            
    defined by placing the following header
into the message to be sent:

     mdn-request-header = "Disposition-notification-to"   ":"   address this specification. The address field "X-Disposition-qualifier-field"          
    is used to convey additional error or status information on the value             
    specified as an RFC 822 user@domain address, and is in the return address for "disposition-field".                                             
    
    Situations arise in EDI where even if a trading partner cannot be                 
    authenticated correctly, the message disposition notification.

A note trading partners still agree                         
    to implementors: this RFC does not preclude continue processing the sending of a
signed receipt whenever EDI content transactions. Transaction reconciliation           
    is received by a done between the trading partner.
The sending of partners at a signed receipt can be made later time. The                         
    "X-Disposition-qualifier-field" allows for qualifying an "autoprocessed-with-warning"  
    disposition value with a configurable parameter,
and "X-Disposition-qualifier-field" of "authentication-failed"    
    for instance. This use of a signed receipt may be returned disposition qualifier value would convey in the above     
    example, that even though authentication failed, the original message
does not contain a receipt request.
 
4.3 receiving trading            
    partner still processed the received EDI transactions.                            


 
5.3 Message Disposition Notification Format

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

   - content-type - per  RFC1892  RFC 1892 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
       
        "notprocessed" - when the The received content(s) are
         successfully was not processed.
 
        "autoprocessed" - The message has been processed

       * decryption_failed automatically                 
                          in some manner (e.g., printed, faxed, forwarded, gatewayed)  
                          in response to some user request made in advance, without    
                          being displayed to the user.  The user may or may not see    
                          the message later.
        
        "autoprocessed-with-warning" - when The message has been processed automatically       
                                       in some manner (e.g., printed, faxed, forwarded,   
                                       gatewayed) in response to some user request made   
                                       in advance, without being displayed to the user. The user 
                                        may or may not see the message later.                                      |
                                       Additionally, the "disposition-qualifier-field"    
                                       may be set with a warning description.                
         
        "decryption-failed" - The receiver could not decrypt the
         contents

       * authentication_failed contents.
         
        "authentication-failed" - when the The receiver could not authenticate the sender

       * integrity_check_failed sender.
         
        "integrity-check-failed" - when the The receiver could not verify content integrity

   - extension field integrity.

        "unexpected-processing-error" -  A catch-all for additional processing errors.    
                                         
   Note: The "notprocessed" disposition value should be used when the message content is  
   being rejected or ignored, for instance if it is determined that a signed receipt      
   cannot be returned so the UA chooses not to process the message content itself. The    
   "unexpected-processing-error" should be used when an actual error is encountered       
   when processing the message content. 
                                                    
  5.3.1 Message Disposition Notification Extension Fields

   The following extension field "extension fields" will be added in order to support signed-receipts signed receipts for
   RFC 1767 specified MIME content types and multi-part specified MIME content types which includes that include the RFC
   1767 MIME content types. The "extension fields" defined below follow the 
   "disposition-field" in the MDN.
      
     The "X-Disposition-qualifier-field" is used to further qualify the value          
     in the "disposition-field". The value of the "X-Disposition-qualifier-field"      
     can be used to further describe the "autoprocessed-with-warning" disposition      
     value, or as further elaboration of any other "disposition-field". This field is  
     optional, and when it is not used, does not appear in the MDN. The values
     for the "X-Disposition-qualifier-field" are implementation dependent.  

     - extension field = "X-"  "Disposition-qualifier-field"  ":"  value               
                          
     The "X-Received-content-MIC" extension field is sent only when set when the integrity of the     
     received message is verified.  The MIC is the hex coded quantity computed over    
     a "body part" with a message digest or hash function. For details of "what"       
     the "X-Received-content-MIC" should be calculated over, see Section 5.2.1.        
     The algorithm used to calculate the "X-Received-content-MIC" value should be      
     the same as the "micalg" value received in the multipart/signed. When no signature 
     is received, then it is recommended that the SHA1 algorithm be used to calculate  
     the "X-Received-content-MIC" value.                                               
                  
     This field is set only when the contents of the message are processed             
     successfully. This field is used in conjunction with the
     received contents are successfully processed. recipient's signature    
     on the MDN in order for "non-repudiation of receipt" to occur on the sender's     
     side.      

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

MIC or message integrity check, is defined as                          

     where:                                                                            

     <MIC> = <hexMicValue> "," <micalg>                                                

     <hexMicValue> = the result of a one-way
hash function applied to the received EDI Interchange and RFC 1767 MIME
content type information, or one way hash function, coded                    
                     as hexadecimal digits.
      
     < micalg> = the multi-part MIME content containing
RFC 1767 MIME EDI content information. The micalg value defined in RFC1847, an IANA registered               
                 MIC algorithm ID token.

     The "X-Signed-receipt-disposition" extension field is also referred to as a
message digest set when using a request
     for a signed receipt is made by the MD5 one-way hash function. 


4.4 sender, but cannot be returned by the receiver. 

   - extension field = "X-" "Signed-receipt-disposition": signed-receipt-disposition

     where signed-receipt-disposition is:

      "unsupported-format" - A request for a signed receipt cannot be returned because 
                             the requested format is not supported.
           
      "unexpected-error" -   A catch-all for errors that prevent a signed receipt from 
                             being returned when it has been requested.
              
5.4 Message Disposition Notification Processing

     4.4.1
         
     5.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 2045 [1] 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 to contain a partial message as well.
     This is allowed by the Internet standards, and it is
     the responsibility of the user agent to re-assemble 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 2045 [1] defines the use of Content-Type:
     message/partial. Support of the message/partial content type for
     use in Internet EDI is optional.                
       
     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.

     In general, EDI content compresses well, since there is repetitive
     data in most EDI Interchanges. Instead of implementing the
     message/partial, compression of the EDI Interchange can be done
     after the signature is applied to the EDI Interchange, and before
     encryption. When no signature is applied, then compression is applied
     before the encryption. Compression applied
     before the encryption. Compression is an alternative solution to
     implementing Content-Type: message/partial when sending large EDI
     Interchanges on the Internet.

     Applying compression before encryption strengthens cryptographic                   
     security since repetitious strings are reduced.  This sequence of                   
     signature, compression, then encryption, or compression then encryption,            
     is consistent with the order in which PGP implementations handle compression.        

     Note: Compression is done automatically when using PGP encryption.                   

     The MIME standards [1], do not define a way in which to convey                      
     that a message has been compressed. However, RFC 2045 [1] does allow the definition 
     of additional MIME header fields to further describe the content of a message.      

     RFC 2068 [11], the HTTP/1.1 specification does define a Content-Encoding field that 
     is primarily used to convey compression information:                                

                  Content-Encoding = "Content-Encoding" ":" content-coding               

     where content-coding can take on the values of "gzip" or "compress".                

     The gzip compression standard is furthur described in RFC 1952 [12], and compress   
     is an alternative solution to
     implementing Content-Type: message/partial when sending large EDI
     Interchanges on the Internet.

     Applying standard UNIX file compression before encryption strengthens cryptographic
     security since repetitious strings program. Both "gzip" and "compress" are reduced.  This sequence is
     consistent       
     registered with IANA.                                                               

     Trading partners can adopt the PGP sequence as well.
 
     4.4.3 use of the Content-Encoding header if they need to   
     compress their EDI data and convey the compression type to their trading partners.         
       

     
     5.4.2 Example

     The following is an example of a signed receipt returned by a UA
     after successfully processing a MIME EDI content type that was signed. type. The sending
     trading partner has requested a return signed receipt.  
     This example follows the S/MIME application/x-pkcs-7-signature format. 

     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.

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

--separator
      &Content-Type:  multipart/report;  report-type=disposition
      &       notification;  boundary = "xxxxx"
      &
      &--xxxxx
      &Content-Type: text/plain
      &    The
      &The message sent to Edi Recipient <Edi_Recipient@edicorp.com> 
      &    has
      &has been received, the EDI Interchange was succesfully
      &    decrypted successfully
      &decrypted and its integrity was verified. In addition, the
      &    sender
      &sender of the message, Edi Sender <Edi_Sender@othercorp.com>
      &    was
      &was authenticated as the originator of the message. There is
      &    no
      &no guarantee however that the EDI Interchange was
      &    syntactically
      &syntactically correct, or was received by the EDI
      &    application.
      &application.
      &
      &--xxxxx
      &    Content-Type:
      &Content-Type:  message/disposition-notification
      &
      &    Reporting-UA:
      &Reporting-UA:  good-edi-internet-ua.edicorp.com  (ediua 1.0)
      &    Original-Recipient:
      &Original-Recipient:  rfc822;  Edi_Recipient@edicorp.com
      &    Final-Recipient:
      &Final-Recipient:  rfc822;  Edi_Recipient@edicorp.com
      &    Original-Message-ID:
      &Original-Message-ID:  <17759920005.12345@edicorp.com>
      &    Disposition:
      &Disposition:  autoprocessed
      &    X-Received-MIC:   Q2hlY2sgSW50XwdyaXRIQ……
      &X-Disposition-qualifier-field: none
      &X-Received-content-MIC:   Q2hlY2sgSW50XwdyaXRIQ, rsa-sha1
      &
      &--xxxxx
      &    Content-Type:
      &Content-Type: message/rfc822
      &
      &To: <recipient email>
      &Subject: 
      &       
      &     [additional header fields go here]  
      &
      &--xxxxx--
--separator
    Content-Type: application/x-pkcs7-mime application/x-pkcs7-signature
    Content-Transfer-Encoding: base64

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

    fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQere
    /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF
    frtFFKFG+GFff=
    =ndaj
@signerInfos = SignerInfo
--separator--

Notes:

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

-The text preceeded preceded by "@" indicates PKCS#7 defined fields and types.
(See PKCS#7:Cryptographic

 (For details on how to prepare the multipart/signed with protocol
  = "application/x-pkcs7-signature" see the "S/MIME Message Syntax Standard from RSA Labs, Inc.) Specification,
  PKCS Security Services for MIME" documentation.) 

Note: As specified by RFC 1892, 1892 [10], returning the original or portions of
the original message in the third body part of the multipart/report is not
necessary. required. 
This is an optional body part. It is recommended that the received headers from the
original message be placed in the third body part, as it can be
helpful in tracking problems. 


5. 

Also 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 of the multipart/report when used in    
this way, allows a person to better diagnose a problem in detail.                

6.   Public key certificate handling

     5.1

     6.1 Near term approach

     In the near term, the exchange of public keys and certificaition 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 RFC822 RFC 822 [3] email address. The procedures for
     establishing a trading partnership and configuring the secure EDI
     messaging system might vary among trading partners and software
     packages.

     For systems which make use of X.509 certificates, it is recommended
     that trading partners self-certify each other if an agreed upon
     certification authority is not used. It is highly recommended that
     when trading partners are using S/MIME, that they also exchange
     public key certificates using the recommendations specified in the
     S/MIME Implementation Guide Version 2. The message formats and
     S/MIME conformance requirements for certificate exchange are
     specified in this document.
    
     This applicability statement does NOT require the use of a
     certification authority. 

     5.2

     6.2 Long term approach

     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.


6.


7.  Authors' Addresses

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

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

Nancy Turaj
nturaj@.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.


8. References

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

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

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

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

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

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

[5]  R. Fajman, "An Extensible Message Format for Message Disposition
     Notifications", 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, Oct.     
	3,1995    
     3, 1995

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

[8]  S. Dusse, "S/MIME Message Specification; PKCS Security
     Services for MIME", Internet draft: draft-dusse-mime-msg-spec
     00.txt

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

[11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext
     Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

[12] L. Deutsch, "GZIP File Format Specification Version 4.3", RFC 1952, 
     May 23, 1996.  





----