-
Notifications
You must be signed in to change notification settings - Fork 146
spki: make SubjectPublicKeyInfo
own the public key
#778
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
spki: make SubjectPublicKeyInfo
own the public key
#778
Conversation
NOTE: breaking change. Previously `AlgorithmIdentifier::parameters` were always `AnyRef`. This commit changes them to a generic parameter `Params`. An alias `AlgorithmIdentifierRef` provides a type identical to the original with `AnyRef` as its `parameters`, which is used in all of the other crates in this repo.
6adaae7
to
1efe27a
Compare
spki/src/spki.rs
Outdated
#[derive(Copy, Clone, Debug, Eq, PartialEq)] | ||
pub struct SubjectPublicKeyInfo<'a, Params> { | ||
#[derive(Clone, Debug, Eq, PartialEq)] | ||
pub struct SubjectPublicKeyInfo<Params> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This obviously doesn't work as this, the intention was to remove the lifetime from here, maybe I should add a parameter like
pub struct SubjectPublicKeyInfo<Params> { | |
pub struct SubjectPublicKeyInfo<Params,Pkey> { |
And consume that as a
SubjectPublicKeyInfo<Any,BitString> // Owned version
pub type SubjectPublicKeyInfoRef<'a> = SubjectPublicKeyInfo<AnyRef<'a>,BitStringRef<'a>> // zero copy version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It definitely needs a generic parameter so as to continue supporting a heapless profile.
I was thinking of using a generic Bits
parameter with &[u8]
and Box<[u8]>
type aliased as you propose. The former could be aliased as something like type SubjectPublicKeyInfoOwned
.
There's a potential argument to be made that using a BitString*
type is semantically more correct, although I'm not aware of any public key formats which aren't octet-aligned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went with BitString
/BitStringRef
to stick as close as possible to the RFC definition.
I can reuse the Bytes
type I introduced in #771
This was definitely my next planned followup to #769, but if you want to work on it in parallel that's cool. |
haha :) I missed that! sorry. |
763cc8f
to
b259658
Compare
b259658
to
25b9e19
Compare
b09ff11
to
d6741cb
Compare
@baloo this was closed by way of me deleting the |
yup, that took me some time to clean my changes. |
This is based on #769