How is NRR supposed to work when compression is enabled?

[shunkica]

I'm trying to understand how non-repudiation of receipt (NRR) is intended to work end-to-end when compression is enabled in the PMode.

The AS4 spec mandates Compress - Sign - Encrypt on the sending side, and phase4 follows this correctly. This all makes sense and the real-time signature verification at receipt time works correctly - the signature is verified against the compressed bytes before decompression occurs.

However, after the message is processed, the compressed payload bytes are discarded. If a non-repudiation dispute arises after the fact, the receiving AP has a signed receipt containing digest values that cannot be verified against any stored data, because the compressed form of the payload no longer exists.

I noticed in Discussion #204 that IAS4IncomingDumper captures the raw wire message before decompression, which could theoretically be used as a workaround. But this seems like a debugging facility rather than a structured approach to NRR evidence preservation.

[phax]

The mechanism works as a cryptographic chain of evidence linking the original message to its receipt:

Step 1 — Sender signs the User Message

The sender computes SHA-256 digests of the signed elements (the eb:Messaging header and the payload), lists them as ds:Reference entries inside ds:SignedInfo, and signs that SignedInfo block with their private key. The resulting ds:Signature in the User Message now contains a ds:SignedInfo with digest values that cryptographically bind to the exact content sent.

Step 2 — Receiver builds the Receipt

After successfully verifying the signature and processing the message, the receiver constructs an eb:Receipt signal. The critical part is the ebbpsig:NonRepudiationInformation element inside it. This element contains copies of each ds:Reference from the original message's ds:SignedInfo — meaning the digest algorithm, the digest values, and the transform chain are carried over verbatim. The receipt also includes eb:RefToMessageId pointing back to the original eb:MessageId and the date and time when the receipt was created.

Step 3 — Receiver signs the Receipt

The receiver signs this entire receipt with their own private key, producing a second independent ds:Signature.

What this proves

The sender now holds a document (the signed receipt) where:

• The receiver's signature proves the receipt is authentic and untampered — the receiver can't deny producing it
• The embedded digest values from the original ds:SignedInfo prove which specific message content the receiver is acknowledging — you can match them against the original message's digests
• The eb:RefToMessageId ties it to a specific message exchange
• The eb:Timestamp establishes when

If a dispute arises, the sender can present the original signed message and the signed receipt. A third party can independently verify both signatures, confirm the digest values in the receipt match the digests in the original message's signature, and thereby confirm that the receiver acknowledged receipt of that exact content. Neither party can repudiate their part — the sender can't deny sending (their signature on the message), and the receiver can't deny receiving (their signature on the receipt containing the original digests).

[shunkica]

I understand this, but this does not account for the compression layer.

C1 -> generates and submits XML file to C2
C2 -> compresses the XML, and calculates a digest over the compressed payload
C3 -> receives the compressed payload, returns a NRR to C2, and then decompresses the payload and gives the XML to C4

Since neither C1 or C4 (more importantly C1) have the exact payload which was transferred (because they are not in the posession of the gzipped data, and gzip is non-deterministic, meaning it cant be recreated), all they have is proof that something was sent and delivered, not that the exact XML file they sent/received.
And since C2 and C3 do not deterministically store the compressed payload, instead treat it as a temporary file, the actual payload is lost.

From AS4 spec:

The output of GZIP compression varies depending on implementation or parameters settings. When using AS4 compression, 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.

[phax]

Sorry for not capturing your initial focal point.
This topic has already been discussed in the community as you can see from the attached document:
(eDelivery).(NRO and NRR for data exchanged using the eDelivery AS4 with compression).(v1.0).pdf

Unfortunately this is problem still remains - not just in the Peppol Network. If this is of relevance to you, I suggest you file an RFC towards your Network Owner to deal with that in larger scope.

[shunkica]

Does phase4 follow the AS4 spec recommendation of storing the compressed payload data for legal reasons?

Because It seems to me like this is only possible by using IAS4IncomingDumper and IAS4OutgoingDumper, and the problem with these is that it is not yet clear if the message is valid or not at that point, and there is no receipt yet.

Basically what I want to create is an archive which will contain the original (compressed) payload, the signature of the C2 over this payload, and the NRR from C3 for that message, creating a fully self-contained document+NRR capsule.

[phax]

I don't think there is yet a callback to retrieve the "compressed only" document. Can you please create a ticket for that - thanks