Support v0.3 bundles

[haydentherapper]

Description

The primary change is the addition of the certificate field to be used when issuing bundles verified with the public good instance. This removes the ambiguity when dealing with a chain that contains more than just a leaf certificate and verifying with the public good instance. The chain should only be used for self-hosted Sigstore instances now.

[haydentherapper]

Note we should first support verification of v3 bundles, then figure signing. I started a thread to sync with the other clients on slack to confirm how they’re handling which field to put certificates and their chains.

[haydentherapper]

Thread since it'll get deleted. tl;dr is use the certificate field with namespaced commands for BYO as the goal.

Hayden:

Thinking about how to add support for v0.3 bundles on the signing path. How are you deciding between adding the signing certificate to the x509_certificate_chain field vs the new certificate field?
For example, thinking about signing from the public good instance - We could add a special case that when fulcio or rekor URL match *.sig(store|stage).dev, we only add a certificate. This feels wrong though to hardcode this special case.
Should we decide based on if a trust root is provided, either by CLI or via TUF?
This is not the best approach either, because a trust root could contain only a root, and an intermediate could be provided out of band. However, this might just be a Cosign issue, I'm not sure if other clients allow certificates and chains to be provided on signing.

William Woodruff
1 month ago
i've also been thinking about this, and don't have a great answer yet 🙁
one idea, tied to
@Jussi Kukkonen
's proposal (sigstore/protobuf-specs#183): if the trust root indicates that it's part of the PGI via that oauth URL, then we'd special-case and emit certificate instead of x509_certificate_chain. but yeah, that would be hardcoding a special case and feels a bit weird
#183 trustroot: Should OAuth issuer(s) be included?
This is not a fully defined feature request but I wanted to write this down before holidays...
I was testing if a sigstore client (sigstore-python) really can choose the "sigstore instance" purely based on trusted_root.json: verification seems to work pretty well without any hard coded urls etc, but signing still has a an issue or at least a usability problem: A signing client can use trusted_root.json to select the Fulcio instance it uses, but it also has to choose the OAuth issuer (dex) URL and for things to work that issuer needs to be accepted by the Fulcio instance.
Should the sigstore_trustroot CertificateAuthority message include a parameter that describes the accepted OAuth issuers tha… Show more
Labels
enhancement
Comments
3
https://github.com/[sigstore/protobuf-specs](https://github.com/sigstore/protobuf-specs)|sigstore/protobuf-specssigstore/protobuf-specs | Dec 20th, 2023 | Added by GitHub

William Woodruff
1 month ago
in sigstore-python's case, we don't have the OOB intermediate case -- we only accept a trust root via TUF (and soon via a CLI flag), so i think we can unconditionally emit just certificate

Hayden Blauzvern
1 month ago
One solution might be separating BYO PKI from sigstore deployments. All of the newer sigstore clients have mostly been focused on the latter. Cosign has support for both but it's a bit messy and intertwined.
At some point, we want to create a namespaced commands for signing with sigstore vs signing with our own PKI but emitting sigstore bundles.

Hayden Blauzvern
1 month ago
So then at this point, unless a client is handling chains on signing, we should just use the certificate field.

William Woodruff
1 month ago
that's personally my preference, yeah!

kommendorkapten
1 month ago
Going with namespaced commands my be a good way. The caveat Ii would have is that we make this more around semantics vs deployment URLs. As if Company X deploys a Sigstore that has the same semantics and deployment model as PGI (TUF, trusted_root.json with intermediates etc) the defualt clients should work against such a deployment IMHO. At GitHub we are doing something similar, but are not running e.g. Rekor, so with a change the verification policy (WithObserverTimestamps instead of WithTransparencyLog and WithIntegratedTimestamps) verification should be possible for an artifact signed by our instance as our trust root follows the same format as PGI’s.

[steiza]

I can start looking into this as part of #101

[haydentherapper]

Thanks! I had made a tiny progress on this but nothing substantial. Should be straightforward, just need to pull from the certificate field in addition to the certificate_chain field. We should keep generating v2 bundles for signing given ongoing discussions on media type.

[codysoyland]

Fixed in #101