Add parameter ecdsa_deterministic_signing to x509 sign methods

[emlun]

Hi! This is a feature I implemented for myself in order to generate reproducible test vectors for W3C Web Authentication (see also the pull request). The feature already exists in the ECDSA layer, so this patch just plumbs it through to the X.509 layer. I named the parameter ecdsa_deterministic_signing to mirror the corresponding deterministic_signing parameter in the ec module, and the ecdsa_ prefix mirroring its sibling parameter rsa_padding.

I tried to get this to work in PKCS7SignatureBuilder.add_signer too, since its sign_and_serialize Rust implementation also has calls that need a new false argument, but didn't manage to get PKCS7SignatureBuilder.sign() to produce reproducible outputs. I think one reason for that is that sign_and_serialize in Rust internally sets the signing time to now(), but making that injectable as a parameter didn't seem to suffice to make the result deterministic. My experiments are available on my wip/pkcs7-sign-ecdsa-deterministic branch in case there's interest in it.

[reaperhulk]

Let's separate whether we want this from the specifics of this implementation. I'm not aware of any security reason to not allow deterministic and we can (mostly) reuse existing implementation. While it's a niche requirement and for leaf certificates you can get the same deterministic behavior with ed25519 keys I think I'm fine with supporting it.

I do wonder if we want to extend the signing APIs this way or if we want to revisit them entirely. It sure would be nice if we were passing the ECDSA(hash, deterministic) structure rather than what we've got now... @alex do you have an opinion?

[alex]

Hmm, on the one hand, I don't love the dangling bool.

On the other hand, passing a full ECDSA() object duplicates the hash algorithm, and then we gotta check that they don't disagree I guess? And we can't just replace the hash with the ECDSA object, because the RSA padding doesn't carry a hash and there's no object that represents both. We kind of failed at symmetry here.

So all the solutions, short of redo signing, feel wrong.

[reaperhulk]

Yeah it seems like we would need to either do some comical overloading of sign such that it can take entirely different arguments in addition to the existing ones, define a new sign method that has a better signature but is functionally identical except for this one feature, or embrace our fate.

[emlun]

Thanks for the replies! Please let me know if you'd like me to do anything here, otherwise I'll wait for y'all to decide how you want to proceed. 🙂