Thoughts around if this is generalizable for other root/key signing ceremonies?

[mlieberman85]

I know there are some things that the wrapper you've built around go-tuf appear to be very specific to Sigstore's key signing ceremony needs, but reading through the process it does seem like with some changes this could be generalized to support key signing ceremony use cases.

Before going down the rabbit hole of either trying to extend go-tuf to support some of the operations here or to fork this and make it more generalized am I off base?

[haydentherapper]

Cc @jku

[jku]

Thanks for ping :)

@mlieberman85 the sigstore approach is generalizable (and I believe this is absolutely the right direction to go), and there are some interesting improvements possible as well (as the CI system can handle a lot more of the somewhat complicated process management of a signing event than it does in root-signing).

I've been building something in this direction in https://github.com/jku/repository-playground/tree/main/playground: It's a CI based generic (if opinionated) TUF implementation for sigstore-style uses cases. It's not based on go-tuf but I would argue that should not matter: signing tooling should be just that: services & tools, not a part of your development environment.

• Example repository deployments in https://github.com/jku/test-repo-for-playground, https://github.com/kommendorkapten/tuf-playground-1/ -- note how there's essentially no code in the actual TUF repository
• Example signing event (initial signing with two root signers) in Signing event: sign/init kommendorkapten/tuf-playground-1#1 (the messaging is still a WIP but you get the idea: there is a signing event branch, a GitHub Action tracks that branch and always explains in the issue what the next step is and what signers need to do)
• Design doc in: https://docs.google.com/document/d/140jiFHGc3wwEmNaJmUdgkNeNK4i4CC-lm5-eVQYXiL0. I would say the current implementation is close to feature complete WRT this design doc but still very rough around the edges

If you want more details, ping me on slack (sigstore or CNCF) or send an email (jkukkonen at google.com) -- I'm happy to chat even if repository-playground does not look like the direction you want to go in.

[asraa]

Hey! Yes - I would definitely chat with @jku - the easiest for prototyping would definitely be the fully online GitHub repository deployment.

That being said, our current tooling on this repository was meant to specifically handle multi-HSM root key management.

I would strongly dissuade you from using go-tuf right now, because it's API currently is not in good shape, although @rdimitrov has been reworking it to mirror a similar API to python-tuf. I would recommend his updated API or using python-tuf.

This repository still exists I guess to show an example deployment, however. If you wanted something to work ASAP, then @jku's repository deployment setup or a fork of this library works. I believe @kommendorkapten has been able to work with a fork of this repository to sign an independent root.

[mlieberman85]

Thanks! This was super helpful Yeah, there's no rush on my end. I'm writing up a few things and was including TUF in there and I knew Sigstore used TUF for its root signing ceremony and was looking through to see if it was something that could easily be done via the go-tuf CLI. All these links are great and I'll read through and ping folks.

Separate to this, I do like the CLI element of go-tuf. I recognize that the API isn't as stable as python-tuf, but similar to how cosign is a CLI frontend that supports the common use cases for Sigstore, I think it would be nice to have something similar for TUF as well.

[jku]

I recognize that the API isn't as stable as python-tuf, but similar to how cosign is a CLI frontend that supports the common use cases for Sigstore, I think it would be nice to have something similar for TUF as well.

I'm unsure how well I'm describing the repository-playground design on the README but just to make it clear: CLI tooling is provided for

• signing
• delegation management (including repository creation)
• target management

The last one being a bit work-in-progress still. What is not provided is "generic tuf metadata editing tools" -- my belief is that those are a design mistake for anything except software development, debugging, etc.

[mlieberman85]

Thanks for the clarification. I hope to take a closer look at the repository either later today or early tomorrow (Eastern Time).

[jku]

Updating this:

• The generic TUF repository implementation for sigstore-like use cases now lives in https://github.com/theupdateframework/tuf-on-ci
• I'm currently working on some import functionality so existing repos can be managed with tuf-on-ci without client interruption
• next step WRT sigstore is proposing the maintenance of a sigstore staging/testing TUF repository with tuf-on-ci -- and if that works fine, the same for actual sigstore rootsigning TUF repository. I will likely file an issue on this soon (to get some feedback, especially from root-signing signers, but also from others looking for a system like this)

[jku]

I think I'm going to close this as "works for me": tuf-on-ci is demonstrably usable by others and this repository has just become a decent example of a reasonably complex deployment with custom client tests etc -- although I would not use it as example before #1356 because it will be much easier to see what goes on after that