Use GCP Cloud KMS asymmetric signing keys to sign and verify payloads
domain: cloud.google.com · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Create an asymmetric signing key in Cloud KMS, selecting a signing algorithm (e.g., RSA_SIGN_PKCS1_2048_SHA256 or EC_SIGN_P256_SHA256) and protection level
Grant the signing service account roles/cloudkms.signerVerifier on the key; for verify-only workloads, grant roles/cloudkms.verifier
Compute the digest of the data to sign using the algorithm's hash function locally, then call the :asymmetricSign endpoint with the digest — never send the full payload to KMS for signing
Retrieve the public key with :getPublicKey and distribute it (or its certificate) to verifying parties; the private key never leaves KMS
Verifiers use the public key and a standard crypto library to verify the signature locally without calling KMS
Implement key version pinning: verifiers must use the public key corresponding to the key version that was active at signing time; store the key version reference alongside signatures
Known gotchas
Cloud KMS signs the digest, not the raw data; passing the wrong digest algorithm or a pre-hashed value hashed again will produce a signature that does not verify
Public keys are version-specific; if a new key version is created, old signatures must still be verified with the old version's public key — maintain a version-to-public-key mapping
Asymmetric keys cannot be used for symmetric encrypt/decrypt operations; verify the key purpose (ASYMMETRIC_SIGN vs ASYMMETRIC_DECRYPT) when creating the key
Give your agent this knowledge — and 15,600+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?