AS2 — Applicability Statement 2

Le protocole de transport EDI sur internet le plus déployé : un POST HTTPS, une charge utile signée et chiffrée en S/MIME, un accusé de réception cryptographique en retour. Standardisé par l'IETF en 2002.

Qu'est-ce qu'AS2 ?

AS2 est un applicability statement au sens de la RFC 2026 §3.2 — c'est-à-dire un document qui ne définit pas de nouveau protocole, mais qui spécifie comment des standards existants (HTTP, MIME, S/MIME, MDN) s'assemblent pour échanger « structured business data » entre deux partenaires. AS2 succède à AS1 (RFC 3335, 2002), qui faisait la même chose sur SMTP — l'apport d'AS2 est l'utilisation de HTTP en transport, plus rapide et plus pilotable. AS4 (OASIS ebMS, profil 2010) viendra plus tard pour le réseau PEPPOL eDelivery, sur une pile SOAP : AS2 reste le standard de facto pour les flux bilatéraux entre intégrateurs hors écosystème PEPPOL.

L'idée centrale est la « secure transmission loop » (RFC 4130 §2.3.1) : l'émetteur signe et chiffre sa charge utile en S/MIME, l'envoie en POST HTTP au destinataire, et demande un signed receipt. Le destinataire vérifie la signature, recalcule un MIC (Message Integrity Check) sur le contenu reçu, et renvoie un MDN (Message Disposition Notification) signé contenant ce MIC. Si l'émetteur retrouve le même MIC que celui qu'il avait calculé à l'envoi, il a une preuve cryptographique de non-répudiation de la réception (NRR).

Anatomie d'un échange AS2

Un message AS2 est un POST HTTP dont le corps est un multipart/signed (RFC 1847). Première partie : la charge utile EDI, déclarée avec un Content-Type tel que application/EDIFACT ou application/EDI-X12 (RFC 4130 §4.2 énumère les types MIME MUST be supported). Deuxième partie : la signature S/MIME en application/pkcs7-signature. Si la charge utile est également chiffrée, le tout est lui-même encapsulé dans un application/pkcs7-mime.

Trois en-têtes spécifiques à AS2 sont obligatoires dans tout POST et toute MDN (RFC 4130 §6) :

• AS2-Version — 1.0 pour la conformité de base, 1.1 pour les implémentations supportant la compression de RFC 3274.
• AS2-From et AS2-To — chaînes ASCII imprimables de 1 à 128 caractères, sensibles à la casse, identifiant l'émetteur et le destinataire (typiquement un DUNS ou un identifiant négocié entre partenaires).

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

En retour, le destinataire renvoie un MDN. Quand l'accusé est synchrone (le cas le plus simple), le MDN est la réponse HTTP elle-même, et son corps est un multipart/signed qui contient un multipart/report à deux parties (texte lisible + message/disposition-notification machine), plus la signature S/MIME du report. La donnée critique est l'en-tête Received-content-MIC du report : c'est lui qui scelle la preuve de réception.

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 on the multipart/report]
------=_PartMDN--

MDN — synchrone vs asynchrone

RFC 4130 §7.2 décrit deux variantes d'accusé :

• MDN synchrone — retourné dans la même connexion TCP/IP que le POST d'origine, comme corps de la réponse HTTP. Avantage : l'émetteur a une confirmation immédiate dans un flux logique simple. Inconvénient : pour un gros payload, le temps de traitement côté destinataire peut dépasser le timeout IP de la connexion.
• MDN asynchrone — le destinataire ferme la connexion d'origine avec une simple réponse de transport, puis ouvre une nouvelle connexion (HTTP, HTTPS ou SMTP, vers l'URL fournie dans Disposition-Notification-To et Receipt-Delivery-Option) pour pousser le MDN. Avantage : pas de timeout. Inconvénient : l'émetteur doit corréler le MDN entrant avec la requête sortante via Original-Message-ID.

MIC, signature, chiffrement

RFC 4130 §6.2 spécifie comment calculer le MIC (Message Integrity Check). Ce n'est pas un hash brut sur le contenu : c'est un digest cryptographique appliqué après canonicalisation MIME de la partie signée, conformément à la procédure S/MIME (RFC 3851). Le digest est ensuite encodé en Base64 et émis dans l'en-tête Received-content-MIC du MDN, sous la forme <digest>, <algo>. Le destinataire et l'émetteur doivent calculer exactement le même digest, sous peine de rupture de la preuve de réception.

Les algorithmes admis ont évolué :

• SHA-1 et MD5 — historiques, mentionnés par RFC 4130 mais proscrits depuis longtemps pour cause de collisions. À considérer uniquement pour interopérer avec un partenaire legacy bien identifié.
• SHA-256, SHA-384, SHA-512 — les digests recommandés depuis 2010 par les programmes Drummond ; SHA-256 est le défaut de facto.

Côté chiffrement (RFC 4130 §6.3 et RFC 3851), AS2 supporte 3DES, AES-128, AES-192 et AES-256 en mode CBC. AES-128-CBC est aujourd'hui le minimum acceptable ; AES-256-CBC est la pratique dominante chez les grands distributeurs. Le chiffrement est appliqué dans un application/pkcs7-mime de type enveloped-data, qui enveloppe soit la charge utile seule, soit le multipart/signed déjà signé (« sign then encrypt »).

Côté transport, AS2 ne réserve pas de port officiel. La pratique quasi-universelle est : port 80 en clair sur HTTP (très rare aujourd'hui), port 443 pour HTTPS, et des ports non-standard tels que 10080 ou 10443 pour les serveurs AS2 dédiés en intégration. La sécurité de la couche TLS sous-jacente vient se cumuler avec la sécurité S/MIME applicative — d'où la double protection typique.

Certificats et programme Drummond

RFC 4130 §8 impose des certificats X.509 pour la signature et le chiffrement. Deux modes coexistent :

• Certificats d'une autorité reconnue (CA) — VeriSign, DigiCert, Sectigo. Approche classique mais peu adaptée à AS2 car la chaîne de confiance sert peu : les partenaires AS2 sont connus à l'avance.
• Certificats auto-signés — explicitement autorisés par RFC 4130 §8 (« Certificates may be self-signed »). C'est le cas dominant en pratique, généralement obtenus via le programme de certification d'interopérabilité Drummond.

Le programme Drummond Certified™ AS2 est le marqueur d'interopérabilité de fait pour le protocole. Lancé en 2001 par Rik Drummond (co-auteur de RFC 4130) au sein du Drummond Group, il consiste en une matrice de tests croisés où chaque éditeur candidat échange un jeu de messages avec toutes les autres implémentations certifiées (typiquement plus de 30 participants par cycle annuel). Les tests couvrent la signature SHA-256, le chiffrement AES, les MDN synchrones et asynchrones, la compression RFC 5402, et le profil RFC 6362 (multiples pièces jointes). Un produit Drummond Certified™ est garanti d'échanger avec tous les autres produits certifiés, ce qui est une exigence d'achat fréquente côté grands distributeurs et payeurs santé US.

Les clés publiques échangées au moment de l'enrôlement du partenaire sont stockées par l'agent utilisateur AS2 dans un profil de partenaire, qui mappe l'identifiant AS2-name à un certificat de signature, un certificat de chiffrement, une URL POST cible, des algorithmes négociés (SHA-256, AES-256) et la politique d'accusé (sync ou async, signé ou non).

La famille de RFC

Pièges opérationnels

Les vingt ans de déploiement AS2 ont produit un catalogue d'écueils récurrents qu'il faut anticiper :

• Expiration de certificat partenaire. Les certificats AS2 sont typiquement valides 2 à 5 ans. Quand un partenaire change son certificat sans prévenir, tous les messages signés en sa direction sont rejetés et les messages reçus de lui sont en erreur de signature. Un monitoring d'expiration centralisé (par ex. cron + script openssl) est indispensable.
• Algorithme MIC négocié mais non implémenté. Un partenaire qui annonce SHA-256 dans Disposition-Notification-Options mais qui retourne en réalité un MIC SHA-1 dans son MDN. La vérification NRR échoue silencieusement et le journal d'audit est incomplet.
• Timeout MDN synchrone sur gros payload. Un message de 50 Mo qui prend 90 secondes à traiter au partenaire dépasse les timeouts HTTPS courants (Apache mod_proxy 60 s, NGINX 60 s par défaut). Le client AS2 reçoit un TCP reset et croit l'envoi en erreur, alors que le serveur l'a bien traité. Solution : bascule sur MDN asynchrone au-delà d'un seuil de taille.
• MIC qui diffère d'un partenaire à l'autre sur le même payload. Cause typique : canonicalisation MIME (CRLF vs LF dans les en-têtes) ou trailing whitespace. Toujours conserver le message reçu verbatim avant tout traitement applicatif, pour pouvoir recalculer le MIC en cas de litige.
• Cumul TLS + S/MIME mal configuré. Un load balancer qui terminait TLS et ré-encodait le corps a déjà cassé la signature S/MIME d'innombrables intégrations. La règle : l'agent AS2 doit recevoir le corps byte-pour-byte tel qu'envoyé.

Cas d'usage

• Distribution — Walmart impose AS2 à toute sa base fournisseurs depuis 2002, Target, Carrefour, Lowe's et la majorité des grands distributeurs européens et nord-américains font de même.
• Automobile — Renault, Stellantis, Volkswagen utilisent AS2 ou OFTP2 selon les flux ; AS2 sert souvent comme alternative pour les fournisseurs qui n'ont pas d'infrastructure OFTP.
• Santé (États-Unis) — les échanges HIPAA (transactions X12 270/271, 834, 835, 837) entre payeurs et providers passent massivement par AS2.
• Logistique — 3PL, transporteurs et chargeurs s'échangent IFTMIN, IFTSTA, IFTMBC en EDIFACT ou 856/210/214 en X12 sur AS2.

Outils

• Drummond Group — programme de certification d'interopérabilité AS2. Une implémentation Drummond Certified™ est garantie d'échanger avec toutes les autres implémentations certifiées (40+ éditeurs). drummondgroup.com
• OpenAS2 — implémentation open source en Java, maintenue depuis 2014. github.com/OpenAS2/OpenAs2App
• PHPAS2 — implémentation PHP, utilisée comme brique de validation par plusieurs intégrateurs.

Pour aller plus loin

Sources officielles à consulter avant toute implémentation :

• RFC 4130 — AS2 (le texte canonique, cité verbatim dans cette page).
• RFC 3335 — AS1 (le prédécesseur SMTP, encore référencé pour les MDN par courrier).
• AS4 Profile — OASIS (le successeur SOAP, base technique de PEPPOL eDelivery).
• Page du standard de transport PEPPOL : PEPPOL.