AS2 — Applicability Statement 2

The most widely deployed EDI transport protocol on the public internet: an HTTPS POST, a signed and encrypted S/MIME payload, and a cryptographic receipt in return. Standardised by the IETF in 2002.

What is AS2?

AS2 is an applicability statement in the sense of RFC 2026 §3.2 — that is, a document that does not define a new protocol, but specifies how existing standards (HTTP, MIME, S/MIME, MDN) compose to exchange "structured business data" between two partners. AS2 succeeds AS1 (RFC 3335, 2002), which did the same job over SMTP — AS2's contribution is moving to HTTP transport, which is faster and easier to operate. AS4 (OASIS ebMS, profiled in 2010) will come later for the PEPPOL eDelivery network on a SOAP stack; AS2 remains the de facto standard for bilateral flows between integrators outside the PEPPOL ecosystem.

The central idea is the "secure transmission loop" (RFC 4130 §2.3.1): the sender signs and encrypts its payload in S/MIME, POSTs it over HTTP to the receiver, and asks for a signed receipt. The receiver verifies the signature, recomputes a MIC (Message Integrity Check) over the received content, and returns a signed MDN (Message Disposition Notification) containing that MIC. If the sender finds the same MIC it computed on the way out, it has cryptographic evidence of non-repudiation of receipt (NRR).

Anatomy of an AS2 exchange

An AS2 message is an HTTP POST whose body is a multipart/signed (RFC 1847). First part: the EDI payload, declared with a Content-Type such as application/EDIFACT or application/EDI-X12 (RFC 4130 §4.2 lists the MIME types that MUST be supported). Second part: the S/MIME signature in application/pkcs7-signature. If the payload is also encrypted, the whole thing is wrapped inside an application/pkcs7-mime.

Three AS2-specific headers are mandatory in every POST and every MDN (RFC 4130 §6):

• AS2-Version — 1.0 for the baseline, 1.1 for implementations that support RFC 3274 compression.
• AS2-From and AS2-To — case-sensitive ASCII strings of 1 to 128 printable characters, identifying the sender and the receiver (typically a DUNS number or an identifier agreed between partners).

POST /receive HTTP/1.1
Host: as2.partner.example
User-Agent: ediverse AS2 client
Date: Wed, 13 May 2026 13:34:50 GMT
AS2-Version: 1.1
AS2-From: "ediverse-FR"
AS2-To: 0123456780000
Message-Id: <20260513133450@ediverse.io>
Disposition-Notification-To: as2@ediverse.io
Disposition-Notification-Options: signed-receipt-protocol=optional,
  pkcs7-signature; signed-receipt-micalg=optional,sha256
Content-Type: multipart/signed; boundary="as2BouNdary1";
  protocol="application/pkcs7-signature"; micalg=sha256
Content-Length: 2464

--as2BouNdary1
Content-Type: application/EDIFACT
Content-Disposition: attachment; filename=order-987.edi

UNB+UNOC:3+SENDER:14+RECEIVER:14+260513:1430+CTRL000001'
UNH+1+ORDERS:D:96A:UN:EAN008'
...
UNZ+1+CTRL000001'
--as2BouNdary1
Content-Type: application/pkcs7-signature
  [binary PKCS#7 signature]
--as2BouNdary1--

In return the receiver sends an MDN. When the receipt is synchronous (the simplest case), the MDN is the HTTP response itself, and its body is a multipart/signed that wraps a two-part multipart/report (human-readable text + a machine-readable message/disposition-notification), plus the S/MIME signature of the report. The load-bearing piece of data is the report's Received-content-MIC header: that is what seals the proof of receipt.

HTTP/1.1 200 OK
AS2-From: 0123456780000
AS2-To: "ediverse-FR"
AS2-Version: 1.1
Message-ID: <20260513133451.mdn@as2.partner.example>
Content-Type: multipart/signed; micalg=sha256;
  protocol="application/pkcs7-signature";
  boundary="----=_PartMDN"

------=_PartMDN
Content-Type: multipart/report;
  report-type=disposition-notification;
  boundary="----=_PartReport"

------=_PartReport
Content-Type: text/plain

MDN for -
 Message ID: <20260513133450@ediverse.io>
 From: "ediverse-FR"
 To: "0123456780000"
 Received on: 2026-05-13 at 13:34:51 (UTC)
 Status: processed

------=_PartReport
Content-Type: message/disposition-notification

Reporting-UA: partner AS2 server
Original-Recipient: rfc822; 0123456780000
Final-Recipient: rfc822; 0123456780000
Original-Message-ID: <20260513133450@ediverse.io>
Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha256
Disposition: automatic-action/MDN-sent-automatically; processed

------=_PartReport--
------=_PartMDN
Content-Type: application/pkcs7-signature; name=smime.p7s
  [binary PKCS#7 signature over the multipart/report]
------=_PartMDN--

MDN — synchronous vs asynchronous

RFC 4130 §7.2 describes two receipt flavors:

• Synchronous MDN — returned on the same TCP/IP connection as the original POST, as the body of the HTTP response. Pro: immediate confirmation in a simple logic flow. Con: for a large payload, processing time at the receiver can exceed the IP connection's maximum lifetime.
• Asynchronous MDN — the receiver closes the original connection with a plain transfer-layer response, then opens a new connection (HTTP, HTTPS or SMTP, towards the URL given in Disposition-Notification-To and Receipt-Delivery-Option) to push the MDN. Pro: no timeout. Con: the sender must correlate the inbound MDN with the outbound request through Original-Message-ID.

MIC, signing, encryption

RFC 4130 §6.2 specifies how to compute the MIC (Message Integrity Check). It is not a raw hash over the content — it is a cryptographic digest applied after MIME canonicalisation of the signed part, following the S/MIME procedure (RFC 3851). The digest is then Base64-encoded and emitted in the MDN's Received-content-MIC header as <digest>, <algo>. Both ends must compute the exact same digest, otherwise the proof of receipt is broken.

The accepted algorithms evolved over time:

• SHA-1 and MD5 — legacy, mentioned by RFC 4130 but long since deprecated due to collisions. Consider them only when interoperating with a known-legacy partner.
• SHA-256, SHA-384, SHA-512 — the digests recommended since 2010 by the Drummond programme; SHA-256 is the de facto default.

On the encryption side (RFC 4130 §6.3 and RFC 3851) AS2 supports 3DES, AES-128, AES-192 and AES-256 in CBC mode. AES-128-CBC is today's minimum acceptable; AES-256-CBC is the dominant practice across major retailers. Encryption is wrapped in an application/pkcs7-mime enveloped-data, which either envelops the payload alone or the already signed multipart/signed ("sign then encrypt").

On transport, AS2 has no IANA-assigned port. Common practice is port 80 in clear HTTP (very rare today), port 443 for HTTPS, and non-standard ports like 10080 or 10443 for dedicated integration servers. The TLS layer stacks on top of the S/MIME application security — hence the typical double protection.

Certificates and the Drummond programme

RFC 4130 §8 requires X.509 certificates for both signing and encryption. Two patterns coexist:

• CA-issued certificates — VeriSign, DigiCert, Sectigo. Standard approach, but the trust chain matters little here: AS2 partners are known in advance.
• Self-signed certificates — explicitly allowed by RFC 4130 §8 ("Certificates may be self-signed"). This is the dominant pattern in practice, generally provisioned through the Drummond Group interoperability certification programme.

The Drummond Certified™ AS2 programme is the de facto interoperability marker for the protocol. Launched in 2001 by Rik Drummond (co-author of RFC 4130) inside the Drummond Group, it consists of a cross-vendor test matrix where each candidate exchanges a message set with every other certified implementation (typically 30+ participants per annual cycle). Tests cover SHA-256 signing, AES encryption, sync and async MDNs, RFC 5402 compression, and the RFC 6362 multiple-attachment profile. A Drummond Certified™ product is guaranteed to exchange with every other certified product — a frequent procurement requirement for large retailers and US healthcare payers.

Public keys exchanged at partner enrolment time are stored by the AS2 user agent in a partner profile, which maps the AS2-name identifier to a signing certificate, an encryption certificate, a target POST URL, negotiated algorithms (SHA-256, AES-256) and the receipt policy (sync or async, signed or not).

The RFC family

Operational pitfalls

Twenty years of AS2 deployment have produced a recurring catalogue of failure modes worth anticipating:

• Partner certificate expiry. AS2 certificates typically last 2 to 5 years. When a partner rolls without notice, signed messages bound to them are rejected and inbound messages fail signature verification. Centralised expiry monitoring (e.g. cron + openssl) is mandatory.
• MIC algorithm negotiated but not implemented. A partner advertises SHA-256 in Disposition-Notification-Options but actually returns a SHA-1 MIC in its MDN. NRR verification silently fails and the audit log is incomplete.
• Sync MDN timeout on large payload. A 50 MB message taking 90 seconds to process at the partner exceeds common HTTPS timeouts (Apache mod_proxy 60 s, NGINX 60 s by default). The AS2 client sees a TCP reset and believes the send failed, while the server actually processed it. Fix: switch to asynchronous MDN above a size threshold.
• MIC that differs from one partner to another on the same payload. Typical cause: MIME canonicalisation (CRLF vs LF in headers) or trailing whitespace. Always keep the received message verbatim before any application processing, so the MIC can be recomputed in a dispute.
• Mismatched TLS + S/MIME stack. A load balancer that terminates TLS and re-encodes the body has broken countless AS2 integrations. Rule: the AS2 agent must receive the byte-for-byte body exactly as sent.

Use cases

• Retail — Walmart has mandated AS2 across its entire supplier base since 2002; Target, Carrefour, Lowe's and most large European and North-American retailers do the same.
• Automotive — Renault, Stellantis and Volkswagen use AS2 or OFTP2 depending on the flow; AS2 often serves as a fallback for suppliers without OFTP infrastructure.
• US healthcare — HIPAA exchanges (X12 270/271, 834, 835, 837 transactions) between payers and providers run massively over AS2.
• Logistics — 3PLs, carriers and shippers exchange IFTMIN, IFTSTA, IFTMBC in EDIFACT, or 856/210/214 in X12, over AS2.

Tools

• Drummond Group — AS2 interoperability certification programme. A Drummond Certified™ implementation is guaranteed to exchange with every other certified implementation (40+ vendors). drummondgroup.com
• OpenAS2 — Java open-source implementation, maintained since 2014. github.com/OpenAS2/OpenAs2App
• PHPAS2 — PHP implementation, used as a validation building block by several integrators.

Further reading

Official sources to read before any implementation:

• RFC 4130 — AS2 (the canonical text, cited verbatim throughout this page).
• RFC 3335 — AS1 (the SMTP predecessor, still referenced for email-based MDNs).
• AS4 Profile — OASIS (the SOAP successor, technical backbone of PEPPOL eDelivery).
• PEPPOL transport overview: PEPPOL.