📄 rfc3335.txt
字号:
Network Working Group T. Harding
Request for Comments: 3335 Cyclone Commerce
Category: Standards Track R. Drummond
Drummond Group
C. Shih
Gartner Group
September 2002
MIME-based Secure Peer-to-Peer
Business Data Interchange over the Internet
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes how to exchange structured business data
securely using SMTP transport for Electronic Data Interchange, (EDI -
either the American Standards Committee X12 or UN/EDIFACT, Electronic
Data Interchange for Administration, Commerce and Transport), XML or
other data used for business to business data interchange. The data
is packaged using standard MIME content-types. Authentication and
privacy are obtained by using Cryptographic Message Syntax (S/MIME)
or OpenPGP security body parts. Authenticated acknowledgements make
use of multipart/signed replies to the original SMTP message.
Harding, et. al. Standards Track [Page 1]
RFC 3335 MIME-based Secure EDI September 2002
Table of Contents
1.0 Introduction .................................................3
2.0 Overview .....................................................4
2.1 Purpose of a Security Guideline for MIME EDI .................4
2.2 Definitions ..................................................4
2.2.1 Terms ........................................................4
2.2.2 The Secure Transmission Loop .................................5
2.2.3 Definition of Receipts .......................................5
2.3 Assumptions ..................................................6
2.3.1 EDI Process Assumptions ......................................6
2.3.2 Flexibility Assumptions ......................................7
3.0 Referenced RFCs and Their Contribution .......................8
3.1 RFC 821 SMTP [7] .............................................8
3.2 RFC 822 Text Message Format [3] ..............................8
3.3 RFC 1847 MIME Security Multiparts [6] ........................8
3.4 RFC 1892 Multipart/Report [9] ................................8
3.5 RFC 1767 EDI Content [2] .....................................9
3.6 RFC 2015, 3156, 2440 PGP/MIME [4] ............................9
3.7 RFC 2045, 2046, and 2049 MIME [1] ............................9
3.8 RFC 2298 Message Disposition Notification [5] ................9
3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 9
4.0 Structure of an EDI MIME Message - Applicability .............9
4.1 Introduction .................................................9
4.2 Structure of an EDI MIME Message - PGP/MIME .................10
4.2.1 No Encryption, No Signature .................................10
4.2.2 No Encryption, Signature ....................................10
4.2.3 Encryption, No Signature ....................................10
4.2.4 Encryption, Signature .......................................10
4.3 Structure of an EDI MIME Message - S/MIME ...................10
4.3.1 No encryption, No Signature..................................10
4.3.2 No encryption, Signature ....................................10
4.3.3 Encryption, No Signature ....................................11
4.3.4 Encryption, Signature .......................................11
5.0 Receipts ....................................................11
5.1 Introduction ................................................11
5.2 Requesting a Signed Receipt .................................13
5.2.1 Additional Signed Receipt Considerations ....................16
5.3 Message Disposition Notification Format .....................17
5.3.1 Message Disposition Notification Extensions .................18
5.3.2 Disposition Mode, Type, and Modifier Use ....................19
5.4 Message Disposition Notification Processing .................21
5.4.1 Large File Processing .......................................21
5.4.2 Example .....................................................22
6.0 Public Key Certificate Handling .............................24
6.1 Near Term Approach ..........................................24
6.2 Long Term Approach ..........................................24
7.0 Security Considerations .....................................25
Harding, et. al. Standards Track [Page 2]
RFC 3335 MIME-based Secure EDI September 2002
8.0 Acknowledgments .............................................26
9.0 References ..................................................26
Appendix IANA Registration Form ...................................28
Authors' Addresses ................................................28
Full Copyright Statement ..........................................29
1.0 Introduction
Previous work on Internet EDI focused on specifying MIME content
types for EDI data ([2] RFC 1767). This document 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 document
also recognizes contemporary RFCs and is attempting to "re-invent" as
little as possible. While this document focuses specifically on EDI
data, any other data type is also supported.
With an enhancement in the area of "receipts", as described below
(5.2), secure Internet MIME based EDI can be accomplished by using
and complying with the following RFCs:
-RFC 821 SMTP
-RFC 822 Text Message Formats
-RFC 1767 EDI Content Type
-RFC 1847 Security Multiparts for MIME
-RFC 1892 Multipart/Report
-RFC 2015, 3156, 2440 MIME/PGP
-RFC 2045 to 2049 MIME RFCs
-RFC 2298 Message Disposition Notification
-RFC 2630, 2633 S/MIME v3 Specification
Our intent here is to define clearly and precisely how these are used
together, and what is required by user agents to be compliant with
this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Harding, et. al. Standards Track [Page 3]
RFC 3335 MIME-based Secure EDI September 2002
2.0 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 document is also NOT limited to
strict EDI use, but applies to any electronic commerce application
where business data needs to be exchanged over the Internet in a
secure manner.
2.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 Internet messaging format used to
Notification convey a receipt. This term is used
interchangeably with receipt. A signed
MDN is a signed receipt.
Non-repudiation of NRR is a "legal event" that occurs when
Receipt (NRR) the 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.
Harding, et. al. Standards Track [Page 4]
RFC 3335 MIME-based Secure EDI September 2002
2.2.2 The secure transmission loop
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 environment.
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 signs and encrypts the data
using either PGP/MIME or S/MIME. In addition, the message will
request a signed receipt to be returned to the sender of the
message.
-The receiving organization decrypts the message and verifies the
signature, resulting in verified integrity of the data and
authenticity of the sender.
-The receiving organization then returns a signed receipt to the
sending organization in the form of a message disposition
notification message. This signed receipt will contain the hash
of the signature from the received message, indicating to the
sender that the received message was verified and/or decrypted
properly.
The above describes functionality which, if implemented, would
satisfy all security requirements. This specification, however,
leaves full flexibility for users to decide the degree to which they
want to deploy those security features with their 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 resulting in a receipt which is NOT signed. The second
term is used if the acknowledgment is for an interchange resulting in
a receipt which IS signed. The method used to request a receipt or a
signed receipt is defined in RFC 2298, "An Extensible Message Format
for Message Disposition Notifications".
The "rule" is:
- If a receipt is requested, explicitly specifying that the receipt
be signed, then the receipt MUST be returned with a signature.
Harding, et. al. Standards Track [Page 5]
RFC 3335 MIME-based Secure EDI September 2002
- If a receipt is requested, explicitly specifying that the receipt
be signed, but the recipient cannot support the requested
protocol format or requested MIC algorithms, 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, a receipt
may or may not be returned. This behavior is consistent with the
MDN RFC 2298.
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 signed receipt
coming back from recipient of the message. 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 services.
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 routing from
existing commercial EDI networks (called Value Added Networks or
VANs) to the Internet, work may need to be done in the future to
define ways to pull out some of the envelope information to make
them visible; however, this specification does not go into any
detail on this.
-X12.58 and UN/EDIFACT security considerations
The most common EDI standards bodies, ANSI X12 and EDIFACT, have
defined internal provisions for security. X12.58 is the security
mechanism for ANSI X12 and AUTACK provides security for EDIFACT.
This specification DOES NOT dictate use or non-use of these security
standards. They are both fully compatible, though possibly
redundant, with this specification.
Harding, et. al. Standards Track [Page 6]
RFC 3335 MIME-based Secure EDI September 2002
2.3.2 Flexibility Assumptions
-Encrypted or unencrypted data
This specification allows for EDI message exchange where the EDI
data can either be un-protected or protected by means of encryption.
-Signed or unsigned data
This specification allows for EDI message exchange with or without
digital signature of the original EDI transmission.
-Use of receipt or not
This specification allows for EDI message transmission with or
without a request for receipt notification. If a signed receipt
notification is requested however, a mic value is REQUIRED as part
of the returned receipt, unless an error condition occurs in which a
mic value cannot be returned. In error cases, an un-signed receipt
or MDN SHOULD be returned with the correct "disposition modifier"
error value.
-Formatting choices
This specification defines the 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 RFC
2015/3156/2440, as reflected in [4] "MIME Security with Pretty Good
Privacy" (PGP); OpenPGP Message Format, and RFC 2633/2630 [8]
"S/MIME Version 3 Message Specification; Cryptographic Message
Syntax". PGP/MIME or S/MIME as defined in this Applicability
statement.
-Hash function, message digest choices
When a signature is used, it is RECOMMENDED that the SHA1 hash
algorithm be used for all outgoing messages, and that both MD5 and
SHA1 be supported for incoming messages.
In summary, the following eight permutations are possible in any
given trading relationship:
(1) Sender sends unencrypted data, does NOT request a receipt.
Harding, et. al. Standards Track [Page 7]
RFC 3335 MIME-based Secure EDI September 2002
(2) Sender sends unencrypted data, requests a signed or unsigned
receipt. The receiver sends back the signed or unsigned
receipt.
(3) Sender sends encrypted data, does NOT request a receipt.
(4) Sender sends encrypted data, requests a signed or unsigned
receipt. The receiver sends back the signed or unsigned
receipt.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -