rfc3335.txt

RFC 的详细文档！

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

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

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

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

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

3.0 Referenced RFCs and Their Contribution

3.1 RFC 821 SMTP [7]

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

3.2 RFC 822 Text Message Format [3]

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

3.3 RFC 1847 MIME Security Multiparts [6]

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

3.4 RFC 1892 Multipart/report [9]

   This RFC defines the use of the multipart/report content type,
   something that the MDN RFC 2298 builds upon.



Harding, et. al.            Standards Track                     [Page 8]

RFC 3335                 MIME-based Secure EDI            September 2002


3.5 RFC 1767 EDI Content [2]

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

3.6 RFC 2015, 3156, 2440 PGP/MIME [4]

   These RFCs define the use of content types "multipart/encrypted",
   "multipart/signed", "application/pgp encrypted" and
   "application/pgp-signature" for defining MIME PGP content.

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", "sub-type" and "multipart", as well as encoding
   guidelines, which establishes 7-bit US-ASCII as the canonical
   character set to be used in Internet messaging.

3.8 RFC 2298 Message Disposition Notification [5]

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

3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8]

   This specification describes how MIME shall carry CMS Objects.

4.0 Structure of an EDI MIME Message - Applicability

4.1 Introduction

   The structures below are described hierarchically in terms of which
   RFC's are applied to form the specific structure.  For details of how
   to code in compliance with all RFC's involved, turn directly to the
   RFC's referenced.

   Also, these structures describe the initial transmission only.
   Receipts, and requests for receipts are handled in section 5.









Harding, et. al.            Standards Track                     [Page 9]

RFC 3335                 MIME-based Secure EDI            September 2002


4.2 Structure of an EDI MIME Message - PGP/MIME

4.2.1 No Encryption, No Signature

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

4.2.2 No Encryption, Signature

   -RFC822/2045
     -RFC1847 (multipart/signed)
       -RFC1767 (application/EDIxxxx or /xml)
       -RFC2015/2440/3156 (application/pgp-signature)

4.2.3 Encryption, No Signature

   -RFC822/2045
     -RFC1847 (multipart/encrypted)
       -RFC2015/2440/3156 (application/pgp-encrypted)
         -"Version: 1"
       -RFC2015/2440/3156 (application/octet-stream)
         -RFC1767 (application/EDIxxxx or /xml) (encrypted)

4.2.4 Encryption, Signature

   -RFC822/2045
     -RFC1847 (multipart/encrypted)
       -RFC2015/2440/3156 (application/pgp-encrypted)
         -"Version: 1"
       -RFC2015/2440/3156 (application/octet-stream)
         -RFC1847 (multipart/signed)(encrypted)
           -RFC1767 (application/EDIxxxx or /xml)(encrypted)
           -RFC2015/2440/3156 (application/pgp-signature)(encrypted)

4.3 Structure of an EDI MIME Message - S/MIME

4.3.1 No Encryption, No Signature

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

4.3.2 No Encryption, Signature

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




Harding, et. al.            Standards Track                    [Page 10]

RFC 3335                 MIME-based Secure EDI            September 2002


4.3.3 Encryption, No Signature

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

4.3.4 Encryption, Signature

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

5.0 Receipts

5.1 Introduction

   In order to support non-repudiation of receipt (NRR), a signed
   receipt, based on digitally signing a message disposition
   notification, is to be implemented by a receiving trading partner's
   UA (User Agent).  The message disposition notification, specified by
   RFC 2298 is digitally signed by a receiving trading partner as part
   of a multipart/signed MIME message.

   The following support for signed receipts is REQUIRED:

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

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

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

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

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

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





Harding, et. al.            Standards Track                    [Page 11]

RFC 3335                 MIME-based Secure EDI            September 2002


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

   3) If the sent message was signed, then the receiving trading partner
      has verified the integrity of the sent 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 receiving trading partner authenticates signatures in a
      message using the sender's public key.  The authentication
      algorithm performs the following:

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

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

      c) The MIC extracted from the message that was sent, and the MIC
         calculated using the same one-way hash function that the
         sending trading partner used is compared for equality.

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

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

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









Harding, et. al.            Standards Track                    [Page 12]

RFC 3335                 MIME-based Secure EDI            September 2002


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

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

      PGP/MIME: protocol = "application/pgp-signature"

   8) The signature information is formatted according to S/MIME or
      PGP/MIME specifications.

   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 MUST
   be calculated across the entire multi-part content, including the
   MIME headers.

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

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

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

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

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

5.2 Requesting a Signed Receipt

   Message Disposition Notifications are requested as per RFC 2298,

   "An Extensible Message Format for Message Disposition Notification".
   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:




Harding, et. al.            Standards Track                    [Page 13]

RFC 3335                 MIME-based Secure EDI            September 2002


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

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

   In addition to requesting a message disposition notification, a
   message disposition notification that is digitally signed, or what
   has been referred to as a signed receipt, can be requested by placing
   the following in the message header following the "Disposition-
   Notification-To" line.

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

   where

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

   where

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

   where

     importance = "required" | "optional"

   So the Disposition-notification-options string could be:

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

   The currently supported values for <protocol symbol> are
   "pkcs7-signature", for the S/MIME detached signature format, or
   "pgp-signature", for the pgp signature format.

   The currently supported values for MIC algorithm values are:

   Algorithm   Value
   used

   MD5         md5
   SHA-1       sha1





Harding, et. al.            Standards Track                    [Page 14]

RFC 3335                 MIME-based Secure EDI            September 2002


   (Historical Note:  Some early implementations of EDIINT emitted and
   expected "rsa-md5" and "rsa-sha1" for the micalg parameter.)
   Receiving agents SHOULD be able to recover gracefully from a micalg
   parameter value that they do not recognize.

   An example of a formatted options line would be as follows:

   Disposition-notification-options:
     signed-receipt-protocol=optional, pkcs7-signature;
     signed-receipt-micalg=optional, sha1, md5

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

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

      The "signed-receipt-micalg" parameter is a list of MIC algorithms
      preferred by the requester for use in signing the returned
      receipt.  The list of MIC algorithms should be honored by the
      recipient from left to right.