AS2 Specification Modernization

1.1. Applicable RFCs

Previous work on Internet EDI focused on specifying MIME content types for EDI data [RFC1767]. 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 recognizes contemporary RFCs and avoids re-inventing mechanisms wherever possible. Although this document focuses on EDI data, any other data types describable in a MIME format are also supported.¶

Internet MIME-based EDI can be accomplished by using and complying with the following RFCs:¶

 o  RFC 2616 Hyper Text Transfer Protocol (baseline: HTTP/1.1)
 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 8098 Message Disposition Notification (updates RFC 3798)
 o  RFC 3851, 3852 S/MIME v3.1 Specification
 o  RFC 8551 S/MIME v4.0 (updated algorithm requirements including AES,
    AES-GCM, AES-CCM)

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. Implementers should note that HTTP/2 and HTTP/3 MAY be used as transports, but are not required for interoperability.¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Backward Compatibility and Interoperability

A central design principle of this specification is "backward compatibility" with RFC 4130 and with the underlying RFCs it references. This specification does not redefine or override backward-compatibility rules established in those RFCs. Implementations MUST rely on the mechanisms provided in underlying standards.¶

Consistent with the Robustness Principle ("be conservative in what you send and liberal in what you receive"), this document clarifies requirements and aligns terminology but does not introduce breaking changes. Implementations that conformed to RFC 4130 remain conformant to this specification. Any deviations are limited to clarifications intended to improve interoperability.¶

Implementations MAY interoperate using S/MIME Version 3.1 RFC3851 [RFC3852] with legacy trading partners, but conformant implementations MUST also support S/MIME Version 4.0 [RFC8551] to meet the algorithm requirements of this specification and ensure forward compatibility. These provisions ensure smooth migration for existing deployments while establishing RFC 8551 as the baseline for new implementations.¶

This specification defines requirements for modern AS2 deployments using contemporary cryptographic algorithms. It does not redefine or extend the use of weak algorithms such as 3DES or SHA-1. When both partners support this version of AS2, only modern algorithms are in scope.¶

When interoperability with RFC 4130 systems is required, implementers SHOULD apply the clarifications provided in Appendix B (Legacy Interoperability). Appendix B is non-normative and does not alter the algorithm requirements defined in Section 7, but records expected behavior when communicating with legacy systems.¶

1.3. Rationale

The updates in this specification reflect community consensus to:¶

 o  Preserve backward compatibility with RFC 4130 and the underlying
    RFCs it references.
 o  Provide explicit guidance on which protocol versions form the
    interoperability baseline for certification and testing.
 o  Incorporate de facto updates already widely deployed (e.g., RFC 8098
    for MDNs, migration from SHA-1 to SHA-2 wherever possible).
 o  Document stronger security requirements while allowing
    backward-compatible fallback to enable phased adoption.
 o  Avoid unnecessary disruption by permitting, but not requiring,
    newer transport features such as HTTP/2, and by clarifying rather
    than redefining MDN behavior.

This approach reduces ambiguity, simplifies certification, and ensures interoperability across implementations.¶

1.4. Terms

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

   EDI:     Electronic Data Interchange

   EC:      Electronic Commerce (often referred to as Business to Business, B2B).

   B2B:     Business to Business

   Receipt: The functional message that is sent from a receiver to a
            sender to acknowledge that an EDI/EC interchange has been
            received. 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 over the same
            TCP/IP connection as the sender's original message.

   Asynchronous Receipt: A receipt returned to the sender over a different
            TCP/IP connection than the sender's original message.

   Message Disposition Notification (MDN): The Internet messaging format
            used to convey a receipt. This term is used interchangeably
            with receipt. An MDN is a receipt.

   Non-repudiation of receipt (NRR): A "legal event" that occurs when
            the original sender of an signed EDI/EC interchange has
            verified the signed receipt coming back from the receiver.
            The receipt contains data identifying the original message
            for which it is a receipt, including the message-ID and a
            cryptographic hash (MIC). The original sender must retain
            suitable records providing evidence concerning the message
            content, its message-ID, and its hash value. The original
            sender verifies that the retained hash value is the same as
            the digest of the original message, as reported in the
            signed receipt. NRR is not considered a technical message,
            but instead is thought of as an outcome of possessing
            relevant evidence.

   S/MIME:  A format and protocol for adding cryptographic signature
            and/or encryption services to Internet MIME messages.

   Cryptographic Message Syntax (CMS): An encapsulation syntax used to
            digitally sign, digest, authenticate, or encrypt arbitrary
            messages.

   SHA-1:   A secure, one-way hash algorithm used in conjunction with
            digital signature. This algorithm is retained for backward
            compatibility but is deprecated in this specification.
            Implementations MUST support SHA-256 or stronger where possible,
            and SHOULD prefer these algorithms in production environments
            unless legacy partners cannot yet migrate to SHA-256 or stronger.

   MD5:     A secure, one-way hash algorithm used in conjunction with
            digital signature. This algorithm is obsolete and MUST NOT be generated
            by conformant implementations.

   MIC:     The Message Integrity Check (MIC) is a cryptographic method used
            to verify that a message has not been altered or tampered with during
            transmission or storage, ensuring the data is trustworthy and complete.
            It works by generating a unique hash value from the message's contents,
            which is then transmitted with the message. The recipient recalculates
            the hash on the received message and compares it to the provided MIC;
            if they don't match, the message is discarded, indicating it was modified.

   User Agent (UA): The application that handles and processes the AS2 request.

2.1. Overall Operation

An HTTP POST operation [RFC2616] is used to send appropriately packaged EDI, XML, or other business data. The Request-URI ([RFC2616], Section 10.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. HTTPS is RECOMMENDED as the default transport for new implementations (see Section 10.1).¶

The security protocols and structures used also support auditable records of these document data transmissions, acknowledgements, and authentication.¶

The message formats and processing requirements described below maintain strict backward compatibility (see Section 1.2).¶

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 not limited to strict EDI use; it applies to any electronic commerce application for which business data needs to be exchanged securely over the Internet.¶

2.3. Definitions

  o  The organization sending EDI/EC data signs, encrypts and compresses
     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 decompresses and 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.

2.4. Assumptions

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

3.9. RFC 3274 Compressed Data Content Type for Cryptographic Message Syntax (CMS) [RFC3274]

This RFC defines a mechanism for compressing data within the Cryptographic Message Syntax (CMS), which is the foundation for Secure/Multipurpose Internet Mail Extensions (S/MIME). It specifies a CompressedData content type that allows data to be compressed prior to being signed or encrypted. This reduces the size of transmitted messages and improves efficiency without altering the security services provided by signing or encryption. AS2-Version 1.1 incorporated the compression capability described in RFC 3274, enabling trading partners to optionally apply compression to message payloads before signing and/or encrypting. Most modern AS2 implementations support this feature to reduce bandwidth usage and improve transmission performance, particularly for large payloads.¶

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 on how to code in compliance with all RFCs involved, refer to the specific RFCs. 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, no compression
      - RFC2616/2045
        - RFC1767/RFC3023 (application/EDIxxxx or /xml)

   No encryption, signature, no compression
      - RFC2616/2045
        - RFC1847 (multipart/signed)
          - RFC1767/RFC3023 (application/EDIxxxx or /xml)
          - RFC3851 (application/pkcs7-signature)

   Encryption, no signature, no compression
      - RFC2616/2045
        - RFC3851 (application/pkcs7-mime)
          - RFC1767/RFC3023  (application/EDIxxxx or /xml) (encrypted)

   Encryption, signature, no compression
      - RFC2616/2045
        - RFC3851 (application/pkcs7-mime)
          - RFC1847 (multipart/signed)(encrypted)
            - RFC1767/RFC3023  (application/EDIxxxx or /xml) (encrypted)
            - RFC3851 (application/pkcs7-signature)(encrypted)

   No encryption, no signature (with optional compression)
      - RFC2616/2045
        - RFC3274 (application/pkcs7-mime; CompressedData) [optional]
          - RFC1767/RFC3023 (application/EDIxxxx or /xml)

   No encryption, signature (compression may occur before or after signing)
      - RFC2616/2045
        - [optional RFC3274 (CompressedData) if compress-before-sign]
          - RFC1847 (multipart/signed)
            - [optional RFC3274 (CompressedData) if compress-after-sign]
              - RFC1767/RFC3023 (application/EDIxxxx or /xml)
              - RFC3851 (application/pkcs7-signature)

   Encryption, no signature (with optional compression)
       - RFC2616/2045
         - RFC3851 (application/pkcs7-mime)
           - [optional RFC3274 (CompressedData)]
             - RFC1767/RFC3023 (application/EDIxxxx or /xml) (encrypted)

   Encryption, signature (compression may occur before or after signing)
      - RFC2616/2045
        - RFC3851 (application/pkcs7-mime)
          - [optional RFC3274 (CompressedData) if compress-before-sign]
            - RFC1847 (multipart/signed) (encrypted)
              - [optional RFC3274 (CompressedData) if compress-after-sign]
              - 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)

Key Notes¶

o RFC 3274 (CompressedData) is the normative reference for compression.¶

o Compression MAY be combined with signing and/or encryption in either order, but the choice affects what the digital signature covers.¶

o Many implementations compress before signing and encrypting to maximize size reduction, but compression after signing and before encrypting MUST also be supported.¶

o 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.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 (TLS), the request-URI MUST indicate the appropriate scheme value, HTTPS. Implementations MUST support TLS 1.2 or higher and SHOULD follow the guidance in Section 10.1. Encrypted message bodies MAY be used in addition to TLS when required by business policy.¶

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

5.2. Unused MIME Headers and Operations

5.3. Modification of MIME or Other Headers or Parameters Used

      "<" id-left "@" id-right ">"

5.4. HTTP Response Status Codes

Implementations MUST use standard HTTP response codes to signal the outcome of the message transfer. The meaning of the HTTP status code is limited to the success or failure of the transport operation itself, not the semantic processing of the AS2 message content. 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.¶

Receiving implementations MAY send an interim 102 (Processing) response [RFC4918] under HTTP/1.1 to indicate that the inbound message has been fully received and that processing is underway. The 102 response can help prevent sender-side network timeouts for large synchronous transfers by signaling progress while decryption, signature verification, or storage continues.¶

Use of 102 (Processing) is OPTIONAL. It has been deprecated in later HTTP specifications and MUST NOT be used with HTTP/2 or HTTP/3, where interim responses have different semantics. Implementations Implementations that do not receive a 102 response MUST NOT assume that a failure has occurred solely because no interim status was returned. They SHOULD continue waiting for the final status response for at least the duration of their configured HTTP read timeout or any timeout agreed upon between trading partners.¶

To minimize the risk of network timeouts during lengthy message processing, receivers SHOULD return an appropriate transfer-layer response as quickly as possible after receiving the full message content. For asynchronous message exchanges, the preferred response is 204 No Content, which indicates that the message has been received successfully and that an asynchronous MDN will follow once processing has completed. This convention is maintained for interoperability with existing AS2 products and certification profiles.¶

Some implementations MAY instead use 202 Accepted to indicate successful receipt and deferred processing; however, 204 No Content remains the recommended and most widely deployed response for asynchronous workflows.¶

Implementations MAY close the connection immediately after sending this response if persistent connections are not required by configuration.¶

After processing completes, the receiver MUST return a final HTTP status code indicating the success or failure of the message transfer. The sender MUST use this final response to determine whether retry is appropriate.¶

Retry MUST NOT be attempted when:¶

 o the final HTTP response indicates successful receipt (e.g., `200 OK` or
   `204 No Content` for asynchronous transfers, or `202 Accepted` for
   implementations that use deferred processing semantics) **and** a
   valid MDN has been received confirming the message disposition; or
 o a permanent-failure status code is returned (4xx other than 408), or

Retry MAY be attempted when:¶

 o the HTTP connection fails before the final status is received,
 o a transient error such as 408 (Request Timeout) or 5xx (Server Error)
   occurs, or
 o no response is received within the configured timeout.

Implementations SHOULD refer to Section 5.5 for additional guidance on retry logic, back-off behavior, and use of partial-transfer recovery. The 102 (Processing) status code, if used, MUST NOT be treated as a trigger for retry.¶

5.5. HTTP Error Recovery and Reliability

When an AS2 message transfer fails due to a transient transport-layer condition (for example, an HTTP 408 Request Timeout, 425 Too Early, 500 Internal Server Error, 503 Service Unavailable or network interruption before the final response), the sending system SHOULD attempt an automatic retry.¶

Each retry attempt MUST reuse the same Message-ID value so that the receiving system can identify duplicate transmissions and prevent double-processing. A receiving system detecting a duplicate Message-ID MUST NOT treat the message as new and SHOULD return the previously generated MDN, if available.¶

Implementations SHOULD permit configuration of retry behavior rather than enforcing fixed intervals or limits. The following guidelines are RECOMMENDED but not required:¶

 o **Retry intervals** SHOULD increase exponentially (e.g., 5 min,
   10 min, 20 min, 40 min, …) to reduce congestion.
 o **Retry duration** SHOULD be configurable based on business
   requirements; some environments may continue for several days, while
   others may terminate after one or two attempts.
 o **Maximum attempts** SHOULD be limited to prevent indefinite
   retries when persistent errors occur.

Implementations SHOULD NOT retry when:¶

 o A final 2xx response and/or valid MDN has been received;
 o The HTTP response indicates a permanent failure (e.g., 400, 401,
   403, 404);
 o The partner has explicitly rejected the message by sending a signed
   MDN with a "failed" disposition.

The HTTP 102 (Processing) interim status MAY be used under HTTP/1.1 to indicate progress on long-running synchronous operations. It MUST NOT be used as a signal to initiate or suppress retries. Implementations MUST ignore 102 responses when determining whether a retry is required. The 102 response MUST NOT be used with HTTP/2 or HTTP/3.¶

Implementations MAY also support AS2 Restart, which allows a partially uploaded message to resume from the point of interruption rather than retransmitting the entire payload. This optional feature is defined in [I-D.draft-harding-as2-restart-02]. Implementations supporting Restart MUST ensure message integrity through signature or checksum validation of all resumed segments.¶

Additional guidance for retry management, error classification, and duplicate detection is described in [I-D.draft-duker-as2-reliability-16]. While both of these drafts are expired, they remain widely referenced in AS2 interoperability testing and provide a useful operational baseline for error-recovery behavior.¶

The objective of error recovery is reliability, not speed. Systems SHOULD favor successful delivery over strict timing, provided that duplicate protection and security requirements are preserved.¶

6.1. AS2 Version Header

To promote backward compatibility, AS2 includes a version header. The major version digit indicates wire-level compatibility; minor version digits designate feature sets, clarifications, or extensions that remain compatible within the same major version. Thus, all values in the "1.x" range are compatible with AS2-Version 1.0, while a future "2.0" would indicate a non-backward-compatible revision.¶

Receiving systems MUST NOT fail due to the absence of the AS2-Version header. Its absence MUST be assumed to be equivalent to the default AS2-Version value of 1.0.¶

   AS2-Version: 1.0  - All implementations of this specification MUST support and
                       advertise "AS2-Version: 1.0". Versions in the range "1.0"
                       through "1.9" MAY be used. All implementations MUST interpret
                       any value in that range as conforming to this specification,
                       with no differences in baseline behavior. In other words, only
                       the major version digit ("1") defines compatibility for implementations
                       that do not support additional, non-AS2-specified functionality.

                       Implementations MAY use "1.1" through "1.9" to signal extensions of
                       this specification. Any such extensions MUST be fully transparent to
                       implementations that recognize only "AS2-Version: 1.0".

   AS2-Version: 1.1  - Designates those implementations that MUST support compression as
                       defined by RFC 3274.

   AS2-Version: 1.2  - Indicates those implementations that include an EDIINT-Features header
                       as defined in RFC 6017. The values in an EDIINT-Features header specify
                       the features supported by the AS2 implementation. Examples may include
                       CEM, AS2-Reliability and multiple-attachments, however others may also be included.
                       A receiving implementation MUST NOT fail if it does not support or understand
                       any of the supported values contained within an EDIINT-Features header.

   AS2-Version: 1.3  - Indicates those implementations that support the modernization defined
                       by this specification, including updated algorithm requirements (e.g.,
                       SHA-256 for MIC/signatures; AES as the encryption baseline per [RFC8551]),
                       alignment with MDN handling as specified in [RFC8098], and support for
                       multiple-recipient encryption as described in [Section 7.2](#encryption-algorithms){:format="none"}
                       of this specification.

                       When both partners are configured for AS2 version 1.3, weak algorithms (e.g., SHA-1,
                       3DES, RC2, MD5) MUST NOT be generated by conformant implementations. When interoperating
                       with a legacy partner that operates at AS2 version 1.2 or lower, implementations MAY apply
                       the legacy interoperability clarifications described in Appendix B (non-normative).

                       Future minor versions (1.x) may designate additional extensions or clarifications
                       that remain backward-compatible with AS2 version 1.0. A major version update
                       (2.0 or higher) would indicate a non-backward-compatible revision.

6.2. AS2 Product header

The AS2-Product header value identifies the AS2 product and version used by the sender. This information enables interoperability testing, certification, and troubleshooting by allowing trading partners to detect known product-specific behaviors or version-related quirks.¶

The AS2-Product header value is OPTIONAL for AS2-Version 1.x systems but MUST be included in messages generated by implementations declaring AS2-Version: 1.3 or 2.0 (or later).¶

The header field value MUST follow the format:¶

     * <product-name>: lowercase alphanumeric and hyphen characters (a–z,
        0–9, "-") without spaces.
     * <major.minor[.patch]>: version string consistent with the product’s
        release version, with one or more numeric components separated by dots.

   Examples:

      AS2-Product: biztalk:2025.1
      AS2-Product: drummond-connect:4.2.3

Implementations MUST NOT use arbitrary identifiers or vendor aliases that do not reflect the actual product in use. The value is static and determined at build time. If a product supports multiple AS2 variants, the version portion MAY include an implementation-specific suffix (e.g., "1.2-drummond").¶

Implementations MAY use the AS2-Product value for automated interoperability tuning or to apply compatibility workarounds for known product versions. However, this field is not intended for feature-negotiation purposes; supported feature tokens belong in the EDIINT-Features header.¶

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

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

 o  MUST each be an AS2-name,
 o  MUST each be comprised of from 1 to 128 printable ASCII characters, and
 o  MUST NOT be folded
 o  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. This explicitly includes situations where embedded spaces are part of the AS2-name.¶

The AS2-To and AS2-From header fields MUST be present in all AS2 messages and AS2 MDNs whether they are synchronous or asynchronous in nature.¶

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, such as an MDN error disposition value of "unknown-trading-relationship", if the sending system requested an MDN.¶

7.1. Hash Algorithms

Implementations MUST support SHA-256 for message integrity check (MIC) calculations and digital signatures. Implementations SHOULD support SHA-384 or stronger algorithms. SHA-1 and MD5 are deprecated due to known weaknesses and MUST NOT be generated by conformant implementations.¶

See Appendix B for clarifications on handling legacy algorithms when interoperating with RFC 4130 systems.¶

7.2. Encryption Algorithms

Implementations MUST support AES encryption algorithms as defined in S/MIME Version 4.0 [RFC8551]. At a minimum, AES-128-CBC MUST be supported, and AES-256-CBC SHOULD be supported. Implementations are also RECOMMENDED to support AES-128-GCM and AES-256-GCM. Support for AES-CCM is also RECOMMENDED for environments requiring authenticated encryption.¶

Triple DES (3DES) and RC2 are deprecated and MUST NOT be generated by conformant implementations.¶

To support recoverable decryption and regulatory requirements, implementations SHOULD support multiple-recipient encryption of the content-encryption key (CEK), consistent with [RFC8551] Section 3.3. A copy of the CEK encrypted for the originator SHOULD also be included in the EnvelopedData, and the same principle applies to AuthEnvelopedData when using AES-CCM or AES-GCM.¶

See Appendix B for guidance on handling 3DES and other weak algorithms when interoperating with legacy AS2 systems.¶

8.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 requirements in this section update but do not alter the compatibility of MDN formats with existing AS2 implementations (see Section 1.2). This ensures interoperability with both RFC 3798 and RFC 8098 implementations.¶

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

  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/pkcs7-signature"

  8. The signature information is formatted according to S/MIME
     specifications.

The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a 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 contained within the multi-part MIME content.¶

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.

8.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 synchronous response MUST indicate transfer-layer success or failure, such as 200 OK or 202 Accepted. The format of this response MAY be identical to that used when no AS2-MDN is requested.¶

The asynchronous AS2-MDN is sent on a separate HTTP or HTTPS 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 receiving system SHOULD return a transfer-layer response (typically 202 Accepted or 204 No Content) as soon as the last byte of the inbound message has been received, without waiting for decryption, signature verification, or message persistence. This minimizes the risk of network timeouts and ensures that the sender can begin awaiting the asynchronous MDN promptly. The asynchronous MDN MUST be transmitted as an independent HTTP message, separate from the original connection used to submit the AS2 message.¶

Implementations MAY use persistent (keep-alive) HTTP connections. Closing the TCP connection immediately after sending the response is RECOMMENDED for simplicity, but not required. Some application servers and frameworks manage connection lifecycles automatically and may keep the socket open. The AS2 specification does not mandate that the AS2 layer explicitly close the connection.¶

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 (e.g., "200 OK" or "204 No Content")
   {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 also utilize a transfer protocol different from that used to send the original AS2 message.¶

The advantage of the synchronous MDN is that it provides the sender of the AS2 message with a verifiable confirmation of delivery within a single synchronous logic flow. However, if the message is large, the time required to process it and return the AS2-MDN on the same connection may exceed the maximum configured time permitted for maintaining an open connection.¶

The advantage of the asynchronous MDN is that it provides for the rapid return of a transfer-layer acknowledgment from the receiver, confirming receipt of data, while allowing full processing to occur later. This reduces connection duration and timeout risk. However, the asynchronous AS2-MDN MUST include sufficient identifying information (for example, Original-Message-ID and Final-Recipient) so that the message originator can correlate the MDN with its original message and update the processing status accordingly.¶

Synchronous and asynchronous HTTP or HTTPS MDNs are both valid under this specification. Implementations MUST support receiving both types and SHOULD support sending both.¶

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

The "Disposition-notification-to" header field is retained for compatibility with the MDN specification [RFC3798], but its value is not used by AS2 implementations to determine where to return the MDN. Its presence just indicates that an MDN receipt is to be returned to the originator. In AS2, the field value may be an email address, a URL, a fully qualified domain name, an AS2 identifier, or any other implementation-specific string. Implementations MUST NOT reject a message based on the syntax of this field. This document relaxes the original requirement from RFC 4130, which mandated an email address, in order to reflect current AS2 practice while maintaining backward compatibility (see Section 1.2).¶

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

This is an example requesting that the MDN be asynchronous:¶

    Receipt-Delivery-Option: http://www.example.com/Path

Receipt-delivery-option syntax allows the return-url to use some schemes other than HTTP using the POST method.¶

The "receipt-delivery-option: return-url" string indicates the URL to use for an asynchronous MDN. This header is NOT present if the receipt is to be synchronous. The email value in Disposition- notification-to is not used in this specification because it was limited to RFC 2822 addresses (now replaced by [RFC5322]); 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

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,sha-256,sha1

For signing options, consider the disposition-notification-options syntax:¶

    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-256      sha-256
     SHA-384      sha-384
     SHA-512      sha-512
     SHA-1        sha-1 or sha1 (should *only* be used in legacy deployments that
                                 cannot support SHA-256 or greater)

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 identifies one or more message integrity check (MIC) algorithms, in order of preference, that the requester supports for signing the returned receipt. Although multiple values MAY be listed to indicate fallback options, only a single MIC algorithm is used in the returned MDN because the "Received-content-MIC" field conveys exactly one digest value.¶

   Recipients MUST select the first algorithm in the list that they also support and MUST compute the Received-content-MIC using that algorithm. Senders SHOULD list the strongest algorithm first. Modern implementations SHOULD include only a single value unless multiple values are needed to support phased migration away from weaker algorithms. Implementations MUST accept messages that contain multiple values and MUST ignore unsupported values.¶

   When a sender lists multiple algorithms, recipients MUST NOT fall back to an algorithm that is not explicitly listed by the sender. Trading partners typically pre-configure acceptable MIC algorithms through bilateral agreement, and runtime negotiation is not needed. If none of the algorithms listed is supported, the recipient SHOULD reject the message and MAY return an unsigned MDN indicating "unsupported-mic-algorithm" rather than silently selecting a weaker algorithm. When the header is absent (e.g., unsigned messages), an implementation MUST use a locally configured default algorithm; SHA-256 SHOULD be preferred, but SHA-1 MAY be used when required for legacy partners.¶

   The following algorithm requirements apply to all implementations:¶

   o Implementations MUST support SHA-256.¶

   o Implementations SHOULD support SHA-384 or stronger.¶

   o SHA-1 MAY be accepted only when required for interoperability with legacy partners and MUST NOT be generated for new deployments once both parties support stronger algorithms.¶

   o MD5 is obsolete and MUST NOT be generated.¶

   See Section 10 for additional algorithm requirements and deprecation timelines.¶

   Both the "signed-receipt-protocol" and the "signed-receipt-micalg" option parameters are REQUIRED when requesting a signed receipt.¶

   The lack of the presence of the "Receipt-Delivery-Option" indicates that a receipt is synchronous in nature. The presence of the "Receipt-Delivery-Option: return-url" indicates that an asynchronous receipt is requested and SHOULD be sent to the "return-url".¶

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 8.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 be considered invalid.¶

  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 outer MIME or any other RFC
     5322 headers, since these may sometimes be altered or reordered by
     intermediary user agents or proxies.

8.4. MDN Format and Values

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

AS2-MDN = AS2-sync-MDN | AS2-async-http-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-MDN-body =
   AS2-signed-MDN-body | AS2-unsigned-MDN-body

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

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: duplicate-filename" |
    "error: illegal-filename" |
    "error: insufficient-message-security" |
    "error: integrity-check-failed" |
    "error: invalid-message-id" |
    "error: unexpected-processing-error" |
    "error: unknown-trading-relationship" |
    "warning: " AS2-MDN-warning-description |
    "failure: " AS2-MDN-failure-description

AS2-MDN-warning-description = *( TEXT )

AS2-MDN-failure-description = *( TEXT )

AS2-received-content-MIC-field =
    "Received-content-MIC" ":" encoded-message-digest ","
    digest-alg-id CRLF

encoded-message-digest =
    1*( 'A'-'Z' | 'a'-'z' | '0'-'9' | '/' | '+' | '=' )
    ; i.e., base64(message-digest)

digest-alg-id = "sha-256" | "sha-384" | "sha-512" | "sha-1" | "sha1"
                 ; 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
                 ; sha1 | sha-1 should only be used by legacy deployments that cannot support sha-256 or greater

8.5. Disposition Mode, Type, and Modifier

   Disposition: automatic-action/MDN-sent-automatically; processed

   Disposition: "disposition-mode";  failed/Failure: unsupported format

   "Failure: unsupported format"
   "Failure: unsupported MIC-algorithms"

   o "Error: authentication-failed"         - the receiver could not
                                              authenticate the sender.

   o "Error: decompression-failed"          - the receiver could not
                                              decompress the message
                                              contents.

   o "Error: decryption-failed"             - the receiver could not
                                              decrypt the message
                                              contents.
   o "Error: duplicate-filename"            - the message payload contained
                                              a filename already received
                                              by the backend server.

   o "Error: illegal-filename"              - the message payload contained
                                              a filename that could nor be
                                              processed by the backend server.

   o "Error: insufficient-message-security" - the content of the message
                                              was not appropriately enveloped
                                              according to the agreed-upon
                                              message security.

   o "Error: integrity-check-failed"        - the receiver could not
                                              verify content integrity.

   o "Error: invalid-message-id"            - the receiver could not
                                              parse the value of the
                                              Message-ID header because it
                                              was not syntactically correct.

   o "Error: unexpected-processing-error"   - a catch-all for any
                                              additional processing
                                              errors.

   o "Error: unknown-trading-relationship"   - the receiver could not
                                              correlate the AS2-To/AS2-From
                                              header values to values known
                                              to the system.

   Disposition: "disposition-mode"; processed/Error: decryption-failed

   "Warning: authentication-failed, processing continued"

   Disposition: "disposition-mode"; processed/Warning:
     authentication-failed, processing continued

  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

  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.

  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

8.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 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, follow the same semantics as those defined in [RFC3798]. 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 portion) 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 portion). Also, an MDN SHOULD have its own unique Message-ID HTTP header. The HTTP reply SHOULD normally omit the third optional part of the multipart/report (this was historically used to return the original message or its headers within the SMTP context).¶

9.1. Certificate Roles and Requirements

While TLS certificates and AS2 message-signing certificates both use the X.509 standard, they serve distinct purposes and MUST be managed separately:¶

• TLS Certificates are used solely to secure the HTTPS transport channel. They establish session-level confidentiality and integrity and SHOULD be issued by a trusted certification authority (CA) in production environments. Self-signed TLS certificates MAY be used for testing or by explicit agreement between trading partners, provided they include a Subject Alternative Name (SAN) extension containing the hostname and/or IP address. The SAN extension MUST be marked as non-critical.¶

• AS2 Certificates are used for signing and encrypting AS2 messages and SHOULD NOT be the same as the TLS certificate. Separation ensures that a compromise of the transport layer does not affect message-level security. AS2 certificates MAY be CA-issued or self-signed, depending on organizational policy and trading-partner agreements.¶

AS2 certificates MUST use a key length of at least 2048 bits for RSA keys. For elliptic-curve certificates, the selected curve MUST provide equivalent or stronger security (e.g., P-256 or higher).¶

Although short certificate lifetimes are now common in the TLS ecosystem due to CA/Browser Forum requirements and industry regulations, AS2 certificates generally do not require the same frequency of renewal. AS2 systems handle far fewer encrypted transactions than high-volume web servers, and certificate rollover can be operationally complex. Implementations SHOULD allow independent lifetime policies for AS2 and TLS certificates.¶

9.2. Certificate Exchange and Renewal

Automated certificate management significantly reduces operational risk. Implementations SHOULD support Certificate Exchange Messaging (CEM) [RFC6017] to enable secure, automated exchange of AS2 certificates between trading partners. When CEM is not available, manual exchange processes MUST ensure integrity and authentication of keys prior to activation.¶

The AS2 GET method MAY be used for initial retrieval of partner certificates if protected by appropriate authentication (for example, Basic Authentication). Implementations using AS2 GET MUST ensure that certificate delivery is integrity-protected and that access is restricted to authorized partners.¶

9.3. Operational Guidance

• TLS and AS2 certificates MUST be managed separately.¶

• CEM SHOULD be supported to reduce manual errors and configuration drift.¶

• Self-signed certificates SHOULD include SAN extensions for clarity and validation consistency.¶

• Implementations SHOULD support configurable expiration and notification mechanisms for certificate renewal.¶

• Administrators SHOULD avoid reusing TLS certificates as AS2 certificates, even when technically possible.¶

For security and algorithm lifecycle considerations, see Section 7 (Section 7) and Section 10 (Section 10).¶

10.1. HTTPS and TLS Requirements

Consensus Update: Implementations MUST support TLS 1.2 or higher and SHOULD support TLS 1.3. TLS 1.3 is strongly encouraged as the default where platform support allows, but TLS 1.2 remains the mandatory baseline to ensure interoperability with older environments (e.g., legacy JVMs). Products SHOULD allow administrators to configure which TLS versions are enabled, so that TLS 1.3 can be mandated by policy where required. Future revisions of this specification are expected to mandate TLS 1.3 as the minimum required version once deployment is widespread.¶

Administrators SHOULD use only cipher suites listed as “Recommended (Y)” in the IANA TLS Parameters registry. Implementations SHOULD provide configurable cipher selection rather than hardcoding cipher lists.¶

New implementations of AS2 SHOULD use HTTPS as the default transport protocol to provide confidentiality and integrity in transit. Plain HTTP remains permitted to support message-level encryption and backward compatibility with existing deployments.¶

This guidance promotes strong encryption, aligns with current best practices, and ensures that AS2 remains interoperable with existing deployments while allowing administrators to phase out weaker protocols and cipher suites over time.¶

Future Considerations Per BCP 195/RFC 7525bis, new IETF protocols and major revisions are expected to mandate TLS 1.3. AS2-bis is a backward-compatible revision, and therefore specifies MUST support of TLS 1.2 and SHOULD support of TLS 1.3 to preserve interoperability with existing implementations. At the same time, implementers are strongly encouraged to deploy TLS 1.3 as the default for all new products and configurations. Future versions of AS2 (for example, a potential AS2-Version 1.3 or subsequent update) are expected to raise the baseline to MUST support TLS 1.3 or higher, and may deprecate TLS 1.2 once widespread deployment makes this feasible. Implementers are encouraged to prepare for a future revision of this specification that will mandate TLS 1.3 as the minimum required version.¶

10.2. TLS Server Certificates

The following certificate types MUST be supported for TLS server 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  issued by a certification authority (CA)

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

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

Because server certificates are exchanged, and also trust is established during the configuration of the trading partner relationship, runtime validation (including hostname matching and certificate path validation) SHOULD be performed unless an out-of-band trust model has been explicitly agreed upon by trading partners. If a self-signed TLS certificate is used, it SHOULD contain a Subject Alternative Name (SAN) extension that includes the hostname and/or IP address of the sender. If included, this certificate extension MUST be marked as non-critical.¶

Note: Although not restricted by this specification, self-signed TLS certificates should be used with great care, especially in production environments.¶

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

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

If TLS is used for transport, the guidance in Section 10.1 applies.¶

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

11.1. Registration

RFC 4130 originally defined 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".¶

This document updates that definition, and IANA is requested to replace RFC 4130 with this document as the reference for the MDN Disposition Modifier Names registry.¶

   Parameter-name:  warning
   Semantics: See [Section 8.4.3](#as2-mdn-fields){:format="none"} and
   [Section 8.5.5](#processing-warnings){:format="none"} in this document.

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

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

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

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

[RFC3274]

Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, DOI 10.17487/RFC3274, June 2002, <https://www.rfc-editor.org/rfc/rfc3274>.

[RFC3280]

Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, DOI 10.17487/RFC3280, April 2002, <https://www.rfc-editor.org/rfc/rfc3280>.

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

[RFC4130]

Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)", RFC 4130, DOI 10.17487/RFC4130, July 2005, <https://www.rfc-editor.org/rfc/rfc4130>.

[RFC5322]

Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/rfc/rfc5322>.

[RFC6017]

Meadors, K., Ed., "Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field", RFC 6017, DOI 10.17487/RFC6017, September 2010, <https://www.rfc-editor.org/rfc/rfc6017>.

[RFC8098]

Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, <https://www.rfc-editor.org/rfc/rfc8098>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8551]

Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.

13.2. Informative References

[I-D.draft-duker-as2-reliability-16]

Duker, J. and dale.moberg@gmail.com, "Operational Reliability for EDIINT AS2", Work in Progress, Internet-Draft, draft-duker-as2-reliability-16, 21 October 2014, <https://datatracker.ietf.org/doc/html/draft-duker-as2-reliability-16>.

[I-D.draft-harding-as2-restart-02]

Harding, T., "AS2 Restart for Very Large Messages", Work in Progress, Internet-Draft, draft-harding-as2-restart-02, 26 January 2011, <https://datatracker.ietf.org/doc/html/draft-harding-as2-restart-02>.

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

[RFC4918]

Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/rfc/rfc4918>.

A.1. Signed Message Requesting a Signed, Synchronous Receipt

   POST /receive HTTP/1.1
   Host: 10.234.160.12:80
   User-Agent: AS2 Company Server
   Date: Wed, 31 Jul 2025 13:34:50 GMT
   AS2-Version: 1.3
   AS2-From: "as2 Name"
   AS2-To: 0123456780000
   Subject: Test Case
   Message-Id: <200207310834482A70BF63@\"~~foo~~\">
   Disposition-Notification-To: mrAS2@example.com
   Disposition-Notification-Options: signed-receipt-protocol=optional,
        pkcs7-signature; signed-receipt-micalg=optional,sha-256
   Content-Type: multipart/signed; boundary="as2BouNdary1as2";
        protocol="application/pkcs7-signature"; micalg=sha-256
   Content-Length: 2464

   --as2BouNdary1as2
   Content-Type: application/edi-x12
   Content-Disposition: attachment; filename=rfc1767.dat

     {ISA ...EDI transaction data...IEA...}

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

     {omitted binary pkcs7 signature data}

   --as2BouNdary1as2--

A.2. MDN for Message in A.1, Above

   HTTP/1.1 200 OK
   AS2-From: 0123456780000
   AS2-To: "as2 Name"
   AS2-Version: 1.3
   Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
   Content-Type: multipart/signed; micalg=sha-256;
        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: "as2 Name"
   &  To: 0123456780000
   &  Received on: 2025-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: 43d9tGY3gNSGuFaut4PAGvuc+48VgW6USgXLDPTxsBU=, sha-256
   &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.

   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.

A.3. Signed, Encrypted Message Requesting a Signed, Asynchronous Receipt

   POST /trading_partner HTTP/1.1
   Host: 10.240.1.2:58101
   User-Agent: AS2 Company Server
   Message-ID: <#as2_company#01#a4260as2_companyout#>
   Date: Thu, 19 Dec 2024 15:04:18 GMT
   Subject: Signed and encrypted message with 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,sha-256
   Receipt-Delivery-Option: http://10.240.1.2:58201/exchange/as2_company
   AS2-From: as2_company
   AS2-To: "AS2 Test"
   AS2-Version: 1.3
   Connection: close
   Content-Length: 3428

     {omitted binary encrypted data}

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

   POST / HTTP/1.1
   Host: 10.234.160.12:80
   Connection: close, TE
   TE: trailers, deflate, gzip, compress
   User-Agent: AS2 Company Server
   Date: Thu, 19 Dec 2024 15:05:38 GMT
   Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
   AS2-Version: 1.3
   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
   From: as2debug@example.com
   Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
   Content-Type: multipart/signed; micalg=sha-256;
        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
   2024 15:04:18 GMT with Subject <Signed and encrypted message with 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=

   ------=_Part_337_6452266.1040310218750-

C.1. General

• Removed all references to AS1/SMTP throughout the draft.¶

• Included descriptions and references for compressed content, which was previously supported since AS2 version 1.1.¶

• This draft explicitly allows negotiation of newer RFCs while retaining legacy support, where necessary.¶

• Updated formatting and cross-references so that all internal "Section X.Y" references are properly linked in HTML and XML output.¶

• Moved legacy interoperability clarifications to Appendix B to avoid confusion with normative text.¶

• Clarified that appendices are non-normative unless otherwise indicated.¶

C.2. Changes affecting Section 1.2 - Backward Compatibility and Interoperability

• Expanded to explicitly state the dual-reference policy:¶

  • Implementations MAY interoperate with S/MIME v3.1 (RFC 3851/3852).¶

  • Conformant implementations MUST also support S/MIME v4.0 (RFC 8551).¶

• Added explicit pointer to Appendix B for legacy interoperability clarifications.¶

• Clarified that RFC 8551 forms the baseline for new implementations.¶

C.3. Changes affecting Section 5.1 - AS2-Version Header

• Retained definitions for AS2-Version 1.0, 1.1, and included the previously supported version 1.2.¶

• Added AS2-Version: 1.3:¶

  • Defines modernization requirements (SHA-256, AES baseline per RFC 8551).¶

  • Aligns MDN behavior with RFC 8098.¶

  • Requires support for multiple-recipient encryption (Section 7.2).¶

  • States weak algorithms (SHA-1, MD5, 3DES, RC2) MUST NOT be generated by conformant 1.3 implementations.¶

  • Points to Appendix B for legacy interoperability when communicating with 1.2 or earlier partners.¶

• Added note about future versioning: minor versions (1.x) remain backward compatible; major version (2.0+) would indicate non-backward-compatible revisions.¶

C.4. Changes affecting Section 5.3.3 — Message-Id and Original-Message-Id

• Prohibit spaces and control characters in newly generated Message-Id values; recommend removal (not substitution) when constructing from other attributes.¶

• Clarify receiver behavior: implementations are not required to accept malformed Message-Id values; they SHOULD return an MDN with processed/error and a human-readable explanation (per [RFC8098]).¶

• Keep angle-bracket guidance; brackets are required on send and are not part of the identifier value. Receivers SHOULD NOT reject solely for missing brackets.¶

• Update normative reference to [RFC5322].¶

C.5. Changes affecting Sections 5.4 and 5.5 — Reliability and Restart

• Expanded Section 5.4 to clarify that HTTP 102 (Processing) MAY be used under HTTP/1.1 for progress indication but MUST NOT be used under HTTP/2 or 3.¶

• Changed previous requirement to close connections before retry to optional behavior; clarified that 102 is deprecated but still permitted for backward compatibility.¶

• Expanded Section 5.5 to reference the AS2 Reliability ([I-D.draft-duker-as2-reliability-16]) and AS2 Restart ([I-D.draft-harding-as2-restart-02]) drafts.¶

• Clarified that implementations SHOULD support configurable retry logic and MAY implement restart for large or interrupted transfers.¶

• Added explicit normative language about duplicate detection using Message-ID.¶

C.6. Changes affecting Section 6 — Additional AS2-Specific HTTP Headers

• Added new AS2-Product header to identify the sending product and version.¶

• Defined header format as <product-name>:<major.minor[.patch]>.¶

• Required inclusion for AS2-Version 1.3 or 2.0 and later.¶

• Clarified that the header enables interoperability diagnostics and implementation-specific workarounds, not capability negotiation.¶

• Explicitly stated that arbitrary or misleading product names MUST NOT be used.¶

C.7. Changes affecting Section 7 - Algorithm Requirements

• Introduced a new dedicated section consolidating algorithm requirements.¶

• Hash Algorithms:¶

  • MUST support SHA-256.¶

  • SHOULD support SHA-384 or stronger.¶

  • SHA-1 and MD5 deprecated; MUST NOT be generated by conformant implementations.¶

• Encryption Algorithms:¶

  • MUST support AES-128-CBC; SHOULD support AES-256-CBC.¶

  • RECOMMENDED to support AES-GCM and AES-CCM modes.¶

  • 3DES and RC2 deprecated; MUST NOT be generated.¶

  • SHOULD support multiple-recipient encryption (per RFC 8551 §3.3).¶

• Added explicit cross-references to Appendix B for legacy interoperability.¶

C.8. Changes affecting Section 8 - MDN Processing

• Updated to align MDN behavior with RFC 8098 (superseding RFC 3798).¶

• Clarified semantics for signed-receipt-micalg:¶

  • Allow multiple algorithms in header for backward compatibility.¶

  • Conformance requires selecting one algorithm in Received-content-MIC.¶

  • SHA-256 set as the default minimum; SHA-1 only permitted for legacy use.¶

• Relaxed constraints on the content of the Disposition-notification-to header.¶

• Definitions have been included for additional supported error dispositions.0¶

• Clarified required MDN fields:¶

  • Final-Recipient — MUST always be present.¶

  • Original-Message-ID — REQUIRED and must match the original message exactly.¶

  • Message-ID in the MDN — optional.¶

  • Disposition-Notification-To — MAY use any format (email, URL, hostname); receiving systems MUST ignore syntax issues per RFC 4130.¶

• Updated asynchronous MDN handling to reflect practical implementation realities:¶

  • HTTP 200-level responses SHOULD be sent immediately after receiving the last byte, before full decryption or validation, to minimize timeout risk.¶

  • Persistent (keep-alive) connections MAY be used; closing is optional and implementation-dependent.¶

  • Receipt of a 200-level response only acknowledges receipt, not successful processing.¶

• Emphasized that asynchronous MDNs are sent as independent HTTP messages per Section 7.3, and clarified that connection handling should not be mandated at the application layer.¶

• Added standardized disposition-modifier extensions to improve error reporting.¶

• New recommended modifiers:¶

  • error: decompression-failed¶

  • error/duplicate-filename¶

  • error/illegal-filename¶

  • error: insufficient-message-security¶

  • error/invalid-message-id¶

  • error/unknown-trading-relationship¶

• Clarified that implementations returning these modifiers MUST include a human-readable explanation in the MDN Explanation field.¶

C.9. Changes affecting Section 9 — Public Key Certificate Handling

• Revised the opening paragraph to reference the optional AS2 GET method, in addition to manual partner onboarding.¶

• Expanded the section to clarify separate roles and lifecycle management for TLS certificates (transport security) and AS2 certificates (message signing and encryption).¶

• Stated that TLS and AS2 certificates SHOULD NOT be reused or shared to prevent cross-impact if one certificate is compromised.¶

• Required a minimum RSA key length of 2048 bits (or equivalent elliptic-curve strength such as P-256).¶

• Clarified that:¶

  • TLS certificates SHOULD be CA-signed in production; self-signed certificates MAY be used in test environments or by partner agreement, provided they include a Subject Alternative Name (SAN) extension with hostname and/or IP address.¶

  • AS2 certificates MAY be CA-issued or self-signed per partner policy.¶

• Added guidance that AS2 certificate lifetimes need not mirror the short renewal cycles of TLS certificates; renewal policies SHOULD be independent.¶

• Recommended CEM for automated certificate exchange between partners to reduce manual errors and downtime.¶

• Introduced optional support for AS2 GET to retrieve partner certificates, provided retrieval is authenticated (for example, Basic Auth or mutual TLS) and integrity-protected.¶

• Added operational recommendations:¶

  • Maintain separate TLS / AS2 certificates.¶

  • Include SAN extensions in all self-signed certificates.¶

  • Support configurable expiry-notification mechanisms.¶

  • Avoid reusing TLS certificates for AS2 message security.¶

C.10. Changes affecting Section 10 - Security Considerations

• Provided guidance for the usgae of HTTPS and the minimum and recommended usage of TLS versions.¶

• Expanded discussion of algorithm lifecycle:¶

  • SHA-1 and MD5 deprecated; 3DES formally withdrawn by NIST (2024).¶

  • Implementations MUST NOT generate deprecated algorithms.¶

  • Migration guidance provided for interoperability.¶

• Added explicit references back to Section 7 (Algorithm Requirements) and Appendix B (Legacy Interoperability).¶

C.11. Changes affecting Section 11 - IANA Considerations

• Clarified that IANA must update existing MDN registries to reference this specification (replacing RFC 4130).¶

• Added direct links to IANA registry pages for clarity.¶

C.12. Appendices

• Appendix A: Updated Message Examples with newer algorithms.¶

• Appendix B: Legacy Interoperability (non-normative clarifications):¶

  • Captures behavior when interoperating with RFC 4130 systems.¶

  • Explicit note: 3DES withdrawn by NIST in 2024; MAY only be accepted for backward compatibility, MUST NOT be generated.¶

• Appendix C: This Change Log.¶