-
Notifications
You must be signed in to change notification settings - Fork 8
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
Key generation only gives serialized key, not x/y point. #185
Comments
Hey David! Thank you for raising this issue. I agree that we should be more agnostic to the representation of public keys. That said, we designed the API to deal with byte arrays as much as possible. Couple of options come to mind, Update the pub key input description to something like,
Go the node crypto route and allow both byte arrays and key objects (plus possibly strings, points etc). So something like,
Do let me know if you have a preference between the two. Personally, I'm leaning towards the first one at the moment, since I'm not clear on the advantage of the second. cc @tplooker and @selfissued |
I would generally recommend a more OO approach - have a type in the rust library which privately holds the most appropriate format - and have generators, constructors and accessors which will internally operate based on that type. That also allows you to say have a constructor reject invalid x/y coordinates outright, which then makes this a precondition you can rely on. It seems if you accept a union of types, you'll need this object internally anyway. However, I can understand not wanting to bridge another type based on your wide array of language bindings. |
I would note that we perform this checks internally either way
This is one of my concerns yes. Although I agree that the proposal will be useful, It's hard to justify the required work given that it is not necessary at the moment (since we only support a single curve). I think the best course at the moment could be a utility object/functions to handle the necessary transformations. Would that be acceptable?? |
Given that the key representation at https://datatracker.ietf.org/doc/draft-ietf-cose-bls-key-representations/ uses (x, y) pairs, I believe we need to address this. |
@BasileiosKal and I spoke about this today. He's going to implement utility functions that convert between the key representations. |
The JWK representation described at https://www.ietf.org/archive/id/draft-ietf-cose-bls-key-representations-04.html , no longer uses OKP based on the serialization in pairing-friendly-curves, but x/y coordinates. This is probably best solved by having a
Key
type, possibly with aPrivateKey
type, to represent public and private keys. That way this/these type(s) can handle serialization and initialization from various representations, and can be supplied inside things like theBbsSignRequest
object.The text was updated successfully, but these errors were encountered: