Can we use Sigstore (fulcio) certificates as SLSA provenance?

[kpk47]

I was chatting with @woodruffw about how SLSA interacts with Sigstore, and he pointed out that a lot of the information in SLSA provenance is already present in Fulcio certificates (see https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md). If we make the two match more closely, then the provenance attestation becomes optional.

The main benefit is that it gets easier to write tooling and push adoption: Code signing is already well-understood, and there are already efforts to make it ubiquitous. If we can find a way to attach SLSA metadata to code signing, then we can grow SLSA adoption without having to build the infrastructure for passing around separate provenance attestations.

The main downside is that we would need to get Sigstore (and maybe eventually other CAs) on board with the idea. I'm not sure that's feasible.

Does this idea resonate?

If it's helpful, I put together a scratch doc that compares the fulcio certificates and provenance attestations for npm packages build on both GitHub and GitLab: https://docs.google.com/document/d/1HLCbuzeL6kiNmqIe7oEW3K8Rer7VyKWjFU7OjWjz988/edit?usp=sharing. There isn't a ton of overlap, but it's a good start.

[kpk47]

@haydentherapper @steiza I'd like your input

[mlieberman85]

Certificates to me at least are about identity. So a code signing certificate is about associating an identity with something. So for example with Fulcio and a build I'm associating an artifact with the identity of the build which is a combination of like github repo, workflow, etc. I can see an argument here that all the inputs to a build, i.e. the elements we use for build provenance to be part of a certificate but I think I would need to see some more examples. There are a few specific and a few more broad concerns. I've put a few questions and comments in the doc, but here are a few overarching ones:

• My biggest technical concern is I've seen SLSA attestations for complicated builds end up being megabytes or even tens of megabytes large. Now this isn't the case with a lot of Github workflows where you can just encode pointers to the data (which can lead to tampering), but a lot of folks use other tools. Including lists of thousands of hashes for example could pose a problem.

I can see this potentially being one of many ways to suggest folks generate provenance.

[MarkLodato]

I've long thought that it doesn't make sense to duplicate information in both the certificate and the payload, which leads to mistakes and confusion. So I'm on board with formalizing the notion that provenance can be put in the certificate instead of the payload. It also makes it more clear which party attests to what.

nit: I wouldn't characterize it as "the provenance attestation becomes optional". It's still a provenance attestation. It's just that the information is in the cert rather than the payload.

I think the next steps would be:

1. Formalize this notion in the SLSA docs, specifically that if the provenance is in the cert, it should not be duplicated in the payload.
2. Create tooling to make it easier to work with provenance-in-cert information. For example, would the recommendation be for libraries to translate the certificate information into the SLSA Provenance JSON format?
3. As needed, work with Sigstore to generalize the x.509 extensions. I feel like the current fields are overly rigid and we may want to make it easier to add arbitrary information to the cert.

[colek42]

This would be a non starter for most of our attestations. Tracking all the inputs and outputs of a build process requires a huge amount of data. One possibility, however would be to include a ref to the attestation.

[MarkLodato]

@colek42 To clarify, I don't think anyone is suggesting that this is mandatory, just that if you are already putting it in the certificate, that it does't make sense to duplicate it in the payload.

[SantiagoTorres]

I think we've had this conversation like 4 times already.

On Sigstore adding this info in the cert was meant as a quick stopgap measure while SLSA adoption caught up (at least that was the conclusion last time). Bloating the certificate with more information related to provenance (or otherwise) on undocumented x509 OIDs sounds like re-inventing the spec but with more bureaucracy and non standard tooling.

My thoughts are:

Policy & Parsing

Most x509 parsing libraries do not have code to support policy around random OIDs. Instead, you have to write a lookup on a particular OID value (which you need to know beforehand, in a registry of sorts), fetch the value, ensure the type is right (e.g,. not everything is a binary string), and then do the check.

At that point the question is: what is the benefit of putting it in the cert?

One annoying thing about this, and I'd agree it can be consiidered minor, is that commands like openssl x509 -text will, by default, not display unregistered extensions. This is annoying not only because then you have to have custom tooling/cmdline flags to show you the things you have in there, but also because the x509 spec is so large you can't write a simple parser without pulling in a big library to just dump the contents of the OIDs that you decided to use.

Unrelated extensions and bloat

Another issue is that x509 is meant to support way more beyond artifact/attestation signing. Tools should then not only reason about what's in the cert that relates to supply chain security (see above), but also about what is there that is not related to supply chain security. For example, what is the expected behavior of a tool when they identify a CRLDistributionPoints Extension? What about FreshestCRL? what about a non-critically-marked InhibitAnyPolicy on a non-CA certificate? what does this even mean for supply chain artifacts?

You could claim that then we can just standardize the elements inside of a cert that are to be validated and discard everything else. At that point, we are just dealing with a non-trivial amount of junk becuase we decided to use a standard that was never designed to store arbitrary data about the layer above of what it is signing.

Composability

I think my bigger point is that attestations (and the various SLSA types), are meant to be composable. You should be able to reason through not only what's on SLSA, but what else is in other attestations. For example, you want to ensure that a vulnerability scan attestation from trivy has the same subject as the subject on a SLSA attestation (to verify you're indeed scanning the right thing). In order to support this by inlining it in x509 certificates we'd have to have what would essentially amount to the in-toto attestation layer inside of multiple x509 certificates.

You could of course do that, by essentially constructing a map of OIDs to keys in the in-toto/SLSA/ITE-9 specs.

At that point, you have re-invented the subject layer inside of an x509 cert. Is it worth it?

I'm personally against this (and I think I've had this discussion before with @woodruffw when we originally added those fields into Fulcio), because I think it's just adding unnecessary medium-term complexity for a very near-sighted adoption plan. Not only this, we could be spending our cycles on doing something else that relates not only to SLSA, but Sigstore and in-toto as a complete ecosystem.

[steiza]

Yes, this question has come up before. There's very similar data in the Fulcio code signing certificate and in the SLSA provenance in-toto attestation, so why have the information in two places?

I think the answer is we should work towards having that information in one place, and that one place should be the in-toto attestation, not the Fulcio signing certificate.

Today many SLSA provenance in-toto attestations are created in a place where an end user could access and tamper with them. So in implementations like npm build provenance, we check to ensure the in-toto predicate fields match the Fulcio signing certificate, to ensure the in-toto document hasn't been tampered with.

This requires Fulcio to understand each CI/CD provider, and requires us to ship changes to Fulcio whenever those providers add new features, we handle a new attestation type, or we add a new provider. I don't speak for the entire Sigstore project, but generally I think we want Fulcio to be as simple as possible. Otherwise we risk making Fulcio a bottleneck for iterating on supply chain security capabilities.

So ideally, we'd move in-toto attestation document creation and signing away from a place where end users can tamper with them, and instead are provided by the platform we're trusting to create the OIDC workload identity. Then we can trust the (signed) in-toto attestation document itself, and we don't need the same values in the Fulcio code signing certificate.

We won't be able to do this overnight, but hopefully we can work with CI/CD providers to move in this direction.

Your point on making it easier to store signatures and attestations is well taken, but the Fulcio code signing certificate was not intended to stand on its own to enable verification. Having all this information in one file is the point of the Sigstore bundle: to include the Fulcio code signing certificate, but also inclusion proofs, observer timestamps, and the attestation contents (including the artifact hash that @mlieberman85 calls out on the linked doc).

[haydentherapper]

Great discussions about this, and thanks Kris for proposing this spec update!

I want to keep Sigstore and SLSA independent, but treat this proposal as collaboration between the two. What goes into a Fulcio certifiacte should be independent of the SLSA specification. It can contain both more than the SLSA spec (e.g. identity information, source metadata [1]), and less than the SLSA spec (e.g. build provenance required by the SLSA spec not present in the certificate).

I'll take the strong stance that Fulcio should not be aware of SLSA requirements. Fulcio's job is to link information from a CI/CD or identity provider to a signing event. In the given example in the linked doc, I wouldn't want to update Fulcio extensions to exactly match what's in the SLSA spec. To @steiza's point, this would create a bottleneck around iterating on certificate values.

However, we know that many of Fulcio's extensions map to SLSA requirements. Again, this requires no changes on Sigstore/Fulcio's part. This is more about flexibility and tooling on the SLSA side. SLSA could its spec to be more flexible in provenance formats - X.509 vs JSON vs CBOR. Some languages will have better support for each format, which means there will be a need for additional tooling. This SLSA tooling will also be responsible for maintaining the mapping between Fulcio extensions and SLSA requirements. This opens us up to support for other formats in the future, as long as SLSA maintains a mapping between these formats and its current requirements. This last point may be contentious, so please take note! This flexibility in formats may not be preferred.

With this collaboration, you create a cycle for improvements. CI/CD providers expose additional metadata in OIDC tokens. Fulcio records this information. SLSA updates its tooling to map this new information to a SLSA requirement. SLSA proposes additional requirements, and asks CI/CD providers to expose additional metadata in the OIDC token. And the cycle continues.

[1] Noting that the Source track is not finalized, and once it is, this source metadata may meet SLSA requirements

[trishankatdatadog]

I had actually pointed out in the Wed (1/24) OpenSSF Securing Software Repositories WG call that Will's "publisher provenance" can be thought of as a SLSA v1 build provenance w/o the provenance. More precisely, my best understanding is that it's like Fulcio-specific signatures on the DSSE envelope but w/o the actual payload.

If one really must do this, then one should propose and use a "null" or at least a "trusted-publisher" predicate type for in-toto attestations, but not make the SLSA v1 provenance optional. The biggest reason for the latter is that then would then defeat any policy¹ we might want to enforce over SLSA v1 provenance attestations.

Footnotes

1. Whether you want to continue to use in-toto for this or not, but you should since you are using its attestations anyway. ↩

[kpk47]

Thanks for the discussion, everyone! I'm seeing the objections fall into a few categories (let me know if I miss any):

• This change would be tying the Sigstore and SLSA projects together.
• • I don't mean to suggest that we should make Fulcio certificates the only acceptable provenance format. I agree that tying the two projects together doesn't make sense. However, the two projects do work particularly nicely together, and a relatively small amount of work could create a virtuous cycle between adoption for build provenance and code signing.
• Putting provenance information in the certificate is abusing the x509 standard.
• • Guilty as charged.
• x509 is cumbersome
• • True, though it's also ubiquitous, and I have a feeling we can leverage that ubiquity to further SLSA's goals. For example, maybe signing a git commit (a well-understood though perhaps uncommon operation) could be the default way to produce SLSA Source provenance?
• The existing in-toto attestation format for provenance has nice properties.
• • I agree. However, the SLSA specification is clear that alternate provenance formats are acceptable. What isn't entirely clear to me is what counts as a good-enough alternate format. I am proposing that maybe a Fulcio certificate backed by a CI/CD system's OIDC provider might be good enough.

I propose the following plan:

1. Update the SLSA spec to clarify what is required in a provenance document of each level and why it is required (specifically, how it's used in verification). Ideally this clarification would live in the core specification, not in any one attestation format. This work would not only benefit the question at hand. We could also use the updated specification to enhance slsa-verifier's verification logic and/or write tools to convert between different provenance formats.
2. Decide whether a CI/CD OICD-backed Fulcio certificate meets the requirements laid out in (1). If not, then it would be up to Sigstore whether they want to add or modify certificate extensions to meet SLSA's requirements.

Thoughts on this plan?

[trishankatdatadog]

2. Decide whether a CI/CD OICD-backed Fulcio certificate meets the requirements laid out in (1). If not, then it would be up to Sigstore whether they want to add or modify certificate extensions to meet SLSA's requirements.

Sorry, but I still don't understand why the payload --- more precisely, an in-toto attestation, and more specifically, the SLSA v1 provenance --- should impose any requirement on the signatures (including any X.509 certificate chain). (And vice versa, actually, besides that the signature should be a function of the payload.)

Suppose you weren't using Fulcio to make the signature. What is the problem again here? I believe this goes back to @steiza's point: the information you are looking for should be in the payload, not the signatures, as much as possible.

One more point: redundancy is a friend of security. But maybe I misunderstood something here, so, open to corrections.

[kpk47]

Sorry, but I still don't understand why the payload --- more precisely, an in-toto attestation, and more specifically, the SLSA v1 provenance --- should impose any requirement on the signatures (including any X.509 certificate chain). (And vice versa, actually, besides that the signature should be a function of the payload.)

I think you may be missing some subtlety in my suggestion. I'm not saying the payload should impose requirements on the certificate chain. I'm saying a certain shape of certificate chain could influence what goes in the payload in the first place. I do understand the argument that relying on the certificate in that way would break layering. Maybe that's okay since we wouldn't be changing the trust model -- you have to trust the certificate anyways.

Suppose you weren't using Fulcio to make the signature. What is the problem again here? I believe this goes back to @steiza's point: the information you are looking for should be in the payload, not the signatures, as much as possible.

This proposal only makes sense when using Fulcio. Other CAs don't tie keys to a [identity, payload] pair in the same way. However, when we do have that nice property because we have a Fulcio certificate, why not take advantage of it?

I want to emphasize that I'm not suggesting we remove SLSA's in-toto attestation for build provenance. The concrete work I'm proposing is a specification change that would clarify what is required of alternate provenance formats, which are clearly allowed in v1.0.

[SantiagoTorres]

"I know I'm abusing the x509 spec but I draw a line on abuses on specs at 1, so let's change the SLSA spec"

I'm kidding :P

But really, I'm trying to understand what's the value add here.

The Fulcio extensions aren't exactly well tested and, afaict, there is not a lot of tooling that would make SLSA more widespread in that regard. W/ regards to in-toto, there is tooling to help with not only these certs but also SPIFFE and other PKI bits. All in all, all of these ecosystems have substantial maintainer overlap , so why not work on the right projects, w/ the right tooling with an appropriate purpose-fit?

As I said, I'm mostly against adding that change to the spec because:

1. It doesn't really add much? other than muddying the waters and relying on a feature of Fulcio that hell, who knows what it'll be later. I also don't know how useful it'll be to inform Fulcio design from the SLSA side (or vice versa).
2. It's busy work on something that, realistically, won't make writing SLSA compatible tooling easier. I don't think there are x509 tools that make it much easier to deal with non-defined OIDs that are any easier than inspecting a dictionary (or marshalling an object in Go for that matter). Are people going "oh I'd adopt SLSA but only if it was an x509 extension field in a Fulcio cert"?

[haydentherapper]

The Fulcio extensions aren't exactly well tested

What do you mean by this? These extensions are simply values from CI/CD identity tokens. We have seen them used already to generate SLSA provenance for npm. If you're referring to verification policies that ingest these extensions/values, both SLSA and Sigstore are working towards better tooling to simplify verification.

It doesn't really add much? other than muddying the waters and relying on a feature of Fulcio that hell, who knows what it'll be later.

One thing to stress is this is optional. If an ecosystem can adopt the SLSA spec as-is today, this proposal would not impact them. This proposal is most useful for an ecosystem that has already adopted Sigstore and an ecosystem where builds are primarily through CI/CD. Consider Homebrew as a good example of such (@woodruffw may have more thoughts).

I also don't know how useful it'll be to inform Fulcio design from the SLSA side (or vice versa).

We are already including provenance and source metadata as optional extensions. As I mentioned above, Fulcio's role will not be to interpret the SLSA specification, it will be to provide a verifiable record of an identity token and its values. SLSA can influence what a CI/CD provider includes in its tokens, which will be recorded by Fulcio.

It's busy work on something that, realistically, won't make writing SLSA compatible tooling easier. I don't think there are x509 tools that make it much easier to deal with non-defined OIDs that are any easier than inspecting a dictionary...

I think we're getting hung up on the challenges of X.509 tooling, which is a bit in the weeds. It might be worth zooming out and considering that, more generally, this issue is proposing support for additional formats for provenance. I think this will come up in other contexts - Look at C2PA, which is using CBOR/COSE.

[SantiagoTorres]

What do you mean by this? These extensions are simply values from CI/CD identity tokens. We have seen them used already to generate SLSA provenance for npm. If you're referring to verification policies that ingest these extensions/values, both SLSA and Sigstore are working towards better tooling to simplify verification.

I mean that, for example, there is no academic publication/formal analysis/systematic writeup studying the threat surface of these elements in the certificate as far as I can tell. I'm not trying to minimize their usefulness, I just think that, for example, we would have a harder time standardizing bits of Sigstore if we were to add these to the spec. I'm happy to have these, but I'm nervous about e.g., updating a spec --- any spec --- making assumptions about how this looks like. I'm honestly surprised we already have deprecated OIDs in Fulcio , and it makes me wonder how it will evolve.

One thing to stress is this is optional. If an ecosystem can adopt the SLSA spec as-is today, this proposal would not impact them. This proposal is most useful for an ecosystem that has already adopted Sigstore and an ecosystem where builds are primarily through CI/CD. Consider Homebrew as a good example of such (@woodruffw may have more thoughts).

Optional things are very hard to remove from specs

We are already including provenance and source metadata as optional extensions. As I mentioned above, Fulcio's role will not be to interpret the SLSA specification, it will be to provide a verifiable record of an identity token and its values. SLSA can influence what a CI/CD provider includes in its tokens, which will be recorded by Fulcio.

I am aware! this is, again, what I discussed as opening a can of worms back when it was done for the first time.

I think we're getting hung up on the challenges of X.509 tooling, which is a bit in the weeds. It might be worth zooming out and considering that, more generally, this issue is proposing support for additional formats for provenance. I think this will come up in other contexts - Look at C2PA, which is using CBOR/COSE.

I agree, but I think we are not zooming out propertly: what is the duty of SLSA? what is the duty of in-toto? what is the duty of Fulcio? There is nothing in in-toto that says "no CBOR" or "no x509", both of those things are supported. Take, for example, SCITT, (here is an impl of slsa + in-toto + scitt) explicitlly recommends CBOR, and explicitly acknowledges in-toto payloads. This, to me is like saying "why are we discussing oidc authentication at the link-local layer?!"

Again, I'm mostly confused, because this really doesn't seem like it is trying to have a value add, but rather add an -- admittedly optional -- waste of cycles for something that is not entirely considering the rest of the ecosystem (and we are trying to zoom out). To reiterate:

1. I don't think it'll help with adoption
2. I don't think it will help in adding value that other things in the ecosystem don't add

[woodruffw]

(Sorry folks, I was out of office today. I'm going to post a short summary of my thoughts, and write up a more detailed response on Monday.)

As a high level position: I think it's good to minimize duplicated state in systems. Duplicated state means duplicated behavioral checks, which means behavioral differentials.

As part of that, I think treating Fulcio certificates as a form of provenance makes sense when the identity borne by Fulcio certificate is essentially a form of provenance (like it is with GitHub Actions OIDC originated certificates). I agree with @kpk47's general rationales when it comes to the tradeoffs here: the Sigstore ecosystem is already "bought in" on X.509, and IME as a client implementor the custom OIDs/extensions are not a significant engineering burden or hurdle.

In terms of value add: simplicity in many implementation contexts. There's the duplicated state mentioned above, and also the complexity of each additional artifact for adopting indices (with "detached" provenance documents, every single artifact becomes tripled: the artifact, the Sigstore bundle, and the sidecar document).

There are also downsides: this doesn't address build provenance for other kinds of Sigstore identities (emails, usernames, really anything other than CI identities). But I think this problem also manifests in a equally (or more) pernicious form in the "detached" case: in that case, you need to form a trustworthy binding between two identities (the provenance and the signing identity), which means we essentially leave the identity problem that Sigstore solves unsolved.

(Sorry if I've missed any responses to these points above -- I promise that I will catch up here on Monday! And thank you again @kpk47 for starting the conversation here!)

[lehors]

I think we're getting hung up on the challenges of X.509 tooling, which is a bit in the weeds. It might be worth zooming out and considering that, more generally, this issue is proposing support for additional formats for provenance. I think this will come up in other contexts - Look at C2PA, which is using CBOR/COSE.

This is actually my biggest concern with this proposal: introducing "additional formats for provenance". I don't think introducing more variability in how this information is shared is desirable.

[lehors]

To add to my point above: practically speaking there is no way to undo what's already been done so making it possible to have the provenance data in the envelop will not simplify anything.
Anyone will still need to support the case where provenance data is in the payload of the certificate and will in addition need to support the case where that data is in the envelop.

[trishankatdatadog]

To add to my point above: practically speaking there is no way to undo what's already been done so making it possible to have the provenance data in the envelop will not simplify anything. Anyone will still need to support the case where provenance data is in the payload of the certificate and will in addition need to support the case where that data is in the envelop.

On top of that, the SLSA v1 Provenance will only be one of many in-toto attestations in the future (e.g., Release). Many of these attestations would presumably be signed with Fulcio. Is the plan then to adapt each and every one of those attestations to also move some of their payloads to Fulcio certificates?

[MarkLodato]

I think folks might be reading this proposal more broadly than intended. This is strictly about provenance attestations where the certificate already contains a copy of what is in the payload's predicate (e.g. Fulcio GitHub Actions OIDC originated certificates). Today, verifiers already have to parse the x.509 certificate extensions to verify the provenance; it's not secure to ignore them. So, the proposal is to call out that it's OK to omit that data from the payload to avoid duplication. I think that would simplify both producing and consuming provenance.

Note that this not proposing creating something new that doesn't already exist. Rather, it's just removing duplication from what's already being done.

With that narrow view, for folks who are opposed to this, could you help us understand the objection? What is worse about this than the status quo?

The only think I can think of is that it makes it harder to inspect the provenance without any tooling and without verifying. I'm not sure if that's a positive or a negative though :)

[MarkLodato]

Discussed at today's spec meeting. Brief recap of arguments against (not my opinions, trying to summarize the discussion):

• Slippery slope - not something we want to encourage, want to move in a different direction. Even if it makes sense in this limited case, there is significant concern that this is not the right long-term direction, so explicitly approving this would not be in our long-term interest. (I'm not sure if everyone would characterize it this way, but this is how I understood it.)
• Not sure this model extends to future SLSA Build L4+.
• Technically it is adding a new format (variant with no-payload) since you can’t take away the old one (with payload), so it’s not really simplifying the verifier.

Nothing has been decided, but IIUC this is what most of the discussion centered around.

[adityasaky]

Technically it is adding a new format (variant with no-payload) since you can’t take away the old one (with payload), so it’s not really simplifying the verifier.

To add on to this, supporting different formats that still follow the SLSA attestation model is one thing, but in my read, this proposal doesn't follow the attestation model either.

[woodruffw]

So, the proposal is to call out that it's OK to omit that data from the payload to avoid duplication. I think that would simplify both producing and consuming provenance.

Yes, this is my understanding of the proposal. My perspective as a Sigstore client implementor is that I need to verify all of the state that's currently already in the X.509 leaf cert (which is there by necessity as part of Sigstore's identity binding mechanism), so having it in two places rather than just one doubles the amount of errors I can introduce.

I don't think anybody wants to shove additional formats or complex predicates/statements into X.509 -- that would be a disaster 🙂. Instead, it'd be nice to take the things that are already intrinsic in a Sigstore identity and, where applicable, use those as the sole source of provenance. More precisely: when a Sigstore identity is already a machine identity like a GHA or GitLab workflow.

[laurentsimon]

It's worth noting that the Fulcio provenance cert has a different property than the SLSA build provenance.
Fulcio cert indicates that a signing event happened in a runner, but says nothing about where the build took place (or at least started). In other word, signing and building are not performed in a single atomic operation, so there's no reason to believe they happen on the same runner: a user could perform the build on a self-hosted runner, and sign the resulting build in a Github-hosted runner. Put differently, Fulcio cert is more a "repo ownership" provenance, and is sort of the public equivalent of the OIDC token. SLSA provenance, on the other hand, is about where artifact are built.. or at least where the built started.

Since the externalParameters of GitHub's SLSA provenance is the user's workflow, should the Fulcio cert not contain information to ensure that the entire workflow is made up of the same runner?