doc: Add RFC documents

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]
+