Abstract signing cryptography

[puiterwijk]

This allows implementing signing and verification with more than openssl
PKey(Ref), like a TPM or AWS KMS keys (#5).

It implements the abstracted methods for PKeyRef, and PKey calls out to
PKeyRef.

Signed-off-by: Patrick Uiterwijk patrick@puiterwijk.org

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the Apache License Version 2.0, as specified in the LICENSE file of this repository.

[puiterwijk]

The way it is implemented with traits and impls for PKeyRef and PKey, it is still compatible with the old API (it should not be needed to update existing code that is using this).

[petreeftime]

Nice! I actually had something similar in the works, but with dyn Traits instead, so that you could potentially use more than one crypto provider at a time. Seemed useful to have both AWS KMS and OpenSSL, for example; but since this is complete, I am inclined to merge this instead and maybe rework it later on.

[petreeftime]

Actually, this seems to be very similar indeed. Will need to go through a more thorough review, since it's a pretty large change.

[puiterwijk]

@petreeftime thanks. Let me know if you want me to rebase this patch.

Also, I submitted implementations for KMS and TPM, but I think those might very well be better positioned as external crates (e.g. aws-nitro-enclaves-cose-tpm), so that it's easier to maintain by other folks if you aren't interested in maintaining the TPM implementation (I'd be happy to maintain that crate separately).
Luckily that is totally possible with this implementation: any external crate can implement this trait.

I mostly submitted those two implementations to show off that this trait implementation makes that absolutely possible.

[puiterwijk]

I just rebased this on the current main branch.

[puiterwijk]

I fixed the clippy needless borrows in this PR, since this PR would again have merge conflicts if it goes in after fixes for that were to go in.

[jethrogb]

Can you make openssl an optional dependency?

[petreeftime]

I think this would make more sense when we add a secondary crypto provider such as ring.

[jethrogb]

The traits as proposed in this PR can immediately be implemented by external crates, so I don't see why the OpenSSL dependency should be required.

[puiterwijk]

So, openssl itself is still needed for encryption (which I did not abstract in this PR), and we still use it for things like computing digests before passing them to the crypto layer.

[puiterwijk]

I have submitted #28, which makes openssl a fully optional dependency (well, it is abstracted away, right now it's the only crypto implementation and you'll need one).

[petreeftime]

@petreeftime thanks. Let me know if you want me to rebase this patch.

Also, I submitted implementations for KMS and TPM, but I think those might very well be better positioned as external crates (e.g. aws-nitro-enclaves-cose-tpm), so that it's easier to maintain by other folks if you aren't interested in maintaining the TPM implementation (I'd be happy to maintain that crate separately).
Luckily that is totally possible with this implementation: any external crate can implement this trait.

I mostly submitted those two implementations to show off that this trait implementation makes that absolutely possible.

I don't see a reason why the TPM implementation couldn't be maintained here, I don't think it would end up being touched too much after the inital implementation. If this doesn't work out for whatever reason, we can figure out if we can be moved somewhere else instead. I think all we need to do in that case is to have the interface for the PrivateKey and PublicKey as public.

[puiterwijk]

The error is due to bitflags 1.3.0, 1.3.1: that now has a MSRV of 1.45, 1.46, which was released Aug 11, 22:52, Aug 12, 03:34.