MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)

AS2 supports twelve security permutations (combinations of signed/unsigned data, encrypted/unencrypted data, and signed/unsigned/no receipt) to give trading partners full flexibility. Only permutation 12—signed data, encrypted data, signed receipt—provides the complete secure transmission loop required for NRR.

security, crypto

Synchronous MDNs offer verifiable confirmation within a single connection but may fail for large messages if processing exceeds the connection timeout. Asynchronous MDNs allow rapid return of a transfer-layer response without holding a long-lived connection open, at the cost of requiring enough identifying information in the MDN to reconcile the original message.

http, email

The Disposition-notification-to header retains a mail-address field as a residue of SMTP MDN semantics (RFC 3798), even though AS2 uses HTTP and the address is not used for routing. Receiving applications MUST ignore the value and MUST NOT complain about RFC 2822 syntax violations; the Receipt-Delivery-Option header was introduced to carry the actual return URL.

http, email

AS2 implementations MUST accept the historic Disposition field constructions (e.g., 'automatic-action/MDN-sent-automatically; processed/error: authentication-failed') for backward compatibility with earlier AS2 versions. Constructions using pure RFC 3798 disposition-modifiers are not guaranteed compatible with AS2 implementations prior to version 1.1.

http, email

HTTP can handle binary data, so Content-Transfer-Encoding of MIME is not required and its absence MUST NOT result in transaction failure. A value of 'binary' or '8-bit' is permissible but not required.

http, email

When an asynchronous MDN is sent via SMTP, it MUST follow RFC 3335 (AS1) semantics and formatting rather than AS2 HTTP formatting. AS2-To and AS2-From headers are not required in asynchronous SMTP MDNs.

http, email

AS2-MDN field names (e.g., 'Disposition:', 'Final-Recipient:') are case insensitive. AS2 implementations MUST NOT make assumptions regarding user-supplied warning-description or failure-description text values.

http, email

Message-Id is formatted as '<id-left@id-right>' per RFC 2822, with a maximum length of 998 characters; SHOULD be 255 characters or less for backward compatibility, and SHOULD be globally unique. When sending, always include angle brackets; when receiving, do not check for them.

http, email

MIC calculation rules for signed receipts: for signed messages, MIC is calculated over the RFC 1767/3023 MIME header and content after canonicalization; for encrypted unsigned messages, MIC is over the decrypted and canonicalized content; for unsigned unencrypted messages, MIC is calculated over message contents without MIME or RFC 2822 headers.

http, email, crypto

SHA-1 is RECOMMENDED for all outgoing message signatures; implementations SHOULD support both MD5 and SHA-1 for incoming messages. A MIC value is REQUIRED as part of any returned receipt except when a severe error prevents digest computation.

crypto, security

The AS2-To and AS2-From headers MUST be present in all AS2 messages and AS2 MDNs (synchronous or asynchronous), except for asynchronous MDNs sent via SMTP. In a response or MDN, AS2-To MUST match the AS2-From of the corresponding request, and vice versa.

http

The 'failed' AS2-disposition-type MUST NOT be used for processing problems other than when a failure prevents proper MDN generation. In error cases (decryption failure, auth failure, etc.), the 'processed' disposition-type with the 'error' modifier MUST be used instead.

http, email

The following MIME content types MUST be supported: multipart/signed, multipart/report, message/disposition-notification, application/PKCS7-signature, application/PKCS7-mime, application/EDI-X12, application/EDIFACT, application/edi-consent, and application/XML.

http, email

The Host request header MUST be included in the POST request when sending business data, to allow one server IP address to service multiple hostnames and conserve IP addresses.

http

When a signed receipt is requested and there is an error processing message contents, a signed receipt MUST still be returned. The reason for the processing failure MUST be set in the disposition-field; the request for a signed receipt SHALL still be honored.

http, email, security

X.509 certificates are REQUIRED for public key handling. It is RECOMMENDED that trading partners self-certify each other if no agreed-upon certification authority is used; a CA is OPTIONAL and certificates may be self-signed.

pkix, crypto, security

An AS2 message is structured as MIME content inside an HTTP POST request, with additional AS2-specific headers. The Request-URI identifies the process for unpacking and handling data, and the MDN reply is returned either in the HTTP response body or via a separate HTTP POST to the sender.

http, email, security

Disposition-notification-options carries signed receipt parameters: 'signed-receipt-protocol' (e.g., pkcs7-signature) and 'signed-receipt-micalg' (ordered list of preferred MIC algorithms, sha1 or md5). Both parameters are REQUIRED when requesting a signed receipt; they use importance='optional' so UAs that cannot sign still return an unsigned MDN.

http, email, crypto

The AS2-MDN body is a MIME multipart/report with report-type=disposition-notification. When signed, the outer content-type is multipart/signed; the first part is a multipart/report and the second part is application/pkcs7-signature. The machine-readable part includes final-recipient-field, AS2-disposition-field, and optionally AS2-received-content-MIC-field.

http, email, crypto

The AS2-Version header indicates the version of the specification implemented. All implementations MUST interpret versions '1.0 through 1.9' as implementing this specification. Receiving systems MUST NOT fail due to the absence of this header. AS2-Version: 1.1 designates support for compression per RFC 3274.

http

The Receipt-Delivery-Option header specifies the URL for asynchronous MDN delivery. Its absence indicates a synchronous receipt. The value MUST be a URL indicating the transport destination (HTTP, HTTPS, or SMTP/mailto). The Disposition-notification-to header MUST carry a mail-address even though its value is ignored for routing.

http, email

This specification registers a new MDN Disposition-modifier extension: 'warning'. It is used with the 'processed' disposition-type to indicate the message was successfully processed but an exceptional condition occurred (e.g., 'Warning: authentication-failed, processing continued'). Parameters signed-receipt-protocol, signed-receipt-micalg, and Received-content-MIC were previously registered by RFC 3335 and are reused here.

registry, email

40-bit encryption is considered weak and offers little security over plaintext; using weak cryptography is never recommended unless the only alternative is none. Processing software MUST take immediate, noticeable action to inform end users of certificate validation failures, including expired certs, revoked certs, invalid CRLs, or broken certificate chains.

security, crypto, pkix

Business data documents normally contain transaction IDs enabling duplicate detection; replays should be discarded as part of normal processing. Detection of duplicates by Message-Id or business transaction identifiers is recommended to guard against replay attacks.

security

For HTTPS, server-side certificates MUST support four types: with URL in CN, without URL in CN, self-signed, and CA-certified. The complete certification chain MUST be included and all verifications MUST chain to root or an accepted trust anchor.

security, pkix, tls

NRR (non-repudiation of receipt) is a business/legal concept, not a purely technical one. To satisfy strict NRR, authentication and integrity MUST be provided; the RECOMMENDED mechanism is digital signatures on both the original message and the receipt. If a digital signature is omitted from the original message, some alternative authentication (client-side SSL, IPsec, HTTP auth over SSL) MUST accompany the receipt request.

security, crypto

AS2 MDNs exist in two modes: synchronous (returned in the HTTP response on the same TCP connection as the original POST) and asynchronous (sent on a separate HTTP, HTTPS, or SMTP connection). When asynchronous MDN is requested, the HTTP response MUST be sent back before the MDN is processed and sent on the separate connection.

http, email

The AS2-disposition-field is 'Disposition: action-mode/sending-mode; AS2-disposition-type[/AS2-disposition-modifier]'. Disposition types are 'processed' or 'failed'. Modifiers include 'error', 'warning', and extensions such as 'error: authentication-failed', 'error: decryption-failed', 'error: integrity-check-failed', 'error: unexpected-processing-error'.

http, email

The AS2-From and AS2-To headers carry an AS2-name: either an AS2-atomic-name (1–128 printable ASCII chars, excluding double-quote and backslash) or an AS2-quoted-name (double-quoted, up to 128 chars allowing space and escaped quote/backslash). Values are case-sensitive and MUST NOT be folded.

http

The Received-content-MIC field carries the base64-encoded message digest: 'Received-content-MIC: <base64-digest>, <digest-alg-id>' where digest-alg-id is 'sha1' or 'md5'. This field is required for signed receipts and optional for unsigned receipts. The MIC algorithm MUST match that used on the signed message.

http, email, crypto