Use root-of-trust bundle as the TUF target file

[jku]

This is not a fully formed feature request but an idea from protobuf-specs issue about defining the root-of-trust bundle. If we end up in a situation where:

• there exists a bundle format that fully defines a root of trust for a sigstore instance
• sigstore clients are expected to be able to use this bundle format

then the logical conclusion seems to be that the bundle file should be the target file delivered via TUF. Delivering individual certificates and keys would only lead to clients implementing two code paths for trust initialization.

This would handily also solve the issues of target discovery (as we could have well-known targetpaths like "sigstore/sigstore.dev/trustroot.protobuf" and "sigstore/sigstore.example.com/trustroot.protobuf").

The downsides I can see:

• when the trust root changes, the whole trust root gets transmitted (instead of a single cert)
• signers are now signing an opaque binary: (this is already the case to an extent -- it's not like PEMs are human readable -- and could be mitigated with tooling?)

[asraa]

+1, this would simplify the idea for target discovery: look for the trust bundle provided by the repository you want, with the specific "mime-type":
sigstore/sigstore.dev/trustroot.protobuf
sigstore/sigstage.dev/trustroot.protobuf
sigstore/my_personal_ecosystem.dev/trustroot.protobuf

etc

[jku]

Potential further downside that I did not realize until talking to Fredrik today:

• Using protobuf means a new runtime dependency to all sigstore clients. For reference, the (pure) python protobuf package is about 20000 lines of code._

This is meaningful since sigstore is being proposed as a component of package management systems: Adding dependencies to package management clients like pip is not ideal.

[asraa]

Ohh you are right. Does it make sense to serialize as JSON?

[joshuagl]

TIL that protobuf generated code depends on a protobuf runtime. 🤔
Serialising to JSON sounds like a good option! cc @kommendorkapten

[jku]

TIL that protobuf generated code depends on a protobuf runtime

Me too! I thought the generated code would have the deserialization embedded in it, but at least a naive protoc compile produces python that imports google.protobuf modules

[kommendorkapten]

It might be possible to trim the dependencies if we only rely on JSON? Just an idea. But as long as we rely on JSON for the canonical encoding, hand-rolling a "JSON unmarshaller" for e.g. Python will be pretty straightforward, which tbh in Python is just relying on the native JSON parser. There are just some caveats which I think we are all aware of (int64 as strings and manual Base64 decoding of the binary data). As long as we are fine with that, I see no issues of using the native JSON parser for unmarshalling, which is probably the most common thing the package managers is gonna do.

[asraa]

I'm also thinking: for clients that want to add in multiple TUF roots, can we do a merge on TrustBundle information canonically?

TrustBundle1 from TUF instance1 + TrustBundle2 + TUF instance2 is well-defined?

This comes back to the repository map in general, which, because the targets are bundled, now has little semantics over something like "choose Rekor from instance 1 and Fulcio from 2". But that's hairy anyway. You usually want to trust all in the ecosystem. You would need to iterate over the valid Fulcio instances at the time. But then, you can let the policy-controller (@vaikas) scrape from verification output what was actually used. (On my mind: I will add a VerificationOutput into sigstore-go with the details on how the verification was performed)

[vaikas]

FWIW, I had been modeling in my head (and jotted in the policy-controller doc (from the other issue)) that the policy-controller figures out what keys/certs (well, the whole proto now) should be used by the verification logic. So, by the time the verify method is called it will not have all the pieces, but only the ones that are deemed to be suitable for verification for that particular image. Then it either passes or fails (with the deets).

[asraa]

. So, by the time the verify method is called it will not have all the pieces, but only the ones that are deemed to be suitable for verification for that particular image. Then it either passes or fails (with the deets).

Woah! Interesting. I'll take a look tomorrow.

[kommendorkapten]

I'm writing up something on this, I'll expect to publish it into the client spec later today. When writing this, and thinking about this exact issue, I thought about if we should restrict each TrustedRoot to a single TUF root. As a TUF root typically refers to a single "environment" I think it may simplify to make it so, and that would also remedy the need for merging, and for artifact verification, the first rough cut is to find the desired environment, then any filtering can happen inside that TrustedRoot.

Or put it differently, do we ever anticipate that a single artifact will require verification materials from more than one TrustedBundle? Public keys for verifying a signature does not count, as that's considered part of the policy, and so is provided via ArtifactVerificationOptions. The TrustedRoot is only signature transparency logs, CAs + CTLogs and TSAs.

[kommendorkapten]

Added a proposal to the client spec: https://docs.google.com/document/d/1kbhK2qyPPk8SLavHzYSDM8-Ueul9_oxIMVFuWMWKz0E/edit#heading=h.3exhkahaxwkq

[bdehamer]

I took a crack at assembling the trusted-root (JSON-serialized form of the protobuf message) with the actual sigstore data just so I could see what it would look like: #584

[asraa]

Thank you! I think we could also get this into staging for early access as I schedule the next root-signing event.

I'm adding this to a v6 milestone along with some other items to plan for the next one. I'll try to target 4-5 weeks from now depending on what other items come up.

[asraa]

Closing this in favor of the remaining TODOs: #616

Thanks everyone!