Support non-Sigstore TSAs

[haydentherapper]

The sigstore TSA implements an API to fetch timestamps, as does any other public TSA. Every API uses different paths to request timestamps, but all should conform to the same API structure, accepting timestamp queries and returning timestamp responses. We should support providing a path (timestamp-url) not to the sigstore TSA instance, but instead to the complete path to fetch a TSR (e.g. <sigstoretsapath.com>/api/v1/timestamp, or https://freetsa.org/tsr, or http://timestamp.digicert.com)

This means using a different TSA client than the sigstore TSA client, which is only useful for fetching timestamps from a service that has the same API paths as the sigstore TSA.

Ignore everything below, left as an unnecessary alternative

For users that want to leverage a TSA that uses a different API than the sigstore TSA, we should support attaching a signed timestamp after artifact signing.

For container signing, UX would look something like:

1. User signs container with Cosign
2. User fetches signature from OCI annotation
3. User crafts a timestamp query, for example using openssl (where --data should be the signature)
4. User requests a timestamp from their trusted TSA, for example FreeTSA
5. User attaches the signed timestamp to OCI

Verification with a signed timestamp should then work without any modification, but this should be confirmed.

For blob signing, during verification, simply pass the signed timestamp you fetched from a trusted TSA after signing with --rfc3161-timestamp. The one caveat is it must be crafted as a [struct]

cosign/pkg/cosign/bundle/tsa.go

Lines 18 to 24 in a84600e

	type RFC3161Timestamp struct {
	// SignedRFC3161Timestamp contains a DER encoded TimeStampResponse.
	// See https://www.rfc-editor.org/rfc/rfc3161.html#section-2.4.2
	// Clients MUST verify the hashed message in the message imprint,
	// typically using the artifact signature.
	SignedRFC3161Timestamp []byte
	}

). I propose we be more lax in accepting a raw or base64 encoded TSR in addition to the struct (I don't think we should add a command to convert a TSR into this struct)

[asraa]

RFC 3161 TSA's have a required API - shouldn't cosign be using that? That way it'd be compatible with all RFC 3161 TSA's.

I think there were some specifics of the sigstore's TSA API, but maybe cosign should implement a TSA client from the base API in the spec?

[haydentherapper]

Yea, you're right, there isn't a specification for standardizing the API path, but there is for what the TSA should accept (a timestamp query). I agree, we can add a TSA client that fetches a TSR based on a TSQ and a provided path (FreeTSA uses https://freetsa.org/tsr, I think Digicert is just http://timestamp.digicert.com). Right now the client is for sigstore's TSA API only, a wrapper around the openapi definition.