Skip to content

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

Closed
@jku

Description

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

Activity

added
bugSomething isn't working
on Aug 31, 2024
self-assigned this
on Aug 31, 2024
jku

jku commented on Aug 31, 2024

@jku
MemberAuthor

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

jku commented on Sep 2, 2024

@jku
MemberAuthor

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

jku commented on Sep 2, 2024

@jku
MemberAuthor

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

changed the title KMS keyid issue in migration signing event [root v11] KMS keyid for timestamp/snapshot should be fixed on Sep 3, 2024
added a commit that references this issue on Jan 20, 2025
added a commit that references this issue on Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    [root v11] KMS keyid for timestamp/snapshot should be fixed · Issue #1347 · sigstore/root-signing