Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prototype: Plugin keyless verification #1902

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

wata727
Copy link
Member

@wata727 wata727 commented Nov 4, 2023

See #1351

Recently, the new sigstore-go was released by the Sigstore community. This is a long-awaited library that provides a Go API for keyless verification, which is what was ultimately needed for TFLint's plugin mechanism.

This PR is a prototype that uses sigstore-go for plugin verification. A stable version of sigstore-go has not yet been released, so this implementation is subject to change in the future. The goal here is a proof of concept.

Once this feature is merged, we will be freed from managing GPG keys embedded in TFLint, and third-party developers can safely provide plugin installations without declaring a signing_key.

To understand this change, you need to understand Sigstore's underlying technology. The following documentation may be helpful.

Please note that sigstore-go primarily support Sigstore bundles. On the other hand, the TFLint plugin is signed with Cosign, so the common example of sigstore-go is not available out of the box. This may be improved in a future sigstore-go version. This prototype solves this problem by implementing its own entity to satisfy the SignedEntity interface.

Specifically, what keyless verification does is as follows:

  1. Verify SET (Signed Entity Timestamp) in VerifyObserverTimestamps. The SET is embedded in the transparency log, which can be retrieved from Rekor based on the artifact's SHA-256. The SET and T logs cannot be tampered with because they are verified using Rekor's root public key.
  2. Verify certificate chain in VerifyLeafCertificate. This allows you to verify that the certificate passed was issued by Fulcio using Fulcio's root public key. At the same time, it verifies that the certificate was valid in SET and ensures that the leaked and revoked short-lived certificate has not been reused.
  3. Verify SCT (Signed Certificate Timestamp) in VerifySignedCertificateTimestamp. This ensures that the certificate was recorded in CT log servers. The SCT is verified using the CT log server's root public key, so it cannot be tampered with.
  4. Verify signature in VerifySignatureWithArtifact. Since the certificate's public key is guaranteed in previous steps, we use it to verify that the artifact is signed.
  5. Verify certificate identity in certificateIdentities.Verify. Since anyone can issue a certificate, the final step is to verify the certificate's identity. The identity is embedded in a certificate signed by Fulcio, so there is no room for tampering.

Please read the comments for details.

@wata727 wata727 marked this pull request as draft November 4, 2023 10:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant