rfc3335.txt

RFC 的详细文档！

      & Content-Type:  multipart/report; report-type=disposition
      &   notification;  boundary="xxxxx"
      &
      & --xxxxx
      & Content-Type: text/plain
      &
      & The message sent to Recipient <[e-mail]>
      & has been received, the EDI Interchange was successfully
      & decrypted and its integrity was verified.  In addition, the



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


      & sender of the message, Sender <[e-mail]>
      & 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: Interchange.cyclonesoftware.com (CI 2.2)
      & Original-Recipient: rfc822; [e-mail]
      & Final-Recipient: rfc822;  [e-mail]
      & Original-Message-ID: <[e-mail] >
      & Disposition: automatic-action/MDN-sent-automatically; processed
      & Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, sha1
      &
      & --xxxxx
      & Content-Type: message/rfc822
      &
      & To: <recipient email>
      & Subject:
      &
      &  [additional header fields go here]
      &
      & --xxxxx--

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

        MIIHygYJKoZIhvcNAQcDoIIHuzCCB7cCAQAxgfIwge8CAQAwg
        ZgwgYMxFjAUBgNVBAMTDVRlcnJ5IEhhcmRpbmcxEDAOBgNVBA
        oTB0NZQ0xPTkUxDDAKBgNVBAsTA04vQTEQMA4GA1UEBxMHU=

      --separator--

   Notes:

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

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






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


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

   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.0 Public Key Certificate Handling

6.1 Near Term Approach

   In the near term, the exchange of public keys and certification of
   these keys must be handled as part of the process of establishing a
   trading partnership.  The UA and/or EDI application interface must
   maintain a database of public keys used for encryption or signatures,
   in addition to the mapping between EDI trading partner ID and 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 Version 3 Message Specification.  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.  The use of a certification authority is
   therefore OPTIONAL.

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.






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


7.0 Security Considerations

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

   Extracted from S/MIME Version 2 Message Specification:

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

   Extracted from S/MIME Version 2 Certificate Handling:

   When processing certificates, there are many situations where the
   processing might fail.  Because the processing may be done by a user
   agent, a security gateway, or other program, there is no single way
   to handle such failures.  Just because the methods to handle the
   failures has not been listed, however, the reader should not assume
   that they are not important.  The opposite is true:  if a certificate
   is not provably valid and associated with the message, the processing
   software should take immediate and noticeable steps to inform the end
   user about it.

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

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

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






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


8.0 Acknowledgments

   Many thanks go out to the previous authors of the MIME-based Secure
   EDI IETF Draft:  Mats Jansson.

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

   In addition, the authors would like to thank Harald Alvestrand, Jim
   Galvin, and Roger Fajman for their guidance and input.

9.0 References

   [1]  Borenstein, N. and N. Freed, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

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

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

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

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

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

        Callas, J., Donnerhacke, L., Finney, H. and R.Thayer "OpenPGP
        Message Format", RFC 2440, November 1998.

        Elkins, M., Del Torto, D., Levien, R. and T. Roessler "MIME
        Security with OpenPGP", RFC 3156, August 2001.

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

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



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


   [7]  Klensin, J., "Simple Mail Transfer Protocol",  RFC 2821, April
        1982.

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

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

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







































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


Appendix IANA Registration Form

A.1 IANA registration of the signed-receipt-protocol content
    disposition parameter

      Parameter-name: signed-receipt-protocol
      Syntax: See section 5.2 of this document
      Specification: See section 5.2 of this document

A.2 IANA registration of the signed-receipt-micalg content
    disposition parameter

      Parameter-name: signed-receipt-micalg
      Syntax: See section 5.2 of this document
      Specification: See section 5.2 of this document

A.3 IANA registration of the Received-content-MIC MDN extension
    field name

      Extension field name: Received-content-MIC
      Syntax: See section 5.3.1 of this document
      Specification: See section 5.3.1 of this document

Authors' Addresses

   Terry Harding
   Cyclone Commerce
   8388 E. Hartford Drive
   Scottsdale, Arizona 85255, USA

   EMail: [e-mail]


   Chuck Shih
   Gartner Group
   251 River Oaks Parkway
   San Jose, CA 95134-1913 USA

   EMail: [e-mail]


   Rik Drummond
   Drummond Group
   P.O. Box 101567
   Ft. Worth, TX 76105 USA

   EMail: [e-mail]




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


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.  v This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




















Harding, et. al.            Standards Track                    [Page 29]