Support X.509 Certificate Chain Verification in Bundle v0.3+

[yangkenneth]

Description
The Sigstore bundle specification (v0.3+) currently requires verification material to contain a single X.509 certificate rather than a certificate chain. However, this creates limitations for use cases where the signing certificate is not directly issued by a Trusted Root and requires Intermediate Certificate Authorities to build a complete chain of trust [example].

Changes Made
In sigstore-go, we've added an AllowCertificateChain() option that permits v0.3+ bundles to contain X.509 certificate chains in their verification material sigstore/sigstore-go#581. This allows clients to:

1. Create v0.3 bundles with certificate chains (instead of downgrading to v0.2).
2. Verify v0.3 bundles containing certificate chains when the AllowCertificateChain option is enabled.

Request
Other Sigstore client implementations (Python, Rust, Ruby, etc.) should consider adding similar support for certificate chain verification in v0.3+ bundles to maintain cross-client compatibility.

Related PRs

• Support Verification in sigstore/cosign with X.509 Certificate Chain sigstore-go#581
• Supporting OCI Signing with X.509 Certificate Chain cosign#4614

[woodruffw]

I might be missing something here, but I don't understand the problem statement: v2 is not a "downgrade" from v3 per se, it's just a different representation of the same verification state but for different Sigstore deployment topologies. Ref:

https://github.com/sigstore/protobuf-specs/blob/69e5b5d27559a51c7afbba17496dbb95bb9f3e35/protos/sigstore_bundle.proto#L88-L92

In other words: if you have a Sigstore deployment where your X.509 PKI requires a non-trivial chain (i.e. anything more than a leaf and a root of trust), then you should use a v2 bundle. They're not invalid or discouraged for anything except the Sigstore PGI, since the PGI doesn't have a trust layout that requires the "chain" concept.

[yangkenneth]

I might be missing something here, but I don't understand the problem statement: v2 is not a "downgrade" from v3 per se, it's just a different representation of the same verification state but for different Sigstore deployment topologies. Ref:

https://github.com/sigstore/protobuf-specs/blob/69e5b5d27559a51c7afbba17496dbb95bb9f3e35/protos/sigstore_bundle.proto#L88-L92

In other words: if you have a Sigstore deployment where your X.509 PKI requires a non-trivial chain (i.e. anything more than a leaf and a root of trust), then you should use a v2 bundle. They're not invalid or discouraged for anything except the Sigstore PGI, since the PGI doesn't have a trust layout that requires the "chain" concept.

sigstore/sigstore-go#581 (comment)

[Hayden-IO]

Before I add anything - I asked @yangkenneth to post here because I didn't want us to make a change just in sigstore-go without having at least a rough consensus from other clients on what the path forward is for private PKI. I'm a little concerned that Cosign's deviations are going to start to work their way into sigstore-go, and we really really want to avoid that.

---

I have a different view of v2/v3 bundles. The current v0.3 bundle is effectively a stable format - there's a few fields to deprecate related to the Rekor v2 rollout, but besides that we could declare this v1.0. I view v0.2 bundles as an older format and not one we should continue to proliferate. I'm not sure we ever made a call on what to do about v0.2 bundles, though some client devs had talked about providing utilities to "upgrade" to v0.3 bundles so we could start working towards clients not having to handle any older formats.

The bundle was designed primarily to support the well-lit path, ephemeral keys + code signing certs + transparency. The format does have some flexibility for other signing options though - managed keys are supported, and time stamping and transparency are optional. And we do have support for certificate chains already - specified here, the bundle allows for certificate chains for non-PGI use-cases.

@woodruffw you mentioned in the other thread it's a semantic change, do you think the current comment is sufficient? I don't think any clients read from the field currently, but we do specify the purpose of the field, we just don't have any conformance tests to standardize this across clients.

The proposal in sigstore-go is to allow intermediate certificates only when a caller explicitly opts in. It would not be a requirement for all clients to implement - I wouldn't be surprised if only sigstore-go does to support private PKI in Cosign, though I still think we should create conformance tests.

Another option is to either create a separate bundle format specifically for private PKI use cases. Problem is we don't have really understand the private PKI user journeys now and would be guessing at what we need to change between both bundle formats.

I guess another option is to say we just shouldn't deal with intermediate chains at all outside of the trusted root and if someone has a PKI that uses ephemeral intermediates, Sigstore simply doesn't support this.

cc a few other client maintainers - @woodruffw @steiza @kommendorkapten

[steiza]

Yeah, we talked about this at the March 3rd Sigstore clients meeting.

The conclusion we came to was to add a flag to clients, when doing verification, that allows a certificate chain in the bundle, even with the v0.3 bundle. This is sort of a "I know what I'm doing flag" for folks who are using private deployments with intermediate certificates in their signed material/bundle. We would have to update the protobuf bundle documentation, conformance tests (hence this issue) and client behavior. Clients would need to be careful when constructing the certificate chain and only trust material from the trusted root, not the intermediate from the bundle (if present). And we would leave in the specification the part about how when using PGI you should only put the leaf certificate in the bundle, but probably we would not make clients "PGI aware" to enforce this.

[yangkenneth]

@Hayden-IO @woodruffw following up to see if we can move forward with the client changes presented at sigstore/sigstore-go#581