Open
Conversation
|
+1 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Try implementing hs2019 support (using PSS).
I've been reading through both these drafts:
But still find it a bit confusing on how the digital signature algorithm should be derived from keyId in a good way both at the client and at the server side (funny the same confusion is stated in this appendix B.1.1.1)
Right now I've only added support for PSS algorithm, other algorithms can simply be added by creating new structs in the
hs2019.gofile. I was thinking that as the client will chose the algorithm and use the correcths2019struct, the server can then look up the algorithm in theKeyGetterimplementing struct (just like for the key data) and verify the signature using the newGetKeyAlgorithmfunction (this will be a breaking change for structs implementing this interface today, the whole new draft version feels a bit breaking with the new way of specifying the algorithm).Hope I haven't misunderstood the new draft version completely, all change requests and help is appreciated.
Related issue: #7
As all the other algorithms have now become deprecated it would probably be a good idea to remove them entirely. But in order to not introduce even more breaking changes I've kept them and just added a deprecation message to update the algorithm to
hs2019if any other version is used. Guess this will also collide with #6The removal can then be done in a second step (after users of this lib get some time to migrate to the new algorithm)