Sigstore is a set of tools / link to Tooling page from Overview page

[smythp]

On the current iteration of the main Overview page, we don't actually come right out and say what Sigstore is, i.e. that it's a set of tools. Once we have the new "Tooling" page in place, we could add a line about this and link to that page.

Arises from discussion in #210

[olivekl]

Thanks, @smythp. I have drafted out some text for the opening Overview page to make things easier for newcomers. I'll paste it here for discussion and can open a PR if you think it's helpful. Happy for people to iterate on this as well.
@haydentherapper @jonvnadelberg @ltagliaferri

__
/index.md
Sigstore is a suite of tools that empowers software developers and consumers to securely sign and verify software artifacts such as release files, container images, binaries, software bills of materials (SBOMs), and more. The signing materials are stored in a tamper-resistant public log so there’s no need to manage or store keys.

Sigstore is a Linux Foundation project backed by Google, Red Hat, and Purdue University. It is 100% open source and free to use for all developers and software providers. The sigstore community develops and maintains the source code and tooling as a public good, non-profit service to improve the open source software supply chain.

Why cryptographic signing?

Digital signatures are a way to verify the authenticity of a software artifact. Software consumers can trace software back to the source to know who created the artifact and that it hasn’t been altered or tampered with after it was signed.

In a landscape of growing software supply chain attacks, unsigned software is at risk for several attack vectors:

• Typosquatting -- [explain briefly]

• Dependency confusion -- [explain briefly]

Why Sigstore?

Sigstore improves on traditional methods of signing to be more convenient and secure.

Convenience: users can take advantage of convenient tooling, easy container signing, and can even bypass the difficult problem of key management and rotation.

Security: with Sigstore, the artifact is not just signed; it’s signed, verified, and witnessed.

Traditional artifact signing relies on exchanging cryptographic keypairs for signature verification. The software creator keeps one key secret (the private “signing” key) and publishes the other (the public “verification” key). When a software consumer wants to verify an artifact’s signature, the verification key is exchanged to prove that the holder of the private key created the signature.

This traditional approach has several weaknesses:

• Identity: how do you know the person signing the artifact is who they say they are?
• Key management: how do you keep the private key secure so it can’t be lost or stolen? How do you make the public key easily accessible for users, but also protect it from tampering by a malicious attacker?
• Key revocation: if the keypair is compromised, how do you distribute new keys in a way that convinces users of your legitimacy and that you’re not an attacker?

Sigstore addresses these problems by helping users move away from a key-based signing approach to an identity-based one. When using sigstore’s full capabilities, your artifact is:

• Signed: with easy-to-use tooling (called Cosign)
• Verified: by checking your identity with our certificate authority (called Fulcio)
• Witnessed: by recording the signing information in a permanent transparency log (called Rekor)

The signer can even forgo using long-lived keypairs. With “keyless” or “ephemeral key” signing, users verify the artifact using the transparency log for signature verification rather than keys.

Read more in [Main Concepts]

[jonvnadelberg]

If it's ok, I'm going to implement Kara's draft into the overview. Unless there is an objection, @smythp ? Let me know.

[olivekl]

If it's ok, I'm going to implement Kara's draft into the overview. Unless there is an objection, @smythp ? Let me know.

Thank, @jonvnadelberg. Feel free to clean it up / edit. It gets messier as it goes. :)

[smythp]

Closing this issue, with thanks to @jonvnadelberg for his work in #241.

cc: @olivekl