Vault docker container does not return public key for ed25519 vault transit keys

[Ruddickmg]

Describe the bug
The vault docker container does not return the public key for keys created in the vault transit engine

To Reproduce
Steps to reproduce the behavior:

1. Enable transit vault secrets enable transit.
2. Create key vault write transit/keys/my-key type="ed25519" derived=true
3. Attempt to retrieve the public key vault read transit/keys/my-key
4. See output with an empty value for public_key :

Key Value

---

allow_plaintext_backup false
auto_rotate_period 0s
convergent_encryption false
deletion_allowed false
derived true
exportable false
imported_key false
kdf hkdf_sha256
keys map[1:map[certificate_chain: creation_time:2025-10-03T03:31:26.850259447Z hybrid_public_key: name:ed25519 public_key:]]
latest_version 1
min_available_version 0
min_decryption_version 1
min_encryption_version 0
name my-key
supports_decryption false
supports_derivation true
supports_encryption false
supports_signing true
type ed25519

Expected behavior
The public key should be returned in the vault read transit/keys/my-key response as detailed in the vault documentation that states "an asymmetric key will return its public key in a standard format for the type."

Environment:

• Vault Server Version (retrieve with vault status): 1.20.4
• Vault CLI Version (retrieve with vault version): v1.20.4
• Server Operating System/Architecture: linux x86 (ubuntu latest) running in docker v27.3.1

Vault server configuration file(s):

docker hcl config

listener "tcp" {
  address = "0.0.0.0:8200"
  tls_disable = true
}

[VogonAnthology]

No, the public key will not be exposed for a ed25519 derivation key (derived set to "true"). There is no usecases I could thing of where you would need to get the public key of derivation key, it is nonetherless available using "vault transit/export/public-key/:name".

Or if you are not using it as a derivation key (using "context" to generate derived keys, whose are the ones you would usually use their public key), I suggest you to leave/set "derived=false", you will then get the public key using "vault read transit/keys/:name" as expected.

[Ruddickmg]

No, the public key will not be exposed for a ed25519 derivation key (derived set to "true"). There is no usecases I could thing of where you would need to get the public key of derivation key, it is nonetherless available using "vault transit/export/public-key/:name".

Or if you are not using it as a derivation key (using "context" to generate derived keys, whose are the ones you would usually use their public key), I suggest you to leave/set "derived=false", you will then get the public key using "vault read transit/keys/:name" as expected.

My main use case for this is testing - making sure that the signature generation and/or validation logic of my application is working correctly by validating against the public key of the derivation key (without needing to know the derived key)

[VogonAnthology]

I don't see the point in "making sure that the signature generation works" this particular way, just call the sign method and catch the response... I'm probably missing something here.

If your only concern is to make sure that the derivation key is the "right one", as in "checking it hasn't somehow changed", why would it ? If you need to identify the right one between versions, you can just save the the name+version.

Anyhow, as said in previous reply, the derivation key's public key is available with :

• transit/export/public-key/:name (even works with exportable set to false)

Another way would to get a reliable/deterministic public key would be to use the sign method with an arbitrary context and input...