sigstore
Add new version of TrustedRoot
Description
Since the first TrustedRoot version, we've added two new fields:
- Checkpoint key ID, https://github.com/sigstore/protobuf-specs/pull/629, to distinguish between log ID (always
SHA256(PKIX public key)) and checkpoint key ID (computed based on https://github.com/C2SP/C2SP/blob/main/signed-note.md#signatures). In Rekor v1, these may be distinct if the log key is not an ECDSA key. For Rekor v2, there is no longer a concept of a log ID, so we've been reusing the log ID field to contain the checkpoint key ID. - Operator, https://github.com/sigstore/protobuf-specs/pull/634. Operator was added for SigningConfig structs to group log deployments together by operator, e.g. sigstore.dev or a company. Operator was also added to TrustedRoot so that clients that support verification policies (i.e. sigstore-go) can use the Operator field to select only distinct log operators to count towards thresholds.
In updating the SigningConfig and adding the Operator field, we realized that simply adding a new field to a proto isn't a breaking change, but actually setting that field and trying to parse JSON causes a parser error, effectively making new fields breaking changes.
We need to create a new TrustedRoot, trusted_root.v0.2.json (following the new versioning convention), with the checkpoint key ID and operator fields set.
cc @jku @kommendorkapten Thoughts? Would be nice if we could get this in before v13, but if not, that's OK, we'll need to do another root signing event once we have Rekor v2 up in production. We'll also need to bump https://github.com/sigstore/protobuf-specs/blob/fc7b187add49cd688d19667c8a1888c79338ba6d/protos/sigstore_trustroot.proto#L153 before this change, not sure if that's feasible before v13 as well.
This is minor update in terms of functionality/work required. Let me see if I can get this going by EOW, I think it's possible. Then we can add it to v13 signing event.
