Closed
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
jku commentedon Aug 31, 2024
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.
It seems I do not personally have the permissions to do this with gcloud:
There is a
tuf_key_viewers
variable defined in scaffolding but I'm not sure where that should be setjku commentedon Sep 2, 2024
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 commentedon Sep 2, 2024
The workaround seems to have worked -- although next issues is still preventing seeing the results (see #1349)
'root' role/delegation change
'root' role/delegation change