trustroot: initial client config messages

[woodruffw]

WIP; needs workshopping 🙂. Closes #259.

CC @haydentherapper @loosebazooka @kommendorkapten

[haydentherapper]

LGTM, I think this just needs a regeneration

[woodruffw]

LGTM, I think this just needs a regeneration

Done!

[haydentherapper]

@woodruffw Do you want to get this in before 0.3.1?

[woodruffw]

@haydentherapper Yep! I'll rework on top of #279 now.

[kommendorkapten]

Thanks!

Before merging, I would just like to make sure we are agreeing on how this will be distributed via PGI TUF root (i.e how this should be documented in the Sigstore Client Spec).

We now have:

• SigningConfig
• TrustedRoot

And then ClientTrustConfig = {SigningConfig, TrustedRoot}

The TUF repository already ships TrustedRoot as single artifact, trusted_root.json.
How would we ship the SigningConfig? My recommendation is to add a new artifact to the TUF root called signing_config.json. Why? Do not break the clients. Adding a new target is trivial.

The alternative is to add a new target client_trust_config that contains both messages. The downside is that we would need to duplicate the trusted_root.

Shipping two files from the TUF repo is not the end of the world IMHO. We can still allow clients to accept a single file (client_trust_config) to simplify the UX when e.g. invoked via the terminal.

As we are in the process of adding support for trusted root to a lot of components, withdrawing that from the TUF repository would be very disruptive 😅

[woodruffw]

This might be a minority opinion, but IMO it's okay for the PGI TUF repo to not ship SigningConfig at all -- the PGI and staging instances both have "well-known" signing configurations already, so a client can (continue to) hardcode them.

In other words, IMO it's okay if SigningConfig and ClientTrustConfig exist entirely as message definitions for checking user (i.e. non-TUF) JSON inputs against, with the idea being that they establish the interface for clients that want to support CLIs like --client-trust-config trust.json.

Regardless of the above, I 100% agree about not removing the current trusted_root.json target -- IMO if we want to put SigningConfig or ClientTrustConfig in the TUF repo, then a separate file (either just the signing config or the combined client trust) would be perfectly cromulent 🙂

[kommendorkapten]

Sounds good, I think we are in agreement!

[woodruffw]

Merging!

[haydentherapper]

@woodruffw @kommendorkapten I think a primary motivation would be if we move Rekor to yearly sharding, since the URL would change periodically and clients would need to discover it without breaking old clients. I don't think we need to immediately ship a SigningConfig though since this isn't the case currently, but I do think we should start making plans for adding an additional file distributed through TUF.

[kommendorkapten]

@haydentherapper yes, I proposed in the client meeting to today that we add the signing_config.json to the TUF repo during next signing.