Skip to content
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

Open
MattDavis00 opened this issue May 13, 2024 · 2 comments
Open

Add support for asymmetric keys to the transit client #93

MattDavis00 opened this issue May 13, 2024 · 2 comments

Comments

@MattDavis00
Copy link
Contributor

Currently the read and export 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:

// vault@926ee8c21172:/$ curl -XGET --insecure --silent -H "X-Vault-Token: $VAULT_TOKEN" $VAULT_ADDR/v1/transit/keys/my-new-key
{
    "request_id": "b59d5612-b16f-8742-641c-32e29943433f",
    "lease_id": "",
    "renewable": false,
    "lease_duration": 0,
    "data": {
        "allow_plaintext_backup": false,
        "auto_rotate_period": 0,
        "deletion_allowed": false,
        "derived": false,
        "exportable": false,
        "imported_key": false,
        "keys": {
            "1": {
                "creation_time": "2024-05-10T13:36:49.809157592Z",
                "name": "rsa-2048",
                "public_key": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA01QgwZl/tD7cWZl1NPQ2\nG8+cvI6KkF+wB94xfatdKJ07Ga0bsqYaeE98ZUZU7amRH9Kmdz/4Cu9xXdwlosSS\ntedXfRT8zcWpqEUpV4c4/lT/ox6W67KW2l44liiVt2f9PmviRoYclNWUJa6X+ZCU\n68p/Rd9RSb/xBsywTb8uJN1Q1cZM2JbKhWnaLa7jPsXG9hvnxJ2QFuN3+iZ2OCff\nCjhl0Anumc7lL6wEU/Yd1WuX+5afcHaGttHkWAasrhq3KFHhXlwf4+jrJ5C+aOfb\nevJgGUYjXgf4buV3sPFVmnhvyiyyEV/CysNbXx3KrI/OGgf7HQ+f3+hnpomo8lhd\nwwIDAQAB\n-----END PUBLIC KEY-----\n"
            },
            "2": {
                "creation_time": "2024-05-10T13:36:49.878041842Z",
                "name": "rsa-2048",
                "public_key": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7Ttq3kD0Tev7uWnupVGS\neGl4IURKqiUpoPKdevpnYTfuKt/MVP9Ej1Qz7XOP3q6mC3Vb0mSK+6FNjWNakd7D\nQecJwVFuZXp4lF8uzTF5xXFiPiiw5WMS7v7oNmzTE15Msse1yLHcxQGveeRmrl1L\nTYzcLHb705AzgeXoHqLNNWfTC72fqlPhMvOIcWyWOatz/Dp9ukfcR7HAmxhlpluY\n8e+lift8xah4uQFFDuIwXBQ7f5G8+j9RKMyWjA8pv/pY12jDl/vOi6V2b5YJvJie\nVV9gNa1+9JjamG1bsmHYhRIK0rBTewdvD3Tyg+T8Yl5HQNqkIvdwaBZ/RIc+PVeI\ndwIDAQAB\n-----END PUBLIC KEY-----\n"
            },
            "3": {
                "creation_time": "2024-05-10T13:36:49.958724342Z",
                "name": "rsa-2048",
                "public_key": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5FQYHEs8U1QsnkTMDrB\n6MfpGK1eVdS84FepYyvpA//suDbJGS9l6XP333wuebwoTL42B5qiZ1tudbIeOWaK\nBDQ5dfjbjRB87k/h4nuQ2DNEUwhgVPjxS3XEocefVWxCfmwQqTjSvhVX2l3DmWiE\n1b/vgikBcYxkqTDTUytuN+IbvZmkFzcM+20UaemRQ5VeNP2MEjZsX4cBATFMkC6k\nYoXb3r+SeKd5JDp/qCSUeabkaxBoV1MprXCy8sEgxSEn/1SGOlVQvB9COQQ/Y/bq\nHQUNGKgrQWGXh4W+Uz4C/GIsKosVuTcGV/o/eONg5uft958NTa1vf93XaKpLOlbw\nOQIDAQAB\n-----END PUBLIC KEY-----\n"
            }
        },
        "latest_version": 3,
        "min_available_version": 0,
        "min_decryption_version": 1,
        "min_encryption_version": 0,
        "name": "my-new-key",
        "supports_decryption": true,
        "supports_derivation": false,
        "supports_encryption": true,
        "supports_signing": true,
        "type": "rsa-2048"
    },
    "wrap_info": null,
    "warnings": null,
    "auth": null
}

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:

pub enum ExportKeyType {
    EncryptionKey,
    SigningKey,
    HmacKey,
}

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.

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 <mattdavis@cloudflare.com>
@MattDavis00
Copy link
Contributor Author

This commit fixes my initial problem of not being able to deserialize the public key data from the response:
MattDavis00@253523b

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 <mattdavis@cloudflare.com>
@Haennetz
Copy link
Collaborator

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 <mattdavis@cloudflare.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants