-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for borrowed RemoteKeyPair
#212
Conversation
ccdfaf3
to
f334ef6
Compare
I've submitted #213 which I think provides a simpler way to satisfy your use case. Would be happy to get your feedback. |
Yeah I also prefer #213 I think. |
As an alternative to #212, this goes further in the direction of #205, removing `alg` and `key_pair` from `CertificateParams` and requiring the caller to pass in a reference to them when signing. This seems to have a number of nice properties: * `alg` is derived from the passed in `KeyPair`, so key algorithm mismatch errors can no longer occur * No need for passing in a signing algorithm when parsing from pre-existing parameters or key pairs * Should make it easy to support long-lived (remote) key pairs The main downside as far as I can see is that the top-level API gets a bit more complicated, because generating a `KeyPair` must now be done by the caller, and for now we force them to pick a signing algorithm. I think we might mitigate this by adding a no-argument constructor like `generate_default()` (or use `generate()` for the no-argument variant and `generate_for()` for the variant that requires an argument). Generally, this feels like a clear improvement in the API's design to me.
@corrideat Does #213 meet your needs? Can this PR be closed? |
Since there are conflicts and I believe #213 meets the required need I'm going to close this PR. Feel free to re-open with the conflicts resolved if you think there's an outstanding need to be addressed. Thanks for the PR! |
This implements #211