cosign attest[-blob]: add TSA certificate command-line options and AttestOptions fields

[dmitris]

Description

Currently I'm not able to use our internal TSA with cosign attest (I'm testing the version from #3889) - the error is below. The TLS connection to the TSA server requires a custom CA roots, but cosign attest - unlike cosign sign - doesn't have the --timestamp certificate fields, other than --timestamp-server-url. cosign sign does have the following fields:

$ cosign sign --help
[...]
    --timestamp-client-cacert='':
	path to the X.509 CA certificate file in PEM format to be used for the connection to the TSA Server

    --timestamp-client-cert='':
	path to the X.509 certificate file in PEM format to be used for the connection to the TSA Server

    --timestamp-client-key='':
	path to the X.509 private key file in PEM format to be used, together with the 'timestamp-client-cert' value,
	for the connection to the TSA Server

    --timestamp-server-name='':
	SAN name to use as the 'ServerName' tls.Config field to verify the mTLS connection to the TSA Server

    --timestamp-server-url='':
	url to the Timestamp RFC3161 server, default none. Must be the path to the API to request timestamp responses,
	e.g. https://freetsa.org/tsr

For parity with cosign sign and to enable using a non-public TSA which is crucial for a private infrastructure / BYOPKI use case, I suggest to add the command-line flags above. I will submit a PR equivalent to the patch that we internally have to apply for several month now - it would be great not to have to patch cosign code! 😄

Initially we hesitated whether we should try to submit that change since there were discussions regarding use of the trusted root. But now having looked into this more closely, I believe the trusted root is more relevant to the verification (cosign verify, cosign verify-attestation) than to producing signatures and attestation. Even though I'm aware and understand the reservations regarding the "command-line flag proliferation", I think in this case it would be justified. In particular, it would help up to test and get practical experience with the attestations in the "new bundle format" once #3889 is merged. Please let me know if you have any questions - will attach a PR with the suggested change shortly.

Previous related issues / PRs:

• add support for mTLS connection to the TSA (timestamp server) #3006
• add 'cosign sign' command-line parameters for mTLS #3052
• add mTLS to TSA for sign-blob command #3200

The current cosign attest error:

cosign attest --verbose --timestamp-server-url https://tsa.athenz.internal.cloud:4443/api/v1/timestamp \
 --tlog-upload=false --no-upload=false --key import-cosign.key --certificate-chain cacert.pem \
 -certificate cert.pem --predicate spdx.json --type spdxjson \
 --new-bundle-format=true docker.ouroath.com:4443/dmitris/busybox-7ade8c80@sha256:10ca8dd553deab7f00b6ca68eb33c8f8ef9234524ef4f32e243a8aa2a6ca8147
Using payload from: spdx.json
Error: signing docker.ouroath.com:4443/dmitris/busybox-7ade8c80@sha256:10ca8dd553deab7f00b6ca68eb33c8f8ef9234524ef4f32e243a8aa2a6ca8147: error making request to timestamp authority: Post "https://tsa.athenz.internal.cloud:4443/api/v1/timestamp": tls: 
failed to verify certificate: x509: “athenz.tsa” certificate is not trusted
error during command execution: signing docker.ouroath.com:4443/dmitris/busybox-7ade8c80@sha256:10ca8dd553deab7f00b6ca68eb33c8f8ef9234524ef4f32e243a8aa2a6ca8147: error making request to timestamp authority: Post "https://tsa.athenz.internal.cloud:4443/api/v1/timestamp": 
tls: failed to verify certificate: x509: “athenz.tsa” certificate is not trusted