



Network Working Group                                           D. Petta
Internet-Draft                                       Drummond Group, LLC
Intended status: Informational                           15 October 2025
Expires: 18 April 2026


                    AS2 Specification Modernization
                       draft-petta-rfc4130bis-01

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.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://DrummondGroup.github.io/draft-petta-rfc4130bis/draft-petta-
   rfc4130bis.html.  Status information for this document may be found
   at https://datatracker.ietf.org/doc/draft-petta-rfc4130bis/.

   Source for this draft and an issue tracker can be found at
   https://github.com/DrummondGroup/draft-petta-rfc4130bis.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.







Petta                     Expires 18 April 2026                 [Page 1]

Internet-Draft       AS2 Specification Modernization        October 2025


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 18 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Applicable RFCs . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Overall Operation . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Purpose of a Security Guideline for MIME EDI  . . . . . .   7
     2.3.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   7
       2.3.1.  The Secure Transmission Loop  . . . . . . . . . . . .   7
       2.3.2.  Definition of Receipts  . . . . . . . . . . . . . . .   8
     2.4.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .   8
       2.4.1.  EDI/EC Process Assumptions  . . . . . . . . . . . . .   8
       2.4.2.  Flexibility Assumptions . . . . . . . . . . . . . . .   9
   3.  References RFCs and Their Contributions . . . . . . . . . . .  11
     3.1.  RFC 2616 HTTP v1.1 RFC2616  . . . . . . . . . . . . . . .  11
     3.2.  RFC 1847 MIME Security Multiparts RFC1847 . . . . . . . .  11
     3.3.  RFC 3462 Multipart/Report RFC3462 . . . . . . . . . . . .  11
     3.4.  RFC 1767 EDI Content RFC1767  . . . . . . . . . . . . . .  11
     3.5.  RFC 2045, 2046, and 2049 MIME RFC2045, RFC2046, and
           RFC2049 . . . . . . . . . . . . . . . . . . . . . . . . .  11
     3.6.  RFC 3798 Message Disposition Notification RFC3798 . . . .  11



Petta                     Expires 18 April 2026                 [Page 2]

Internet-Draft       AS2 Specification Modernization        October 2025


     3.7.  RFC 3851 and 3852 S/MIME Version 3.1 Message Specifications
           and Cryptographic Message Syntax (CMS) RFC3851 / RFC3852   11
     3.8.  RFC 3023 XML Media Types RFC3023  . . . . . . . . . . . .  11
   4.  Structure of an AS2 Message . . . . . . . . . . . . . . . . .  11
     4.1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  Structure of an Internet EDI MIME Message . . . . . . . .  12
   5.  HTTP Considerations . . . . . . . . . . . . . . . . . . . . .  13
     5.1.  Sending EDI in HTTP POST Requests . . . . . . . . . . . .  13
     5.2.  Unused MIME Headers and Operations  . . . . . . . . . . .  14
       5.2.1.  Content-Transfer-Encoding Not Used in HTTP
               Transport . . . . . . . . . . . . . . . . . . . . . .  14
       5.2.2.  Message Bodies  . . . . . . . . . . . . . . . . . . .  14
     5.3.  Modification of MIME or Other Headers or Parameters
           Used  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
       5.3.1.  Content-Length  . . . . . . . . . . . . . . . . . . .  14
       5.3.2.  Final Recipient and Original Recipient  . . . . . . .  14
       5.3.3.  Message-Id and Original-Message-Id  . . . . . . . . .  14
       5.3.4.  Host Header . . . . . . . . . . . . . . . . . . . . .  15
     5.4.  HTTP Response Status Codes  . . . . . . . . . . . . . . .  15
     5.5.  HTTP Error Recovery . . . . . . . . . . . . . . . . . . .  15
   6.  Additional AS2-Specific HTTP Headers  . . . . . . . . . . . .  16
     6.1.  AS2 Version Header  . . . . . . . . . . . . . . . . . . .  16
     6.2.  AS2 System Identifiers  . . . . . . . . . . . . . . . . .  16
   7.  Structure and Processing of an MDN Message  . . . . . . . . .  18
     7.1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .  18
     7.2.  Synchronous and Asynchronous MDNs . . . . . . . . . . . .  20
     7.3.  Requesting a Signed Receipt . . . . . . . . . . . . . . .  22
       7.3.1.  Signed Receipt Considerations . . . . . . . . . . . .  25
     7.4.  MDN Format and Values . . . . . . . . . . . . . . . . . .  27
       7.4.1.  AS2-MDN General Formats . . . . . . . . . . . . . . .  27
       7.4.2.  AS2-MDN Construction  . . . . . . . . . . . . . . . .  28
       7.4.3.  AS2-MDN Fields  . . . . . . . . . . . . . . . . . . .  28
       7.4.4.  Additional AS2-MDN Programming Notes  . . . . . . . .  30
     7.5.  Disposition Mode, Type, and Modifier  . . . . . . . . . .  31
       7.5.1.  Disposition Mode Overview . . . . . . . . . . . . . .  31
       7.5.2.  Successful Processing Status Indication . . . . . . .  31
       7.5.3.  Unsuccessful Processed Content  . . . . . . . . . . .  32
       7.5.4.  Unsuccessful Non-Content Processing . . . . . . . . .  33
       7.5.5.  Processing Warnings . . . . . . . . . . . . . . . . .  34
       7.5.6.  Backward Compatibility with Disposition Type, Modifier,
               and Extension . . . . . . . . . . . . . . . . . . . .  34
     7.6.  Receipt Reply Considerations in an HTTP POST  . . . . . .  36
   8.  Public Key Certificate Handling . . . . . . . . . . . . . . .  37
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  37
     9.1.  NRR Cautions  . . . . . . . . . . . . . . . . . . . . . .  39
     9.2.  HTTPS Remark  . . . . . . . . . . . . . . . . . . . . . .  40
     9.3.  Replay Remark . . . . . . . . . . . . . . . . . . . . . .  40
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  40



Petta                     Expires 18 April 2026                 [Page 3]

Internet-Draft       AS2 Specification Modernization        October 2025


     10.1.  Registration . . . . . . . . . . . . . . . . . . . . . .  41
       10.1.1.  Disposition Modifier 'warning' . . . . . . . . . . .  41
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  41
   12. Appendix A: Message Examples  . . . . . . . . . . . . . . . .  41
     12.1.  A.1.  Signed Message Requesting a Signed, Synchronous
            Receipt  . . . . . . . . . . . . . . . . . . . . . . . .  41
     12.2.  A.2.  MDN for Message A.1, Above . . . . . . . . . . . .  42
     12.3.  A.3.  Signed, Encrypted Message Requesting a Signed,
            Asynchronous Receipt . . . . . . . . . . . . . . . . . .  44
     12.4.  A.4.  Asynchronous MDN for Message A.3, Above  . . . . .  44
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  46
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  46
     13.2.  Informative References . . . . . . . . . . . . . . . . .  47
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  47

1.  Introduction

   This draft is a copy of the original RFC4130 draft with only the
   changes necessary to render it in markdown.  Future versions of this
   draft will propose changes, hopefully with the consensus of the IETF
   community.

   NOTE: This version contains IDENTICAL content of the original
   (expired) bis document.  The only difference are edits to trigger
   updates so that the expiration date could be modified.

1.1.  Applicable RFCs

   Previous work on Internet EDI focused on specifying MIME content
   types for EDI data [RFC1767] and extending this work to support
   secure EC/EDI transport over SMTP [RFC3335].  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:










Petta                     Expires 18 April 2026                 [Page 4]

Internet-Draft       AS2 Specification Modernization        October 2025


    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 [RFC3852].

1.2.  Terms

   AS2: Applicability Statement 2 (this document); see RFC 2026
   [RFC2026], Section 3.2

   EDI: Electronic Data Interchange

   EC: Business-to-Business Electronic Commerce

   B2B: Business to Business

   Receipt: The functional message that is sent from a receiver to a
   sender to acknowledge receipt of an EDI/EC interchange.  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,



Petta                     Expires 18 April 2026                 [Page 5]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

   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 [RFC2616] is used to send appropriately
   packaged EDI, XML, or other business data.  The Request-URI
   ([RFC2616], 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.




Petta                     Expires 18 April 2026                 [Page 6]

Internet-Draft       AS2 Specification Modernization        October 2025


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
   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.






Petta                     Expires 18 April 2026                 [Page 7]

Internet-Draft       AS2 Specification Modernization        October 2025


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.  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



Petta                     Expires 18 April 2026                 [Page 8]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

   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 [RFC3851] / [RFC3852] "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.



Petta                     Expires 18 April 2026                 [Page 9]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

   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.



Petta                     Expires 18 April 2026                [Page 10]

Internet-Draft       AS2 Specification Modernization        October 2025


3.  References RFCs and Their Contributions

3.1.  RFC 2616 HTTP v1.1 [RFC2616]

   This document specifies how data is transferred using HTTP.

3.2.  RFC 1847 MIME Security Multiparts [RFC1847]

   This document defines security multipart for MIME: multipart/
   encrypted and multipart/signed.

3.3.  RFC 3462 Multipart/Report [RFC3462]

   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 [RFC1767]

   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 [RFC2045], [RFC2046], and [RFC2049]

   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 [RFC3798]

   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) [RFC3851] / [RFC3852]

   This specification describes how S/MIME will carry CMS Objects.

3.8.  RFC 3023 XML Media Types [RFC3023]

   This RFC defines the use of content type "application" for XML
   (application/xml).

4.  Structure of an AS2 Message




Petta                     Expires 18 April 2026                [Page 11]

Internet-Draft       AS2 Specification Modernization        October 2025


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 implementations and RFCs are
   mentioned specifically in the sections below.

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 [RFC3335].



Petta                     Expires 18 April 2026                [Page 12]

Internet-Draft       AS2 Specification Modernization        October 2025


   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
            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 ([RFC2616], Section 10.4.2 and elsewhere).

   The request line is followed by entity headers specifying content
   length ([RFC2616], Section 14.14) and content type ([RFC2616],
   Section 14.18).  The Host request header ([RFC2616], Sections 9 and
   14.23) is also included.

   When using Transport Layer Security [RFC2246] 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,
   ([RFC2616] Sections 8.1.2, 8.2, and 19.7.1).  A number of other
   differences exist because HTTP does not conform to MIME [RFC2616] as
   used in SMTP transport.  Relevant differences are summarized below.







Petta                     Expires 18 April 2026                [Page 13]

Internet-Draft       AS2 Specification Modernization        October 2025


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 [RFC2616].  This difference is
   discussed in [RFC2616], 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.

5.2.2.  Message Bodies

   In [RFC2616], Section 3.7.2, it is explicitly noted that multiparts
   MUST have null epilogues.

   In [RFC3335], 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 [RFC2616], Sections
   3.5 and 3.6 discuss some options for compressing or chunking entities
   to be transferred.  In [RFC2616], 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
   [RFC2616], 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 [RFC2822]:

         "<" 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).



Petta                     Expires 18 April 2026                [Page 14]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

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 [RFC2616], 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
   [RFC2616], 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 [RFC2616].  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.





Petta                     Expires 18 April 2026                [Page 15]

Internet-Draft       AS2 Specification Modernization        October 2025


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[RFC3335].

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.









Petta                     Expires 18 April 2026                [Page 16]

Internet-Draft       AS2 Specification Modernization        October 2025


     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 [RFC2234].

   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.




Petta                     Expires 18 April 2026                [Page 17]

Internet-Draft       AS2 Specification Modernization        October 2025


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.

   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:






Petta                     Expires 18 April 2026                [Page 18]

Internet-Draft       AS2 Specification Modernization        October 2025


     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.

   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.




Petta                     Expires 18 April 2026                [Page 19]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

   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.




Petta                     Expires 18 April 2026                [Page 20]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

   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 [RFC3335].






Petta                     Expires 18 April 2026                [Page 21]

Internet-Draft       AS2 Specification Modernization        October 2025


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 [RFC3335]
   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

   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.



Petta                     Expires 18 April 2026                [Page 22]

Internet-Draft       AS2 Specification Modernization        October 2025


   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
   [RFC3335].

   Finally, the header, Disposition-notification-options, identifies
   characteristics of message disposition notification as in [RFC3798].
   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:














Petta                     Expires 18 April 2026                [Page 23]

Internet-Draft       AS2 Specification Modernization        October 2025


       Disposition-notification-options =
                "Disposition-Notification-Options" ":"
                 disposition-notification-parameters
   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        sha-1 or 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.







Petta                     Expires 18 April 2026                [Page 24]

Internet-Draft       AS2 Specification Modernization        October 2025


       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".

   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.






Petta                     Expires 18 April 2026                [Page 25]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

   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).







Petta                     Expires 18 April 2026                [Page 26]

Internet-Draft       AS2 Specification Modernization        October 2025


7.4.  MDN Format and Values

   This section defines the format of the AS2 Message Disposition
   Notification (AS2-MDN).

7.4.1.  AS2-MDN General Formats

   The AS2-MDN follows the MDN specification [RFC3798] 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 [RFC2616].  HTTP
   entities referred to below are not further defined in this document.
   Refer to RFC 2616 [RFC2616] 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





Petta                     Expires 18 April 2026                [Page 27]

Internet-Draft       AS2 Specification Modernization        October 2025


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
   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 [RFC3798], 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



Petta                     Expires 18 April 2026                [Page 28]

Internet-Draft       AS2 Specification Modernization        October 2025


   RFC 3798, Section 7, "Collected Grammar", for the original grammar.

   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 ) )









Petta                     Expires 18 April 2026                [Page 29]

Internet-Draft       AS2 Specification Modernization        October 2025


   digest-alg-id = "sha-1" |
   "sha1" |
   "md5"
   ; The "sha1" is a legacy spelling of the "sha-1" defined hash in the
   IANA Textual Names Registry ; It should be maintained for backwards
   compatibility

   "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.

   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.




Petta                     Expires 18 April 2026                [Page 30]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

   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.





Petta                     Expires 18 April 2026                [Page 31]

Internet-Draft       AS2 Specification Modernization        October 2025


   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":

      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.








Petta                     Expires 18 April 2026                [Page 32]

Internet-Draft       AS2 Specification Modernization        October 2025


   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"

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





Petta                     Expires 18 April 2026                [Page 33]

Internet-Draft       AS2 Specification Modernization        October 2025


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
   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.










Petta                     Expires 18 April 2026                [Page 34]

Internet-Draft       AS2 Specification Modernization        October 2025


     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

   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.







Petta                     Expires 18 April 2026                [Page 35]

Internet-Draft       AS2 Specification Modernization        October 2025


  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

  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 ([RFC3798], 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



Petta                     Expires 18 April 2026                [Page 36]

Internet-Draft       AS2 Specification Modernization        October 2025


   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,
   in addition to the mapping between the EDI trading partner ID and the
   RFC 2822 [RFC2822] 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
   [RFC3850].

   The message formats useful for certificate exchange are found in
   [RFC3851] and [RFC3852].

   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.












Petta                     Expires 18 April 2026                [Page 37]

Internet-Draft       AS2 Specification Modernization        October 2025


   Extracted from RFC 3851 [RFC3851]: 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 [RFC3850]: 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 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 [RFC3851], [RFC3852] and [RFC3850].







Petta                     Expires 18 April 2026                [Page 38]

Internet-Draft       AS2 Specification Modernization        October 2025


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.

   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.








Petta                     Expires 18 April 2026                [Page 39]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

   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



Petta                     Expires 18 April 2026                [Page 40]

Internet-Draft       AS2 Specification Modernization        October 2025


   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.

11.  Acknowledgments

   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.  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.

12.1.  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



Petta                     Expires 18 April 2026                [Page 41]

Internet-Draft       AS2 Specification Modernization        October 2025


   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...} <br>

   --as2BouNdary1as2
   Content-Type: application/pkcs7-signature

    {omitted binary pkcs7 signature data}

   --as2BouNdary1as2--

12.2.  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
   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"



Petta                     Expires 18 April 2026                [Page 42]

Internet-Draft       AS2 Specification Modernization        October 2025


   & 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--

   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.








Petta                     Expires 18 April 2026                [Page 43]

Internet-Draft       AS2 Specification Modernization        October 2025


   4.  As specified by RFC 3462 [RFC3462], 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.

12.3.  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:58201/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:58201/exchange/as2_company
   AS2-From: as2_company
   AS2-To: "AS2 Test"
   AS2-Version: 1.1
   Host: 10.240.1.2:58101
   Connection: close
   Content-Length: 3428

    {omitted binary encrypted data}   <br>

12.4.  A.4.  Asynchronous MDN for Message A.3, Above

   POST / HTTP/1.1
   Host: 10.240.1.2:58201
   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:58201/exchange/as2_company
   AS2-To: as2_company
   AS2-From: "AS2 Test"
   Subject: Your Requested MDN Response



Petta                     Expires 18 April 2026                [Page 44]

Internet-Draft       AS2 Specification Modernization        October 2025


   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:58201/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.

   ------=_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=



Petta                     Expires 18 April 2026                [Page 45]

Internet-Draft       AS2 Specification Modernization        October 2025


   ------=_Part_337_6452266.1040310218750-

13.  References

13.1.  Normative References

   [RFC1767]  Crocker, D., "MIME Encapsulation of EDI Objects",
              RFC 1767, DOI 10.17487/RFC1767, March 1995,
              <https://www.rfc-editor.org/rfc/rfc1767>.

   [RFC1847]  Galvin, J., Murphy, S., Crocker, S., and N. Freed,
              "Security Multiparts for MIME: Multipart/Signed and
              Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847,
              October 1995, <https://www.rfc-editor.org/rfc/rfc1847>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/rfc/rfc2026>.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
              <https://www.rfc-editor.org/rfc/rfc2045>.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/rfc/rfc2046>.

   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Five: Conformance Criteria and
              Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
              <https://www.rfc-editor.org/rfc/rfc2049>.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
              November 1997, <https://www.rfc-editor.org/rfc/rfc2234>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616,
              DOI 10.17487/RFC2616, June 1999,
              <https://www.rfc-editor.org/rfc/rfc2616>.

   [RFC2822]  Resnick, P., Ed., "Internet Message Format", RFC 2822,
              DOI 10.17487/RFC2822, April 2001,
              <https://www.rfc-editor.org/rfc/rfc2822>.




Petta                     Expires 18 April 2026                [Page 46]

Internet-Draft       AS2 Specification Modernization        October 2025


   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,
              <https://www.rfc-editor.org/rfc/rfc3023>.

   [RFC3335]  Harding, T., Drummond, R., and C. Shih, "MIME-based Secure
              Peer-to-Peer Business Data Interchange over the Internet",
              RFC 3335, DOI 10.17487/RFC3335, September 2002,
              <https://www.rfc-editor.org/rfc/rfc3335>.

   [RFC3462]  Vaudreuil, G., "The Multipart/Report Content Type for the
              Reporting of Mail System Administrative Messages",
              RFC 3462, DOI 10.17487/RFC3462, January 2003,
              <https://www.rfc-editor.org/rfc/rfc3462>.

   [RFC3798]  Hansen, T., Ed. and G. Vaudreuil, Ed., "Message
              Disposition Notification", RFC 3798, DOI 10.17487/RFC3798,
              May 2004, <https://www.rfc-editor.org/rfc/rfc3798>.

   [RFC3850]  Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Certificate Handling",
              RFC 3850, DOI 10.17487/RFC3850, July 2004,
              <https://www.rfc-editor.org/rfc/rfc3850>.

   [RFC3851]  Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, DOI 10.17487/RFC3851, July 2004,
              <https://www.rfc-editor.org/rfc/rfc3851>.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, DOI 10.17487/RFC3852, July 2004,
              <https://www.rfc-editor.org/rfc/rfc3852>.

13.2.  Informative References

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, DOI 10.17487/RFC2246, January 1999,
              <https://www.rfc-editor.org/rfc/rfc2246>.

Author's Address

   Debra Petta
   Drummond Group, LLC
   Email: IETF-Activity@drummondgroup.com








Petta                     Expires 18 April 2026                [Page 47]
