sigstore
[targets v11] Add client signing configuration
Description
Tracking issue to add the new client signing configuration described in https://github.com/sigstore/protobuf-specs/pull/277 for the next root/target signing
cc @kommendorkapten
I am not opposed to another artifact in the repo but I'll mention these downsides so it's clear to everyone:
- sigstore "client api" now includes the new proto. If a client that wants to use this data it needs parse this new file
- sigstore "client api" now includes the targetpath used in the TUF repo
- clients that want to use this data now need to download this targetpath with tuf
These are all reasonable but the last two items specifically are the price we pay for not just adding new optional fields into trusted_root.json.
I was re reading the client notes and I see it’s actually unclear what the decision was on whether or not this should be its own file. @kommendorkapten do you know what the conclusion was?
@haydentherapper the overall agreement was to add a new file to not break anything for the existing clients.
It's listed here: (third bullet point: SigningConfig URLs from TUF)
New target (signing_config.json [agreed on naming])
As we call the trusted root trusted_root.json, we should call this signing_confg.json IMO.
Test in staging ongoing in https://github.com/sigstore/root-signing-staging/issues/157
Just so we're making an informed decision: Has any client implemented SigningConfig support? Or in other words are we sure that the SigningConfig design is good? I notice it does not seem to have a versioning scheme built in.
If we are not sure, there is the option of just adding it in root-signing-staging and not here until we have more data.
No, no client has. I had thought sigstore-python did, but they implemented support for the ClientTrustConfig (https://github.com/sigstore/sigstore-python?tab=readme-ov-file#configuring-a-custom-root-of-trust-byo-pki), which is the combination of both a trust root and signing config (spec).
If this is still up for debate whether this should be one of two files, then I think we should hold off until the next signing event.
as any client implemented SigningConfig support?
ah yes I forgot sigstore-python has that (via supporting ClientTrustConfig that combines SigningConfig and TrustedRoot).
If this is still up for debate whether this should be one of two files
I was not implying that. I am asking
- can we actually test that the file frederik added in root-signing-staging works: it looks like we can with sigstore-python with a bit of fiddling
- are we comfortable supporting SigningConfig as it is from now on
One question is what about if there are additional services that aren't distributed - what should that UX be? Can a client specify additional tlogs to write to? What about TSAs, where Sigstore isn't distributed such a list?
I think we have the right structure for SigningConfig that I'd be good with shipping it as part of the TUF root.
What I remember is that we should only ship trusted_root.json and signing_config.json. A client may combine them to use if needed. We avoided to ship the ClientTrustConfig as it would duplicate the trusted_root.json.
I don't remember why we didn't version the SigningConfig and only the ClientTrustConfig tough.
@kommendorkapten the lack of version isn't intentional, do you want to send a PR to add it?