Labeling service signing keys are harder to rotate than repo signing keys, but there should be a relatively clear path and affordances for doing rotations and resigning.
The label stream could include an #identity event type to signal that the labeler service identity has updated. This would make downstream identity purge/refresh more timely and reliable.
Expectations around resigning existing labels (of which there might be millions) should be clarified. Should the re-signed labels be re-emitted with new sequence numbers? New cts timestamps?
Maybe not not: it would be easier if the service could re-sign labels internally, and make them available via queryLabels or the stream endpoint via the old sequence numbers. Downstream services don't necessarily even need to re-index the labels or store the signatures. On the other hand, some mirroring/archival consumers may wish to re-ingest to get the updated signature.
Labeling service signing keys are harder to rotate than repo signing keys, but there should be a relatively clear path and affordances for doing rotations and resigning.
The label stream could include an
#identityevent type to signal that the labeler service identity has updated. This would make downstream identity purge/refresh more timely and reliable.Expectations around resigning existing labels (of which there might be millions) should be clarified. Should the re-signed labels be re-emitted with new sequence numbers? New
ctstimestamps?Maybe not not: it would be easier if the service could re-sign labels internally, and make them available via
queryLabelsor the stream endpoint via the old sequence numbers. Downstream services don't necessarily even need to re-index the labels or store the signatures. On the other hand, some mirroring/archival consumers may wish to re-ingest to get the updated signature.