[djc]

First semver-incompatible PR on main for 0.15.0.

Preparation for

• add pluggable crypto provider #450

cc @jgreeer

[cpu]

Preparation for #450

Can you say more about the motivation? The diff doesn't seem completely unreasonable, but it's also making a lot of places throw away a return value from the key generation. It feels mildly like the older approach was a little bit more ergonomic and I'm not sure I'm 100% on what we gain by trading some of that away to not have the KeyPair hold the DER.

[djc]

Preparation for #450

Can you say more about the motivation? The diff doesn't seem completely unreasonable, but it's also making a lot of places throw away a return value from the key generation. It feels mildly like the older approach was a little bit more ergonomic and I'm not sure I'm 100% on what we gain by trading some of that away to not have the KeyPair hold the DER.

In my mind the next step here is getting rid of KeyPair completely in favor of only having Box<dyn SigningKey>, which seems like a mostly unnecessary layer at this point (which would need more complexity with crypto providers). In terms of defense in depth, since rcgen does not need the type capable of signing to also contain a more readable/leakable copy of the private key contents we should probably not retain/hold that by default.