MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet
Extracted elements (29)
EDI envelope headers (ISA/IEA for X12; UNA/UNB/UNZ for EDIFACT) are encrypted and remain invisible in the MIME package. Routing optimization from VANs to the Internet would require future work to expose envelope information, but is outside this specification's scope.
Public key certificate handling is left flexible: certification authorities are OPTIONAL, trading partners may self-certify each other, and long-term Internet EDI standards may eventually simplify partnership establishment. The near-term approach relies on bilateral exchange during trading-partner setup.
The 'importance=Optional' attribute is used for signed-receipt-protocol and signed-receipt-micalg parameters so that UAs which do not understand those parameters can still generate an unsigned MDN in response, maintaining backward compatibility while allowing the sender to learn why a signed receipt was not returned.
Some early EDIINT implementations emitted and expected 'rsa-md5' and 'rsa-sha1' (rather than 'md5' and 'sha1') for the micalg parameter; receiving agents SHOULD recover gracefully from unrecognized micalg values to maintain compatibility with these legacy implementations.
The internal EDI security standards X12.58 (for ANSI X12) and AUTACK (for EDIFACT) are fully compatible with, though possibly redundant to, this specification; their use or non-use is not mandated.
Both the 'signed-receipt-protocol' and the 'signed-receipt-micalg' option parameters are REQUIRED when requesting a signed receipt.
For any signed messages, canonicalization as specified in RFC 1848 MUST be performed before the MIC is calculated; for encrypted unsigned messages, content after decryption MUST be canonicalized before MIC calculation.
For unsigned, unencrypted messages, the MIC MUST be calculated over message contents prior to Content-Transfer-Encoding and without MIME or RFC 822 headers, since these are sometimes altered or reordered by MTAs.
If a receipt is requested explicitly specifying that the receipt be signed, the receipt MUST be returned with a signature.
If a signed receipt is requested but the recipient cannot support the requested protocol format or requested MIC algorithms, a receipt—either signed or unsigned—SHOULD be returned.
Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize, a consideration for legacy interoperability.
Support for the message/partial content type is OPTIONAL, and in the absence of knowledge that the recipient supports partial messages it SHOULD NOT be used.
The algorithm used to calculate the 'Received-content-MIC' value MUST be the same as the 'micalg' value used by the sender in the multipart/signed message.
The receiving UA MUST provide: decryption of the symmetric key using the receiver's private key, decryption of the EDI interchange, authentication of the sender's signature, formatting of the MDN with the calculated MIC in the Received-content-MIC field, and creation of a multipart/signed MIME message.
The user MUST NOT be allowed to configure the UA to refuse sending a signed receipt when the sender requests one; requests for signed receipts must always be honored.
When a request for a signed receipt is made, the 'Received-content-MIC' MUST always be returned to the requester.
When a signature is used, it is RECOMMENDED that the SHA1 hash algorithm be used for all outgoing messages, and that both MD5 and SHA1 be supported for incoming messages.
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.
Eight security permutations are defined spanning all combinations of: unencrypted vs. encrypted data, unsigned vs. signed data, and no receipt vs. signed/unsigned receipt requested. Only permutation (8)—encrypted, signed, with signed receipt—satisfies all security requirements.
MDN disposition fields defined for Internet EDI include disposition-mode values (automatic-action, manual-action, MDN-sent-automatically, MDN-sent-manually), disposition-type values (processed, failed), and disposition-modifier values (error, warning) with specific EDI error codes: decryption-failed, authentication-failed, integrity-check-failed, unexpected-processing-error.
The Disposition-notification-options header carries two parameters: 'signed-receipt-protocol' (specifying pkcs7-signature or pgp-signature) and 'signed-receipt-micalg' (an ordered list of preferred MIC algorithms, honored left to right).
The 'secure transmission loop' is the core pattern: the sender signs and encrypts the EDI interchange and requests a signed receipt; the receiver decrypts, verifies, and returns a signed MDN containing the hash of the received message's signature.
IANA registration of three items: (1) 'signed-receipt-protocol' content disposition parameter, (2) 'signed-receipt-micalg' content disposition parameter, and (3) 'Received-content-MIC' MDN extension field name, all defined in sections 5.2 and 5.3.1.
40-bit encryption is considered weak by most cryptographers and offers little security over plaintext. S/MIME supports stronger algorithms such as tripleDES or AES, and these should be used when feasible; weak cryptography is never recommended unless the only alternative is no cryptography.
Certificate processing may fail in many ways (no chain to trusted CA, inability to check CRL, invalid or expired CRL, expired certificate, revoked certificate); processing software must check all cases thoroughly and take immediate, noticeable steps to inform the end user of any failure.
Non-repudiation of receipt (NRR) is a legal event that requires: the sender verifies the signed receipt using the receiver's public key, and the returned MIC inside the MDN matches the digest of the original message. NRR is not possible without signatures on both the message and the receipt.
A signed receipt is structured as multipart/signed with the multipart/report (containing MDN headers including Received-content-MIC) as the first body part and the detached digital signature (application/pkcs7-signature or application/pgp-signature) as the second body part.
The Disposition-notification-options parameter syntax is: attribute '=' importance ', ' 1#value, where importance is 'required' or 'optional'. Example: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha1, md5.
The 'Received-content-MIC' MDN extension field encodes as: 'Received-content-MIC' ':' <base64MicValue> ',' <micalg>, where base64MicValue is the base64-encoded one-way hash result and micalg is an IANA-registered MIC algorithm ID token.