Make it possible to use this library with only roles/cloudkms.signerVerifier permissions

[stanhu]

I'm trying to use osslsigncode to sign a binary. On a Debian system this invocation looks like:

osslsigncode sign -h sha256 \
  -pkcs11engine /usr/lib/x86_64-linux-gnu/engines-3/pkcs11.so \
  -pkcs11module /usr/local/lib/libkmsp11.so \
  -key "pkcs11:object=example-key" \
  -certs test.crt -in test.bin -out test.signed.bin

I would expect that the roles/cloudkms.signerVerifier role would be sufficient here. However, it is not. https://cloud.google.com/kms/docs/reference/permissions-and-roles shows that roles/cloudkms.signerVerifier has the following IAM permissions:

• cloudkms.cryptoKeyVersions.useToSign
• cloudkms.cryptoKeyVersions.useToVerify
• cloudkms.cryptoKeyVersions.viewPublicKey
• cloudkms.locations.get
• cloudkms.locations.list
• resourcemanager.projects.get

As documented in https://github.com/GoogleCloudPlatform/kms-integrations/blob/6529ddfd020fa6655c153c0e66bed9176ab68e78/kmsp11/docs/user_guide.md#authentication-and-authorization, this library needs the IAM permissions cloudkms.cryptoKeys.list and cloudkms.cryptoKeyVersions.list.

https://github.com/GoogleCloudPlatform/kms-integrations/blob/6529ddfd020fa6655c153c0e66bed9176ab68e78/kmsp11/docs/user_guide.md#configuration says that at least 1 key_ring must be defined. It wasn't clear to me whether specifying CKA_LABEL or CKA_ID would skip the loading of the key ring.

[tdbhacks]

Fair question, the tricky part is the underlying object model that was chosen when this library was first created. Behind the scenes, the library recursively builds a token / object list, with each object representing a KMS symmetric / private / public key. As part of that we use List* calls (hence the need for cloudkms.cryptoKeys.list and cloudkms.cryptoKeyVersions.list), regardless of the specific way in which the library is being invoked, since this all happens during library initialization when the user config is being parsed.

We might be able to shift away from this object model through some significant changes on how we load CryptoKeyVersions, if feasible, but we don't plan on doing so for now.

[stanhu]

Yeah, I played around with doing this and agree it's definitely doable. I changed ObjectLoader to load in an explicit list of keys and their versions instead of listing them. If this is something you would accept a PR for, I can look into cleaning this up and adding tests.

[tdbhacks]

Glad you got it to work! I'd hold off on the PR for now because it would have to be yet another on-demand feature in our LibraryConfig (https://github.com/GoogleCloudPlatform/kms-integrations/blob/6529ddfd020fa6655c153c0e66bed9176ab68e78/kmsp11/config/config.proto), we don't have much capacity to review at the moment, and the source of truth for this repo is internal so it's always a bit messy to merge external contributions because of the lack of automated commit mirroring.

There might be another option too here, which is a "single key mode": instead of a full yaml config, we could allow users to point KMS_PKCS11_CONFIG to a specific CryptoKey/CryptoKeyVersion name. Just one key/version, and no other config options allowed, for self-contained CUJs like yours. That may or may not make things easier, would need some more thinking.

Thanks for raising this though, will keep it open as a FR.

[stanhu]

There might be another option too here, which is a "single key mode": instead of a full yaml config, we could allow users to point KMS_PKCS11_CONFIG to a specific CryptoKey/CryptoKeyVersion name. Just one key/version, and no other config options allowed, for self-contained CUJs like yours. That may or may not make things easier, would need some more thinking.

Yeah, that would work too. It might be clearer if an entirely different config variable from KMS_PKCS11_CONFIG is used (e.g. KMS_PKCS11_CRYPTO_KEY).