-
Notifications
You must be signed in to change notification settings - Fork 62
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
Add support for asymmetric keys to the transit client #93
Comments
MattDavis00
added a commit
to MattDavis00/vaultrs
that referenced
this issue
May 13, 2024
…route Previously the route assumed a symmetric key's creation unix timestamp would be returned. For asymmetric keys the response differs; it returns the creation RFC3339 timestamp, public key, and key type. Mentions jmgilman#93. Signed-off-by: Matt Davis <[email protected]>
This commit fixes my initial problem of not being able to deserialize the public key data from the response: |
MattDavis00
added a commit
to MattDavis00/vaultrs
that referenced
this issue
May 17, 2024
…route Previously the route assumed a symmetric key's creation unix timestamp would be returned. For asymmetric keys the response differs; it returns the creation RFC3339 timestamp, public key, and key type. Mentions jmgilman#93. Signed-off-by: Matt Davis <[email protected]>
Can you please add a pull request with the commit? |
MattDavis00
added a commit
to MattDavis00/vaultrs
that referenced
this issue
Aug 20, 2024
…route Previously the route assumed a symmetric key's creation unix timestamp would be returned. For asymmetric keys the response differs; it returns the creation RFC3339 timestamp, public key, and key type. Mentions jmgilman#93. Signed-off-by: Matt Davis <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the
read
andexport
functions for the transit client do not support asymmetric keypairs.The read response fails to deserialize, as the response differs for symmetric vs asymmetric keys.
Asymmetric read response:
This does not follow the
"{key_id}": {unix_timestamp}
format that symmetric keys use, and hence does not deserialize.A similar issue for the export route exists, where the only supported key types are:
Where
PublicKey
is omitted.It would be nice to support asymmetric keys; I will probably start working on some basic support in a fork, and see how I get along.
The text was updated successfully, but these errors were encountered: