Hi @est31,

This crate is a valuable part of the Rust X.509/TLS ecosystem and I'm very grateful for the work you've put in. I'm writing this issue to float the idea of collaborative maintenance of rcgen, potentially under the rustls organization banner. Is this something you would be open to?

I think having a community supporting rcgen will help realize some untapped potential:

• Pull request review. We can help get PRs missing review (e.g. Add example of generating a new CA and a new server cert signed by it #99) or requiring a final push (e.g. Enable botan CI on windows #125) across the line. It will also help move larger features (e.g. lib: add cert and CRL distribution point extension support. #136, Certificate Revocation List (CRL) generation support. #128) forward faster.
• Issue triage and support. We can help respond to user questions (e.g. Support for pkcs#1 format #123, Help with loading self-signed CA root certificate #126), and prioritize improvements requested through the issue tracker that may remain.
• Feature gaps. We can help implement making ring optional (e.g. Make ring optional #74), add more examples (e.g. Do we have a complete example #110, API is not very clear about how to sign one Certificate with another one. #89, Add example to demonstrate how to create a CA and a certificate signed with that CA. #79), fix bugs (e.g. serialize_der() regenerates the certificate #62, rcgen should refuse emply subject_alt_names #73), and increase test coverage (e.g. Test that go accepts our generated certs and CSRs #34).

From the Rustls side we can bring a lot of Rust, X.509, TLS, and PKI expertise. We also have resources that can help fund sustained contributions to projects like this as part of a broader mission to replace memory unsafe code in the TLS ecosystem. I see rcgen as an important part of this mission and both @ctz and @djc are supportive of this idea.

Some immediate priorities that come to mind:

• Applying the best practices we use throughout the Rustls ecosystem (applying rustfmt, measuring test coverage, creating smaller modules, documenting a release process, etc).
• Augmenting the parameter struct API model with an easier to understand builder model.
• Implementing a command line tool atop the library ala minica to offer a paved road for consumers to make a quick standalone PKI without writing Rust code.
• Helping tune generated certificates to have no findings/warnings with tools like Zlint.

If you'd like to join the Rustls Discord server we can talk through any hesitations you might have.

Thanks for considering this!