Preserve original compressed attachment bytes for NRR compliance

[shunkica]

Problem

When AS4 compression is enabled (as determined by the PMode), the processing order is Compress → Sign → Encrypt. Digital signatures and NRR receipts are therefore computed over the compressed form of the payload.

However, Phase4 currently treats compressed bytes as transient data — _decompressAttachments() in AS4IncomingHandler replaces the attachment's IHasInputStream with a decompressing wrapper, and the original compressed bytes are discarded. The decompressed bytes become the stored form.

This inverts the AS4 recommendation and creates an NRR gap:

Incoming:

• The SPI handler (handleIncomingSBD) receives only decompressed payloads
• The original compressed bytes no longer exist
• The receiver cannot later verify the digest chain from the senders signature against stored data

Outgoing:

• The access point compresses, signs, and transmits the payload
• The receipt received from C3 contains digest references over the compressed attachment
• The original compressed bytes used for signing are not preserved after sending
• The sender cannot later verify the received NRR receipt against stored data

In both directions, the cryptographic proof is rendered unverifiable because the data it references (compressed bytes) no longer exists. GZIP is non-deterministic, so re-compressing the decompressed payload will not reproduce the original bytes.

AS4 Spec Guidance

The AS4 specification explicitly addresses this:

Access Points SHOULD store compressed payload data for the duration of the period during which access to the source data is needed to handle any non-repudiation disputes.

I realize that AS4 mandates C3 must deliver to C4 the uncompressed bytes, but it does not mandate that the uncompressed form must be stored at C3. The spec recommends the opposite - store the compressed form.

Current Workaround

The only current way to capture original compressed bytes is via IAS4Incoming/OutgoingDumper, which capture the raw MIME wire format. However:

• This is a debugging facility, not a structured API
• It requires MIME parsing to extract the compressed attachment from the raw multipart body
• Message validity/status is unknown at dumping time

Proposed Solution

The compressed payload should be treated as the single source of truth, and the decompressed payload should be treated as transient data - produced on demand for validation and delivery to C4.

Concretely:

1. Preserve the original compressed bytes on the attachment or message state before decompression
2. Continue to provide decompressed bytes to SPI handlers for validation and business processing
3. Expose the compressed bytes to SPI handlers so they can store the canonical form alongside NRR receipts
4. For outgoing messages, similarly preserve the compressed bytes on the sending report so the sender can store them for NRR verification

This way the framework aligns with the AS4 recommendation: compressed bytes are the archival form, decompressed bytes are the operational form.

Related

• Discussion How is NRR supposed to work when compression is enabled? #360 — NRR with AS4 compression
• Discussion How to properly dump i/o messages and as4 receipts? #204 — Message dumping and AS4 receipts
• eDelivery NRO and NRR for data exchanged using AS4 with compression (v1.0)