RE: [ebxml-msg-as4] follow-up on Receipts

["Moberg Dale" <dmoberg@axway.com>]

 

1. In case of large payloads, there is a performance problem for generating digests to be included in Receipt for NRR: such payloads would have to be first saved on disk. Indeed, streaming is not sufficient, as it is a read-only-once procedure, and here we'd need two readings: one for creating the digest, the other for delivery.

 

I think this is implementation dependent. Not part of profile. If a computational process can be done faster than IO to a disk or network, then it is not a performance problem in this context. And that will depend on both how it is coded up, what hardware is deployed, and what load is present, etc. Computing digests is generally one of the less expensive operations for security.

 

2. There seems to be a consensus to make the inclusion fo digest(s) optional in the Receipt, e.g. based on agreement (PMode). Rationale: the Receipt serves several purposes (including simple Ack) and in some cases NRR is not the primary concern.

 

OK, but it should be clear that NRR means a signed receipt containing the digest values of the parts.

 

3. "small" documents are expected to be the most common case, when NRR is required. In such cases it is not a problem to compute a hash for each attached payload.

 

? Not sure why this is presumed. Do we need to make this assumption for the profile?

 

4. In case NRR may still be required for large payloads, some alternative solution could be considered for support in AS4: e.g. the original message must be signed. By validating the signature , the receiving MSH (i.e. its Security module) effectively computes a digest. In tightly integrated implementations, could this digest by accessible by the ebms processor? Or, would it be sufficient for NRR to send back in the Receipt the signature of the original message (itself signed over by the Receipt signature), so that the Receiver cannot deny having received the original (signed) message from which this signature was generated?

 

I think that the only thing being specified is what is included in the receipt, and not how the value is found. If your implementation wants to just decrypt the signed digest value and return it, without checking it, the receiver would in effect be vouching for having received some data that it had not really verified. That seems dicey to me. But the spec would be fulfilled by returning evidence that would support a NRR claim. And to just return the encrypted digest would encourage implementations to engage in unwise optimizations (from the perspective of security).

 

For the technical details, as background see:

 

http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf

 

The various ways of describing the plain text that is signed would be what we would reference to explain what the digest is over.

 

I need to check the receipt schema, but we can probably produce an example ds:Reference for each entry in the receipt.

 

 

 

 

Jacques