Support CryptoProvider like plugin mechanism

[howardjohn]

rustls/rustls#1540 in rustls provides a mechanism to plug in arbitrary crypto providers. While the in-tree ones only have ring and aws_lc_rs, mirroring rcgen, there are out of tree providers that can be used. However, if an application depends on rcgen, these benefits are negated (assuming a project requires all crypto to be done by a specific implementation).

It would be nice to have a pluggable model.

[howardjohn]

Ah I missed #208 which is a step in the direction (sort of)

[cpu]

I personally think this makes sense to implement and see #208 and #223 as steps in that general direction. I think there are some other old issues that would benefit from a solution here too (e.g. #60, #74)

Are you interesting in contributing a PR for something analogous to the rustls CryptoProvider trait?

[HKalbasi]

I would like to work on this. Does it make sense to share (part of) this trait with the rustls? For example KeyProvider seems relevant.

[djc]

What is your motivation to work on this/what's the use case/what problem are you trying to solve?

[HKalbasi]

My motivation is basically #60. Latest time I used rcgen, it was unable to create certificate with some specific crypto algorithm, so I kept a C++ dependency which I want to remove in long term and replace it with rcgen.

[est31]

Having the ability to add support for unknown algorithms is a different use case from wanting this plugin mechanism to use one specific crypto implementation.

I think the best way forward is to ask the aws_lc_rs bindings crate to extend the API to the algorithms you require, and rcgen can then add support for those algorithms in the main branch.

[djc]

@HKalbasi which algorithm(s) do you need?

[HKalbasi]

I thought this issue is precondition to using aws_lc_rs in rcgen. It has been a while since latest time I tried rcgen, now that aws_lc_rs is supported, it might be possible that now my problem is resolved. I will retry and ask the aws_lc_rs if the algorithm was not supported.