Open gibbz00 opened 5 months ago
Hey @gibbz00, I'm curious about the use case here. Usually signing keys are somewhat long-lived (at least 24 hours, though typically on the order of months with major OIDC providers), so my assumption was that they'd be generated elsewhere and then loaded from disk or a secrets vault at startup. Would you mind providing a bit more context so I can determine how widely-applicable these changes are likely to be?
Two things that I'm trying to achieve: Creating the signing keys when starting a server. And being able to have access to the original signing key so that it can be used in other libraries (e.g for https://github.com/ramosbugs/oauth2-rs/issues/274).
I'm currently creating the keys myself to achieve this. They are then converted to PEM to be read from PEM again in
CoreRsaPrivateSigningKey::from_pem
. I'm also forced to store both versions of the same key separately.As such, I would like the ability for
CoreRsaPrivateSigningKey
to provide anew_random
constructor, but also a method which exposes the inner signing key. Perhaps unified underPrivateSigningKey
trait methods. Doing so removes the need for users to pull in a bunch of crypto-dependencies themselves, whilst still being able to reuse the private signing in other parts of the rust ecosystem.I would be more than happy to create PRs myself if these features would be appreciated.