[root v11] KMS keyid for timestamp/snapshot should be fixed

[jku]

EDIT: the immediate issue was worked around: this is now open until the key in metadata is modified so the online-uri for the timestamp/snapshot key is correct. The value is gcpkms://projects/sigstore-root-signing/locations/global/keyRings/root/cryptoKeys/timestamp which is what the old workflows used. IT should be gcpkms:projects/sigstore-root-signing/locations/global/keyRings/root/cryptoKeys/timestamp/cryptoKeyVersions/1

original issue follows:

---

We tried merging the migration signing event on friday. This failed since the KMS keyid is incorrect:

• I used projects/sigstore-root-signing/locations/global/keyRings/root/cryptoKeys/timestamp since that is what the legacy workflows use
• The KeyManagementServiceClient.asymmetric_sign() in GCP KMS python bindings requires the full keyid however -- there should be a version identifier included in the string
• this error could not happen with tuf-on-ci normally (since the public key is fetched from GCP API with the keyid when the key is inserted in the metadata) but in this import case this check does not happen

Next steps:

• verify the correct keyid
• decide on how to fix: I initially thought keyholders will have to resign but it is possible we could add a code workaround -- this would allow us to move fast and hopefully not break more things

[jku]

The legacy signing uses sigstore/sigstore to sign: that just picks the highest version number available: see code -- this is IMO incorrect for TUF (since a new keyversion is a really an entriely different key that will no longer match the public key in the metadata) but explains the different keyid usage.

I believe we cannot see from logs which key version is actually used in the legacy online-signing.

verify the correct keyid

It seems I do not personally have the permissions to do this with gcloud:

from google.cloud import kms
client = kms.KeyManagementServiceClient()
request = {"name": "projects/sigstore-root-signing/locations/global/keyRings/root/cryptoKeys/timestamp/cryptoKeyVersions/1"}
client.get_public_key(request)

...

google.api_core.exceptions.PermissionDenied: 403 Caller does not have required permission to use project sigstore-root-signing. Grant the caller the roles/serviceusage.serviceUsageConsumer role, or a custom role with the serviceusage.services.use permission

There is a tuf_key_viewers variable defined in scaffolding but I'm not sure where that should be set

[jku]

There is a workaround in tuf-on-ci: we will re-try the signing event merge in #1348

This issue should remain open even after that so we can properly fix the KMS keyid in the next signing event

[jku]

The workaround seems to have worked -- although next issues is still preventing seeing the results (see #1349)