Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[targets v11] Add client signing configuration #1194

Open
haydentherapper opened this issue Apr 4, 2024 · 12 comments
Open

[targets v11] Add client signing configuration #1194

haydentherapper opened this issue Apr 4, 2024 · 12 comments
Labels
enhancement New feature or request

Comments

@haydentherapper
Copy link
Contributor

Description

Tracking issue to add the new client signing configuration described in sigstore/protobuf-specs#277 for the next root/target signing

cc @kommendorkapten

@haydentherapper haydentherapper added the enhancement New feature or request label Apr 4, 2024
@haydentherapper haydentherapper changed the title [v10 root] Add client signing configuration [v10 signing] Add client signing configuration Apr 4, 2024
@jku
Copy link
Member

jku commented Apr 5, 2024

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.

@haydentherapper
Copy link
Contributor Author

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?

@kommendorkapten
Copy link
Member

@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.

@jku
Copy link
Member

jku commented May 29, 2024

This should happen in root-signing-staging first

@jku
Copy link
Member

jku commented Aug 21, 2024

Test in staging ongoing in sigstore/root-signing-staging#157

@jku
Copy link
Member

jku commented Aug 21, 2024

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.

@haydentherapper
Copy link
Contributor Author

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.

@jku
Copy link
Member

jku commented Aug 21, 2024

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

@haydentherapper
Copy link
Contributor Author

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.

@kommendorkapten
Copy link
Member

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.

@haydentherapper
Copy link
Contributor Author

@kommendorkapten the lack of version isn't intentional, do you want to send a PR to add it?

@kommendorkapten
Copy link
Member

Yes, I'll fix that.

@haydentherapper haydentherapper changed the title [v10 signing] Add client signing configuration [v11 signing] Add client signing configuration Sep 3, 2024
@jku jku changed the title [v11 signing] Add client signing configuration [targets v11] Add client signing configuration Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants