Enable easier embedded root version updates for client codebases

[jku]

Description

Clients embed a version of root metadata as the initial source of trust into their client apps and typically into their source code repos. They should also update that version sometimes, and it seems this is not always happening (see sigstore/sigstore#1138)

The benefits of updating the embedded root are:

• less network traffic when clients avoid downloading old root metadata
• better client user experience (because less downloads)
• slightly better security as well

There is a downside too:

• updating the root metadata should not be done lightly or in an automated fashion as it is the source of all trust

Possible ideas to fix

To make updates easy and to minimize the mentioned downside, sigstore root-signing could probably make things easier for client projects. Some potential ideas:

• maybe include a "suggestion to update embedded root" in some communications to client developers when root is updated
• maybe create a reusable GH workflow that files an issue in the client github repo if the embedded root is not up-to-date ( see https://github.com/theupdateframework/specification/blob/master/.github/workflows/check-latest-spec-version.yml for an example of a similar workflow in the TUF spec repository -- this workflow is used in the TUF implementation repositories). This issue could document what should be updated and how the root should be verified to be correct.

cc @joshuagl

[joshuagl]

I like the idea of having an action client implementers can choose to use. I think we should do that and make noise in the Sigstore client meeting so that folks are aware.

We should create a short Markdown doc in the repo here that the issue and the meeting can link to in order to understand why updating trusted root metadata to newer versions is useful as well as how to do the update securely.

[jku]

... create a reusable GH workflow that files an issue in the client github repo if the embedded root is not up-to-date

Thinking this through: We probably don't want to file the issue immediately when root-signing git changes: instead the trigger should be the published metadata changing. So the workflow process would be

• periodically run a TUF client to get up-to-date local metadata cache from sigstore repository (this could be done with the sigstore client itself but a tiny TUF app included in the workflow might be easiest)
• compare the fresh cached root to the clients embedded root (embedded root path is a workflow input)
• file an issue if the files do not match (could make a PR as well but I'm not sure if that's too much automation?)

TODO: what do we suggest as the easiest way for client maintainers to fetch and store the new root? Running their own client and using the root file from their own local cache?