SMIME signed message verification

[Michael Richardson]

Harald Koch <root at c-works.net> wrote:
    > my task is to sign a message in C for SMIME exchange, which works as
    > expected and openSSL is self-fulfilling with itself in successful
    > verification (and unsuccessful in produced errors as expected). I've
    > tested PKCS7 SMIME functions, as well as CMS ones, leading to the same
    > result: the reference software endpoints (both written in Java; at
    > least one uses BuncyCastle) are unable to verify the signature. See
    > below the BASE64 blocks of a successful reference signature, and an
    > unsuccessful openSSL variant of the same message, both signed with the
    > same certificate and private key. The error message extracted from the
    > Java implementations are:

I have exchanged CMS signed artifacts with Java implementations.
I have CC'ed the author of the Java code to understand if they use
BouncyCastle or are using an OpenSSL wrapper in Java code.

    > - "Unable to verify content integrity: Missing data"
    > - "The system is unable to find out the sign algorithm of the inbound message"

    > I digged a bit deeper into the ASN1 data („cat signature.base64 | base64 -d | openssl asn1parse -inform DER" ), leading to my assumption that the algorithm provided for signature contained differs:
    > - openSSL indicates „rsaEncryption"
    > - Java indicates „sha512WithRSAEncryption"

The first error you got seems inconsistent with this problem.
Is is possible that one of you are sending CMS structures with out-of-band content?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201029/d3fe3b61/attachment.sig>