support for PKCS7_NO_VERIFY in test_support.pkcs7_verify

[zworkb]

This PR adds support for Pkcs7Flags::NOVERIFY so that we can verify pkcs7 signatures without verifying the certificates.

M2Crypto also exposes this option but I would prefer to use cryptography ;)

It is needed when the verifying a signed apple wallet pass. Now I can verify it with the call

    test_support.pkcs7_verify(
        serialization.Encoding.DER,
        signature,
        manifest_json.encode("utf-8"),
        [],
        [pkcs7.PKCS7Options.NoVerify],
    )

without the NoVerify option I get the error:

cryptography.exceptions.InternalError: Unknown OpenSSL error. This error is commonly encountered
...
... (error:10800075:PKCS7 routines:PKCS7_verify:certificate verify error:../crypto/pkcs7/pk7_smime.c:295:Verify error: unable to get local issuer certificate)

The unittests as in

cryptography/tests/hazmat/primitives/test_pkcs7.py

Line 412 in 7a20576

test_support.pkcs7_verify(

use ECPrivateKey but when using RSAPrivateKey I get the above error.

[alex]

test_support.pkcs7_verify is not a public API, so we're not going to take PRs to expand its functionality.

If you're interested in helping us design a public API for PKCS#7 verification, that's something we'd be interested in!

[zworkb]

Currently I am migrating a project from M2Crypto to cryptography. There is an API for verification of pkcs7: https://github.com/eventbrite/m2crypto/blob/0f61819722c07ecffd7cf47c25095b516bf2d85c/M2Crypto/SMIME.py#L207, which is quite similar to test_support.pkcs7_verify.

I am willing to help, but since I am new to the cryptography project I would need some hints what you are expecting from such a public API that exceeds the complexity of M2Crypto's variant

[alex]

That's great to hear re:migration. It's definitely a use case we want to support.

The big thing we'd be looking for in a public API is: Something that fits in place with the rest of our PKCS#7 APIs, something that is general enough to support many different verification use cases, and something that pushes users towards a secure result.

Internal APIs like test_support are really just the bare minimum to write tests, so they're not a good starting point for figuring out what our public APIs should look like.

#11555 is a recent example of working through the API design to add PKCS#7 decrpytion APIs.

[zworkb]

Do you have in mind encapsuling the api in configurable objects as in x509 like
PyServerVerifier/rust and ServerVerifyer/python ?

Additionally I would appreciate some pointers which PKCS#7 verification usecases we should cover for starter.

[nitneuqr]

Do you have in mind encapsuling the api in configurable objects as in x509 like PyServerVerifier/rust and ServerVerifyer/python ?

Additionally I would appreciate some pointers which PKCS#7 verification usecases we should cover for starter.

Hey, I've worked on the new pkcs7_decrypt features the past months.

On my side, my approach was simple: develop something that mimics test_support.pkcs7_decrypt as our own public API, replace the test_support function in our tests, and delete it eventually.

Since decryption is to encryption what verifying is to signing, we should probably adopt the same approach, then improve the function with new features afterwards (maybe PKCS7_NO_VERIFY ?)