Validateur AS2 MDN

Validez une AS2 Message Disposition Notification (RFC 4130) bloc par bloc, 100 % côté client. Multipart/report, disposition, MIC, signature S/MIME.

Comment ça marche

AS2 (Applicability Statement 2, défini par la RFC 4130) transporte des messages EDI (EDIFACT, X12, XML, JSON…) sur HTTPS entre partenaires B2B. À la réception d'un message, le destinataire renvoie un Message Disposition Notification (MDN) qui sert d'accusé de réception synchrone ou asynchrone : il atteste structurellement de la bonne réception et du résultat du traitement applicatif.

Un MDN AS2 est une enveloppe MIME : multipart/report; report-type=disposition-notification qui contient deux ou trois parties — un texte humainement lisible, une section de disposition structurée (message/disposition-notification), et optionnellement une signature S/MIME détachée (application/pkcs7-signature). L'outil parse l'ensemble, extrait les en-têtes de disposition, et vérifie la cohérence du Received-Content-MIC.

Structure d'un MDN AS2

Content-Type: multipart/report; report-type=disposition-notification;
	boundary="--MDN-Boundary"

----MDN-Boundary
Content-Type: text/plain

The AS2 message <msg-123@sender> was successfully received and processed.
----MDN-Boundary
Content-Type: message/disposition-notification

Reporting-UA: ediverse AS2 / 2.4.0
Original-Recipient: rfc822; ReceiverAS2ID
Final-Recipient: rfc822; ReceiverAS2ID
Original-Message-ID: <msg-123@sender>
Disposition: automatic-action/MDN-sent-automatically; processed
Received-Content-MIC: 5lEovTjVA6VqDIWLDQz97/g6yxc=, sha256

----MDN-Boundary--

Le validateur lit chaque partie indépendamment, ce qui permet de diagnostiquer rapidement un MDN tronqué ou mal encodé : boundary absent, partie de disposition manquante, en-tête Final-Recipient oublié. Les diagnostics sont émis avec des codes stables (E_NO_BOUNDARY, E_MISSING_FINAL_RECIPIENT, E_BAD_MIC_FORMAT…).

Codes de disposition

Le champ Disposition (RFC 3798 §3.2.6) indique le résultat du traitement selon le format suivant :

Disposition: <action-mode>/<sending-mode>; <type>[/<modifier>]

Exemples:
  automatic-action/MDN-sent-automatically; processed
  automatic-action/MDN-sent-automatically; processed/warning
  automatic-action/MDN-sent-automatically; failed/error
  manual-action/MDN-sent-manually; denied

• processed — succès. Le message a été reçu et traité ; un éventuel modifier warning signale un problème non-bloquant.
• failed — échec, généralement accompagné du modifier error et d'extensions Error:, Failure:.
• denied — rejet sans traitement (filtre, politique, partenaire inconnu).

MIC et algorithmes

Le Received-Content-MIC est l'empreinte cryptographique du payload original calculée par le destinataire. Son format : <digest base64>, <algorithme>. L'expéditeur la compare au MIC qu'il avait initialement calculé pour garantir l'intégrité du transport.

Les algorithmes reconnus par AS2 (RFC 5751) :

• sha256, sha384, sha512 — recommandés.
• sha1, md5 — historiques, cryptographiquement faibles. L'outil émet un avertissement W_WEAK_MIC_ALG.

Limites

• Le validateur ne recalcule pas le MIC à partir du payload original (qui n'est pas inclus dans le MDN). Il vérifie uniquement la forme et l'algorithme.
• La signature S/MIME détachée est détectée mais non vérifiée : aucune chaîne de certificats n'est résolue, aucune autorité de confiance n'est consultée.
• Les en-têtes de transport HTTP (AS2-To, AS2-From, Disposition-Notification-Options…) ne sont pas exigés — le validateur traite uniquement le corps du MDN tel qu'il aurait été POSTé en retour ou envoyé en asynchrone.

Confidentialité

Documentation associée

• RFC 4130 — MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) ; rfc-editor.org — RFC 4130.
• RFC 3798 — Message Disposition Notification ; rfc-editor.org — RFC 3798.
• RFC 5751 — S/MIME Version 3.2 Message Specification (signature et chiffrement) ; rfc-editor.org — RFC 5751.