Description
When the http response with an MDN is received it is parsed to a MultipartSignedEntity-object.
When the object is serialized back to an outputstream using the method AS2MessageDispositionNotificationEntity#writeTo the string is not guaranteed to be identical to the the string received in the original http-response.
This makes it impossible to calculate an correct message-digest and the method MultipartSignedEntity#isValid returns false because the following exception is thrown:
"org.bouncycastle.cms.CMSSignerDigestMismatchException: message-digest attribute value does not match calculated value"
when calling:
signer.verify(new JcaSimpleSignerInfoVerifierBuilder().setProvider("BC").build(cert)
I tried to use the AS2-client to send messeages to both IBM Datapower and ArcESB and it was not possible to validate the MDN from neither of them.
A few examples of differences between the actual received string and the reconstructed string are (see the full examples further down):
- The order of the fields in the disposition-notification was in the wrong order:
In the original string they where ordered as follows:
Reporting-UA
Original-Recipient
Final-Recipient
Original-Message-ID
Disposition
Received-content-MIC
But in the reconstructed string the field Original-Recipient had been moved down and was placed before Received-content-MIC. - Received-content-MIC returned from both Datapower and ArcESB had a space between the comma-sign and the algorithmId.
In the reconstructed string the space-character was removed.
According to the example in RFC4130 (https://datatracker.ietf.org/doc/html/rfc4130) is seems as if it should be ok to have a space-character. - In the MDN from ArcESB the field Received-content-MIC the word content was written with a capital 'C' i.e. Received-Content-MIC.
I'm not sure if that is valid according to the standard or not.
The actual string received in the http-response:
Content-Type: multipart/report; report-type=disposition-notification; boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3 --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3 Content-Type: text/plain; charset=us-asciiThis MDN response message is for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4yxk@camel.apache.org> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3 Content-Type: message/disposition-notificationReporting-UA: DataPower Original-Recipient: rfc822; "TEST" Final-Recipient: rfc822; "TEST" Original-Message-ID: <52vncg5lq4.1sqyji9ko4yxk@camel.apache.org> Disposition: automatic-action/MDN-sent-automatically; processed Received-content-MIC: vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==, sha-512 --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3--
The String reconstructed from the MultipartSignedEntity:
Content-Type: multipart/report; report-type=disposition-notification; boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3 --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3 Content-Type: text/plain; charset=us-asciiThis MDN response message is for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4yxk@camel.apache.org> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3 Content-Type: message/disposition-notificationReporting-UA: DataPower Final-Recipient: rfc822;"TEST" Original-Message-ID: <52vncg5lq4.1sqyji9ko4yxk@camel.apache.org> Disposition: automatic-action/MDN-sent-automatically;processed Original-Recipient: rfc822; "TEST" Received-content-MIC: vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,sha-512 --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3--
In order to always being able to calculate a correct digest the original string that was signed should be preserved as is.
Attachments
Issue Links
- relates to
-
CAMEL-18917 camel-as2 - Signature is not validated
-
- Resolved
-
- links to