From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4823.txt | 2243 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2243 insertions(+) create mode 100644 doc/rfc/rfc4823.txt (limited to 'doc/rfc/rfc4823.txt') diff --git a/doc/rfc/rfc4823.txt b/doc/rfc/rfc4823.txt new file mode 100644 index 0000000..9b16ac4 --- /dev/null +++ b/doc/rfc/rfc4823.txt @@ -0,0 +1,2243 @@ + + + + + + +Network Working Group T. Harding +Request for Comments: 4823 R. Scott +Category: Informational Axway + April 2007 + + + FTP Transport for Secure Peer-to-Peer + Business Data Interchange over the Internet + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This Applicability Statement (AS) describes how to exchange + structured business data securely using the File Transfer Protocol + (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or + UN/EDIFACT), or other data used for business-to-business data + interchange for which MIME packaging can be accomplished using + standard MIME content types. Authentication and data confidentiality + are obtained by using Cryptographic Message Syntax (S/MIME) security + body parts. Authenticated acknowledgements employ multipart/signed + replies to the original message. + + + + + + + + + + + + + + + + + + + + + +Harding & Scott Informational [Page 1] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Overview ........................................................4 + 2.1. Overall Operations .........................................4 + 2.2. Purpose of a Security Guideline for MIME EDI ...............5 + 2.3. Definitions ................................................5 + 2.3.1. Terms ...............................................5 + 2.3.2. The Secure Transmission Loop ........................6 + 2.3.3. Definition of Receipts ..............................7 + 2.4. Operational Assumptions and Options ........................8 + 2.4.1. EDI/EC Process Assumptions ..........................8 + 2.4.2. Process Options .....................................8 + 2.4.2.1. Security Options ...........................8 + 2.4.2.2. Compression Options .......................10 + 3. Referenced RFCs and Their Contribution .........................10 + 3.1. RFC 959: File Transfer Protocol [3] .......................10 + 3.2. RFC 2228: FTP Security Extensions [4] .....................10 + 3.3. RFC 1847: MIME Security Multiparts [7] ....................10 + 3.4. RFC 3462: Multipart/Report [12] ...........................11 + 3.5. RFC 1767: EDI Content [2] .................................11 + 3.6. RFCs 2045, 2046, and 2049: MIME [1] .......................11 + 3.7. RFC 3798: Message Disposition Notification [6] ............11 + 3.8. RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1 + Message Specification [10] ................................11 + 3.9. RFC 3850: S/MIME Version 3.1 Certificate Handling [11] ....11 + 3.10. RFC 3274: Compressed Data Content Type for + Cryptographic Message Syntax (CMS) [17] ..................11 + 3.11. RFC 3023: XML Media Types [16] ...........................12 + 4. Structure of an AS3 Message ....................................12 + 4.1. Introduction ..............................................12 + 4.2. Structure of an Internet EDI MIME Message .................12 + 5. AS3-Specific Headers ...........................................13 + 5.1. AS3-From and AS3-To Headers ...............................13 + 5.2. AS3-Version Header ........................................14 + 6. FTP Considerations .............................................15 + 6.1. FTP Security Requirements .................................15 + 6.2. Large File Transfers ......................................15 + 6.3. MIME Considerations for FTP ...............................15 + 6.3.1. Required/Optional Headers ..........................15 + 6.3.2. Content-Transfer-Encoding ..........................16 + 6.3.3. Epilogue Must Be Empty .............................16 + 6.3.4. Message-Id and Original-Message-Id .................16 + 7. Structure and Processing of an MDN Message .....................17 + 7.1. Introduction ..............................................17 + 7.2. Message Disposition Notifications (MDN) ...................19 + 7.3. Requesting a Signed Receipt ...............................19 + 7.3.1. Signed Receipt Considerations ......................22 + + + +Harding & Scott Informational [Page 2] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + 7.4. MDN Format and Value ......................................23 + 7.4.1. AS3-MDN General Formats ............................23 + 7.4.2. AS3-MDN Construction ...............................24 + 7.4.3. AS3-MDN Fields .....................................25 + 7.4.4. Additional AS3-MDN Programming Notes ...............26 + 7.5. Disposition Mode, Type, and Modifier ......................29 + 7.5.1. Disposition Mode Overview ..........................29 + 7.5.2. Successful Processing Status Indication ............29 + 7.5.3. Unsuccessful Processed Content .....................29 + 7.5.4. Unsuccessful Non-Content Processing ................30 + 7.5.5. Processing Warnings ................................31 + 8. Public Key Certificate Handling ................................32 + 9. Security Considerations ........................................33 + 10. References ....................................................34 + 10.1. Normative References .....................................34 + 10.2. Informative References ...................................36 + Appendix A. Message Examples ......................................37 + A.1. Signed Message Requesting a Signed Receipt ................37 + A.2. MDN for Message A.1 Above .................................37 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Harding & Scott Informational [Page 3] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +1. Introduction + + Previous work on Internet EDI focused on specifying MIME content + types for EDI data [2] and extending this work to support secure + EC/EDI transport over SMTP [5]. This document expands on RFC 1767 to + specify a comprehensive set of data security features, specifically, + data privacy, data integrity, authenticity, non-repudiation of + origin, and non-repudiation of receipt over FTP. This document also + recognizes contemporary RFCs and is attempting to "re-invent" as + little as possible. While this document focuses on EDI data, any + other data type describable in a MIME format is also supported. + + Internet MIME-based EDI can be accomplished by using and complying + with the following documents: + + - RFC 959: File Transfer Protocol + - RFC 2228: FTP Security Extensions + - RFC 1767: EDI Content Type + - RFC 3023: XML Media Types + - RFC 1847: Security Multiparts for MIME + - RFC 3462: Multipart/Report + - RFCs 2045 to 2049: MIME + - RFC 3798: Message Disposition Notification + - RFCs 3850, 3851, and 3852: S/MIME v3.1 Specifications + - RFC 3274: Compressed Data Content for Cryptographic Message + Syntax + - RFC 4217: Securing FTP with TLS + - "Compressed Data for EDIINT" by T. Harding + + 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 [19]. + +2. Overview + +2.1. Overall Operations + + An FTP upload operation is used to send appropriately packaged EDI, + XML, or other business data. The receiving application will poll the + FTP server for inbound messages, unpackage and handle the message + data, and generate a reply for the originator that contains a message + disposition acknowledgement within a multipart/report that is signed + or unsigned. This request/reply transactional interchange provides + secure, reliable, and authenticated transport for EDI or other + + + +Harding & Scott Informational [Page 4] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + business data using FTP. The security protocols and structures used + also support auditable records of these transmissions. + +2.2. Purpose of a Security Guideline for MIME EDI + + The purpose of these specifications is to ensure interoperability + between B2B Electronic Commerce 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.3. Definitions + +2.3.1. Terms + + AS3 Applicability Statement 3. This is the third + applicability statement produced by the IETF + EDIINT working group. + + EDI Electronic Data Interchange + + EC Business-to-Business Electronic Commerce + + B2B Business to Business + + Receipt The functional message that is sent from a + receiver to a sender to acknowledge receipt of + an EDI/EC interchange. + + Signed Receipt A receipt containing a digital signature. + + Message Disposition The Internet messaging format used to convey a + Notification (MDN) receipt. This term is used interchangeably with + receipt. An MDN is a receipt. + + 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. + + S/MIME A format and protocol for adding Cryptographic + signature and/or encryption services to Internet + MIME messages. + + + + + + +Harding & Scott Informational [Page 5] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + NOTE: While the S/MIME specification describes + more than one format for a signed message, + all signed messages or receipts used with + AS3 MUST utilize the multipart/signed + format. + + SHA-1 A secure, one-way hash algorithm used in + conjunction with digital signature. SHA-1 is + the recommend algorithm for AS3. + + MD5 A secure, one-way hash algorithm used in + conjunction with digital signature. This + algorithm is acceptable but not recommended due + to its short key length and known weaknesses. + + MIC The message integrity check (MIC) is a + representation of the message digest, which + results from the application of the selected + hash algorithm to the content to be signed. Of + particular interest is the digital signature, + which includes an encrypted copy of the digest. + Additionally, an MDN containing a Received- + content-MIC header will also contain (as that + header's value) a base-64-encoded representation + of the digest. + + User Agent (UA) The application that handles and processes the + AS3 request. + + STL Secure Transmission Loop, described in the next + section. + +2.3.2. The Secure Transmission Loop + + This document's focus is on the formats and protocols for exchanging + EDI/EC content to which security services have been applied using the + File Transmission Protocol (FTP) as the transport. + + The "Secure Transmission Loop" (STL) comprises the following two + steps: + + a) The originator sends a signed and encrypted document with a + request for a signed receipt. + + b) The recipient decrypts the document, verifies the signature, and + returns a signed receipt to the sender. + + + + + +Harding & Scott Informational [Page 6] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + In other words, the following events occur during the execution of + the STL: + + - The organization sending EDI/EC data signs and encrypts the data + using 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, as + requested to the sending organization in the form of a message + disposition notification. 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 that, if implemented, will satisfy + all security requirements and provide non-repudiation of receipt for + the exchange. While trading partners will usually want to utilize + the STL, this specification does not require it. + +2.3.3. Definition of Receipts + + The term used for both the functional activity and the message for + acknowledging delivery of an EDI/EC interchange is "receipt" or + "signed receipt". The term receipt is used if the acknowledgment is + for an interchange resulting in a receipt that is NOT signed. The + term signed receipt is used if the acknowledgment is for an + interchange resulting in a receipt that IS signed. A term often used + in combination with receipts is non-repudiation of receipt. NRR + refers to a legal event that occurs only when the original sender of + an interchange has verified the signed receipt coming back from the + recipient of the message. Note that NRR is not possible without + signatures. + + For additional information on formatting and processing receipts in + AS3, refer to Section 7. + + + + + + + + + + + + +Harding & Scott Informational [Page 7] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +2.4. Operational Assumptions and Options + +2.4.1. EDI/EC Process Assumptions + + - Encrypted object is an EDI/EC Interchange. + + This specification assumes that a typical EDI/EC interchange is the + lowest level object that will be subject to the application of + security services. + + Specifically, for EDI ANSI X12, the entire document (including the + ISA and IEA segments) is the atom to which security is applied. + For EDIFACT, the corresponding definition includes the segments + UNA/UNB and UNZ. In other words, EDI/EC 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 extract some elements of the envelope to make them + visible; however, that is beyond the scope of this specification. + + - 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. + +2.4.2. Process Options + +2.4.2.1. Security Options + + - Encrypted or un-encrypted data + + This specification allows for EDI/EC message exchange where the + EDI/EC data can be either un-protected or protected by means of + encryption. + + + + + + + +Harding & Scott Informational [Page 8] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + - Signed or unsigned data + + This specification allows for EDI/EC message exchange with or + without digital signature of the original EDI transmission. + + - Use of receipt or not + + This specification allows for EDI/EC 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 that + results in the inability to compute a valid digest. (Such a case + would result, for instance, if an encrypted message could not be + decrypted.) Under such circumstances, an unsigned receipt (MDN) + SHOULD be returned with the correct "disposition modifier" error + value. + + - Security formatting + + This specification relies on the guidelines set forth in RFCs 3852 + [9] and 3851 [10]. The first of these RFCs describes the + Cryptographic Message Syntax (CMS), and the second contains the + S/MIME Version 3.1 Message Specification describing a MIME + container for CMS objects. Whenever the term S/MIME is used in + this document, it refers to Version 3.1 as described therein. + + - Hash function, message digest choices + + When a signature is used, it is RECOMMENDED that the SHA-1 hash + algorithm be used for all outgoing messages; however, both MD5 and + SHA-1 MUST be supported for incoming messages. + + - Permutation summary + + In summary, the following twelve security permutations are possible + in any given trading relationship: + + 1. Sender sends un-encrypted data, does NOT request a receipt. + + 2. Sender sends un-encrypted data, requests an unsigned receipt. + The receiver sends back the unsigned receipt. + + 3. Sender sends un-encrypted data, requests a signed receipt. The + receiver sends back the signed receipt. + + 4. Sender sends encrypted data, does NOT request a receipt. + + + + + +Harding & Scott Informational [Page 9] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + 5. Sender sends encrypted data, requests an unsigned receipt. The + receiver sends back the unsigned receipt. + + 6. Sender sends encrypted data, requests a signed receipt. The + receiver sends back the signed receipt. + + 7. Sender sends signed data, does NOT request a receipt. + + 8. Sender sends signed data, requests an unsigned receipt. + Receiver sends back the unsigned receipt. + + 9. Sender sends signed data, requests a signed receipt. Receiver + sends back the signed receipt. + + 10. Sender sends encrypted and signed data, does NOT request a + receipt. + + 11. Sender sends encrypted and signed data, requests an unsigned + receipt. Receiver sends back the unsigned receipt. + + 12. Sender sends encrypted and signed data, requests a signed + receipt. Receiver sends back the signed receipt. This case + represents the Secure Transmission Loop described above. + +2.4.2.2. Compression Options + + The AS3 specification supports compression of transmitted data + directly through the application of RFC 3274. Implementation details + may be found in that RFC and in Harding's document, "Compressed Data + for EDIINT". + +3. Referenced RFCs and Their Contribution + +3.1. RFC 959: File Transfer Protocol [3] + + RFC 959 specifies how data is transferred using the File Transfer + Protocol (FTP) + +3.2. RFC 2228: FTP Security Extensions [4] + + This RFC describes a framework for providing security services to + FTP. + +3.3. RFC 1847: MIME Security Multiparts [7] + + This document defines security multiparts for MIME: + multipart/encrypted and multipart/signed. + + + + +Harding & Scott Informational [Page 10] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +3.4. RFC 3462: Multipart/Report [12] + + RFC 3462 defines the use of the multipart/report content type, upon + which RFC 3798 builds to define the Message Disposition Notification. + +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. RFCs 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 definitions of + "content type", "sub-type", and "multipart", as well as encoding + guidelines, which establish 7-bit US-ASCII as the canonical character + set to be used in Internet messaging. + +3.7. RFC 3798: Message Disposition Notification [6] + + This Internet RFC defines how a Message Disposition Notification + (MDN)is requested, as well as the format and syntax of the MDN. The + MDN is the vehicle used by this specification to provide both signed + and unsigned receipts. + +3.8. RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1 Message + Specification [10] + + This specification describes how MIME shall carry Cryptographic + Message Syntax (CMS) Objects. + +3.9. RFC 3850: S/MIME Version 3.1 Certificate Handling [11] + + RFC 3850 describes certificate handling in the context of CMS and + S/MIME. + +3.10. RFC 3274: Compressed Data Content Type for Cryptographic Message + Syntax (CMS) [17] + + This specification provides a mechanism to wrap compressed data + within a CMS object. + + + + + + + + + +Harding & Scott Informational [Page 11] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +3.11. RFC 3023: XML Media Types [16] + + This RFC defines the use of content type "application" for XML. Note + that while conforming implementations SHOULD support the expanded + syntax that RFC 3023 introduces for the "+xml" suffix, no support for + external parsed entity types is anticipated (as it adds significant + complexity to signature processing). + +4. Structure of an AS3 Message + +4.1. Introduction + + The basic structure of AS3 messages comprises MIME encapsulated data + with both customary MIME headers and a few additional AS3-specific + outer headers. The structures below are described hierarchically in + terms of which RFCs have been applied to form the specific structure. + The reader is referred directly to the referenced RFCs for + implementation details. + + Any additional restrictions imposed by this AS are specifically + discussed in the sections that follow. + +4.2. Structure of an Internet EDI MIME Message + + No encryption, no signature + + -RFC822/2045 + -RFC1767/RFC2376 (application/EDIxxxx or /xml) + + No encryption, signature + + -RFC822/2045 + -RFC1847 (multipart/signed) + -RFC1767/RFC2376 (application/EDIxxxx or /xml) + -RFC3851 (application/pkcs7-signature) + + Encryption, no signature + + -RFC822/2045 + -RFC3851 (application/pkcs7-mime) + -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) + + + + + + + + + + +Harding & Scott Informational [Page 12] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + Encryption, signature + + -RFC822/2045 + -RFC3851 (application/pkcs7-mime) + -RFC1847 (multipart/signed)(encrypted) + -RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted) + -RFC3851 (application/pkcs7-signature)(encrypted) + + MDN, no signature + + -RFC822/2045 + -RFC3798 (message/disposition-notification) + + MDN, signature + + -RFC822/2045 + -RFC1847 (multipart/signed) + -RFC3798 (message/disposition-notification) + -RFC3851 (application/pkcs7-signature) + + While all MIME content types SHOULD be supported, + the following MIME content types MUST be supported: + + Content-Type: multipart/signed + Content-Type: multipart/report + Content-type: message/disposition-notification + Content-Type: application/PKCS7-signature + Content-Type: application/PKCS7-mime + Content-Type: application/EDI-X12 + Content-Type: application/EDIFACT + Content-Type: application/edi-consent + Content-Type: application/XML + +5. AS3-Specific Headers + +5.1. AS3-From and AS3-To Headers + + The AS3-From and AS3-To headers have been provided to assist the + sender and the recipient of an EC document to identify each other: + + AS3-From: < AS3-name > + AS3-To: < AS3-name > + + These headers contain textual values, described by the ABNF [22] + below, identifying the sender/receiver of a data exchange. A value + may be company specific (e.g., a Data Universal Numbering System + (DUNS) number), or it may be simply some string mutually acceptable + to both trading partners used to identify each to the other. + + + +Harding & Scott Informational [Page 13] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + AS3-text = "!" / ; printable ASCII characters + %d35-91 / ; except double-quote (%d34) + %d93-126 ; or backslash (%d92) + + AS3-qtext = AS3-text / SP ; allow space only in quoted text + + AS3-quoted-pair = "\" DQUOTE / ; \" or + "\" "\" ; \\ + + AS3-quoted-name = DQUOTE 1*128( AS3-qtext / + AS3-quoted-pair) DQUOTE + + AS3-atomic-name = 1*128AS3-text + + AS3-name = AS3-atomic-name / AS3-quoted-name + + Note: SP and DQUOTE are defined in [ABNF]RFC 4234. + + The AS3-From header value and the AS3-To header value MUST each be an + AS3-name comprising 1 to 128 printable ASCII characters. The header + MUST NOT be folded, and the value for each of these headers is case- + sensitive. + + The AS3-quoted-name SHOULD be used only if the AS3-name does not + conform to AS3-atomic-name. + + The AS3-To and AS3-From header fields MUST be present in all AS3 + messages and AS3 MDNs. + + Implementations that map entities such as EDI identifiers/qualifiers + to AS3 identifiers may choose to constrain the set of AS3-To/AS3-From + text values to a subset of the full set defined above, but they may + not extend that set. + + If the AS3-From or the AS3-To or the association of the two header + values is determined to be invalid or unknown to the receiving + system, the receiving system MAY respond with an unsigned MDN + containing an explanation of the error if the sending system + requested an MDN, but it is not required to return an MDN under those + circumstances. + +5.2. AS3-Version Header + + The AS3-Version header is a header that is required only if the value + of the header is not "1.0". Its purpose is to allow systems to + determine which version of this specification (should the + specification evolve over time) the sender of a document has used to + + + + +Harding & Scott Informational [Page 14] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + package the document. A user agent MUST NOT reject a message if the + version header is missing. + + AS3-Version: 1*DIGIT . 1*DIGIT + + A version header value of "1.1" indicates an implementation can + support EDIINT data compression [20]. A user agent MUST NOT send + compressed messages to trading partners who do not use a version + header of "1.1" or greater. + +6. FTP Considerations + +6.1. FTP Security Requirements + + FTP has long been viewed as an insecure protocol primarily because of + its use of cleartext authentication [3]. This is addressed by RFC + 2228 [4], and the use of one of the security mechanisms described + therein is strongly encouraged. Specifically, conforming + implementations of AS3 SHALL employ FTP client/servers that support + the AUTH command described within [4]. While any authentication + mechanism based upon [4] MAY be utilized, AUTH TLS (as described in + [18]) MUST be supported. (Note that [18] relies on TLS Version 1.0 + [13], not Version 1.1 [23].) + +6.2. Large File Transfers + + Large files are handled correctly by the TCP layer. However, the + mechanism for compressing data, referenced in Section 2.4.2.2, + efficiently reduces transmission requirements for many data types + (including both XML and traditional EDI data). Additionally, some + FTP implementations support compression as well. + +6.3. MIME Considerations for FTP + +6.3.1. Required/Optional Headers + + An AS3 message MUST contain the following outer headers: + + AS3-To + AS3-From + Date + Message-ID + Content-Type + + + + + + + + +Harding & Scott Informational [Page 15] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + An AS3 message OPTIONALLY MAY contain the following outer headers: + + Subject + AS3-Version (assumed to be 1.0 if not present) + Content-Length + + An AS3 message requesting a receipt MUST contain a Disposition- + Notification-To header and MAY contain a Disposition-Notification- + Options header (if the receipt is to be signed). + + Additional headers MAY be present but are ignored. + +6.3.2. Content-Transfer-Encoding + + FTP defines several data structures and character encodings via the + STRU[cture] and TYPE commands. AS3 requires the file-structure + (default) and the image type. The Content-Transfer-Encoding header + SHOULD NOT be used; if the header is present, it SHOULD have a value + of binary or 8-bit. The absence of this header or the use of + alternate values such as "base64" or "quoted-printable" MUST NOT + result in transaction failure. Content transfer encoding of MIME + parts within the AS3 message are similarly constrained. + +6.3.3. Epilogue Must Be Empty + + A MIME message containing an epilogue [1] SHALL NOT be used. + +6.3.4. Message-Id and Original-Message-Id + + Message-Id and Original-Message-Id are formatted as defined in + Section 3.6.4 of RFC 2822 [15]: "<" id-left "@" id-right ">". + Message-Id length is a maximum of 998 characters. Message-Id SHOULD + be globally unique; id-right should be something unique to the + sending host environment (e.g., a host name). When sending a + message, always include the angle brackets. Angle brackets are not + part of the Message-Id value. + + NOTE: When creating the Original-Message-Id header in an MDN, always + use the exact syntax contained in the original message: do not + strip or add "angle brackets". + + + + + + + + + + + +Harding & Scott Informational [Page 16] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +7. Structure and Processing of an MDN Message + +7.1. Introduction + + In order to support non-repudiation of receipt, a signed receipt, + based on digitally signing a message disposition notification, is to + be implemented by a receiving trading partner's UA. The message + disposition notification specified by RFC 3798 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. + + 3) 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. + + 4) 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 EC + Interchange. + + 2) If the sent message was signed, then the receiving trading partner + has authenticated the sender of the EC Interchange. + + 3) If the sent message was signed, then the receiving trading partner + has verified the integrity of the sent EC Interchange. + + Regardless of whether the EDI/EC Interchange was sent in S/MIME + format or not, the receiving trading partner's UA MUST provide the + following basic processing: + + 1) If the sent EDI/EC Interchange is encrypted, then the encrypted + symmetric key, and initialization vector (if applicable) is + decrypted using the receiver's private key. + + + + + +Harding & Scott Informational [Page 17] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + 2) The decrypted symmetric encryption key is then used to decrypt the + EDI/EC 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 are 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. + + 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/pkcs7-signature". + + 8) The signature information is formatted according to S/MIME + specifications. The EC Interchange and the RFC 1767 MIME EDI + content header can actually be part of a multipart MIME content + type. When the EDI Interchange is part of a multipart MIME + content type, the MIC MUST be calculated across the entire + multipart 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 was sent, and then + was delivered and acknowledged by the receiving trading partner. + + + + +Harding & Scott Informational [Page 18] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + 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 EC 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. + +7.2. Message Disposition Notifications (MDN) + + The AS3-MDNs are returned on a separate FTP TCP/IP connection and are + a response to an AS3 message. + + The following diagram illustrates the delivery of an AS3-MDN + delivery: + + AS3-MDN + [S] ----( connect )----> [R] [FTP Server] + [S] ----( send )-------> [R] [AS3-Message] + [S] ----( disconnect )-> [R] [FTP Server] + + [S] <---( connect )----- [R] [FTP Server] + [S] <---( send )-------- [R] [AS3-MDN]] + [S] <---( disconnect )-- [R] [FTP Server] + + Note: Refer to Section 7.4.4 for additional + programming notes. + +7.3. Requesting a Signed Receipt + + Message Disposition Notifications are requested as per RFC 3798. A + request that the receiving user agent issue a message disposition + notification is made by placing the following header into the message + to be sent: + + MDN-request-header = "Disposition-notification-to" ":" ftpurl + + This syntax is a residual of the use of MDN's in an SMTP transfer. + Since this specification is adjusting the functionality from SMTP to + + + +Harding & Scott Informational [Page 19] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + FTP and retaining as much as possible from the [5] functionality, the + ftpurl must be present. + + The ftpurl field is specified as an RFC 1738 ; + signed-receipt-micalg=optional, , ,...; + + The currently supported value for is "pkcs7- + signature" for the S/MIME detached signature format. + + The currently supported values for MIC algorithm values are: + + Algorithm Value + Used + -------- ------- + MD5 md5 + SHA-1 sha1 + + Receiving agents SHOULD be able to recover gracefully from a + parameter value that they do not recognize. + + 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 + and calculating the micalg in the Received-content-MIC header. + + The list of MIC algorithms should be honored by the recipient from + left to right. Both the "signed-receipt-protocol" and the + "signed-receipt-micalg" option parameters are REQUIRED when + requesting a signed receipt. + + 2) The "importance" attribute of "Optional" is defined in RFC 3798, + Section 2.2, and has the following meaning: + + Parameters with an importance of "Optional" permit a UA that does + not understand the particular options parameter to still generate + an MDN in response to a request for an MDN. A UA that does not + + + +Harding & Scott Informational [Page 21] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + understand the "signed-receipt-protocol" parameter, or the + "signed-receipt-micalg" parameter, will obviously not return a + signed receipt. + + The importance of "Optional" is used for the signed receipt + parameters because it is RECOMMENDED that an MDN be returned to + the requesting trading partner even if the recipient could not + sign it. + + The returned MDN will contain information on the disposition of + the message as well as on why the MDN could not be signed. See + the Disposition field in Section 7.5 for more information. + + Within an EDI trading relationship, if a signed receipt is expected + and is not returned, then the validity of the transaction must be + determined by the trading partners. Typically, if a signed receipt + is required by the trading relationship and is not received, the + transaction will likely not be considered valid. + +7.3.1. Signed Receipt Considerations + + The method used to request a receipt or a signed receipt is defined + in RFC 3798, "An Extensible Message Format for Message Disposition + Notifications". + + The "rules" for processing a receipt-request follow: + + 1) When a receipt is requested, explicitly specifying that the + receipt be signed, then the receipt MUST be returned with a + signature unless conditions (2) or (3) below are applicable. + + 2) When a receipt is requested, explicitly specifying that the + receipt be signed, but the recipient cannot support either the + requested protocol format, or requested MIC algorithms, then + either a signed or unsigned receipt SHOULD be returned. + + 3) When a receipt is requested, explicitly specifying that the + receipt be signed, but the recipient is unable to compute the + digest (e.g., message was encrypted, and recipient unable to + decrypt), then the recipient SHOULD NOT return "Received-content- + MIC" in the MDN to the requestor. If the MDN sets the disposition + (e.g., "processed/error: decryption-failed") appropriately, then + the "Received-content-MIC" may be returned, but the value must be + discarded. + + + + + + + +Harding & Scott Informational [Page 22] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + 4) When a signature is not explicitly requested, or if the signed + receipt request parameter is not recognized by the UA, then no + receipt, an unsigned receipt, or a signed receipt MAY be returned + by the recipient. + + 5) If a message is received without a request for a receipt, then a + receipt (signed or unsigned) MAY be returned. + + The "Received-content-MIC" MUST be calculated as follows: + + - For any signed messages, the MIC to be returned is calculated on + the RFC 1767 MIME header and content. Canonicalization as + specified in RFC 1848 MUST be performed before the MIC is + calculated, since the sender requesting the signed receipt was + also REQUIRED to canonicalize. + + - For encrypted, unsigned messages, the MIC to be returned is + calculated on the decrypted RFC 1767 MIME header and content. + The content after decryption MUST be canonicalized before the + MIC is calculated. + + - For unsigned, un-encrypted messages, the MIC MUST be calculated + over the message contents prior to Content-Transfer-Encoding and + without the MIME or any other RFC 822 [14] headers, since these + are sometimes altered or reordered by message transfer agents + (MTAs). + +7.4. MDN Format and Value + + This section defines the format of the AS3 Message Disposition + Notification (AS3-MDN). + +7.4.1. AS3-MDN General Formats + + The AS3-MDN follows the MDN specification [6] except where noted in + this section. The modified entity definitions in this document use + the vertical-bar character, '|', to denote a logical "OR" + construction. Refer to RFC 2045 for the format of MIME-message- + headers. + + The format of the AS3-MDN is + + MDN, no signature + + -RFC822/2045 + -RFC3798 (message/disposition-notification) + + + + + +Harding & Scott Informational [Page 23] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + MDN, signature + + -RFC822/2045 + -RFC1847 (multipart/signed) + -RFC3798 (message/disposition-notification) + -RFC3851 (application/pkcs7-signature) + +7.4.2. AS3-MDN Construction + + The AS3-MDN-body is formatted as a MIME multipart/report with a + report-type of "disposition-notification". + + When unsigned, the transfer-layer ("outermost") entity-headers of the + AS3-MDN contain the Content-Type header that specifies a content type + of "multipart/report", parameters indicating the report-type, and the + value of the outermost multipart boundary. + + When the AS3-MDN is signed, the transfer-layer ("outermost") entity- + headers of the AS3-MDN contain a Content-Type header that specifies a + content type of "multipart/signed", parameters indicating the + algorithm used to compute the message digest, the signature + formatting protocol (e.g., pkcs7-signature), and the value of the + outermost multipart boundary. The first part of the MIME + multipart/signed message is an imbedded MIME multipart/report of type + "disposition-notification". The second part of the multipart/signed + message contains a MIME application/pkcs7-signature message. + + The first part of the MIME multipart/report is a "human-readable" + portion that contains a general description of the message + disposition. The second part of the MIME multipart/report is a + "machine-readable" portion that is defined as + + AS3-disposition-notification-content = + [ reporting-ua-field CRLF ] + [ mdn-gateway-field CRLF ] + [ original-recipient-field CRLF ] + final-recipient-field CRLF + [ original-message-id-field CRLF ] + AS3-disposition-field CRLF + *( failure-field CRLF ) + *( error-field CRLF ) + *( warning-field CRLF ) + *( extension-field CRLF ) + [ AS3-received-content-MIC-field CRLF ] + + It is noted that several of the optional fields defined by RFC 3798 + and shown above are not relevant to a point-to-point transport such + as FTP and would not normally appear in an AS3 MDN. + + + +Harding & Scott Informational [Page 24] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +7.4.3. AS3-MDN Fields + + The rules for constructing the AS3-disposition-notification-content + are identical to the rules for constructing the disposition- + notification-content as defined in Section 7 of RFC 3798 [6] except + that the RFC 3798 disposition-field has been replaced with the AS3- + disposition-field and that the AS3-received-content-MIC field has + been added. The differences between the RFC 3798 disposition-field + and the AS3-disposition-field are described below. Where there are + differences between this document and RFC 3798, those entity names + have been changed by prepending "AS3-". Entities below that do not + differ from RFC 3798 are not necessarily further defined in this + document. + + Refer to RFC 3798 [6] and RFC 4234 [22] for entities that are not + further defined in this document. + + AS3-disposition-field = "Disposition:" disposition-mode ";" + AS3-disposition-type [ "/" AS3-disposition-modifier] + + disposition-mode = action-mode "/" sending-mode + + action-mode = "manual-action" / "automatic-action" + + sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" + + AS3-disposition-type = "processed" / "failed" + + AS3-disposition-modifier = ( "error" / "warning" ) / + AS3-disposition-modifier-extension + + AS3-disposition-modifier-extension = + "error: authentication-failed" / + "error: decompression-failed" / + "error: decryption-failed" / + "error: insufficient-message-security" / + "error: integrity-check-failed" / + "error: unexpected-processing-error" / + "warning: " AS3-MDN-warning-description / + "failure: " AS3-MDN-failure-description + + AS3-MDN-warning-description = *( TEXT ) + + AS3-MDN-failure-description = *( TEXT ) + + AS3-received-content-MIC-field = + "Received-content-MIC:" encoded-message-digest + "," digest-alg-id CRLF + + + +Harding & Scott Informational [Page 25] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + encoded-message-digest = + 1*( ALPHA / DIGIT / "/" / "+" ) *3"=" + ;( i.e. base64( message-digest ) ) + + digest-alg-id = "sha1" / "md5" + + The "Received-content-MIC" extension field is set after the integrity + of the received message is verified. The MIC is the base64-encoded + message-digest computed over the received message with a hash + function. This field is required for signed receipts but optional + for unsigned receipts. For details defining the specific content + over which the message-digest is to be computed, see Section 7.3.1 of + this document. + + The algorithm used to calculate the message digest MUST be the same + as the "micalg" value used by the sender in the multipart/signed + message. When no signature is received, the message-digest MUST be + calculated using the algorithm specified by the "micalg" value in the + Disposition-Notification-Options header. When no signature is + received and no micalg parameter is provided, then the SHA-1 + algorithm MUST be used to calculate the digest. This field is set + only when the contents of the message are processed successfully. + This field is used in conjunction with the recipient's signature on + the MDN in order for the sender to verify non-repudiation of receipt. + + AS3-MDN field names (e.g., "Disposition:", "Final-Recipient:") are + case-insensitive (cf. RFC 3798, Section 3.1.1). + + AS3-MDN action-modes, sending-modes, AS3-disposition-types, and AS3- + disposition-modifier values that are defined above, and user-supplied + *( TEXT ) values are also case-insensitive. AS3 implementations MUST + NOT make assumptions regarding the values supplied for AS3-MDN- + warning-description or AS3-MDN-failure-description or for the values + of any (optional) error, warning, or failure fields. + +7.4.4. Additional AS3-MDN Programming Notes + + 1. Unlike SMTP, for FTP transactions, Original-Recipient and Final + Recipient SHOULD NOT be different. The value in Original- + Message-ID MUST match the original Message-ID header value. + + 2. Refer to RFC 3462 and RFC 3798 for the formatting of the + Content-Type entity-headers for the MDN. + + 3. Use an action-mode of "automatic-action" when the disposition + described by the disposition type was a result of an automatic + action, rather than an explicit instruction by the user for this + message. + + + +Harding & Scott Informational [Page 26] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + 4. Use an action-mode of "manual-action" when the disposition + described by the disposition type was a result of an explicit + instruction by the user rather than some sort of automatically + performed action. + + 5. Use a sending-mode of "MDN-sent-automatically" when the MDN is + sent because the UA had previously been configured to do so. + + 6. Use a sending-mode of "MDN-sent-manually" when the user + explicitly gave permission for this particular MDN to be sent. + + 7. The sending-mode "MDN-sent-manually" is ONLY meaningful with + "manual-action", not with "automatic-action". + + 8. The "failed" disposition type MAY NOT be used for the situation + in which there is some problem in processing the message other + than interpreting the request for an MDN. The "processed" or + other disposition type with appropriate disposition modifiers is + to be used in such situations. + + 9. An AS3 implementation MUST present to its trading partners an + FTP-compliant server interface where inbound documents and MDNs + are received. + + 10. An AS3 implementation MUST be able to retrieve inbound messages + from its currently configured FTP server interface. + + Note: Programming Notes 9 and 10 do not imply any specific method for + supplying the FTP server interface. But, they do allow for + several different types of implementations. Some vendors may + choose to imbed an FTP-compliant server interface within their + product, and others may choose to utilize off-the-shelf FTP + servers to supply the required FTP server interface. Some may + choose to utilize hosting services provided by their trading + partner or by a third-party hosting service. Whichever method + is utilized, an AS3 implementation MUST support rules 9 and 10. + + 11. AS3 implementations MAY imbed an FTP server interface within + their product. + + 12. AS3 implementations MUST be configurable to allow the use of an + external FTP hosting service. + + Note: An external FTP hosting service may be hosted by a third-party + or possibly hosted by your trading partner. + + + + + + +Harding & Scott Informational [Page 27] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + 13. An AS3 implementation MUST be able to send business documents and + MDNs to a trading partner's currently configured FTP server + interface. + + 14. An AS3 implementation may imbed FTP client code into their + product or use a third-party FTP client. + + 15. Example Configurations + + 1. Peer to Peer + Trading Partner A (TPA) is using a local FTP server, and + Trading Partner B (TPB) is using an imbedded FTP server. + + [A Client] ----( connect )----> [B Server] + [A Client] ----( send )-------> [B Server] [AS3-Message] + [A Client] ----( disconnect )-> [B Server] + + [A Server] <---( connect )----- [B Client] + [A Server] <---( send )-------- [B Client] [AS3-MDN]] + [A Server] <---( disconnect )-- [B Server] + [A Client] <---( GET )--------- [A Server] + + 2. Third-Party Hosting + Both parties are using the same third-party-hosted FTP server. + + [A Client] ----( connect )----> [Hosted Server] + [A Client] ----( send )-------> [Hosted Server] [AS3-Message] + [A Client] ----( disconnect )-> [Hosted Server] + [Hosted Server]( GET )--------> [B Client] + + [Hosted Server] <---( connect )----- [B Client] + [Hosted Server] <---( send )-------- [B Client] [AS3-MDN]] + [Hosted Server] <---( disconnect )-- [B Client] + [A Client] <---( GET )--------- [Hosted Server] + + 3. Trading Partner Hosting + TPA is using the imbedded FTP server hosted by TPB. + + [A Client] ----( connect )----> [B Server] + [A Client] ----( send )-------> [B Server] [AS3-Message] + [A Client] ----( disconnect )-> [B Server] + + [B Server] <---( connect )----- [B Client] + [B Server] <---( send )-------- [B Client] [AS3-MDN]] + [B Server] <---( disconnect )-- [B Client] + [A Client] <---( GET )--------- [B Server] + + + + + +Harding & Scott Informational [Page 28] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +7.5. Disposition Mode, Type, and Modifier + +7.5.1. Disposition Mode Overview + + This section will provide a brief overview of how processed, error, + failure, or warning notifications are used. + +7.5.2. Successful Processing Status Indication + + When a receipt or signed receipt is requested, and the received + message contents are successfully processed by the receiving EDI UA, + a receipt or MDN SHOULD be returned with the "disposition-type" set + to "processed". When the MDN is sent automatically by the EDI UA, + and there is no explicit way for a user to control the sending of the + MDN, then the first part of the "disposition-mode" should be set to + "automatic-action". + + When the MDN is being sent under user-configurable control, then the + first part of the "disposition-mode" should be set to "manual- + action". Since a request for a signed receipt should always be + honored, the user MUST not be allowed to configure the UA not to send + a signed receipt when the sender requests one. + + The second part of the "disposition-mode" is set to "MDN-sent- + manually" if the user gave explicit permission for the MDN to be + sent. Again, the user MUST not be allowed to explicitly refuse to + send a signed receipt when the sender requests one. The second part + of the "disposition-mode" is set to "MDN-sent-automatically" whenever + the EDI UA sends the MDN automatically, regardless of whether the + sending was under a user's, an administrator's, or software control. + + Since EDI content is generally handled automatically by the EDI UA, a + request for a receipt or signed receipt will generally return the + following in the "disposition-field": + + Disposition: automatic-action/MDN-sent-automatically; processed + + Note this specification does not restrict the use of the + "disposition-mode" to just automatic actions. Manual actions are + valid as long as it is kept in mind that a request for a signed + receipt MUST be honored. + +7.5.3. Unsuccessful Processed Content + + The request for a signed receipt requires the use of two + "disposition-notification-options", which specify the protocol format + of the returned signed receipt, and the MIC algorithm used to + calculate the MIC over the message contents. The "disposition-field" + + + +Harding & Scott Informational [Page 29] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + values that should be used in the case where the message content is + being rejected or ignored should be specified in the MDN + "disposition-field" as below. (An example of this case is when the + EDI UA determines that a signed receipt cannot be returned because it + does not support the requested protocol format, so the EDI UA chooses + not to process the message contents itself.) + + Disposition: "disposition-mode"; failed/Failure: unsupported Format + + The "failed" AS3-disposition-type should be used when a failure + occurs that prevents the proper generation of an MDN. + + For example, this disposition-type would apply if the sender of the + message requested the application of an unsupported message- + integrity-check (MIC) algorithm. + + The "failure:" AS3-disposition-modifier-extension should be used with + an implementation-defined description of the failure. + + Further information about the failure may be contained in a failure- + field. The syntax of the "failed" "disposition-type" is general, + allowing the sending of any textual information along with the + "failed" "disposition-type". Implementations WILL support any + printable textual characters after the Failure disposition-type. + + For use in Internet EDI, the following "failed" values are pre- + defined and MUST be supported: + + "Failure: unsupported format" + "Failure: unsupported MIC-algorithms" + +7.5.4. Unsuccessful Non-Content Processing + + When errors occur in processing the received message, other than + content, the "disposition-field" should be set to the "processed" + "disposition-type" value and the "error" "disposition-modifier" + value. + + The "error" AS3-disposition-modifier with the "processed" + disposition-type should be used to indicate that an error of some + sort occurred that prevented successful processing of the message. + + Further information may be contained in an error-field. + + An "error:" AS3-disposition-modifier-extension should be used to + combine the indication of an error with a pre-defined description of + a specific, well-known error. Further information about the error + may be contained in an error-field. + + + +Harding & Scott Informational [Page 30] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + For use in Internet EDI, the following "error" "disposition-modifier" + values are defined: + + "Error: decryption-failed" + The receiver could not decrypt the message contents. + + "Error: authentication-failed" + The receiver could not authenticate the sender. + + "Error: integrity-check-failed" + The receiver could not verify content integrity. + + "Error: insufficient-message-security" + The security level of the message did not match the agreed level + between TPs. + + "Error: decompression-failed" + The receiver could not decompress the message contents. + + "Error: unexpected-processing-error" + A catch-all for any additional processing errors. + + An example of how the "disposition-field" would look when processing + errors, other than content, are detected is as follows: + + EXAMPLE + Disposition: "disposition-mode"; + processed/Error: decryption-failed + +7.5.5. Processing Warnings + + Situations arise in EDI where even if a trading partner cannot be + authenticated correctly, the trading partners still agree to continue + processing the EDI transactions. Transaction reconciliation is done + between the trading partners at a later time. In the content + processing warning situations described above, the "disposition- + field" SHOULD be set to the "processed" "disposition-type" value, and + the "warning" "disposition-modifier" value. + + The "warning" AS3-disposition-modifier should be used with the + "processed" disposition-type to indicate that the message was + successfully processed but that an exceptional condition occurred. + + Further information may be contained in a warning-field. + + + + + + + +Harding & Scott Informational [Page 31] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + A "warning:" AS3-disposition-modifier-extension should be used to + combine the indication of a warning with an implementation-defined + description of the warning. Further information about the warning + may be contained in a warning-field. + + For use in Internet EDI, the following "warning" "disposition- + modifier" values are defined: + + "Warning: authentication-failed, processing continued" + + An example of how the "disposition-field" would look when processing + warnings, other than content, are detected is as follows: + + EXAMPLE + Disposition: "disposition-mode"; processed/Warning: + authentication-failed, processing continued + +8. Public Key Certificate Handling + + 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 FTP + URL/URI. The procedures for establishing a trading partnership and + configuring the secure EDI messaging system might vary among trading + partners and software packages. + + X.509 certificates are REQUIRED. It is RECOMMENDED that trading + partners self-certify each other if an agreed-upon certification + authority is not used. This applicability statement does NOT require + the use of a certification authority. + + The use of a certification authority is therefore OPTIONAL. + Certificates may be self-signed. It is 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.1 Message Specification. + + The message formats and S/MIME conformance requirements for + certificate exchange are specified in this document. 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 & Scott Informational [Page 32] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +9. Security Considerations + + This entire document is concerned with secure transport of business- + to-business data, and it considers both privacy and authentication + issues. + + Extracted from S/MIME Version 2 Message Specification [21]: + + 40-bit encryption is considered weak by most cryptographers. + Using weak cryptography in S/MIME offers little actual security + over sending plaintext. However, other features of S/MIME, such + as the specification of tripleDES 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 3.1 Certificate Handling [11]: + + 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 Internet mail addresses in a certificate matches the sender + of a message, if the certificate contains at least one mail + address + - no certificate chain leads to a trusted CA + - no ability to check the Certificate Revocation List (CRL) for a + certificate + - an invalid CRL was received + - the CRL being checked is expired + - the certificate is expired + - the certificate has been revoked + + + + + + + +Harding & Scott Informational [Page 33] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + 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. + + The following certificate types MUST be supported. + With URL + Without URL + Self Certified + Certification Authority Certified + + The complete certification chain MUST be included in all + certificates. All certificate verifications MUST "chain to root". + Additionally, the certificate hash should match the hash recomputed + by the receiver. + +10. References + +10.1. Normative References + + [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, November + 1996. + + Freed, N. and N. Borenstein, "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] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, + RFC 959, October 1985. + + [4] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, + October 1997. + + [5] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure + Peer-to-Peer Business Data Interchange over the Internet", RFC + 3335, September 2002. + + [6] Hansen, T. and G. Vaudreuil, "Message Disposition + Notification", RFC 3798, May 2004. + + + + +Harding & Scott Informational [Page 34] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + [7] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security + Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", + RFC 1847, October 1995. + + [8] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April + 2001. + + [9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, + July 2004. + + [10] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions + (S/MIME) Version 3.1 Message Specification", RFC 3851, July + 2004. + + [11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions + (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July + 2004. + + [12] Vaudreuil, G., "The Multipart/Report Content Type for the + Reporting of Mail System Administrative Messages", RFC 3462, + January 2003. + + [13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [14] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT + MESSAGES", STD 11, RFC 822, August 1982. + + [15] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + [16] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", + RFC 3023, January 2001. + + [17] Gutmann, P., "Compressed Data Content Type for Cryptographic + Message Syntax (CMS)", RFC 3274, June 2002. + + [18] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October + 2005. + + [19] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + +Harding & Scott Informational [Page 35] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +10.2. Informative References + + [20] Harding, T., "Compressed Data for EDIINT", Work in Progress, + January 2007. + + [21] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. + Repka, "S/MIME Version 2 Message Specification", RFC 2311, + March 1998. + + [22] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [23] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.1", RFC 4346, April 2006. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Harding & Scott Informational [Page 36] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +Appendix A. Message Examples + + NOTE: All examples are provided as an illustration only, and are not + considered part of the protocol specification. If an example + conflicts with the protocol definitions specified above or with + that of a referenced RFC, the example is wrong. + +A.1. Signed Message Requesting a Signed Receipt + + Date: Wed, 31 Jul 2002 13:34:50 GMT + AS3-Version: 1.0 + AS3-From: cyclone + AS3-To: "trading partner" + Message-Id: <200207310834482A70BF63@host.com> + Disposition-Notification-To: ftp://host:port/mdnbox + Disposition-Notification-Options: signed-receipt- + protocol=optional,pkcs7-signature; + signed-receipt-micalg=optional,sha1 + Content-Type: multipart/signed; boundary="as3BouNdary1as3"; + protocol="application/pkcs7-signature"; micalg=sha1 + Content-Length: 3075 + + --as3BouNdary1as3 + Content-Type: application/edi-x12 + Content-Disposition: Attachment; filename=rfc1767.dat + + [ISA ...EDI transaction data...IEA...] + + --as3BouNdary1as3 + Content-Type: application/pkcs7-signature + + [omitted binary pkcs7 signature data] + --as3BouNdary1as3-- + +A.2. MDN for Message A.1 Above + + Date: Wed, 31 Jul 2002 13:34:50 GMT + AS3-From: "trading partner" + AS3-To: cyclone + AS3-Version: 1.0 + Message-ID: <709700825.1028122454671.JavaMail@ediXchange> + Content-Type: multipart/signed; micalg=sha1; + protocol="application/pkcs7-signature"; + boundary="----=_Part_57_648441049.1028122454671" + Content-Length: 1024 + + ------=_Part_57_648441049.1028122454671 + + + + +Harding & Scott Informational [Page 37] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + & Content-Type: multipart/report; + & Report-Type=disposition-notification; + & boundary="----=_Part_56_1672293592.1028122454656" + & + &------=_Part_56_1672293592.1028122454656 + &Content-Type: text/plain + &Content-Transfer-Encoding: 7bit + & + &MDN for - + & Message ID: <200207310834482A70BF63@host.com> + & From: cyclone + & To: "trading partner" + & Received on: 2002-07-31 at 09:34:14 (EDT) + & Status: processed + & Comment: This is not a guarantee that the message has been + & completely processed or understood by the receiving translator + & + &------=_Part_56_1672293592.1028122454656 + & Content-Type: message/disposition-notification + & Content-Transfer-Encoding: 7bit + & + & Reporting-UA: AS3 Server + & Original-Recipient: rfc822; "trading partner" + & Final-Recipient: rfc822; "trading partner" + & Original-Message-ID: <200207310834482A70BF63@host.com> + & Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1 + & Disposition: automatic-action/MDN-sent-automatically; processed + & + &------=_Part_56_1672293592.1028122454656-- + + ------=_Part_57_648441049.1028122454671 + Content-Type: application/pkcs7-signature; name=smime.p7s + Content-Transfer-Encoding: base64 + Content-Disposition: attachment; filename=smime.p7s + + MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ + cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA + ------=_Part_57_648441049.1028122454671-- + + Notes: + + 1. The lines proceeded with "&" are what the signature is + calculated over. + + 2. For details on how to prepare the multipart/signed with + protocol="application/pkcs7-signature", see RFC 3851 [10], + "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version + 3.1 Message Specification". + + + +Harding & Scott Informational [Page 38] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + + 3. 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. + + 4. As specified by RFC 3462 [12], 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. However, it is RECOMMENDED that this body part be + omitted or left blank. + +Authors' Addresses + + Terry Harding + Axway + 8388 E. Hartford Drive, Suite 100 + Scottsdale, AZ 85255 USA + + EMail: tharding@us.axway.com + + + Richard Scott + Axway + 8388 E. Hartford Drive, Suite 100 + Scottsdale, AZ 85255 USA + + EMail: rscott@us.axway.com + + + + + + + + + + + + + + + + + + + + + + + +Harding & Scott Informational [Page 39] + +RFC 4823 AS3 Data Interchange for EDIINT April 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Harding & Scott Informational [Page 40] + -- cgit v1.2.3