I've just done a quick encrypt/decrypt test against AWS with a patched step-kms-plugin, and it looks OK 🙂

$ step-kms-plugin encrypt --oaep --in message.txt --no-label --kms 'awskms:' 'awskms:key-id=<key-id>;region=<region>'
// encrypted output in base64 format

$ step-kms-plugin decrypt --oaep --in encrypted.bin --no-label --kms 'awskms:' 'awskms:key-id=<key-id>;region=<region>'
// decrypted output

I've just done a quick encrypt/decrypt test against AWS with a patched step-kms-plugin, and it looks OK 🙂

$ step-kms-plugin encrypt --oaep --in message.txt --no-label --kms 'awskms:' 'awskms:key-id=<key-id>;region=<region>'
// encrypted output in base64 format

$ step-kms-plugin decrypt --oaep --in encrypted.bin --no-label --kms 'awskms:' 'awskms:key-id=<key-id>;region=<region>'
// decrypted output

Yup I confirm. The only requirement is to have an RSA key configured with Key Usage: Encrypt and decrypt and not Sign and Verify :)

Yup I confirm. The only requirement is to have an RSA key configured with Key Usage: Encrypt and decrypt and not Sign and Verify :)

Indeed. I've seen that before with GCP Cloud KMS, and is considered a good practice. In its current form we generally don't check the key capabilities in the KMS implementations before performing crypto operations. An invalid key will thus result in an error upon trying a decryption, whereas it may be an option to check the capabilities before trying to use the key for a purpose it's not configured for. Maybe we'll add something for that in the future 🙂

For your use case you'll thus need the SCEP decrypter configured in addition to the RSA intermediate for signing. If the rest of your stack allows for it, you could also opt for an ECDSA intermediate signer, and the RSA SCEP decrypter.

Is seems there's a lot of places where a new context pops out instead of being propagated. Is that intentional?

Is seems there's a lot of places where a new context pops out instead of being propagated. Is that intentional?

These are the two I see:

• There's no DecryptContext(ctx context.Context, ...) in the stdlib, so it has to come from somewhere when calling a function that expects one when it's being called through the crypto.Decrypter interface. Injecting a parent context during instantiation is possible, but wouldn't be a properly propagated context in that case.
• For preloadKey we maybe can provide an alternative, but I don't consider that part of the scope of this PR. There's an open issue to make initialization of a KMS lazy, and I suspect we may want to touch on context.Context usage there too.