S/MIME sign and immediate verification fails

[Lothar Kimmeringer-4]

Hi,

I'm struggling with this since yesterday and I don't see an error. Attached
you can find my JUnit test class that reproduces the problem I see with my
"real" test case (that's the reason why there is non-ascii data, changing that
to pure ascii has no effect on the problem). Here's what I'm doing:

    - Creating a MimeBodyPart, containing a multipart/alternative block with text/plain
      and text/html data, that has been added to a multipart/mixed block together
      with an attachment containing a text-file
    - Signing the MimeBodyPart the "usual" way, i.e. the way you e.g. find it
      in the example files that are provided with BC itself.
    - Put the resulting MimeMultipart into a MimeBodyPart and use that to
      verify the signature, again the "normal" way.

Whatever I try, I always get a verification check error:

org.bouncycastle.cms.CMSSignerDigestMismatchException: message-digest attribute value does not match calculated value
        at org.bouncycastle.cms.SignerInformation.doVerify(Unknown Source)
        at org.bouncycastle.cms.SignerInformation.verify(Unknown Source)
        at __Run_SMIMESigning.testMailSigning(__Run_SMIMESigning.java:77)

The strange thing is: When I compress before signing, the signature verifcation
check succeeds, the same is the case when I encrypt the signed data afterwards.
I can understand the former in some way but the latter is what I don't get.

I'd really appreciate if somebody can point me where I do something wrong,
because after staring on it for nearly a day, I've gone blind I suppose.


Thanks and best regards,

Lothar Kimmeringer

[Lothar Kimmeringer-4]

Hi,

some correction:

Am 14.06.2019 um 15:44 schrieb Lothar Kimmeringer:

> The strange thing is: When I compress before signing, the signature verifcation
> check succeeds, the same is the case when I encrypt the signed data afterwards.
> I can understand the former in some way but the latter is what I don't get.

I've just realized, that my original test lacked the signed/encrypted
part and after adding it, this one fails, too. So one mystery solved but
my original problem still persists.

Version of BouncyCastle: 1.54

Thanks and best regards,

Lothar Kimmeringer

[Lothar Kimmeringer-4]

Hi again,

some more data points:

  - Bouncy Castle 1.62 leads to the same problem.
  - Only the combination multipart/mixed, containing multipart/alternative
    and an attachment leads to this effect.

For the latter I've extended my test by creating different mail body parts
for signing. All signatures created from these mails successfully verify,
except the "full mail", so I start thinking that I might have found a bug
in BouncyCastle here. Attached you can find a revised version of my test case.

I can open an issue on GitHub if needed.


Thanks and cheers, Lothar

[David Hook-3]

Noticed the git issue. I'll take a look, the test case will help. Out of
interest have you tried this with the non-JavaMail API?

Regards,

David

On 18/6/19 12:52 am, Lothar Kimmeringer wrote:

> Hi again,
>
> some more data points:
>
>  - Bouncy Castle 1.62 leads to the same problem.
>  - Only the combination multipart/mixed, containing multipart/alternative
>    and an attachment leads to this effect.
>
> For the latter I've extended my test by creating different mail body
> parts
> for signing. All signatures created from these mails successfully verify,
> except the "full mail", so I start thinking that I might have found a bug
> in BouncyCastle here. Attached you can find a revised version of my
> test case.
>
> I can open an issue on GitHub if needed.
>
>
> Thanks and cheers, Lothar

[Lothar Kimmeringer-4]

Hi,

Am 21.06.2019 um 09:23 schrieb David Hook:
>
> Noticed the git issue. I'll take a look, the test case will help.

I can write more of them, that check encryption and compression as
well (my original test of my own stuff does that, so it's essentially
copy&paste of existing stuff anyway).

> Out of
> interest have you tried this with the non-JavaMail API?

I'm not aware of a non-JavaMail API and couldn't use it in my
original case because everything is based on JavaMail there.
But if the non-JavaMail API is using SMIMEUtil.outputBodyPart
I expect the same problem, because that's where the linebreak
got lost. I tried to add one myself and it solves the issue
I described here but after that signed/encrypted data stopped
working, so I stopped trying to fiddle with that myself for now.


Thanks and cheers, Lothar