encrypted base64-encoded

[phax]

encrypted base64-encoded

[phax]

When sending something to the Mendelson test server, I'm sending these overall headers:

content-type: application/pkcs7-mime; name="smime.p7m"; smime-type=enveloped-data
subject: AS2 test message from as2-lib
message-id: <github-phax-as2-lib-21082018191418+0200-8636@mycompanyAS2_mendelsontestAS2>
content-transfer-encoding: binary
connection: close, TE
user-agent: ph-OpenAS2/AS2Sender
date: Di, 21 Aug 2018 19:14:19 +0200
mime-version: 1.0
as2-version: 1.1
recipient-address: http://testas2.mendelson-e-c.com:8080/as2/HttpReceiver
as2-from: mycompanyAS2
as2-to: mendelsontestAS2
from: [email protected]
disposition-notification-to: [email protected]
disposition-notification-options: signed-receipt-protocol=required, pkcs7-signature; signed-receipt-micalg=required, sha-384

so I don't see an issue here.

[phax]

Can you please check, if you're payload MIME part also has that Content-Transfer-Encoding. See the following unencrypted example:

content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-384;    boundary="----=_Part_1_197449185.1534872320450"
subject: AS2 test message from as2-lib
message-id: <github-phax-as2-lib-21082018192519+0200-9539@mycompanyAS2_mendelsontestAS2>
connection: close, TE
user-agent: ph-OpenAS2/AS2Sender
date: Di, 21 Aug 2018 19:25:20 +0200
mime-version: 1.0
as2-version: 1.1
recipient-address: http://testas2.mendelson-e-c.com:8080/as2/HttpReceiver
as2-from: mycompanyAS2
as2-to: mendelsontestAS2
from: [email protected]
disposition-notification-to: [email protected]
disposition-notification-options: signed-receipt-protocol=required, pkcs7-signature; signed-receipt-micalg=required, sha-384

------=_Part_1_197449185.1534872320450
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

VGhpcyBpcyBhIHNpbXBsZSB0ZXN0IG1lc3NhZ2UNCkNoZWNrIG91dCBodHRwOi8vZ2l0aHViLmNv
bS9waGF4L2FzMi1saWINCltFT0Zd
------=_Part_1_197449185.1534872320450
Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgIFADCABgkqhkiG9w0BBwEAAKCAMIIC
....
U/8tOAH8vJUd5Vizg3eMtIAigH7UQ6BZotM05+iGKEbnufnidBb6ZetrkPKNBJzEAE3WSR6ZM2Vu
wJzvkEq9eMvrtWQBpvL6gmOUvzGbjhsaNu+87QAAAAAAAA==
------=_Part_1_197449185.1534872320450--

[brianereynolds]

When I use openssl to generate the encrypted file, it automatically adds HTTP headers. E.g.

MIME-Version: 1.0
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m"
Content-Transfer-Encoding: base64

MIJt5wYJKoZIhvcNAQcDoIJt2DCCbdQCAQAxggFEMIIBQAIBADAoMCAxCzAJBgNV
BAYTAkFUMREwDwYDVQQDDAhPcGVuQVMyQQIEUYpVwTANBgkqhkiG9w0BAQEFAASC
.... 

Note this is not a multi-part message, it is the set of HTTP Headers you see above with the remainder a B64 string.

I've tried to send the above message as-is, and tried removing the HTTP headers before sending, but the result is the same - "Malformed Content" on the new SMIMEEnveloped(aPart).

The only way I can get the SMIMEEnveloped to accept the payload is to

• Remove the HTTP headers from the openssl-generated file
• Manually b64-decode it before sending

Note the curl command is always the same.

Trying out the same with the mendelson server, the signed+encrypted message that is sent is actually a multipart message, so this is probably where the difference lies. For S/MIME enveloped-data, Openssl generates a self-contained base64 encoded string, mendelson generates a multi-part message.

I think this difference is referenced in the RFC 2633, section 3.5.

[phax]

I think that AS2 is only about multipart messaging.
The title of RFC 4130 is:

MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)

See the variations from RFC 4130 section 4.2

 No encryption, no signature
      -RFC2616/2045
         -RFC1767/RFC3023 (application/EDIxxxx or /xml)

   No encryption, signature
      -RFC2616/2045
        -RFC1847 (multipart/signed)
          -RFC1767/RFC3023 (application/EDIxxxx or /xml)
          -RFC3851 (application/pkcs7-signature)

   Encryption, no signature
      -RFC2616/2045
        -RFC3851 (application/pkcs7-mime)
          -RFC1767/RFC3023  (application/EDIxxxx or /xml)(encrypted)

   Encryption, signature
      -RFC2616/2045
        -RFC3851 (application/pkcs7-mime)
          -RFC1847 (multipart/signed)(encrypted)
            -RFC1767/RFC3023  (application/EDIxxxx or /xml)(encrypted)
            -RFC3851 (application/pkcs7-signature)(encrypted)

   MDN over HTTP, no signature
      -RFC2616/2045
        -RFC3798 (message/disposition-notification)

   MDN over HTTP, signature
      -RFC2616/2045
        -RFC1847 (multipart/signed)
         -RFC3798 (message/disposition-notification)
         -RFC3851 (application/pkcs7-signature)

So I see no variation without MIME

[brianereynolds]

OK, the items listed in section 4.2 seem pretty clear.

But in practical usage, using the BC SMIMEEnvelopedGenerator along with JceCMSContentEncryptorBuilder to encrypt a MIME message will generate same as what openssl does (example)

I see AS2SenderModule.encrypt uses this code. In truth, I haven't tried to use the AS2SenderModule at all (I'm just interested in receiving messages), but I would expect that if the partnership includes an encryption algorithm => AS2Sender encrypts a message (thus using BC SMIMEEnvelopedGenerator).

[phax]

The example code you are mentioning does it exactly as it is done in as2-lib.
If I however use the Content-Transfer-Encoding base64 I'm getting a MIC mismatch from Mendelson.
Can you please try to use the CTE binary instead?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.