Using key-based signing

[chipzoller]

Most of the examples I've seen for achieving SLSA 3 involve cosign's keyless signing ability. While this is handy, involves managing no keys manually, and can result in better security, there are problems with this in enterprise environments, especially for customers in highly-regulated verticals like finance and healthcare. Cosign's keyless signing ability is still experimental and relies on external infrastructure which can neither be seen nor controlled. And as with all things, it can also go down like in this 10 May event. Most enterprise organizations are not comfortable relying upon such third-party infrastructure which, in outage situations like the one referenced, may render them and their customers unable to perform verification of their products. This can have a cascading and catastrophic effect as those customers may be reselling to other customers. And, to be clear, it isn't just enterprise organizations pedaling a commercial product for whom this would be useful. Many OSS projects may also want to own and control their own keys for similar reasons as those described above.

Some guidance would be very useful to many organizations out there as to how they can attain SLSA level 3 by controlling their own keys but doing so securely. Illustrating this, as so many demo repos have done, using GitHub Actions would be especially useful.

This issue was created at the request of @laurentsimon in an OpenSSF Slack thread here.

[laurentsimon]

Thank you for the issue. We agree this is a compelling use case for enterprise environments.

/cc @hepwori

[ianlewis]

This issue I think is essentially a duplicate of #34 though I'm happy to be told otherwise :)

Though I think there were two things raised on that issue that should be dealt with separately. Namely, having your own Fulcio/Rekor servers etc., and using your own keys. This issue deals with the latter I assume?

[chipzoller]

Correct. Although there's certainly value in both, my suggestion here was guidance on how to use enterprise PKI in the "correct" manner which satisfies the demands of SLSA 3+.

[laurentsimon]

The goal is to avoid the key leaking, which would invalidate the non-forgeability of the provenance. So here are some good practice:

1. The key should never be accessible to a human in plaintext, ever
2. Rotate the keys once in a while. It's up to you how often your rotate: the higher the frequency, the less damage a key leak causes (OIDC-based certificate ephemerality gives you this property)
3. Log every access to the key (e.g., upload each signature to rekor), even if you don't use OIDC. This helps in incidence response, but also allows monitoring for unexpected key usage. Having the key/cert "signed" by a CA makes monitoring easier, otherwise you need looks for different keys after each key rotation, which will become cumbersome
4. Allow only machines request a key signature operation as an oracle. In GCP, there is BinAuthZ to help you do that, I think. Ideally you want to allow a key operation only by software that has a certain level of SLSA provenance: e.g. you want to be sure the software was reviewed, and comes from the right source code (SLSA3 and 2LGTM would give you this).

/cc'ing other folks who may have other advice, give more nuanced answers, and maybe point you to a SLSA doc (if this doc does not exist, we can create one)

@MarkLodato @haydentherapper @joshuagl @asraa

[haydentherapper]

In addition to the key management suggestions Laurent gave, for enterprises that already manage their own signing infrastructure and don't want to rely on the community-hosted Sigstore infrastructure, they can run their own instances of the transparency log and certificate authority. If provenance will be consumed outside of the enterprise, then this comes with the downside of needing to distribute verification keys, rather than relying on the verification keys distributed by the Sigstore community instance.

Very much agree with (3). Even with using a long-lived key, provide an immutable, auditable record of signatures. Fail closed on verification if the signature is not present in the log.

With respect to rotation, you also need to consider how to trust key rotations. Think trust-on-first-use with SSH - You want to avoid presenting a dialogue that warns users of a changed verification key that users will just skip through. This is one reason why we prefer the keyless flow that uses a stable identifier from an identity token, since there is no need to rotate that identifier over time.

[chipzoller]

I appreciate all the tips you two are providing here. I can infer from the responses that the current approach I have taken in this experiment of mine (whereby the signing key is stored as a GitHub secret in the repo) just won't cut it to achieve SLSA 3+. It'd be nice if this could be called out explicitly. The difficulties I still see here, which I'm sure would be echoed by enterprises, is, "this is great advice...but I still don't know what technology to use and how to incorporate them to pass this standard." I'm also not trying to demand an answer, I'm just pointing out that, at some point, the guidance has to be much more prescriptive to direct users what precisely to use and how precisely to use it in order to become SLSA compliant. Hand waving over classes of advice (eg., "do something over here, then do something over there, but don't do these types of things") just isn't enough for most organizations who aren't adept with these security concepts.

[laurentsimon]

Thanks @chipzoller we appreciate your feedback and the lack of tooling/actionable guidance.
Take a look at SLSA roadmap slsa-framework/slsa#384, and feel free to comment and get involved