Add support for key-based verification

[steiza]

Description

At the recent clients and TSC meeting, we determined we would like conformant Sigstore client libraries to be able to verify protobuf bundles that were signed with managed keys, in addition to the verification we support today of signing certificates from Fulcio obtained with an OIDC token.

There's a couple of steps needed for this:

1. We need to update the conformance CLI verify protocol to include verifying with a provided public key, instead of a certificate identity and certificate OIDC issuer. We could take inspiration from / learn lessons from https://github.com/sigstore/sigstore-go/tree/main/examples/sigstore-go-verification here. Note that we should continue to accept a trusted root when verifying with a public key, in case the bundle contains transparency log entries or signed timestamps that also need to be verified.

2. Once we agree on and land the update to the conformance CLI verify protocol, we can update https://github.com/sigstore/sigstore-go/blob/main/test/conformance/main.go to support the protocol (we might want to do this in parallel to test out the proposed protocol changes).

3. We should add some conformance tests that use the CLI verify protocol with managed keys, and either protect them with a flag (like --skip-signing) that's off by default, or include xfail instructions in the subsequent conformance test release.

4. Other clients can then add managed key verification support, and test their implementation with the new conformance tests.

Note that out of scope for these changes are verifying with a public key that's embedded in a X.509 certificate (although we may choose to add that at a later date). The way cosign / sigstore-go handle verifying with a user-managed certificate is to check it against the certificateAuthorities certificate chain in the trusted root that usually points to a Fulcio instance.

Also out of scope is having all client libraries sign with managed keys. There's a lot of complexity here around supporting various cloud HSMs (usually via REST APIs), as well as local HSMs (usually via PCKS #11). Cosign supports these use-cases today, and we encourage Sigstore users who want this functionality to use Cosign.

[haydentherapper]

There's a few interactions with other services we should also standardize.

Should all clients be able to verify Rekor entries where the signature verifier is a public key? I'd say yes - Cosign will default to uploading signatures generated with keys or certs to Rekor.

Is a signed timestamp required with keys? Maybe. A timestamp is required for verifying a short-lived certificate, but a key has no inherent validity window. However, we could imagine someone distributing a trust root policy that states the validity windows of verification keys, at which point some timestamp would be needed. We discussed this in sigstore/sigstore-go#496 and said that timestamps from witnesses would be sufficient.

Should clients support requesting Fulcio certificates for user-provided keys? I'd say no - Cosign supports this but this is such an edge case and I am unaware of anyone asking for this.

Note that out of scope for these changes are verifying with a public key that's embedded in a X.509 certificate

Agreed with this being out of scope. We need to solidify what the requirements are for user-provided certificates. Should they or should they not adhere to the Fulcio certificate specification?

Also out of scope is having all client libraries sign with managed keys

+1 for now. I think we could propose a minimal set of requirements for clients to implement that wouldn't include HSM support, but I don't have a clear use case in mind and we haven't heard ecosystems ask for support.