`sign-blob` for cosign v3

[steiza]

Description

For #4221 we brainstormed many high-level improvements for cosign v3.

I wanted to dig deep into one command (sign-blob) and investigate what a cosign v3 version of that command would look like. Hopefully this discussion will help us align both specifically on what we want to do for sign-blob as well as get a general idea of what's in scope vs out of scope for cosign v3.

I wanted to start with a sign command, because I think we can start dropping support for anything that's not outputting a protobuf bundle soon (maybe after #4318 lands), but verification will likely have to be backwards compatible for longer.

First the "easy" part: if we're moving to only support protobuf bundles, that also means that verification information has to come from a TUF repository (or a trusted root JSON file you supply). I think that motivates the following changes:

Input	Recommendation	Why
--b64	Remove	Moving from detached signature to using signature in bundle
--new-bundle-format	Remove	We're only supporting outputting the new bundle format going forward
--output	Remove	Moving from detached signature to using signature in bundle
--output-certificate	Remove	Moving from detached certificate to using certificate in bundle
--output-signature	Remove	Same behavior as --output
--rfc3161-timestamp	Remove	Moving from detached timestamp to using timestamp in bundle
SIGSTORE_CT_LOG_PUBLIC_KEY_FILE	Remove	Use TUF repository / trusted_root.json instead

But in reviewing the implementation of sign-blob, I was also reminded that we're in the midst of adding support for signing config, which will only be supported by sigstore-go, which means that eventually we want to move all signing over to sigstore-go. So we could just do the changes listed above and achieve a reasonable amount of cleanup, or we could go one step further and transition to always using sigstore-go, which would motivate the following additional changes:

Input	Recommendation	Why
--insecure-skip-verify	Repuprose	Currently only supported outside sigstore-go, but could be used to stop sigstore-go from verifying after signing
--issue-certificate	Remove	Not currently supported by sigstore-go; unclear as to why you would do this; maybe Fulcio with non-ephemeral key?
--oidc-issuer	Remove	Not currently used by sigstore-go; just use what's in the provided token?
--timestamp-client-cacert	Remove	Not supported by sigstore-go; is anyone using this?
--timestamp-client-cert	Remove	See above
--timestamp-client-key	Remove	See above
--timestamp-server-name	Remove	See above

I think both sets of changes could easily fit into one pull request, but I'm open to feedback on if people are interested in just doing the first table of changes described, or the changes described in both tables (and of course if there's anything I've missed or misrepresented!)

[steiza]

With the changes described in both tables, cosign sign-blob would go from having 32 flags (!) down to 20, or ~60% of the current number of flags. That's still a lot of flags, but definitely headed in the right direction.

[haydentherapper]

we could go one step further and transition to always using sigstore-go

Yes!

--insecure-skip-verify

We also have --private-infrastructure which does the same thing, skipping the Rekor check. I'd like to drop this flag, it's constantly used when it really shouldn't be. I think we should give some thought to the policy layer. We could take the policy configuration options in sigstore-go and make them CLI flags? Or turn the policy that is the outcome of sigstore/sig-clients#17 into CLI flags?

I'd also revisit the environment variables and remove any for detached verification material. I'd also like to get rid of COSIGN_EXPERIMENTAL, it's lingered around for too long.

[steiza]

I didn't see --private-infrastructure as part of cosign sign-blob, but I agree as we look at the cosign command generally for v3.

I also agree that we should audit the environmental variables. Where are the supported environmental variables documented? They aren't in the command --help. I'll have to check to see how / if these are handled today.