Summary

  • RFC 5402 permits compression either inside a signature or around the signed MIME entity, but forbids both placements in one document and requires receivers to handle both.
  • The returned MIC follows the declared layer order: for signed traffic it covers the same data that was signed; for unsigned compressed traffic it is calculated after decompression under the specified MIME rules.
  • A signed receipt can establish partner-attributed receipt and integrity for that byte boundary. It cannot, without later evidence, establish attachment extraction, semantic validation, ledger posting or commercial acceptance.

One green status absorbed four different claims

The operations team possessed a real receipt. It carried the original message identifier, a partner signature and the MIC the receiving gateway had calculated. The returned value matched the sender's record. Nothing in that chain was fictional.

The fiction entered when the interface renamed the result “accepted.” Receipt had become integrity; integrity had become successful decoding; successful decoding had become a valid purchase order; and a valid purchase order had become a commercial commitment. Four boundaries disappeared inside one adjective.

RFC 5402 matters because it makes the first of those boundaries unusually visible. An EDIINT message can contain a business payload, a signature and encryption. Compression adds another reversible layer. Its position determines whether the signature covers a compressed container or the original MIME entity, and therefore which bytes the receiver must hash for the returned MIC.

The document was published in February 2010 as an Informational Independent Stream RFC. Its IESG note expressly says it is not an Internet Standards Track specification and asks readers to use caution when judging implementation or deployment. That status is itself a useful control: a recognisable RFC number is evidence of a published procedure, not a certificate that every partner implements the same profile.

Compression can sit on either side of the signature

RFC 5402 permits two arrangements when a business document will be signed. A sender may first compress the innermost MIME body and then sign the resulting compressed-data entity. Or it may first create the multipart/signed entity and then compress that outer signed structure. It must not apply both arrangements to the same document. A conforming receiver must be able to unpack either.

Those choices preserve the same business information only after successful reversal. They do not create the same forensic record.

In the first arrangement, the signature covers a MIME entity whose body is CMS CompressedData. The integrity check is bound to that compressed representation. In the second, the signature was made over the uncompressed business MIME entity, and the signature plus its covered content were later enclosed by compression. The returned MIC for a signed message is calculated over the same data that was signed. It can therefore correspond to compressed or uncompressed material depending on the sender's layer order.

A database column called payload_hash cannot represent both cases unless it also records the stage. Two partners can each say “ZLIB supported,” “signature verified” and “MIC matched” while keeping hashes of different legitimate representations. The correct reconciliation question is not “Which hash is right?” It is “Which transformation stage and canonicalization recipe did each hash name?”

The visible document is not necessarily the hashed document

MIME carries headers, boundaries and transfer encodings as well as the text or binary business content a human recognises. RFC 5402's unsigned cases calculate the MIC over uncompressed content including MIME headers and any applied Content-Transfer-Encoding. RFC 4130 also makes canonicalization part of the AS2 calculation rules. RFC 6362 extends the discipline to a whole multipart/related body when several attachments travel together.

This makes a common forensic shortcut unreliable. An operator opens the XML invoice after receipt, hashes the pretty-printed file and expects it to match the MIC. The gateway may have hashed MIME header fields plus encoded content under a prescribed canonical form. Whitespace normalisation, line endings, header order, boundary text, base64 wrapping and transfer-decoding stage can all change the octets without changing the business data that an application displays.

The mismatch does not automatically mean tampering. It may mean that the investigator discarded the evidence recipe. Conversely, a matching hash over a reconstructed display file is not a substitute for verifying the exact signed or specified MIC input.

The receipt record therefore needs the literal input bytes, MIME parsing result, canonicalization rules, transfer-encoding stage, compression placement, signature-covered range, hash algorithm and resulting digest. A label such as documentHash conceals the coordinate that makes the value repeatable.

Base64 moves with the outer visible binary layer

RFC 5402 notes that base64 Content-Transfer-Encoding is required when a compressed binary MIME body is exposed to a seven-bit transport such as SMTP. If that compressed body sits inside an encrypted MIME part, base64 is unnecessary on the hidden compressed layer; it belongs on the outer encrypted body instead.

This is not decoration. It tells investigators which representation actually crossed the transport. A sender can retain source MIME, CMS compressed bytes, an encrypted envelope and the base64 wire form. The receiver can retain the reverse sequence. If both systems keep only the final XML, they lose the ability to prove where a line-ending conversion, transfer-decoding error or truncation occurred.

Layer-aware evidence also prevents a false accusation. A transport relay can legally alter some outer formatting while the protected inner content remains intact. An application can conversely receive a transport-valid message but fail after decompression. Without stage-specific hashes, both incidents collapse into “file changed.”

Algorithm support is not an interoperability receipt

RFC 5402 requires ZLIB support, using the DEFLATE format. RFC 3274 defines the CMS CompressedData type and its algorithm identifier. It even anticipates a small but instructive encoding difference: historical ASN.1 practice means the algorithm's parameters may appear omitted or encoded as NULL, and implementations may encounter either form.

That is the kind of detail hidden by a capability checkbox. Two products can both claim ZLIB and still disagree about MIME nesting, parameter tolerance, canonicalization, maximum sizes, error handling or partner policy. RFC 5402 also requires AS2 or AS3 version 1.1 or greater when its compression methods are used. A version header communicates an intended profile; it does not prove that a particular message was unpacked under that profile.

Prior agreement matters too. RFC 3274 allows compression capability to be indicated through S/MIME capabilities or handled by an interoperability arrangement. Capability advertisement, bilateral permission, configured enablement and observed success are four separate facts. A gateway should not infer authority to introduce compression merely because the peer once advertised a decoder.

A negative signed receipt is still valuable evidence

When decompression fails and a receipt was requested, RFC 5402 adds the disposition modifier Error: decompression-failed to the signed MDN. That response is not a useless failure. Properly verified, it attributes a precise observation to the receiving partner: the gateway received enough of the exchange to issue a signed disposition, but it could not reverse the compression layer.

The failure must remain precise. It does not establish that the business document was semantically rejected, because the receiver may never have obtained it. It does not prove that the sender's source was invalid, because corruption or transformation may have happened later. It does not establish that the trade never occurred through another channel.

RFC 4130 sharpens the point. When a signed receipt was requested but content processing fails, the receiver must still return a signed receipt, while the transaction itself may not be valid. Signing the report authenticates the report. It does not convert failure into success.

Operationally, this means the negative receipt should open a replay path with preserved wire bytes and layer metadata. It should not be translated into a generic “partner rejection” code that invites finance or fulfilment systems to make an unsupported business decision.

Several attachments create one integrity fate and several business fates

RFC 6362 permits multiple payloads inside a multipart/related EDIINT body. It says that for compressed but unsigned traffic, the MIC is calculated over the uncompressed multipart body after the transport's canonicalization. If the expected and calculated MIC differ, all attachments are invalid and must be retransmitted.

That creates aggregate integrity without erasing attachment-level processing. An order XML, a PDF specification and an image can share one transport envelope and one integrity failure. Once a valid group is extracted, however, each file may enter a different parser, validation rule, retention policy and business workflow. RFC 6362 leaves storage and transaction processing implementation-dependent.

A control system therefore needs two levels of identity. The envelope receipt states which attachment set and MIME structure were protected together. Child records then state whether each extracted part matched its declared media type, passed syntax checks and reached the relevant application. One aggregate MIC should not be copied onto every attachment as proof of semantic validity. Nor should one application rejection be rewritten as evidence that the transport MIC failed.

Efficiency also changes the confidentiality boundary

RFC 3274 gives compression a security consequence beyond integrity bookkeeping. Compressing secret material together with attacker-influenced input before encryption can leak information through the compressed length. Encryption can hide the bytes while preserving the size signal created by compression.

This does not prove that every EDIINT use is vulnerable, and the source set provides no evidence of a particular incident. It does prove that encrypted=true and MIC matched do not exhaust the risk review. The organisation must ask which fields share a compression context, who can influence part of the input, whether an observer can compare sizes across trials, and whether padding or separation policies are needed.

The same feature can therefore improve bandwidth and weaken confidentiality in a specific data arrangement. Treating compression as a procurement checkbox leaves that trade-off invisible to security, legal and business owners.

Build the evidence chain before naming the outcome

A defensible record begins with the trading-partner agreement, expected AS version and permitted compression profile. It preserves the source MIME entity and the canonicalization rules. It records the compression algorithm identifier, tolerated parameter form and exact placement relative to signature and encryption.

It then records the bytes signed, signature result, bytes encrypted, decryption result, transfer decoding, decompression output and hash, MIC input recipe and returned digest. The MDN record includes its signature verification, partner certificate context, original message identifier and disposition.

Only then does the application stage begin: enumerate attachments, validate syntax and schemas, correlate the business transaction, apply duplicate controls, obtain authorised acceptance and post the result to the relevant ledger or workflow. Each stage may refer to the same interchange, but none is licensed to borrow certainty from another.

The standards do not establish present-day vendor behaviour, deployment share or a universal commercial rule. Those questions require partner agreements, implementation documentation and production evidence. They establish enough to reject one attractive shortcut: a matching signed MIC is a strong receipt for a declared byte boundary, not a purchase-order approval.