PKCS7SignatureBuilder now supports new option NoCerts when signing

[frennkie]

This adds the possibility to add the PKCS7_NOCERTS flag/option (as per PKCS7_sign_add_signer) in order to exclude the signer's certificate.

If PKCS7_NOCERTS is set the signer's certificate will not be included in the PKCS7 structure, the signer's 
certificate must still be supplied in the signcert parameter though. This can reduce the size of the signature 
if the signers certificate can be obtained by other means: for example a previously signed message.

[frennkie]

@reaperhulk I only now saw #5498 and the way you are checking for the presence/amount of the certs:

        assert (
            sig.count(rsa_cert.public_bytes(serialization.Encoding.DER)) == 1
        )

Should I change this PR to use the same method or is my approach acceptable too?

UPDATE: I have changed it.

[alex]

Strictly speaking, this is something that can vary on a per-signer basis. Should this flag be passed to add_signer?

[frennkie]

Strictly speaking, this is something that can vary on a per-signer basis.

Correct.

Should this flag be passed to add_signer?

I would leave it up to you to decide this.

It's the same approach with PKCS7_NOSMIMECAP and PKCS7_NOATTR for which it appears a deliberate decision was made to allow this setting only once for all signers.

As #5498 is now merged it would still be possible to e.g. set the PKCS7_NOCERTS for all signers, but then selectively adding the certificate of one particular signer.

[reaperhulk]

@frennkie we're definitely interested in your opinion on Alex's question. As you no doubt know, since you followed the current implementation exactly, we treat a few per-signer flags as globals right now. We can continue to do this or we can expose it per-signer instead.

My personal inclination is to leave this global and add a per-signer form later if we get requests for it. This form would then be the shorthand for "add the flag to all signers".

[reaperhulk]

Haha, I see we replied simultaneously. Definitely curious if you see a use case right now for it to be per-signer though.

[frennkie]

I absolutely see no use case for per-signer! The reason for this is that my (currently only) use for this is the sending of S/MIME e-mails. And in this scenario I don't see how/why two different signers would sign the same message.

This would be different for e.g. subsequently signing a PDF document by (several) different people.

As outlined above.. the current API covers the "normal use case" by default - and still leaves room for special/edge cases.

[reaperhulk]

Good enough for me! Thanks for working on this @frennkie