pasetors
pasetors copied to clipboard
Optional serde support for SymmetricKey, AsymmetricSecretKey and AsymmetricPublicKey
I think allowing the keys to be serialized to and deserialized from PASERK strings would make sense.
This would be a follow up to #23.
Yes, I've been thinking about this as well. I'm writing up some thoughts on your PR comments right now. Will submit in a few.
I'd like to pick this up, is there any more information that I'd need?
If you're okay with it, I'd like to contribute support for the remaining PASERK key types, maybe sometime later. Picking this up should get me accustomed to the codebase.
Hi @SanchithHegde,
Great to hear you're interested in this!
[..] is there any more information that I'd need?
I don't know how comfortable you are with Rust, but I'll try to collect what I think the initial thoughts were here. This issues scope includes at least the standard PASERK formats kn.local
/kn.secret
/kn.public
. serde
support should also be gated behind a feature flag, which should require the flag paserk
to be enabled as well (this is a smaller detail).
Additionally, it would probably also be worthwhile to add the optional serde
support for the Id
struct that enables PASERK IDs.
Regarding adding support for other PASERK formats, this would also be nice to have added. Though we should probably have a look at them and prioritize those that make more sense to support first, compared to others. Further, that ought to go into a different issue if we start this up.
If you have any other questions now or later, feel free to ping me.
This issues scope includes at least the standard PASERK formats
kn.local
/kn.secret
/kn.public
.serde
support should also be gated behind a feature flag, which should require the flagpaserk
to be enabled as well (this is a smaller detail).Additionally, it would probably also be worthwhile to add the optional
serde
support for theId
struct that enables PASERK IDs.
Thanks for specifying the requirements, I'll work on it.
Regarding adding support for other PASERK formats, this would also be nice to have added. [...] Further, that ought to go into a different issue if we start this up.
That is indeed what I had in mind as well, let's take it up on a separate issue.