Closed wiktor-k closed 1 year ago
I don't have any hardware to test this change and the missing match arm makes me wonder if there are any other places that this PR needs to touch.
@legounix, @DeppLearning would you be able to review, check or test this PR? Thanks for your time! :pray:
Thanks a lot for you effort, looks fine to me, I have almost the exact changes, only difference is formatting (i.e. alphabetically ordered within enum variants) and some stupidity on my side :D ( see )
I just tested it using SoftHSM and Thales Luna Cloud HSM and can confirm it works for my use case (which is just generating keypairs and signing/verifying)
Yep, seems pretty similar. Thanks a lot for testing! Now I need to grab a couple of reviewers :sweat_smile:
Thanks for addressing this! As much as I dislike people ignoring the spec and doing their own thing while claiming they're compatible with the spec (as it creates fragmentation and some head-scratching), I think it's useful to cover all these cases. One thing I forgot to mention is - could you document somewhere that this isn't part of the spec and that the backend might not understand it?
One thing I forgot to mention is - could you document somewhere that this isn't part of the spec and that the backend might not understand it?
Yep, totally! This is something really important to document.
I've added a note, please check it since I'm no wordsmith :sweat_smile:
Cross checking PRs I found this comment by @legounix that says SoftHSM supports it so I've added a tests case for generating and signing stuff using Ed25519. It took some time aligning the template for key generation so others may find it useful as a source of inspiration :)
This PR replaces #113.
I've added one missing arm in
TryFrom<CK_MECHANISM_TYPE> for MechanismType
and it seems the explicit constantpub const CKM_EDDSA: CK_MECHANISM_TYPE = 0x00001057;
is no longer needed.