summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4130.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4130.txt')
-rw-r--r--doc/rfc/rfc4130.txt2635
1 files changed, 2635 insertions, 0 deletions
diff --git a/doc/rfc/rfc4130.txt b/doc/rfc/rfc4130.txt
new file mode 100644
index 0000000..c00428d
--- /dev/null
+++ b/doc/rfc/rfc4130.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group D. Moberg
+Request for Comments: 4130 Cyclone Commerce
+Category: Standards Track R. Drummond
+ Drummond Group Inc.
+ July 2005
+
+
+ MIME-Based Secure Peer-to-Peer
+ Business Data Interchange Using HTTP,
+ Applicability Statement 2 (AS2)
+
+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 (2005).
+
+Abstract
+
+ This document provides an applicability statement (RFC 2026, Section
+ 3.2) that describes how to exchange structured business data securely
+ using the HTTP transfer protocol, instead of SMTP; the applicability
+ statement for SMTP is found in RFC 3335. Structured business data
+ may be XML; Electronic Data Interchange (EDI) in either the American
+ National Standards Committee (ANSI) X12 format or the UN Electronic
+ Data Interchange for Administration, Commerce, and Transport
+ (UN/EDIFACT) format; or other structured data formats. The data is
+ packaged using standard MIME structures. Authentication and data
+ confidentiality are obtained by using Cryptographic Message Syntax
+ with S/MIME security body parts. Authenticated acknowledgements make
+ use of multipart/signed Message Disposition Notification (MDN)
+ responses to the original HTTP message. This applicability statement
+ is informally referred to as "AS2" because it is the second
+ applicability statement, produced after "AS1", RFC 3335.
+
+
+
+
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 1]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Applicable RFCs ............................................3
+ 1.2. Terms ......................................................3
+ 2. Overview ........................................................5
+ 2.1. Overall Operation ..........................................5
+ 2.2. Purpose of a Security Guideline for MIME EDI ...............5
+ 2.3. Definitions ................................................5
+ 2.4. Assumptions ................................................7
+ 3. Referenced RFCs and Their Contributions .........................9
+ 3.1. RFC 2616 HTTP v1.1 [3] .....................................9
+ 3.2. RFC 1847 MIME Security Multiparts [6] ......................9
+ 3.3. RFC 3462 Multipart/Report [8] .............................10
+ 3.4. RFC 1767 EDI Content [2] ..................................10
+ 3.5. RFC 2045, 2046, and 2049 MIME [1] .........................10
+ 3.6. RFC 3798 Message Disposition Notification [5] .............10
+ 3.7. RFC 3851 and 3852 S/MIME Version 3.1 Message
+ Specifications and Cryptographic Message Syntax (CMS) [7]..10
+ 3.8. RFC 3023 XML Media Types [10] .............................10
+ 4. Structure of an AS2 Message ....................................10
+ 4.1. Introduction ..............................................10
+ 4.2. Structure of an Internet EDI MIME Message .................11
+ 5. HTTP Considerations ............................................12
+ 5.1. Sending EDI in HTTP POST Requests .........................12
+ 5.2. Unused MIME Headers and Operations ........................12
+ 5.3. Modification of MIME or Other Headers or Parameters Used ..13
+ 5.4. HTTP Response Status Codes ................................14
+ 5.5. HTTP Error Recovery .......................................14
+ 6. Additional AS2-Specific HTTP Headers ...........................14
+ 6.1. AS2 Version Header ........................................15
+ 6.2. AS2 System Identifiers ....................................15
+ 7. Structure and Processing of an MDN Message .....................17
+ 7.1. Introduction ..............................................17
+ 7.2. Synchronous and Asynchronous MDNs .........................19
+ 7.3. Requesting a Signed Receipt ...............................21
+ 7.4. MDN Format and Values .....................................25
+ 7.5. Disposition Mode, Type, and Modifier ......................30
+ 7.6. Receipt Reply Considerations in an HTTP POST ..............35
+ 8. Public Key Certificate Handling ................................35
+ 9. Security Considerations ........................................36
+ 9.1. NRR Cautions ..............................................37
+ 9.2. HTTPS Remark ..............................................38
+ 9.3. Replay Remark .............................................39
+ 10. IANA Considerations ...........................................39
+ 10.1. Registration ............................................39
+ 11. Acknowledgements ..............................................40
+ 12. References ....................................................40
+
+
+
+Moberg & Drummond Standards Track [Page 2]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ 12.1. Normative References ....................................40
+ 12.2. Informative References ..................................41
+ Appendix A: Message Examples ......................................42
+
+1. Introduction
+
+1.1. Applicable RFCs
+
+ 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 [4]. This document expands on RFC 1767 to
+ specify a comprehensive set of data security features, specifically
+ data confidentiality, data integrity/authenticity, non-repudiation of
+ origin, and non-repudiation of receipt over HTTP. This document also
+ recognizes contemporary RFCs and is attempting to "re-invent" as
+ little as possible. Although this document focuses on EDI data, any
+ other data types describable in a MIME format are also supported.
+
+ Internet MIME-based EDI can be accomplished by using and complying
+ with the following RFCs:
+
+ o RFC 2616 Hyper Text Transfer Protocol
+ o RFC 1767 EDI Content Type
+ o RFC 3023 XML Media Types
+ o RFC 1847 Security Multiparts for MIME
+ o RFC 3462 Multipart/Report
+ o RFC 2045 to 2049 MIME RFCs
+ o RFC 3798 Message Disposition Notification
+ o RFC 3851, 3852 S/MIME v3.1 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 [13].
+
+1.2. Terms
+
+ AS2: Applicability Statement 2 (this document); see RFC 2026
+ [11], Section 3.2
+
+ EDI: Electronic Data Interchange
+
+ EC: Business-to-Business Electronic Commerce
+
+ B2B: Business to Business
+
+
+
+Moberg & Drummond Standards Track [Page 3]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Receipt: The functional message that is sent from a receiver to a
+ sender to acknowledge receipt of an EDI/EC interchange.
+ This message may be either synchronous or asynchronous in
+ nature.
+
+ Signed Receipt: A receipt with a digital signature.
+
+ Synchronous Receipt: A receipt returned to the sender during the same
+ HTTP session as the sender's original message.
+
+ Asynchronous Receipt: A receipt returned to the sender on a different
+ communication session than the sender's original message
+ session.
+
+ Message Disposition Notification (MDN): The Internet messaging format
+ used to convey a receipt. This term is used interchangeably
+ with receipt. A MDN is a receipt.
+
+ Non-repudiation of receipt (NRR): A "legal event" that occurs when
+ the original sender of an signed EDI/EC interchange has
+ verified the signed receipt coming back from the receiver.
+ The receipt contains data identifying the original message
+ for which it is a receipt, including the message-ID and a
+ cryptographic hash (MIC). The original sender must retain
+ suitable records providing evidence concerning the message
+ content, its message-ID, and its hash value. The original
+ sender verifies that the retained hash value is the same as
+ the digest of the original message, as reported in the
+ signed receipt. NRR is not considered a technical message,
+ but instead is thought of as an outcome of possessing
+ relevant evidence.
+
+ S/MIME: A format and protocol for adding cryptographic signature
+ and/or encryption services to Internet MIME messages.
+
+ Cryptographic Message Syntax (CMS): An encapsulation syntax used to
+ digitally sign, digest, authenticate, or encrypt arbitrary
+ messages.
+
+ SHA-1: A secure, one-way hash algorithm used in conjunction with
+ digital signature. This is the recommended algorithm for
+ AS2.
+
+ MD5: A secure, one-way hash algorithm used in conjunction with
+ digital signature. This algorithm is allowed in AS2.
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 4]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ MIC: The message integrity check (MIC), also called the message
+ digest, is the digest output of the hash algorithm used by
+ the digital signature. The digital signature is computed
+ over the MIC.
+
+ User Agent (UA): The application that handles and processes the AS2
+ request.
+
+2. Overview
+
+2.1. Overall Operation
+
+ A HTTP POST operation [3] is used to send appropriately packaged EDI,
+ XML, or other business data. The Request-URI ([3], Section 9.5)
+ identifies a process for unpacking and handling the message data and
+ for generating a reply for the client that contains a message
+ disposition acknowledgement (MDN), either signed or unsigned. The
+ MDN is either returned in the HTTP response message body or by a new
+ HTTP POST operation to a URL for the original sender.
+
+ This request/reply transactional interchange can provide secure,
+ reliable, and authenticated transport for EDI or other business data
+ using HTTP as a transfer protocol.
+
+ The security protocols and structures used also support auditable
+ records of these document data transmissions, acknowledgements, and
+ authentication.
+
+2.2. Purpose of a Security Guideline for MIME EDI
+
+ The purpose of these specifications is to ensure interoperability
+ between B2B EC user agents, invoking some or all of the commonly
+ expected security features. This document is also NOT limited to
+ strict EDI use; it applies to any electronic commerce application for
+ which business data needs to be exchanged over the Internet in a
+ secure manner.
+
+2.3. Definitions
+
+2.3.1. The Secure Transmission Loop
+
+ This document's focus is on the formats and protocols for exchanging
+ EDI/EC content securely in the Internet's HTTP environment.
+
+ In the "secure transmission loop" for EDI/EC, one organization sends
+ a signed and encrypted EDI/EC interchange to another organization and
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 5]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ requests a signed receipt, and later the receiving organization sends
+ this signed receipt back to the sending organization. In other
+ words, the following transpires:
+
+ o The organization sending EDI/EC data signs and encrypts the
+ data using S/MIME. In addition, the message will request that
+ a signed receipt be returned to the sender. To support NRR,
+ the original sender retains records of the message, message-ID,
+ and digest (MIC) value.
+
+ o The receiving organization decrypts the message and verifies
+ the signature, resulting in verified integrity of the data and
+ authenticity of the sender.
+
+ o The receiving organization then returns a signed receipt using
+ the HTTP reply body or a separate HTTP POST operation to the
+ sending organization in the form of a signed message
+ disposition notification. This signed receipt will contain the
+ hash of the received message, allowing the original sender to
+ have evidence that the received message was authenticated
+ and/or decrypted properly by the receiver.
+
+ The above describes functionality that, if implemented, will satisfy
+ all security requirements and implement non-repudiation of receipt
+ for the exchange. 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.3.2. 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 first term is used if the acknowledgment is
+ for an interchange resulting in a receipt that is NOT signed. The
+ second term is used if the acknowledgement is for an interchange
+ resulting in a receipt that IS signed.
+
+ The term non-repudiation of receipt (NRR) is often used in
+ combination with receipts. NRR refers to a legal event that occurs
+ only when the original sender of an interchange has verified the
+ signed receipt coming back from recipient of the message, and has
+ verified that the returned MIC value inside the MDN matches the
+ previously recorded value for the original message.
+
+ NRR is best established when both the original message and the
+ receipt make use of digital signatures. See the Security
+ Considerations section for some cautions regarding NRR.
+
+
+
+
+Moberg & Drummond Standards Track [Page 6]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ For information on how to format and process receipts in AS2, refer
+ to Section 7.
+
+2.4. Assumptions
+
+2.4.1. EDI/EC Process Assumptions
+
+ o 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 security services.
+
+ Specifically, in EDI ANSI X12, this means that anything between and
+ including, segments ISA and IEA is secured. In EDIFACT, this means
+ that anything between, and including, segments UNA/UNB and UNZ is
+ secured. In other words, the EDI/EC interchanges including envelope
+ segments remain intact and unreadable during fully secured transport.
+
+ o 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, it would be
+ useful to make some envelope information visible. This
+ specification, however, provides no support for this optimization.
+
+ o 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. Flexibility Assumptions
+
+ o Encrypted or Unencrypted Data
+
+ This specification allows for EDI/EC message exchange in which the
+ EDI/EC data can be either unprotected or protected by means of
+ encryption.
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 7]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ o Signed or Unsigned Data
+
+ This specification allows for EDI/EC message exchange with or without
+ digital signature of the original EDI transmission.
+
+ o Optional Use of Receipt
+
+ This specification allows for EDI/EC message transmission with or
+ without a request for receipt notification. A signed receipt
+ notification is requested; however, a MIC value is REQUIRED as part
+ of the returned receipt, except when a severe error condition
+ prevents computation of the digest value. In the exceptional case, a
+ signed receipt should be returned with an error message that
+ effectively explains why the MIC is absent.
+
+ o Use of Synchronous or Asynchronous Receipts
+
+ In addition to a receipt request, this specification allows the
+ specification of the type of receipt that should be returned. It
+ supports synchronous or asynchronous receipts in the MDN format
+ specified in Section 7 of this document.
+
+ o Security Formatting
+
+ This specification relies on the guidelines set forth in RFC
+ 3851/3852 [7] "S/MIME Version 3.1 Message Specification;
+ Cryptographic Message Syntax".
+
+ o 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, and that both MD5 and
+ SHA-1 be supported for incoming messages.
+
+ o Permutation Summary
+
+ In summary, the following twelve security permutations are possible
+ in any given trading relationship:
+
+ 1. Sender sends un-encrypted data and does NOT request a receipt.
+
+ 2. Sender sends un-encrypted data and requests an unsigned receipt.
+ Receiver sends back the unsigned receipt.
+
+ 3. Sender sends un-encrypted data and requests a signed receipt.
+ Receiver sends back the signed receipt.
+
+ 4. Sender sends encrypted data and does NOT request a receipt.
+
+
+
+Moberg & Drummond Standards Track [Page 8]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ 5. Sender sends encrypted data and requests an unsigned receipt.
+ Receiver sends back the unsigned receipt.
+
+ 6. Sender sends encrypted data and requests a signed receipt.
+ Receiver sends back the signed receipt.
+
+ 7. Sender sends signed data and does NOT request a signed or
+ unsigned receipt.
+
+ 8. Sender sends signed data and requests an unsigned receipt.
+ Receiver sends back the unsigned receipt.
+
+ 9. Sender sends signed data and requests a signed receipt.
+ Receiver sends back the signed receipt.
+
+ 10. Sender sends encrypted and signed data and does NOT request a
+ signed or unsigned receipt.
+
+ 11. Sender sends encrypted and signed data and requests an unsigned
+ receipt. Receiver sends back the unsigned receipt.
+
+ 12. Sender sends encrypted and signed data and requests a signed
+ receipt. Receiver sends back the signed receipt.
+
+ Users can choose any of the twelve possibilities, but only the last
+ example (12), when a signed receipt is requested, offers the whole
+ suite of security features described in Section 2.3.1, "The Secure
+ Transmission Loop".
+
+ Additionally, the receipts discussed above may be either synchronous
+ or asynchronous depending on the type requested. The use of either
+ the synchronous or asynchronous receipts does not change the nature
+ of the secure transmission loop in support of NRR.
+
+3. Referenced RFCs and Their Contributions
+
+3.1. RFC 2616 HTTP v1.1 [3]
+
+ This document specifies how data is transferred using HTTP.
+
+3.2. RFC 1847 MIME Security Multiparts [6]
+
+ This document defines security multipart for MIME:
+ multipart/encrypted and multipart/signed.
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 9]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+3.3. RFC 3462 Multipart/Report [8]
+
+ This RFC defines the use of the multipart/report content type,
+ something that the MDN RFC 3798 builds upon.
+
+3.4. 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.5. RFC 2045, 2046, and 2049 MIME [1]
+
+ These are the basic MIME standards, upon which all MIME related RFCs
+ build, including this one. Key contributions include 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.6. RFC 3798 Message Disposition Notification [5]
+
+ This Internet RFC defines how an MDN is requested, and the format and
+ syntax of the MDN. The MDN is the basis upon which receipts and
+ signed receipts are defined in this specification.
+
+3.7. RFC 3851 and 3852 S/MIME Version 3.1 Message Specifications and
+ Cryptographic Message Syntax (CMS) [7]
+
+ This specification describes how S/MIME will carry CMS Objects.
+
+3.8. RFC 3023 XML Media Types [10]
+
+ This RFC defines the use of content type "application" for XML
+ (application/xml).
+
+4. Structure of an AS2 Message
+
+4.1. Introduction
+
+ The basic structure of an AS2 message consists of MIME format inside
+ an HTTP message with a few additional specific AS2 headers. The
+ structures below are described hierarchically in terms of which RFCs
+ are applied to form the specific structure. For details of how to
+ code in compliance with all RFCs involved, turn directly to the RFCs
+ referenced. Any difference between AS2 implantations and RFCs are
+ mentioned specifically in the sections below.
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 10]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+4.2. Structure of an Internet EDI MIME Message
+
+ No encryption, no signature
+ -RFC2616/2045
+ -RFC1767/RFC3023 (application/EDIxxxx or /xml)
+
+ No encryption, signature
+ -RFC2616/2045
+ -RFC1847 (multipart/signed)
+ -RFC1767/RFC3023 (application/EDIxxxx or /xml)
+ -RFC3851 (application/pkcs7-signature)
+
+ Encryption, no signature
+ -RFC2616/2045
+ -RFC3851 (application/pkcs7-mime)
+ -RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted)
+
+ Encryption, signature
+ -RFC2616/2045
+ -RFC3851 (application/pkcs7-mime)
+ -RFC1847 (multipart/signed)(encrypted)
+ -RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted)
+ -RFC3851 (application/pkcs7-signature)(encrypted)
+
+ MDN over HTTP, no signature
+ -RFC2616/2045
+ -RFC3798 (message/disposition-notification)
+
+ MDN over HTTP, signature
+ -RFC2616/2045
+ -RFC1847 (multipart/signed)
+ -RFC3798 (message/disposition-notification)
+ -RFC3851 (application/pkcs7-signature)
+
+ MDN over SMTP, no signature
+ MDN over SMTP, signature
+ Refer to the EDI over SMTP standard [4].
+
+ Although 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
+
+
+
+
+Moberg & Drummond Standards Track [Page 11]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Content-Type: application/EDIFACT
+ Content-Type: application/edi-consent
+ Content-Type: application/XML
+
+5. HTTP Considerations
+
+5.1. Sending EDI in HTTP POST Requests
+
+ The request line will have the form: "POST Request-URI HTTP/1.1",
+ with spaces and followed by a CRLF. The Request URI is typically
+ exchanged out of band, as part of setting up a bilateral trading
+ partner agreement. Applications SHOULD be prepared to deal with an
+ initial reply containing a status indicating a need for
+ authentication of the usual types used for authorizing access to the
+ Request-URI ([3], Section 10.4.2 and elsewhere).
+
+ The request line is followed by entity headers specifying content
+ length ([3], Section 14.14) and content type ([3], Section 14.18).
+ The Host request header ([3], Sections 9 and 14.23) is also included.
+
+ When using Transport Layer Security [15] or SSLv3, the request-URI
+ SHOULD indicate the appropriate scheme value, HTTPS. Usually only a
+ multipart/signed message body would be sent using TLS, as encrypted
+ message bodies would be redundant. However, encrypted message bodies
+ are not prohibited.
+
+ The receiving AS2 system MAY disconnect from the sending AS2 system
+ before completing the reception of the entire entity if it determines
+ that the entity being sent is too large to process.
+
+ For HTTP version 1.1, TCP persistent connections are the default,
+ ([3] Sections 8.1.2, 8.2, and 19.7.1). A number of other differences
+ exist because HTTP does not conform to MIME [1] as used in SMTP
+ transport. Relevant differences are summarized below.
+
+5.2. Unused MIME Headers and Operations
+
+5.2.1. Content-Transfer-Encoding Not Used in HTTP Transport
+
+ HTTP can handle binary data and so there is no need to use the
+ content transfer encodings of MIME [1]. This difference is discussed
+ in [3], Section 19.4.5. However, a content transfer encoding value
+ of binary or 8-bit is permissible but not required. The absence of
+ this header MUST NOT result in transaction failure. Content transfer
+ encoding of MIME bodyparts within the AS2 message body is also
+ allowed.
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 12]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+5.2.2. Message Bodies
+
+ In [3], Section 3.7.2, it is explicitly noted that multiparts MUST
+ have null epilogues.
+
+ In [4], Section 5.4.1, options for large file processing are
+ discussed for SMTP transport. For HTTP, large files SHOULD be
+ handled correctly by the TCP layer. However, in [3], Sections 3.5
+ and 3.6 discuss some options for compressing or chunking entities to
+ be transferred. In [3], Section 8.1.2.2 discusses a pipelining
+ option that is useful for segmenting large amounts of data.
+
+5.3. Modification of MIME or Other Headers or Parameters Used
+
+5.3.1. Content-Length
+
+ The use of the content-length header MUST follow the guidelines of
+ [3], specifically Sections 4.4 and 14.13.
+
+5.3.2. Final Recipient and Original Recipient
+
+ The final and original recipient values SHOULD be the same value.
+ These values MUST NOT be aliases or mailing lists.
+
+5.3.3. Message-Id and Original-Message-Id
+
+ Message-Id and Original-Message-Id is formatted as defined in RFC
+ 2822 [9]:
+
+ "<" id-left "@" id-right ">" (RFC 2822, 3.6.4)
+
+ Message-Id length is a maximum of 998 characters. For maximum
+ backward compatibility, Message-Id length SHOULD be 255 characters or
+ less. Message-Id SHOULD be globally unique, and 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. For maximum backward
+ compatibility, when receiving a message, do not check for angle
+ brackets. When creating the Original-Message-Id header in an MDN,
+ always use the exact syntax as received on the original message;
+ don't strip or add angle brackets.
+
+
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 13]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+5.3.4. Host Header
+
+ The host request header field MUST be included in the POST request
+ made when sending business data. This field is intended to allow one
+ server IP address to service multiple hostnames, and potentially to
+ conserve IP addresses. See [3], Sections 14.23 and 19.5.1.
+
+5.4. HTTP Response Status Codes
+
+ The status codes return status concerning HTTP operations. For
+ example, the status code 401, together with the WWW-Authenticate
+ header, is used to challenge the client to repeat the request with an
+ Authorization header. Other explicit status codes are documented in
+ [3], Section 6.1.1 and throughout Section 10.
+
+ For errors in the request-URI, 400 ("Bad Request"), 404 ("Not
+ Found"), and similar codes are appropriate status codes. These codes
+ and their semantics are specified by [3]. A careful examination of
+ these codes and their semantics should be made before implementing
+ any retry functionality. Retries SHOULD NOT be made if the error is
+ not transient or if retries are explicitly discouraged.
+
+5.5. HTTP Error Recovery
+
+ If the HTTP client fails to read the HTTP server response data, the
+ POST operation with identical content, including same Message-ID,
+ SHOULD be repeated, if the condition is transient.
+
+ The Message-ID on a POST operation can be reused if and only if all
+ of the content (including the original Date) is identical.
+
+ Details of the retry process (including time intervals to pause,
+ number of retries to attempt, and timeouts for retrying) are
+ implementation dependent. These settings are selected as part of the
+ trading partner agreement.
+
+ Servers SHOULD be prepared to receive a POST with a repeated
+ Message-ID. The MIME reply body previously sent SHOULD be resent,
+ including the MDN and other MIME parts.
+
+6. Additional AS2-Specific HTTP Headers
+
+ The following headers are to be included in all AS2 messages and all
+ AS2 MDNs, except for asynchronous MDNs that are sent using SMTP and
+ that follow the AS1 semantics[4].
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 14]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+6.1. AS2 Version Header
+
+ To promote backward compatibility, AS2 includes a version header:
+
+ AS2-Version: 1.0 - Used in all implementations of this
+ specification. 1.x will be interpreted as 1.0 by
+ all implementations with the "AS2 Version: 1.0"
+ header. That is, only the most significant digit
+ is used as the version identifier for those not
+ implementing additional non-AS2-specified
+ functionality. "AS2-Version: 1.0 through 1.9" MAY
+ be used. All implementations MUST interpret "1.0
+ through 1.9" as implementing this specification.
+ However, an implementation MAY extend this
+ specification with additional functionality by
+ specifying versions 1.1 through 1.9. If this
+ mechanism is used, the additional functionality
+ MUST be completely transparent to implementations
+ with the "AS2-Version: 1.0" designation.
+
+ AS2-Version: 1.1 - Designates those implementations that support
+ compression as defined by RFC 3274.
+
+ Receiving systems MUST NOT fail due to the absence of the AS2-Version
+ header. Its absence would indicate that the message is from an
+ implementation based on a previous version of this specification.
+
+6.2. AS2 System Identifiers
+
+ To aid the receiving system in identifying the sending system,
+ AS2-From and AS2-To headers are used.
+
+ AS2-From: < AS2-name >
+ AS2-To: < AS2-name >
+
+ These AS2 headers contain textual values, as described below,
+ identifying the sender/receiver of a data exchange. Their values may
+ be company specific, such as Data Universal Numbering System (DUNS)
+ numbers, or they may be simply identification strings agreed upon
+ between the trading partners.
+
+
+
+
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 15]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ AS2-text = "!" / ; printable ASCII characters
+ %d35-91 / ; except double-quote (%d34)
+ %d93-126 ; or backslash (%d92)
+
+ AS2-qtext = AS2-text / SP ; allow space only in quoted text
+
+ AS2-quoted-pair = "\" DQUOTE / ; \" or
+ "\" "\" ; \\
+
+ AS2-quoted-name = DQUOTE 1*128( AS2-qtext /
+ AS2-quoted-pair) DQUOTE
+
+ AS2-atomic-name = 1*128AS2-text
+
+ AS2-name = AS2-atomic-name / AS2-quoted-name
+
+ The AS2-From header value and the AS2-To header value MUST each be an
+ AS2-name, MUST each be comprised of from 1 to 128 printable ASCII
+ characters, and MUST NOT be folded. The value in each of these
+ headers is case-sensitive. The string definitions given above are in
+ ABNF format [14].
+
+ The AS2-quoted-name SHOULD be used only if the AS2-name does not
+ conform to AS2-atomic-name.
+
+ The AS2-To and AS2-From header fields MUST be present in all AS2
+ messages and AS2 MDNs whether asynchronous or synchronous in nature,
+ except for asynchronous MDNs, which are sent using SMTP.
+
+ The AS2-name for the AS2-To header in a response or MDN MUST match
+ the AS2-name of the AS2-From header in the corresponding request
+ message. Likewise, the AS2-name for the AS2-From header in a
+ response or MDN MUST match the AS2-name of the AS2-To header in the
+ corresponding AS2 request message.
+
+ The sending system may choose to limit the possible AS2-To/AS2-From
+ textual values but MUST not exceed them. The receiving system MUST
+ make no restrictions on the textual values and SHOULD handle all
+ possible implementations. However, implementers must be aware that
+ older AS2 products may not adhere to this convention. Trading
+ partner agreements should be made to ensure that older products can
+ support the system identifiers that are used.
+
+ There is no required response to a client request containing invalid
+ or unknown AS2-From or AS2-To header values. The receiving AS2
+ system MAY return an unsigned MDN with an explanation of the error,
+ if the sending system requested an MDN.
+
+
+
+
+Moberg & Drummond Standards Track [Page 16]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+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.
+
+ 5. The ability to return either a synchronous or an asynchronous
+ receipt as the sending party requests.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 17]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Regardless of whether the EDI/EC Interchange was sent in S/MIME
+ format, 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.
+
+ 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/pkcs-7-signature"
+
+ 8. The signature information is formatted according to S/MIME
+ specifications.
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 18]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ The EC Interchange and the RFC 1767 MIME EDI content header can
+ actually be part of a multi-part MIME content-type. When the EDI
+ Interchange is part of a multi-part MIME content-type, the MIC MUST
+ be calculated across the entire multi-part content, including the
+ MIME headers.
+
+ The signed MDN, when received by the sender of the EDI Interchange,
+ can be used by the sender as follows:
+
+ o As an acknowledgement that the EDI Interchange sent was
+ delivered and acknowledged by the receiving trading partner.
+ The receiver does this by returning the original-message-id
+ of the sent message in the MDN portion of the signed receipt.
+
+ o As an acknowledgement 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.
+
+ o As an acknowledgement that the receiving trading partner has
+ authenticated the sender of the EDI Interchange.
+
+ o 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. Synchronous and Asynchronous MDNs
+
+ The AS2-MDN exists in two varieties: synchronous and asynchronous.
+
+ The synchronous AS2-MDN is sent as an HTTP response to an HTTP POST
+ or as an HTTPS response to an HTTPS POST. This form of AS2-MDN is
+ called synchronous because the AS2-MDN is returned to the originator
+ of the POST on the same TCP/IP connection.
+
+ The asynchronous AS2-MDN is sent on a separate HTTP, HTTPS, or SMTP
+ TCP/IP connection. Logically, the asynchronous AS2-MDN is a response
+ to an AS2 message. However, at the transfer-protocol layer, assuming
+ that no HTTP pipelining is utilized, the asynchronous AS2-MDN is
+ delivered on a unique TCP/IP connection, distinct from that used to
+ deliver the original AS2 message. When handling an asynchronous
+ request, the HTTP response MUST be sent back before the MDN is
+ processed and sent on the separate connection.
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 19]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ When an asynchronous AS2-MDN is requested by the sender of an AS2
+ message, the synchronous HTTP or HTTPS response returned to the
+ sender prior to terminating the connection MUST be a transfer-layer
+ response indicating the success or failure of the data transfer. The
+ format of such a synchronous response MAY be the same as that
+ response returned when no AS2-MDN is requested.
+
+ The following diagram illustrates the synchronous versus asynchronous
+ varieties of AS2-MDN delivery using HTTP:
+
+ Synchronous AS2-MDN
+
+ [Peer1] ----( connect )----> [Peer2]
+ [Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]]
+ [Peer1] <---( receive )----- [Peer2] [HTTP Response [AS2-MDN]]
+
+ Asynchronous AS2-MDN
+
+ [Peer1] ----( connect )----> [Peer2]
+ [Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]]
+ [Peer1] <---( receive )----- [Peer2] [HTTP Response]
+
+ [Peer1]*<---( connect )----- [Peer2]
+ [Peer1] <--- ( send )------- [Peer2] [HTTP Request [AS2-MDN]]
+ [Peer1] ----( receive )----> [Peer2] [HTTP Response]
+
+ * Note: An AS2-MDN may be directed to a host different from that of
+ the sender of the AS2 message. It may utilize a transfer protocol
+ different from that used to send the original AS2 message.
+
+ The advantage of the synchronous MDN is that it can provide the
+ sender of the AS2 Message with a verifiable confirmation of message
+ delivery within a synchronous logic flow. However, if the message is
+ relatively large, the time required to process this message and to
+ return an AS2-MDN to the sender on the same TCP/IP connection may
+ exceed the maximum configured time permitted for an IP connection.
+
+ The advantage of the asynchronous MDN is that it provides for the
+ rapid return of a transfer-layer response from the receiver,
+ confirming the receipt of data, therefore not requiring that a TCP/IP
+ connection necessarily remain open for very long. However, this
+ design requires that the asynchronous AS2-MDN contain enough
+ information to identify the original message uniquely so that, when
+ received by the AS2 Message originator, the status of the original
+ AS2 Message can be properly updated based on the contents of the
+ AS2-MDN.
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 20]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Synchronous or asynchronous HTTP or HTTPS MDNs are handled according
+ to the requirements of this specification.
+
+ However, SMTP MDNs are formatted according to the requirements of RFC
+ 3335 [4].
+
+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"
+ ":" mail-address
+
+ The following example is for requesting an MDN:
+
+ Disposition-notification-to: xxx@example.com
+
+ This syntax is a residue of the use of MDNs using SMTP transfer.
+ Because this specification is adjusting the functionality from SMTP
+ to HTTP while retaining as much as possible from the [4]
+ functionality, the mail-address MUST be present. The mail-address
+ field is specified as an RFC 2822 localpart@domain [addr-spec]
+ address. However, the address is not used to identify where to
+ return the MDN. Receiving applications MUST ignore the value and
+ MUST not complain about RFC 2822 address syntax violations.
+
+ When requesting MDN-based receipts, the originator supplies
+ additional extension headers that precede the message body. These
+ header "tags" are as follows:
+
+ A Message-ID header is added to support message reconciliation, so
+ that an Original-Message-Id value can be returned in the body part of
+ MDN. Other headers, especially "Subject" and "Date", SHOULD be
+ supplied; the values of these headers are often mentioned in the
+ human-readable section of a MDN to aid in identifying the original
+ message.
+
+ MDNs will be returned in the HTTP response when requested, unless an
+ asynchronous return is requested.
+
+ To request an asynchronous message disposition notification, the
+ following header is placed into the message that is sent:
+
+ Receipt-Delivery-Option: return-URL
+
+
+
+
+Moberg & Drummond Standards Track [Page 21]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Here is an example requesting that the MDN be asynchronous:
+
+ Receipt-Delivery-Option: http://www.example.com/Path
+
+ Receipt-delivery-option syntax allows return-url to use some schemes
+ other than HTTP using the POST method.
+
+ The "receipt-delivery-option: return-url" string indicates the URL to
+ use for an asynchronous MDN. This header is NOT present if the
+ receipt is to be synchronous. The email value in Disposition-
+ notification-to is not used in this specification because it was
+ limited to RFC 2822 addresses; the extension header "Receipt-
+ delivery-option" has been introduced to provide a URL for the MDN
+ return by several transfer options.
+
+ The receipt-delivery-option's value MUST be a URL indicating the
+ delivery transport destination for the receipt.
+
+ An example request for an asynchronous MDN via an HTTP transport:
+
+ Receipt-delivery-option: http://www.example.com
+
+ An example request for an asynchronous MDN via an HTTP/S transport:
+
+ Receipt-delivery-option: https://www.example.com
+
+ An example request for an asynchronous MDN via an SMTP transport:
+
+ Receipt-delivery-option: mailto:as2@example.com
+
+ For more information on requesting SMTP MDNs, refer to RFC 3335 [4].
+
+ Finally, the header, Disposition-notification-options, identifies
+ characteristics of message disposition notification as in [5]. The
+ most important of these options is for indicating the signing options
+ for the MDN, as in the following example:
+
+ Disposition-notification-options:
+ signed-receipt-protocol=optional,pkcs7-signature;
+ signed-receipt-micalg=optional,sha1,md5
+
+ For signing options, consider the disposition-notification-options
+ syntax:
+
+ Disposition-notification-options =
+ "Disposition-Notification-Options" ":"
+ disposition-notification-parameters
+
+
+
+
+Moberg & Drummond Standards Track [Page 22]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ where
+ disposition-notification-parameters =
+ parameter *(";" parameter)
+
+ where
+ parameter = attribute "=" importance ", " 1#value"
+
+ where
+ importance = "required" | "optional"
+
+ So the Disposition-notification-options string could be:
+
+ signed-receipt-protocol=optional,<protocol symbol>;
+ signed-receipt-micalg=optional,<micalg1>,<micalg2>,...;
+
+ The currently used value for <protocol symbol> is "pkcs7-signature"
+ for the S/MIME detached signature format.
+
+ The currently supported values for MIC algorithm <micalg> values are:
+
+ Algorithm Value Used
+ --------- -------
+ SHA-1 sha1
+ MD5 md5
+
+ The semantics of the "signed-receipt-protocol" and the "signed-
+ receipt-micalg" parameters are as follows:
+
+ 1. The "signed-receipt-protocol" parameter is used to request a
+ signed receipt from the recipient trading partner. The "signed-
+ receipt-protocol" parameter also specifies the format in which the
+ signed receipt SHOULD be returned to the requester.
+
+ The "signed-receipt-micalg" parameter is a list of MIC algorithms
+ preferred by the requester for use in signing the returned
+ receipt. The list of MIC algorithms SHOULD be honored by the
+ recipient from left to right.
+
+ Both the "signed-receipt-protocol" and the "signed- receipt-
+ micalg" option parameters are REQUIRED when requesting a signed
+ receipt.
+
+ The lack of the presence of the "Receipt-Delivery-Option"
+ indicates that a receipt is synchronous in nature. The presence
+ of the "Receipt-Delivery-Option: return-url" indicates that an
+ asynchronous receipt is requested and SHOULD be sent to the
+ "return-url".
+
+
+
+
+Moberg & Drummond Standards Track [Page 23]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ 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 a MDN.
+
+ A UA that does not understand the "signed-receipt-protocol"
+ parameter or the "signed-receipt-micalg" 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 and 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
+ is up to the trading partners to resolve.
+
+ In general, if a signed receipt is required in 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" are as follows:
+
+ 1. When a receipt is requested, explicitly specifying that the
+ receipt be signed, then the receipt MUST be returned with a
+ signature.
+
+ 2. When a receipt is requested, explicitly specifying that the
+ receipt be signed, but the recipient cannot support either the
+ requested protocol format or the requested MIC algorithms, then
+ either a signed or unsigned receipt SHOULD be returned.
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 24]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ 3. 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.
+
+ NOTE: For Internet EDI, it is RECOMMENDED that when a signature is
+ not explicitly requested, or if parameters are not recognized, the UA
+ send back, at a minimum, an unsigned receipt. If, however, a signed
+ receipt was always returned as a policy, whether requested or not,
+ then any false unsigned receipts can be repudiated.
+
+ When a request for a signed receipt is made, but there is an error in
+ processing the contents of the message, a signed receipt MUST still
+ be returned. The request for a signed receipt SHALL still be
+ honored, though the transaction itself may not be valid. The reason
+ why the contents could not be processed MUST be set in the
+ "disposition-field".
+
+ When a signed receipt request is made, the "Received-content-MIC"
+ MUST always be returned to the requester (except when corruption
+ prevents computation of the digest in accordance with the following
+ specification). The "Received-content-MIC" MUST be calculated as
+ follows:
+
+ o For any signed messages, the MIC to be returned is calculated
+ on the RFC1767/RFC3023 MIME header and content.
+ Canonicalization on the MIME headers MUST be performed before
+ the MIC is calculated, since the sender requesting the signed
+ receipt was also REQUIRED to canonicalize.
+
+ o For encrypted, unsigned messages, the MIC to be returned is
+ calculated on the decrypted RFC 1767/RFC3023 MIME header and
+ content. The content after decryption MUST be canonicalized
+ before the MIC is calculated.
+
+ o For unsigned, unencrypted messages, the MIC MUST be calculated
+ over the message contents without the MIME or any other RFC
+ 2822 headers, since these are sometimes altered or reordered by
+ Mail Transport Agents (MTAs).
+
+7.4. MDN Format and Values
+
+ This section defines the format of the AS2 Message Disposition
+ Notification (AS2-MDN).
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 25]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+7.4.1. AS2-MDN General Formats
+
+ The AS2-MDN follows the MDN specification [5] except where noted in
+ this section. The modified ABNF definitions in this document use the
+ vertical-bar character, '|', to denote a logical "OR" construction.
+ This usage follows RFC 2616 [3]. HTTP entities referred to below are
+ not further defined in this document. Refer to RFC 2616 [3] for
+ complete definitions of HTTP entities. The format of the AS2-MDN is:
+
+ AS2-MDN = AS2-sync-MDN | AS2-async-http-MDN |
+ AS2-async-smtp-MDN
+
+ AS2-sync-MDN =
+ Status-Line
+ *(( general-header | response-header | entity-header )
+ CRLF )
+ CRLF
+ AS2-MDN-body
+
+ Status-Line =
+ HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+
+ AS2-async-http-MDN =
+ Request-Line
+ *(( general-header | request-header | entity-header )
+ CRLF )
+ CRLF
+ AS2-MDN-body
+
+ Request-Line =
+ Method SP Request-URI SP HTTP-Version CRLF
+
+ AS2-async-smtp-MDN =
+ *(( general-header | request-header | entity-header )
+ CRLF )
+ CRLF
+ AS2-MDN-body
+
+ AS2-MDN-body =
+ AS2-signed-MDN-body | AS2-unsigned-MDN-body
+
+7.4.2. AS2-MDN Construction
+
+ The AS2-MDN-body is formatted as a MIME multipart/report with a
+ report-type of "disposition-notification". When the message is
+ unsigned, the transfer-layer ("outermost") entity-headers of the
+ AS2-MDN contain the content-type header that specifies a content-type
+
+
+
+
+Moberg & Drummond Standards Track [Page 26]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ of "multipart/report" and parameters indicating the report-type, and
+ the value of the outermost multipart boundary.
+
+ When the AS2-MDN is signed, the transfer-layer ("outermost") entity-
+ headers of the AS2-MDN contain a content-type header that specifies a
+ content-type of "multipart/signed" and 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 embedded 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:
+
+ AS2-disposition-notification-content =
+ [ reporting-ua-field CRLF ]
+ [ mdn-gateway-field CRLF ]
+ final-recipient-field CRLF
+ [ original-message-id-field CRLF ]
+ AS2-disposition-field CRLF
+ *( failure-field CRLF )
+ *( error-field CRLF )
+ *( warning-field CRLF )
+ *( extension-field CRLF )
+ [ AS2-received-content-MIC-field CRLF ]
+
+7.4.3. AS2-MDN Fields
+
+ The rules for constructing the AS2-disposition-notification content
+ are identical to the disposition-notification-content rules provided
+ in Section 7 of RFC 3798 [5], except that the RFC 3798 disposition-
+ field has been replaced with the AS2-disposition-field and that the
+ AS2-received-content-MIC field has been added. The differences
+ between the RFC 3798 disposition-field and the AS2-disposition-field
+ are described below. Where there are differences between this
+ document and RFC 3798, those entity names have been changed by pre-
+ pending "AS2-". Entities that do not differ from RFC 3798 are not
+ necessarily further defined in this document; refer to RFC 3798,
+ Section 7, "Collected Grammar", for the original grammar.
+
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 27]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ AS2-disposition-field =
+ "Disposition" ":" disposition-mode ";"
+ AS2-disposition-type [ '/' AS2-disposition-modifier ]
+
+ disposition-mode =
+ action-mode "/" sending-mode
+
+ action-mode =
+ "manual-action" | "automatic-action"
+
+ sending-mode =
+ "MDN-sent-manually" | "MDN-sent-automatically"
+
+ AS2-disposition-type =
+ "processed" | "failed"
+
+ AS2-disposition-modifier =
+ ( "error" | "warning" ) | AS2-disposition-modifier-extension
+
+ AS2-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: " AS2-MDN-warning-description |
+ "failure: " AS2-MDN-failure-description
+
+ AS2-MDN-warning-description = *( TEXT )
+
+ AS2-MDN-failure-description = *( TEXT )
+
+ AS2-received-content-MIC-field =
+ "Received-content-MIC" ":" encoded-message-digest ","
+ digest-alg-id CRLF
+
+ encoded-message-digest =
+ 1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' | '=' ) (
+ i.e. base64( message-digest ) )
+
+ digest-alg-id = "sha1" | "md5"
+
+ "Insufficient-message-security" and "decompression-failed" are new
+ error codes that are not mentioned in the AS1 RFC 3335, and may not
+ be compatible with earlier implementations of AS2.
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 28]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ The "Received-content-MIC" extension field is set when 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.
+
+ For signed messages, the algorithm used to calculate the MIC MUST be
+ the same as that used on the message that was signed. If the message
+ is not signed, then the SHA-1 algorithm SHOULD be used. 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 so that the sender can verify non-repudiation of
+ receipt.
+
+ AS2-MDN field names (e.g., "Disposition:", "Final-Recipient:") are
+ case insensitive (cf. RFC 3798, Section 3.1.1). AS2-MDN action-
+ modes, sending-modes, AS2-disposition-types, and AS2-disposition-
+ modifier values, which are defined above, and user-supplied *( TEXT )
+ values are also case insensitive. AS2 implementations MUST NOT make
+ assumptions regarding the values supplied for AS2-MDN-warning-
+ description or AS2-MDN-failure-description, or for the values of any
+ (optional) error, warning, or failure fields.
+
+7.4.4. Additional AS2-MDN Programming Notes
+
+ o Unlike SMTP, for HTTP transactions, Original-Recipient and Final-
+ Recipient SHOULD not be different. The value in Original-
+ Message-ID SHOULD match the original Message-ID header value.
+
+ o Refer to RFC 3798 for the formatting of the MDN, except for the
+ specific deviations mentioned above.
+
+ o Refer to RFC 3462 and RFC 3798 for the formatting of the content-
+ type entity-headers for the MDN.
+
+ o Use an action-mode of "automatic-action" when the disposition
+ described by the disposition type was a result of an automatic
+ action rather than that of an explicit instruction by the user for
+ this message.
+
+ o 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.
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 29]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ o Use a sending-mode of "MDN-sent-automatically" when the MDN is
+ sent because the UA had previously been configured to do so.
+
+ o Use a sending-mode of "MDN-sent-manually" when the user explicitly
+ gave permission for this particular MDN to be sent.
+
+ o The sending-mode "MDN-sent-manually" is meaningful ONLY with
+ "manual-action", not with "automatic-action".
+
+ o The "failed" disposition type MUST 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.
+
+7.5. Disposition Mode, Type, and Modifier
+
+7.5.1. Disposition Mode Overview
+
+ This section provides a brief overview of how "processed", "error",
+ "failure", and "warning" are used.
+
+7.5.2. Successful Processing Status Indication
+
+ When the request for a receipt or signed receipt, 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 the control of a user, administrator, or software.
+
+ Because 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":
+
+
+
+Moberg & Drummond Standards Track [Page 30]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Disposition: automatic-action/MDN-sent-automatically; processed
+
+ Note that this specification does not restrict the use of the
+ "disposition-mode" just to 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"
+ values that should be used if the message content is being rejected
+ or ignored (for instance, if the EDI UA determines that a signed
+ receipt cannot be returned because it does not support the requested
+ protocol format, the EDI UA chooses not to process the message
+ contents itself) MUST be specified in the MDN "disposition-field" as
+ follows:
+
+ Disposition: "disposition-mode"; failed/Failure:
+ unsupported format
+
+ The "failed" AS2-disposition-type MUST 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:" AS2-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 MUST 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"
+
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 31]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+7.5.4. Unsuccessful Non-Content Processing
+
+ When errors occur in processing the received message (other than
+ content), the "disposition-field" MUST be set to the "processed"
+ value for disposition-type and the "error" value for disposition-
+ modifier.
+
+ The "error" AS2-disposition-modifier with the "processed"
+ disposition-type MUST 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:" AS2-disposition-modifier-extension SHOULD be used to
+ combine the indication of an error with a predefined description of a
+ specific, well-known error. Further information about the error may
+ be contained in an error field.
+
+ For internet EDI use, the following "error" AS2-disposition-modifier
+ values are defined:
+
+ o "Error: decryption-failed" - the receiver could not
+ decrypt the message
+ contents.
+
+ o "Error: authentication-failed" - the receiver could not
+ authenticate the sender.
+
+ o "Error: integrity-check-failed" - the receiver could not
+ verify content integrity.
+
+ o "Error: unexpected-processing-error" - a catch-all for any
+ additional processing
+ errors.
+
+ An example of how the "disposition-field" would look when errors
+ other than those in content processing are detected is as follows:
+
+ Disposition: "disposition-mode"; processed/Error:
+ decryption-failed
+
+7.5.5. Processing Warnings
+
+ Situations arise in EDI when, 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
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 32]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ processing warning situations as described above, the "disposition-
+ field" MUST be set to the "processed" disposition-type value, and the
+ "warning" to the "disposition-modifier" value.
+
+ The "warning" AS2-disposition-modifier MUST 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.
+
+ A "warning:" AS2-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-extension value is defined:
+
+ "Warning: authentication-failed, processing continued"
+
+ An example of how the "disposition-field" would look when warning
+ other than those for content processing are detected is as follows:
+
+ Example:
+
+ Disposition: "disposition-mode"; processed/Warning:
+ authentication-failed, processing continued
+
+7.5.6. Backward Compatibility with Disposition Type, Modifier, and
+ Extension
+
+ The following set of examples represents typical constructions of the
+ Disposition field that have been in use by AS2 implementations. This
+ is NOT an exhaustive list of possible constructions. However, AS2
+ implementations MUST accept constructions of this type to be backward
+ compatible with earlier AS2 versions.
+
+ Disposition: automatic-action/MDN-sent-automatically; processed
+
+ Disposition: automatic-action/MDN-sent-automatically;
+ processed/error: authentication-failed
+
+ Disposition: automatic-action/MDN-sent-automatically;
+ processed/warning: duplicate-document
+
+ Disposition: automatic-action/MDN-sent-automatically;
+ failed/failure: sender-equals-receiver
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 33]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ The following set of examples represents allowable constructions of
+ the Disposition field that combine the historic constructions above
+ with optional RFC 3798 error, warning, and failure fields. AS2
+ implementations MAY produce these constructions. However, AS2
+ servers are not required to recognize or process optional error,
+ warning, or failure fields at this time. Note that the use of the
+ multiple error fields in the second example below provides for the
+ indication of multiple error conditions.
+
+ Disposition: automatic-action/MDN-sent-automatically; processed
+
+ Disposition: automatic-action/MDN-sent-automatically;
+ processed/error: decryption-failed
+ Error: The signature did not decrypt into a valid PKCS#1
+ Type-2 block.
+ Error: The length of the decrypted key does not equal the
+ octet length of the modulus.
+
+ Disposition: automatic-action/MDN-sent-automatically;
+ processed/warning: duplicate-document
+ Warning: An identical message already exists at the
+ destination server.
+
+ Disposition: automatic-action/MDN-sent-automatically;
+ failed/failure: sender-equals-receiver
+ Failure: The AS2-To name is identical to the AS2-From name.
+
+ The following set of examples represents allowable constructions of
+ the Disposition field that employ pure RFC 3798 Disposition-modifiers
+ with optional error, warning, and failure fields. These examples are
+ provided as informational only. These constructions are not
+ guaranteed to be backward compatible with AS2 implementations prior
+ to version 1.1.
+
+ Disposition: automatic-action/MDN-sent-automatically; processed
+
+ Disposition: automatic-action/MDN-sent-automatically;
+ processed/error
+ Error: authentication-failed
+ Error: The signature did not decrypt into a valid PKCS#1 Type-2
+ block.
+ Error: The length of the decrypted key does not equal the
+ octet length of the modulus.
+
+ Disposition: automatic-action/MDN-sent-automatically;
+ processed/warning
+ Warning: duplicate-document
+
+
+
+
+Moberg & Drummond Standards Track [Page 34]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Disposition: automatic-action/MDN-sent-automatically; failed
+ Failure: sender-equals-receiver
+
+7.6. Receipt Reply Considerations in an HTTP POST
+
+ The details of the response to the POST command vary depending upon
+ whether a receipt has been requested.
+
+ With no extended header requesting a receipt, and with no errors
+ accessing the request-URI specified processing, the status line in
+ the Response to the POST request SHOULD be in the 200 range. Status
+ codes in the 200 range SHOULD also be used when an entity is returned
+ (a signed receipt in a multipart/signed content type or an unsigned
+ receipt in a multipart/report). Even when the disposition of the
+ data was an error condition at the authentication, decryption or
+ other higher level, the HTTP status code SHOULD indicate success at
+ the HTTP level.
+
+ The HTTP server-side application may respond with an unsolicited
+ multipart/report as a message body that the HTTP client might not
+ have solicited, but the client may discard this. Applications SHOULD
+ avoid emitting unsolicited receipt replies because bandwidth or
+ processing limitations might have led administrators to suspend
+ asking for acknowledgements.
+
+ Message Disposition Notifications, when used in the HTTP reply
+ context, will closely parallel a SMTP MDN. For example, the
+ disposition field is a required element in the machine-readable
+ second part of a multipart/report for a MDN. The final-recipient-
+ field ([5], Section 3.1) value SHOULD be derived from the entity
+ headers of the request.
+
+ In an MDN, the first part of the multipart/report (the human-readable
+ part) SHOULD include items such as the subject, the date, and other
+ information when those fields are present in entity header fields
+ following the POST request. An application MUST report the Message-
+ ID of the request in the second part of the multipart/report (the
+ machine-readable part). Also, an MDN SHOULD have its own unique
+ Message-ID HTTP header. The HTTP reply SHOULD normally omit the
+ third optional part of the multipart/report (used to return the
+ original message or its headers in the SMTP context).
+
+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,
+
+
+
+Moberg & Drummond Standards Track [Page 35]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ in addition to the mapping between the EDI trading partner ID and the
+ RFC 2822 [9] email address and HTTP 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 they
+ also exchange public key certificates, considering advice provided in
+ [12].
+
+ The message formats useful for certificate exchange are found in [7]
+ and [13].
+
+ In the long term, additional standards may be developed to simplify
+ the process of establishing a trading partnership, including the
+ third-party authentication of trading partners, as well as the
+ attributes of the trading relationship.
+
+9. Security Considerations
+
+ This entire document is concerned with secure transport of business
+ to business data, and it considers both data confidentiality and
+ authentication issues.
+
+ Extracted from RFC 3851 [7]:
+ 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 Triple DES 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 of the relative cryptographic strength
+ of messages.
+
+ Extracted from RFC 3850 [12]:
+ 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 have not been listed, however, the reader should not assume
+
+
+
+Moberg & Drummond Standards Track [Page 36]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ 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 situations in which signature and certificate
+ checking might fail include the following:
+
+ o No certificate chain leads to a trusted CA.
+
+ o No ability to check the Certificate Revocation List (CRL) for a
+ certificate.
+
+ o An invalid CRL was received.
+
+ o The CRL being checked is expired.
+
+ o The certificate is expired.
+
+ o 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. See RFC 3280 for additional information on certificate path
+ validation.
+
+ The following are additional security considerations to those listed
+ in [7] and [12].
+
+9.1. NRR Cautions
+
+ This specification seeks to provide multiple mechanisms that can be
+ combined in accordance with local policies to achieve a wide range of
+ security needs as determined by threat and risk analyses of the
+ business peers. It is required that all these mechanisms be
+ implemented by AS2 software so that the software has capabilities
+ that promote strong interoperability, no matter what policies are
+ adopted.
+
+ One strong cluster of mechanisms (the secure transmission loop) can
+ provide good support for meeting the evidentiary needs of non-
+ repudiation of receipt by the original sender and by a third party
+ supplied with all stated evidence. However, this specification does
+ not itself define non-repudiation of receipt nor enumerate its
+ essential properties because NRR is a business analysis and/or legal
+ requirement, and not relevantly defined by a technical applicability
+ statement.
+
+
+
+Moberg & Drummond Standards Track [Page 37]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Some analyses observe that non-repudiation of receipt presupposes
+ that non-repudiation of the sender of the original message is
+ obtained, and further that non-repudiation should be implemented by
+ means of digital signature on the original message. To satisfy
+ strict NRR evidence, authentication and integrity MUST be provided by
+ some mechanism, and the RECOMMENDED mechanism is digital signatures
+ on both the original message and the receipt message.
+
+ Given that this specification has selected several mechanisms that
+ can be combined in several ways, it is important to realize that if a
+ digital signature is omitted from the original message, in order to
+ satisfy the preceding analysis of NRR requirements, some
+ authentication mechanism MUST accompany the request for a signed
+ receipt and its included Received-content-MIC value. This
+ authentication might come from using client-side SSL, authentication
+ via IPsec, or HTTP authentication (while using SSL). In any case,
+ records of the message content, its security basis, and the digest
+ value need to be retained for the NRR process.
+
+ Therefore, if NRR is one of the goals of the policy that is adopted,
+ by using the mechanisms of the secure transmission loop mentioned
+ above and by retaining appropriate records of authentication at the
+ original message sender site, strong evidentiary requirements
+ proposed for NRR can be fulfilled.
+
+ Other ways of proceeding may fall short of fulfilling the most
+ stringent sets of evidence required for NRR to obtain, but may
+ nevertheless be part of a commercial trading agreement and, as such,
+ are good enough for the parties involved. However, if MDNs are
+ returned unsigned, evidentiary requirements for NRR are weak; some
+ authentication of the identity of the receiver is needed.
+
+9.2. HTTPS Remark
+
+ The following certificate types MUST be supported for SSL server-side
+ certificates:
+
+ o with URL in the Distinguished Name Common Name attribute
+
+ o without URL in the Distinguished Name Common Name attribute
+
+ o self-signed (self-issued)
+
+ o certification authority certified
+
+ The URL, which matches the source server identity, SHOULD be carried
+ in the certificate. However, it is not required that DNS checks or
+ reverse lookups to vouch for the accuracy of the URL or server value.
+
+
+
+Moberg & Drummond Standards Track [Page 38]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Because server-side certificates are exchanged, and also trust is
+ established during the configuration of the trading partner
+ relationship, runtime checks are not required by implementations of
+ this specification.
+
+ The complete certification chain MUST be included in all
+ certificates. All certificate verifications MUST "chain to root" or
+ to an accepted trust anchor. Additionally, the certificate hash
+ SHOULD match the hash recomputed by the receiver.
+
+9.3. Replay Remark
+
+ Because business data documents normally contain transaction ids,
+ replays (such as resends of not-yet-acknowledged messages) are
+ discarded as part of the normal process of duplicate detection.
+ Detection of duplicates by Message-Id or by business transaction
+ identifiers is recommended.
+
+10. IANA Considerations
+
+ RFC 3335 registered two Disposition-Notification-Options parameters
+
+ Parameter-name: signed-receipt-protocol
+ Parameter-name: signed-receipt-micalg
+
+ that are also used by this specification (see Section 7.3).
+
+ RFC 3335 also registered on MDN Extension field name
+
+ Extension field name: Received-content-MIC
+
+ that is also used by this specification (see Section 7.4.3).
+ Registration of the above is therefore NOT needed.
+
+10.1. Registration
+
+ This specification defines an extension to the Message Disposition
+ Notification (MDN) protocol for a disposition-modifier in the
+ Disposition field of a body of content-type "message/disposition-
+ notification".
+
+10.1.1. Disposition Modifier 'warning'
+
+ Parameter-name: warning
+ Semantics: See Sections 7.4.3 and 7.5.5 of this document.
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 39]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+11. Acknowledgements
+
+ Carl Hage, Karen Rosenfeld, Chuck Fenton, and many others have
+ provided valuable suggestions that improved this applicability
+ statement. The authors would also like to thank the vendors who
+ participated in the Drummond Group Inc. AS2 interoperability testing.
+ Their contributions led to great improvement in the clarity of this
+ document.
+
+12. References
+
+12.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] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+ Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [4] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure
+ Peer-to-Peer Business Data Interchange over the Internet", RFC
+ 3335, September 2002.
+
+ [5] Hansen, T. and G. Vaudreuil, "Message Disposition Notification",
+ RFC 3798, May 2004.
+
+ [6] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
+ Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+ RFC 1847, October 1995.
+
+ [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+ (S/MIME) Version 3.1 Message Specification", RFC 3851, July
+ 2004.
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 40]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ [8] Vaudreuil, G., "The Multipart/Report Content Type for the
+ Reporting of Mail System Administrative Messages", RFC 3462,
+ January 2003.
+
+ [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+ [10] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types", RFC
+ 3023, January 2001.
+
+ [11] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+ [12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+ (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
+
+ [13] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
+ July 2004.
+
+ [14] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+12.2. Informative References
+
+ [15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 41]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+Appendix A: Message Examples
+
+ NOTE: All examples are provided for illustration only, and are not
+ considered part of the protocol specification. If an example
+ conflicts with the protocol definitions specified above or in the
+ other referenced RFCs, the example is wrong.
+
+A.1. Signed Message Requesting a Signed, Synchronous Receipt
+
+ POST /receive HTTP/1.0
+ Host: 10.234.160.12:80
+ User-Agent: AS2 Company Server
+ Date: Wed, 31 Jul 2002 13:34:50 GMT
+ From: mrAS2@example.com
+ AS2-Version: 1.1
+ AS2-From: "\" as2Name \""
+ AS2-To: 0123456780000
+ Subject: Test Case
+ Message-Id: <200207310834482A70BF63@\"~~foo~~\">
+ Disposition-Notification-To: mrAS2@example.com
+ Disposition-Notification-Options: signed-receipt-protocol=optional,
+ pkcs7-signature; signed-receipt-micalg=optional,sha1
+ Content-Type: multipart/signed; boundary="as2BouNdary1as2";
+ protocol="application/pkcs7-signature"; micalg=sha1
+ Content-Length: 2464
+
+ --as2BouNdary1as2
+ Content-Type: application/edi-x12
+ Content-Disposition: Attachment; filename=rfc1767.dat
+ [ISA ...EDI transaction data...IEA...]
+
+ --as2BouNdary1as2
+ Content-Type: application/pkcs7-signature
+
+ [omitted binary pkcs7 signature data]
+ --as2BouNdary1as2--
+
+A.2. MDN for Message A.1, Above
+
+ HTTP/1.0 200 OK
+ AS2-From: 0123456780000
+ AS2-To: "\" as2Name \""
+ AS2-Version: 1.1
+ Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
+ Content-Type: multipart/signed; micalg=sha1;
+ protocol="application/pkcs7-signature";
+ boundary="----=_Part_57_648441049.1028122454671"
+ Connection: Close
+
+
+
+Moberg & Drummond Standards Track [Page 42]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ Content-Length: 1980
+
+ ------=_Part_57_648441049.1028122454671
+
+ & 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@\"~~foo~~\">
+ & From: "\" as2Name \""
+ & To: "0123456780000"
+ & 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: AS2 Server
+ &Original-Recipient: rfc822; 0123456780000
+ &Final-Recipient: rfc822; 0123456780000
+ &Original-Message-ID: <200207310834482A70BF63@\"~~foo~~\">
+ &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--
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 43]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ 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 the "S/MIME Message
+ Specification, PKCS Security Services for MIME".)
+
+ 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 [8], 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.
+
+A.3. Signed, Encrypted Message Requesting a Signed, Asynchronous
+ Receipt
+
+ Message-ID: <#as2_company#01#a4260as2_companyout#>
+ Date: Thu, 19 Dec 2002 15:04:18 GMT
+ From: me@example.com
+ Subject: Async MDN request
+ Mime-Version: 1.0
+ Content-Type: application/pkcs7-mime;
+ smime-type=enveloped-data; name=smime.p7m
+ Content-Transfer-Encoding: binary
+ Content-Disposition: attachment; filename=smime.p7m
+ Recipient-Address: 10.240.1.2//
+ Disposition-Notification-To:
+ http://10.240.1.2:8201/exchange/as2_company
+ Disposition-Notification-Options: signed-receipt-protocol=optional,
+ pkcs7-signature; signed-receipt-micalg=optional,sha1
+ Receipt-Delivery-Option:
+ http://10.240.1.2:8201/exchange/as2_company
+ AS2-From: as2_company
+ AS2-To: "AS2 Test"
+ AS2-Version: 1.1
+ Host: 10.240.1.2:8101
+ Connection: close
+ Content-Length: 3428
+
+ [omitted binary encrypted data]
+
+
+
+Moberg & Drummond Standards Track [Page 44]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+A.4. Asynchronous MDN for Message A.3, Above
+
+ POST / HTTP/1.1
+ Host: 10.240.1.2:8201
+ Connection: close, TE
+ TE: trailers, deflate, gzip, compress
+ User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
+ Date: Thu, 19 Dec 2002 15:03:38 GMT
+ Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
+ AS2-Version: 1.1
+ Mime-Version: 1.0
+ Recipient-Address:
+ http://10.240.1.2:8201/exchange/as2_company
+ AS2-To: as2_company
+ AS2-From: "AS2 Test"
+ Subject: Your Requested MDN Response
+ From: as2debug@example.com
+ Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
+ Content-Type: multipart/signed; micalg=sha1;
+ protocol="application/pkcs7-signature";
+ boundary="----=_Part_337_6452266.1040310218750"
+ Content-Length: 3103
+
+ ------=_Part_337_6452266.1040310218750
+ Content-Type: multipart/report;
+ report-type=disposition-notification;
+ boundary="----=_Part_336_6069110.1040310218718"
+
+ ------=_Part_336_6069110.1040310218718
+ Content-Type: text/plain; charset=us-ascii
+ Content-Transfer-Encoding: 7bit
+
+ The message <x12.edi> sent to Recipient <AS2 Test> on Thu, 19 Dec
+ 2002 15:04:18 GMT with Subject <async MDN request> has been received.
+ The EDI Interchange was successfully decrypted, and its integrity was
+ verified. In addition, the sender of the message, Sender
+ <as2_company> at Location http://10.240.1.2:8201/exchange/as2_company
+ was authenticated as the originator of the message. There is no
+ guarantee, however, that the EDI interchange was syntactically
+ correct, or that it was received by the EDI application/translator.
+
+
+
+
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 45]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+ ------=_Part_336_6069110.1040310218718
+ Content-Type: message/disposition-notification
+ Content-Transfer-Encoding: 7bit
+
+ Reporting-UA: AS2@test:8101
+ Original-Recipient: rfc822; "AS2 Test"
+ Final-Recipient: rfc822; "AS2 Test"
+ Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
+ Disposition: automatic-action/MDN-sent-automatically;
+ processed
+ Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1
+
+ ------=_Part_336_6069110.1040310218718--
+
+ ------=_Part_337_6452266.1040310218750
+ Content-Type: application/pkcs7-signature; name=smime.p7s
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7s
+
+ BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM
+ 4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j
+ UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=
+
+ ------=_Part_337_6452266.1040310218750-
+
+Authors' Addresses
+
+ Dale Moberg
+ Cyclone Commerce
+ 8388 E. Hartford Drive, Suite 100
+ Scottsdale, AZ 85255 USA
+
+ EMail: dmoberg@cyclonecommerce.com
+
+
+ Rik Drummond
+ Drummond Group Inc.
+ 4700 Bryant Irvin Court, Suite 303
+ Fort Worth, TX 76107 USA
+
+ EMail: rvd2@drummondgroup.com
+
+
+
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 46]
+
+RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ 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 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.
+
+
+
+
+
+
+
+Moberg & Drummond Standards Track [Page 47]
+