Support for more crypto backends

[jcgruenhage]

Motivated by f.ex. #266, it could make sense to introduce additional crypto backends. Candidates I have in mind:

• openssl: Is already in use everywhere anyway and supports everything under the sun, including more niche things like P-521 and Ed448
• RustCrypto: Might not make sense to use. Most of the crates have not seen formal audits, but they do have implementations for most niche things as well, contrary to ring and aws-lc-rs.

My assumption is that this is a no, but I wanted to make sure this assumption is correct instead of just assuming it blindly, which is why I'm opening an issue about it.

[djc]

I think the way forward here is to change the API to rely on a trait, similar to rustls' CryptoProvider and the rcgen SigningKey trait. That way this crate can remain blissfully unaware of other backends.

Implementations should be represented by &'static dyn AccountKey or SigningKey or something like that.

If you have capacity to work on this in the near future, we probably need a semver-incompatible release soon for

• Support challenge types without tokens (including dns-persist-01) #265

[djc]

I guess given that we also need HMAC and digest support, we reformulate our crypto operations in terms of the rustls CryptoProvider, making the rustls dependency mandatory (but keeping the first-party providers optional).

[jcgruenhage]

I have not looked at the rustls CryptoProvider yet, but I'll look into it. It sounds promising, especially because there's already backends built on rustcrypto, openssl and a bunch more which can be re-used here.

[cpu]

I'm generally supportive of the idea of abstracting the cryptography provider but don't think support for things like P-521 or Ed448 are particularly good examples to motivate the work (will comment more on this in #266).

[jcgruenhage]

I've taken a closer look at what things we need in instant-acme and how they are exposed through rustls CryptoProvider. I think it does not make sense to use the rustls CryptoProvider for the following reasons:

• Getting to some things that we need requires a lot of digging. For example, for Sha256 we need to go through cipher suites looking for a trait object implementing Hashwhere based on the cipher we can say that it'll implementsha256`. This works, but I'd really, really rather not.
• For some things I have not found any way to get to them at all, Hmac implementations for example. I don't know how we'd reliably get to an HmacSha256 impl.
• Just having a CryptoProvider available isn't enough: It might not implement required things, even if we had reliable and easy ways to get to them, they might just not be there.
• Some other things are not handled at all. We need a way to transform the key from SigningKey to jwk. This formatting is not something we can deduct from just the SigningKey trait object without enumerating all key types, which I think we want to avoid.
• If we start wrapping the CryptoProvider with additional logic (for example for jwk handling), then we might as well define our own traits/structs, which is a lot cleaner to implement and easier to reason about.
• Last but not least: If we don't have to hard depend on rustls, that's still nice, and given that going through CryptoProvider would not have been just plug and play with existing CryptoProvider implementations, I think we don't gain anything from going through it and can avoid the needless dependency.

[djc]

Fair enough, so the plan would be to do our own crypto provider like traits?

[jcgruenhage]

Yes. I have made quite some progress already on that. It's not quite ready for review yet, but my intention is that I'll push something soon.

[djc]

Sounds great, thanks!