sigstore/sigstore-go

Go library for Sigstore signing and verification

sigstore-go

A client library for Sigstore, written in Go.

Features:

• Signing and verification of Sigstore bundles compliant with Sigstore Client Spec
• Verification of raw Sigstore signatures by creating bundles for them (see conformance tests for example)
• Signing and verifying with a Timestamp Authority (TSA)
• Signing and verifying (offline or online) with Rekor (Artifact Transparency Log)
• Structured verification results including certificate metadata
• TUF support
• Verification support for custom trusted root
• Basic CLI and examples

There is not built-in support for signing with a KMS or other bring-your-own-key; however you can easily add support by implementing your own version of the interface pkg/sign/keys.go:Keypair.

For an example of how to use this library, see the verification documentation, the CLI cmd/sigstore-go, or the CLI examples below. Note that the CLI is to demonstrate how to use the library, and not intended as a fully-featured Sigstore CLI like cosign.

Background

Sigstore already has a canonical Go client implementation, cosign, which was developed with a focus on container image signing/verification. It has a rich CLI and a long legacy of features and development. sigstore-go is a more minimal and friendly API for integrating Go code with Sigstore, with a focus on the newly specified data structures in sigstore/protobuf-specs. sigstore-go attempts to minimize the dependency tree for simple signing and verification tasks, omitting KMS support and container image verification, and we intend to refactor parts of cosign to depend on sigstore-go.

Status

sigstore-go is currently beta, and may have minor API changes before the 1.0.0 release. It does however pass the sigstore-conformance signing and verification test suite, and correctness is taken very seriously.

Documentation

Documentation is found in the docs subdirectory.

Requirements

• Unix-compatible OS
• Go 1.21

Installation

You can use the CLI with go run as in the below examples, or compile/install the sigstore-go CLI:

$ make install

Examples

$ go run cmd/sigstore-go/main.go \
  -artifact-digest 76176ffa33808b54602c7c35de5c6e9a4deb96066dba6533f50ac234f4f1f4c6b3527515dc17c06fbe2860030f410eee69ea20079bd3a2c6f3dcf3b329b10751 \
  -artifact-digest-algorithm sha512 \
  -expectedIssuer https://token.actions.githubusercontent.com \
  -expectedSAN https://github.com/sigstore/sigstore-js/.github/workflows/release.yml@refs/heads/main \
  examples/bundle-provenance.json
Verification successful!
{
   "version": 20230823,
   "statement": {
      "_type": "https://in-toto.io/Statement/v0.1",
      "predicateType": "https://slsa.dev/provenance/v0.2",
      "subject": ...
    },
    ...
}

You can also specify a TUF root with something like -tufRootURL tuf-repo-cdn.sigstore.dev.

Alternatively, you can install a binary of the CLI like so:

$ go install ./cmd/sigstore-go
$ sigstore-go ...

Testing

Tests are invoked using the standard Go testing framework. A helper exists in the Makefile also.

$ make test

Example bundles

examples/bundle-provenance.json

This came from https://www.npmjs.com/package/sigstore/v/1.3.0/provenance, with the outermost "bundle" key stripped off.

Support

Bug reports are welcome via issues and questions are welcome via discussion. Please refer to SUPPORT.md for details. This project is provided as-is.

sigstore-go's Issues

Add flag for observer timestamps to OCI example

Description

Tracking so it's not forgotten. Blocked by #51

[feat] add NewLiveTrustedRootWithClient()

Description

Re: slsa-framework/slsa-verifier#791 (comment)

I'm proposing that we change NewLiveTrustedRoot to accept an existing client, instead of making a new client for each fetch.
Or, we add a new function NewLiveTrustedRootWithClient() that does the same.

My use case is for my library slsa-verifer, where a user may pass in their existing client with custom opts, which slsa-verifier then uses for retrieving a TrustedRoot. Client.opts is private, so my library wouldn't be able to simply pass along the opts.

Error initializing `SignedEntityVerifier` using `WithSignedCertificateTimestamps` option

Description

I received the following error message while initializing a SignedEntityVerifier to use with the Public Good instance: "when initializing a new SignedEntityVerifier, you must specify at least one of WithObserverTimestamps(), WithSignedTimestamps(), WithIntegratedTimestamps(), or WithoutAnyObserverTimestampsInsecure()".

The example in the verify doc uses the verify.WithSignedCertificateTimestamps option when initializing a new SignedEntityVerifier for use with Public Good. I tried using this option with verify.NewSignedEntityVerifier but I get the same error. Reading through the verifier code, it looks like the code does not check for this option when validating options used with NewSignedEntityVerifier. Should I be using a different option?

Version

v0.1.0

Positioning sigstore-go vs other Sigstore libraries

I'd like to discuss what libraries are authoritative for verification logic throughout the Sigstore stack. I've thought about sigstore-go as glue for services. Ideally, I would like the following (and this is just my thoughts!):

• Rekor libraries
  • Type construction and parsing
  • Rekor client
  • Inclusion/consistency proof verification (if we need to simplify the existing trillian/transparency-dev APIs, otherwise use those directly)
• Fulcio libraries
  • Short-lived certificate verification (FWIW, this is fairly lightweight which is why we see it duplicated in each implementation currently)
  • Fulcio gRPC/HTTP clients
• Timestamp libraries
  • RFC3161 timestamp verification
• sigstore-go
  • Bundle consumption & generation
  • Golang logic for "code signing and transparency"
    • Glue between Signature/Attestation, Certificate/Key, Timestamp, and Inclusion Proof
    • Certificate could be Fulcio, could be self-managed PKI, etc. Timestamp could be from a TSA, SET, etc. These are higher-level concepts that represent the building blocks for transparent signing.
    • Designed such that we can support both the expected Sigstore path and other signing/verification flows
• sigstore/sigstore
  • Shared between Sigstore services and Golang clients (sigstore-go, gitsign)
  • Maybe should get folded into sigstore-go, but circular dependencies can occur

I'd like to align on this, as it'll drive what the dependency tree should look like and how we can simplify it.

Previous discussion around this: sigstore/sigstore#678

Originally posted by @haydentherapper in #28 (comment)

Support additional log key types

Description

Currently sigstore-go only supports ecdsa p-256 for the log's public key. The public instance currently uses this signature algorithm, but we may see other curves or key types used for private deployments.

Could also be fixed as part of #74

Pluralize WithTransparencyLog function name

Description

All other policy functions are pluralized. Should we pluralized WithTransparencyLog too? Might also want to update this to WithRekorLogs pending the discussion in #71.

Leverage Rekor's Verifiers API to extract keys/certs from entries

Description

We've created a Verifiers API in the Entries interface to abstract extracting "verifiers" - eg certificates, public keys, pgp keys, etc - from a given entry. This would simplify the logic in PublicKey() and add support for additional types (though there may be more places where types are hardcoded).

Interface: https://github.com/sigstore/rekor/blob/main/pkg/types/entries.go#L40

Code:

sigstore-go/pkg/tlog/entry.go

Lines 197 to 222 in f7518a6

	func (entry *Entry) PublicKey() any {
	var pemString []byte
	switch e := entry.rekorEntry.(type) {
	case *dsse_v001.V001Entry:
	pemString = []byte(*e.DSSEObj.Signatures[0].Verifier)
	case *hashedrekord_v001.V001Entry:
	pemString = []byte(e.HashedRekordObj.Signature.PublicKey.Content)
	case *intoto_v002.V002Entry:
	pemString = []byte(*e.IntotoObj.Content.Envelope.Signatures[0].PublicKey)
	}
	certBlock, _ := pem.Decode(pemString)
	var pk any
	var err error
	pk, err = x509.ParseCertificate(certBlock.Bytes)
	if err != nil {
	pk, err = x509.ParsePKIXPublicKey(certBlock.Bytes)
	if err != nil {
	return nil
	}
	}
	return pk

Implement Sigstore TUF Client Spec

Description

The TUF client in sigstore-go is very much an MVP, and we would like to enhance it to accomplish a variety of goals:

• Add the TUF Options specified in the Sigstore TUF Client specification. This includes controls for caching behavior and trusted repository mapping.
• Add support for fetching arbitrary targets, including delegate targets. Notably, this client should support the npm TUF delegation.
• Add API/ability to initialize multiple TUF repos in their own namespaces, given a URL and root.json, which can be used by private Sigstore instances with their own fully-contained TUF repos.

Add unit tests for online log verification and inclusion proofs

Description

The mock Sigstore data generates a Rekor log entry with a SignedEntryTimestamp but no inclusion proof (See generateTlogEntry).

Additionally, we don't test the online verification path since we don't have a fake Rekor client. Should be straightforward to add with something like https://github.com/sigstore/rekor-monitor/blob/main/pkg/rekor/mock/mock_rekor_client.go

bug: fix WithCacheValidity

Description

I'm planning to use the tuf client's WithCacheValidity() option. When I use.WithCacheValidity(365 * 2025), it works, but not with 2024. It seems like the initial LastTimestamp is initially set to 0001-01-01 00:00:00 +0000 UTC when using the embedded tuf root.

I'm thinking it should maybe be set to the same day the embedded root was updated, so instead I could just invoke with .WithCacheValidity(7), to say that I want to use my local cache up to 7 days after after refresh. Or if it's the embedded cache, 7 days after the root was published or embedded by maintainers.

Version

[email protected]

Set custom user agent for outbound requests

Description

It would help when debugging traffic to distinguish between different Golang clients. We may need to make a change to go-tuf to pass the custom user agent.

Policy for verifying with key

Description

Currently, when verifying with a key, you must specify WithoutIdentitiesUnsafe() when creating the policy verifier because no identity is provided. It would be more accurate to have a method such as WithKeyHint or WithKeyID, since identities are not needed when verifying with a key. Either this method could take a key fingerprint, or it could take no fingerprint given the bundle should contain a key hint.

If verifying with a Sigstore bundle, a key hint should be provided as a public key identifier. As long as the trust root contains the public key, we can match based on this key hint (currently implemented here. If this is not populated, either a) we should err out, or b) we should use a hint provided via the policy method.

Related: sigstore/protobuf-specs#236 to simplify providing trusted keys.

cc @kommendorkapten @codysoyland @rdimitrov

Verify certificates by issuer regex

Description

When we verify certificates, today we accept:

• An issuer string (e.g. https://token.actions.githubusercontent.com/)
• A SAN string (the user or workload identity used in the certificate)
• A SAN regex (in case you want to support a range of SAN strings)

Noticeably absent is an issuer regex, which is a feature supported by cosign. We should consider adding this capability to sigstore-go.

See #229 (comment) for the initial discussion.

Standardize naming of insecure/unsafe functions

Description

We have a few policy-level configuration functions that allow for insecure verification, useful for testing or private deployments: WithoutAnyObserverTimestampsInsecure, WithoutIdentitiesUnsafe, WithoutArtifactUnsafe. We should pick either "insecure", "unsafe", or some other adjective to describe risky verification behavior.

TrustedMaterial method naming

Description

Before a major release, I'd like to change the names of the interface methods so that each is not called an Authority. Overuse of Authority is going to lead to confusion since transparency logs are never referred to as authorities in any literature. I'd like to make the following changes:

• TSACertificateAuthorities() -> TimestampingAuthorities() (or TimestampAuthorities(), but the former is the RFC3161 name)
• TlogAuthorities() -> RekorLogs() (Specifying Rekor because this refers only to the Rekor personality and wouldn't work with some generic representation of a log)
• CTlogAuthorities -> CTLogs()
• The TlogAuthority struct -> TransparencyLog

A last change I am debating is changing FulcioCertificateAuthorities to CodesigningCertificateAuthorities. I don't think it's the right thing to do, but wanted to note my thoughts. By using Fulcio, we're stating a requirement for a specific certificate profile. "Codesigning" would allow BYO PKI scenarios. However, there are many assumptions made in the codebase around the structure of the certificate - short lived certificates, certain extensions, identities, etc. I think the better approach is to keep FulcioCertificateAuthorities and later add a separate type for a generic code-signing CA which relaxes many of the constraints. We were thinking something along these lines for Cosign, having a dedicated CLI namespace for BYO PKI.

Bundle v0.3 doesn't require tlog entries to have inclusion proofs

Description

The function that validates the bundle bypasses the check for inclusion proofs if the bundle version is v0.3.

Version

Security Policy violation Branch Protection

This issue was automatically created by Allstar.

Security Policy Violation
Dismiss stale reviews not configured for branch main

---

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Populate URIs for TimestampVerificationResult

Description

Currently, the URIs for TimestampVerificationResult structs are not populated on verification - 1, 2, 3, 4.

In order to implement this, we would need to plumb through the trust material, particularly the URI, from the verifier for each verified timestamp.

cc @phillmv

Compare the Rekor entry body to the artifact

Description

Tracking bug for https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/tlog.go#L174

This is not absolutely necessary because we do already compare against the signature which should effectively bind the entry to the artifact.

Additional verification of required fields in the bundle

Description

We currently check for an inclusion proof or promise in a validation function when constructing the bundle.

Further verification for required fields would be ideal. Using proto reflection, we could use the field annotation field_behavior to determine if the field has been annotated as required.

Clean up certificate timestamp comparisons

Description

There are three places we compare certificates against SET or TSA timestamps:

• We aggregate all timestamps from SETs and TSAs and verify the certificate with https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/signed_entity.go#L505-L511
• The code signing certificate is compared against the TSA timestamp here - https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/tsa.go#L113-L117
• We verify the certificate against the SET here - https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/tlog.go#L177-L179

As noted in a comment, the latter two are unnecessary, and so should be removed.

Support v0.3 bundles

Description

The primary change is the addition of the certificate field to be used when issuing bundles verified with the public good instance. This removes the ambiguity when dealing with a chain that contains more than just a leaf certificate and verifying with the public good instance. The chain should only be used for self-hosted Sigstore instances now.

Include skipped signatures in VerificationResult

Description

#47 and #45 introduce skipping log and TSA signatures respectively that the trust bundle cannot verify. This information is not passed back to the verifier, the signatures are just silently skipped over.

We can update VerificationResults to pass this information back, which could be helpful for debugging that the bundle contains the expected trust root material.

Proposal to remove Type for SubjectAlternativeName

Description

A user should not need to be aware of which "type" or GeneralName the subject is set in. Removing Type would simplify how a certificate identity is represented to be comprised of a subject and issuer only. This is also aligned with other Sigstore client implementations.

A similar conversation occurred in Fulcio previously (sigstore/fulcio#716 (comment)), and the threat of "type confusion" was mitigated through CA enforcement that URIs look like URIs and emails look like emails, rather than client enforcement.

Relevant code:

• https://github.com/sigstore/sigstore-go/blob/main/pkg/fulcio/certificate/summarize.go#L37
• https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/certificate_identity.go#L72-L76

I'd like to discuss this, I'm fine if we ultimately decide there is value in keeping this, but with the goal of making breaking changes before a 1.0, wanted to raise this.

Improve error message for verifying certificate identify

Description

encounter verify failing with error failed to verify certificate identity: no matching certificate identify, when verifying the CertificateIdentity of the bundle. However, suggest that the error to be more clear something like

SAN OIDSourceRepositoryURI "username" does not match expected pattern "userName"

Embedded file system file path creation fails on Windows

Description

When creating the path to embedded files, the code uses the filepath.Join, which will use a back slash as the path separator on the Windows platform. However, the embedded file system always uses forward slashes as the path separator, even on Windows, see the docs here.

Version

v0.2.0

Allow configurable signing algorithms

Description

@tetsuo-cpp filed similar issues under Cosign and Rekor. We realise there's a lot of overlap in maintainers, but wanted to make sure that we discuss each project that we plan to touch. Apologies if this feels a bit spammy.

Hi there! At Trail of Bits, we're looking at potentially implementing part of the Configurable Crypto Algorithms proposal (specifically Phase 1). We wanted to float this idea to each of the relevant Sigstore sub-projects so we can hash out the details in a more concrete way.

Across the Sigstore stack, we default to using ECDSA for signatures and SHA256 for hashing. There's more detail in the linked proposal but there are a number of motivations for wanting to customise the signatures that are generated, including paving the way for post-quantum signatures. The proposed design includes having a "supported algorithm" registry (perhaps this can go in the Protobuf specs) that enumerates the approved signature/hash algorithm combinations. We specifically don't want to allow arbitrary mixing and matching of signature and hash algorithm to avoid some of the security pitfalls listed in the proposal.

For sigstore-go, we want to support this set of approved signing algorithms. This can be as simple as a --signing-algorithm flag. As a first pass, we'd like to support ECDSA with SHA256 and SHA384 as well as EdDSA, with ECDSA-SHA256 remaining as the default.

SCT verification should compare timestamp against CT log validity window

Description

As a reminder, the purpose of validity windows is to mitigate two risks:

1. An old signing key for a service is compromised and produces an artifact after the service is turned down
2. A service that was turned down is brought back online and issues a cert or proof after it's been marked as rotated

I've been looking over the code and wanted to confirm if we are verifying validity windows for root metadata. Here's what I've found so far:

• TSA
  • The TSA validity window is compared to the TSA timestamp - https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/tsa.go#L106-L111
  • [Potential bug] There is no comparison for the intermediate and root certificates.
• Rekor
  • The Rekor validity window is compared to the entry integrated time from the SET - https://github.com/sigstore/sigstore-go/blob/main/pkg/tlog/entry.go#L271-L277
  • [Discussion topic] There is no timestamp comparison during verification of a proof because there is no SET. We should not use the integrated timestamp because it is not signed. This means that we cannot verify a log proof was generated during a validity window.
• Fulcio
  • CA validity window is compared to the certificate's not before/after - https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/certificate.go#L27-L32
  • [Potential bug] There is no comparison for the intermediate and root certificates.
• CT log
  • [Potential bug] It doesn't look like we compare the SCT timestamp to the CT log validity window in https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/sct.go

In terms of how to structure the code, as is currently implemented, each service (CA, CT log, Rekor, TSA) should be responsible for comparing any of its artifacts that contain timestamps against the validity windows. TODOs below:

• TSA compared against issued signed timestamps
• TSA compared for each certificate in its chain
• Rekor compared against issued SETs
• CA compared against issued leaf certificates
• CA compared for the root and intermediate CA certificates
• CT log compares against issued SCTs

The metadata I don't know how to verify is if a log proof was created during a log's validity window, since there is no timestamp. Using a certificate's timestamp is not accurate because a certificate may be logged long after a signing event. In the case of BYO PKI, there may also be no timestamps, if you log a signing event with a key. I think there's nothing to compare against in these cases.

Avoid repeating media type strings

Description

With the release of v0.3 all apps relying on the media type constants in pkg/bundle broke as the constants were removed in 20c2ce9

We should return the (existing) constants and/or add a method to create the bundle media type string to avoid duplicating the strings in all code using the library.

Version

v0.3

Reduce dependencies

Description

Tracking issue to coordinate on reducing the number of dependencies in the library.

A few thoughts so far:

• Pulling in Rekor pulls in KMS dependencies. We should look into refactoring upstream to move signing with KMS into its own package.
• Sigstore's timestamp authority pulls in a bunch of dependencies too, while we only need verification. We can either copy code in or refactor upstream.
• JSON libraries are pulling in mongodb for testing. Fixing this upstream is likely to be difficult though.

Changing VerificationContent interface method to return certificate by pointer

Description

HasCertificate returns a certificate by value along with a boolean to denote if the certificate was returned. A proposed simplification of this interface would be to change it to Certificate() (*x509.Certificate), which has two benefits: Passing by pointer over copy to avoid copying potentially large certificates, and removing the need to return a boolean when you can simply check if the return value is not nil.

One question for the original implementers: Was this function named to mirror the other function that returns an interface and boolean, since we can't return an interface by pointer?

Add support for ClientTrustConfig

Description

A ClientTrustConfig message wraps a TrustRoot and a SigningConfig, the latter specifying which URLs should be contacted to fetch a signing certificate, fetch an identity token, log a signing event, and get a signed timestamp.

This standardizes support for bring-your-own-infrastructure without the need to configure each client or bake in any URLs from the public good infrastructure.

Support Signing

Description

It would be great if sigstore-go could not just verify, but also sign bundles.

There aren't many libraries that support signing bundles today (just sigstore-js?) This would also allow sigstore-go to support the full range of tests in sigstore-conformance.

Goals

• sigstore-go/pkg/sign/ supports signing Sigstore bundles
• cmd/conformance/main.go is updated to support sign-bundle and sign (similar to verify, sign will "wrap" the bundle flow).
• Have a "signers API"
  • Have built-in support for signing with Fulcio and a keypair where you have direct access to the private key
    • I'm leaning towards a "batteries included" Fulcio support in the library itself, but if we decide against it we'll at least need support in the conformance driver
• Have a "witness API"
  • Built-in support for a timestamp authority
  • Built-in support for Rekor: entry types hashedrekord and DSSE
• Produces bundles with v0.3.1 (open to feedback here)
• Signing requires exactly 1 signer and at least 1 witness

Anti-Goals

• If we update cmd/sigstore-go/main.go, it should not compete with cosign
• API will support providing custom signers, but we won't support any KMS / HSM-based signing in sigstore-go itself

References

• Sigstore client specification
• https://github.com/sigstore/sigstore-js/blob/main/packages/sign/README.md
  • and the discussion on sigstore/sigstore-js#499

Support intermediate certificates in VerificationMaterial certificate chain

Description

Currently, in https://github.com/sigstore/sigstore-go/blob/main/pkg/bundle/bundle.go when we get a bundle that includes a certificate chain in the verification materials, we assume there is only 1 leaf certificate in the "chain" and no intermediates.

This needs to change if we're going to support certificate chains that include intermediates.

This came up in #101 (comment).

Unifying timestamp verification across SETs and TSA signed timestamps

Description

With the current spec, a client specifies how many SETs and how many timestamps are expected. The current implementation expects that every timestamp that is present is verifiable by material in the trusted root. We propose changing this in two ways: First, ignoring any timestamps that cannot be verified, as long as the threshold is met (noted in the bug below). Two, treating SETs and TSA signed timestamps as equals for fetching verified timestamp.

One approach for this is to expose a policy configuration that states a timestamp can be obtained from either an SET or TSA signed timestamp. This could be via a policy flag that states a threshold must be met for either SETs or signed timestamps. Personally, I like this approach of unifying the two, as SETs no longer are used as a proof of inclusion and instead are just a signed timestamp from the log. This also opens us up to adding timestamp providers, like Roughtime.

Related bug: #43 - Once fixed, as long as some number of timestamps are found that meet the threshold, verification will continue, and any failures will be ignored.

Support for additional transparency log key types

Description

Code:

sigstore-go/pkg/root/trusted_root.go

Lines 137 to 146 in f7518a6

	case protocommon.PublicKeyDetails_PKIX_ECDSA_P256_SHA_256:
	key, err := x509.ParsePKIXPublicKey(tlog.GetPublicKey().GetRawBytes())
	if err != nil {
	return nil, err
	}
	var ecKey *ecdsa.PublicKey
	var ok bool
	if ecKey, ok = key.(*ecdsa.PublicKey); !ok {
	return nil, fmt.Errorf("tlog public key is not ECDSA P256")
	}

The public instance uses ECDSA P256, but private instances can use RSA, other ECDSA curves, and ed25519. Should be a straightforward change, as ParsePKIXPublicKey can parse these key types. Support for PKCS1 encoded keys can be added with ParsePKCS1PublicKey.

Support additional GeneralNames in the SubjectAlternativeName

Description

See https://github.com/sigstore/sigstore-go/blob/main/pkg/fulcio/certificate/summarize.go#L64

• Support OtherName, used by Fulcio for user names in certificates (not currently in use in production)
• Support parsing additional GeneralNames like DNS, for BYO PKI use cases

Use GetLogEntryByIndex when querying Rekor

Description

Relevant code:

sigstore-go/pkg/verify/tlog.go

Lines 135 to 138 in 9a59c7f

	searchParams := rekorEntries.NewSearchLogQueryParams()
	searchLogQuery := rekorModels.SearchLogQuery{}
	searchLogQuery.LogIndexes = []*int64{&logIndex}
	searchParams.SetEntry(&searchLogQuery)

SearchLogQuery is used when querying Rekor to get an entry, which returns a list of entries matching the provided index. This will return a single entry since we are requesting a single index, but we can instead use GetLogEntryByIndex which will always return a single log entry.

(This is a low priority improvement, not a functional one)

Improper verification of number of DSSE signatures

Description

During verification where a DSSE envelope is embedded in the bundle, sigstore-go accepts envelopes a signature count other than 1, which is in violation with the protobuf-bundle spec.

This does not allow for any integrity or authenticity threats, as counter signatures are required, and the verifier must provide a list of accepted verification materials. But this can cause DoS style attacks where a bundle is modified to contain an invalid signature first, as the first signature is returned.

Version

All versions.

Update `VerificationResult` to have a proper `mediaType`

Description

At the time of writing, VerificationResult.Version is set to an int. Versioning is well and good, and should help us handle changes to the struct over time.

However, after thinking about it some more, it became apparent that:

1. should VerificationResult ever get stored to disk, a plain int Version is insufficient for figuring out how to parse the file
2. it is incongruous with other sigstore types & documents in the broader ecosystem

For that reason, I hereby propose we rename Version to MediaType and set it to "application/vnd.dev.sigstore.verificationresult+json;version=0.1" as the current default.

MinVersion not compatible with Bundle v0.3

Description

ProtobufBundle.MinVersion is not compatible with the new v0.3 Bundle MediaType which ends with +json.

This is used by the flag -minBundleVersion flag in the CLI.

Add unit tests for bundle package

Description

Code: https://github.com/sigstore/sigstore-go/tree/f7518a68b37b7887b69e1607b9ddb668ddec117d/pkg/bundle

Support TSAs other than sigstore/timestamp-authority

RFC3161 does not define a specification for the API path of a TSA, only standardizing the input and output as timestamp request and response structures. The Sigstore TSA implementation defines the path to request timestamps as api/v1/timestamp.

As discussed in #187, the current timestamp authority client, which comes from generated code in sigstore/timestamp-authority, only supports the Sigstore TSA implementation. When a URL is provided to the client, it is truncated to only the URL host, and then the API path above is appended.

In order to support arbitrary TSAs, we need to use a custom client that a) uses the provide URL with both the host and path, b) takes in a timestamp request, and c) parses a returned timestamp response.

We have implemented this already in Cosign as part of sigstore/cosign#2708:

• https://github.com/sigstore/cosign/blob/main/internal/pkg/cosign/tsa/client/client.go for the client
• https://github.com/sigstore/cosign/blob/main/internal/pkg/cosign/tsa/mock/mock_tsa_client.go for a mocked client for testing
• https://github.com/sigstore/cosign/blob/main/internal/pkg/cosign/tsa/signer.go#L38-L45 as an example of this being used

I would recommend we upstream this client to sigstore/timestamp-authority or duplicate it in sigstore/sigstore-go.

Upstream bundle interface methods to protobuf-specs, and remove ProtobufBundle type

Description

The ProtobufBundle type is largely a wrapper around the generated protobuf type Bundle:

type ProtobufBundle struct {
	*protobundle.Bundle
	hasInclusionPromise bool
	hasInclusionProof   bool
}

The original purpose of this type was to add interface methods to Bundle to implement the SignedEntity interface, before this repo was open-sourced, and while the protobuf-specs repo was unstable, or perhaps before the generated protobuf types were added there.

In order to use this library, a user who holds a Bundle type must first convert it to a ProtobufBundle type, using NewProtobufBundle. This conversion is simple, but adds boilerplate, and in many cases, it must also be first converted from JSON. We do have a helper func that facilitates this two-step conversion, LoadJSONFromPath, but users working with native protobuf types, such as using gRPC or Twirp, must always convert types, and the ProtobufBundle type doesn't have a clear meaning for users new to the library, and is hard to disambiguate from the actual "protobuf type".

The user experience of this library may be improved if we chose to upstream these interface methods into the protobuf-specs repo, in a file that resides next to the existing generated file. This would also make the upstream type easier to work with, allowing users to extract certificate chains and other types without requiring sigstore-go.

There are a few complications that might make this idea impractical. It would imply the upstreaming of some other interfaces and types to protobuf-specs, such as verify.SignatureContent, verify.VerificationContent, and root.TrustedMaterial, as these types are all bound to the SignedEntity interface.

In case this change would shift too much code up to protobuf-specs and complicate developement on sigstore-go, it could be argued that the generated Bundle type from protobuf-specs should be moved into sigstore-go and have the methods added here.

I would love to hear folk's thoughts on this prior to the 1.0 release, as I think it could make the public APIs cleaner.

Change online flag behavior to only fallback

Description

Bundles are required to have inclusion proofs. The only time online verification would be needed is for API callers who are providing verification material without a bundle and without an inclusion proof/SET.

Online verification provides the same security guarantees as offline verification, for offline or online verification (wrote up details in stacklok/minder#2120 (comment)), except with the added latency and decreased privacy (since you're identifying what artifact hash or identity you're verifying to the log).

I would like to change the behavior of the online flag to fallback to querying Rekor only if an inclusion proof/SET was not successfully verified.

Long-term, I would like to remove online verification entirely and require an inclusion proof to be presented. This somewhat relates to sigstore/sigstore-conformance#122, standardizing on the bundle as input. However this isn't pressing to do immediately, and this would require updating the client spec to remove online verification.

Add configuration to not count SETs towards log threshold

Description

Discussed more in #51 and #44. This should be off by default for v0.2+ bundles, since log inclusion proofs are required, and on by default for v0.1 bundles, since proofs are optional.

Blocked by #51 being merged

Bundle() inline verification of Intoto Statements

I'm getting started with using the Bundle() function to make a signed Sigstore Bundle from an intotoStatement.

I'm invoking similar to

statementBytes, _ := json.Marshal(*statement)
content := &sigstoreSign.DSSEData{
    Data:        statementBytes,
    PayloadType: "application/vnd.in-toto+json",
}
bundleOpts := &sigstoreSign.BundleOptions{
    ...
    TruestedRoot: trustedRoot,
}
bundle, _ := sigstoreSign.Bundle(content, keypair, *bundleOpts)
...

If I specify a TrustedRoot, then Bundle() will also attempt to Verify() before returning the bundle. But I think there may be a few problems with the setup for there.

1. The options artifactOpts := verify.WithArtifact(bytes.NewReader(content.PreAuthEncoding())) may not be correct to use, since it treats the "artifact" as the envelope, not as the artifact(s) that the envelope references.
2. verify.WithArtifactDigest() is probably more appropriate, but it does not currently support multiple artifacts.
3. I'm a still new to go, so I'm not sure about this one: Since the envelope's Digest (: )will be amap[string]string, and not map[string]byte does the hash need to be hex-decoded into bytes before comparison?

Rename ProtobufBundle to Bundle

Description

I propose renaming bundle.ProtobufBundle to bundle.Bundle, as a cleaner name, and to help disambiguate it from the pure-protobuf type in the protobuf-specs repo.

Other discussion about this type is found in #243

Timestamp verification should not fail unless the threshold is not met

Description

Looking at https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/tsa.go#L64, if any timestamp verification fails, then the verifier errors out. Instead, the verifier should succeed as long as the threshold for successful timestamp signatures is met. If there's N timestamps, and the threshold is 1, then the verifier only needs 1 timestamp to verify to succeed.

Add unit tests for SCT verification

Description

Need unit tests for https://github.com/sigstore/sigstore-go/blob/main/pkg/verify/sct.go.