Busting 5 Sigstore Myths

In this post we’ll clarify 5 common misconceptions we’ve heard about Sigstore. For those new to Sigstore, it’s an open source project composed of several different components to make it easy for developers to cryptographically sign software and for consumers to verify it. This enables software to be traced back to the source, and prove that it hasn’t been tampered with after it was signed. Ok, with that quick primer out of the way, let’s dive right into some myth busting.

Myth #1: Short-lived certificates mean you need to re-sign your software artifacts constantly.

In public key cryptography, a certificate is typically valid for several years and the associated private keys need to be secured over that time. This has led to some people believing that because Sigstore is designed with short-lived certificates, developers must re-sign their software artifacts constantly. This is false. Fulcio makes the use of a timestamping service to authenticate the exact time the signature was created. We only care that the signature was created when the certificate was valid, not when the signature is verified. The benefits of this design are that developers do not have to worry about keeping their private keys secure and it avoids the pitfalls of managing key revocation.

Myth #2: Sigstore doesn’t support revocation.

Speaking of revocation, when a certificate is revoked it means it should no longer be trusted. Certificates are usually revoked if there is a key compromise or the certificate shouldn’t have been issued in the first place. Managing certificate revocation is difficult and error prone. Sigstore’s Fulcio supports a form of implicit revocation which avoids these downsides. This type of design is regarded by experts as more scalable, reliable and secure than explicit revocation. Coupled with Sigstore’s transparency log, Rekor, it’s possible to look up exactly what software artifact was signed which enables even finer grained revocation as opposed to not being able to pinpoint exactly which artifact is the “bad one” and therefore having to revoke everything tied to a specific signature.

Myth #3: Sigstore is only for signing and verifying containers!

While Sigstore’s Cosign tool is the easiest way to sign and verify containers today, that doesn’t mean they’re the only thing that can be signed. Sigstore supports signing any blob of data! Binaries, rubygems and yaml are all thirsty for signatures.

Myth #4: The transparency log means you can’t verify signatures offline.

Another common use case is that organizations need to run systems in air-gapped environments with no outside network access. That means it’s not possible to look up a signature in the transparency log, Rekor, right? Wrong! We use what’s called “stapled inclusion proofs” by default, meaning you can verify an object is present in the transparency log without needing to contact the transparency log! The signer is responsible for gathering this evidence from the log and presenting it alongside the artifact and signature. We store this in an OCI image automatically, but you can treat it like a normal file and copy it around for verification as well.

This is exactly how most of Web PKI works too! Browsers do not need to contact transparency logs for every domain they contact - that would be a massive operational load, failure point, and privacy violation for the internet. Instead, the website operator obtains an inclusion proof from their certificate authority, attestation that the CA logged the certificate. The server operator then passes this along to the client with the certificate, often in the form of a Signed Certificate Timestamp.

Myth #5: Sigstore is only for open source software.

Nope! Although Sigstore was created with open source in mind, you can run all of the Sigstore components in your own environment, and many organizations do so already! You can take advantage of the open source sigstore client tooling and integrations, while designing your own PKI to fit your threat model. One of the most common threats we’ve heard is insider attacks. This puts you in control of the root signing certificates. The CA (certificate authority) and transparency log can both be operated in offline, hybrid, or managed (using the public good service) modes. If you need help or are interested in discussing a setup like this, please don’t hesitate to reach out!

Bonus Myth: Is “Sigstore” spelled with a capital or lowercase ‘s?’

This is left as an exercise for the reader. I have no clue. What’s more important is that you start using Sigstore (sigstore?) to sign your software artifacts!