verify: rekor public key should be obtained from the custom instance define via --rekor-url

[hectorj2f]

Description

When using cosign verify with a custom --rekor-url value, I realized the rekor public key is not taken from the custom instance. The rekor public key is always obtained from the rekor.sigstore.dev endpoint.

I believe cosign verify should always use the public key obtained from the endpoint defined via rekor-url for our custom rekor instance. Nowadays it only works if you set the environment variable SIGSTORE_REKOR_PUBLIC_KEY with the public key from your rekor instance.

[asraa]

Hi! Yes this is true. This is because ideally you should be pinning your trust for the ecosystem components out of band, which is why you probably should curl the pem from the custom rekor-url and use SIGSTORE_REKOR_PUBLIC_KEY

[hectorj2f]

@asraa But that is what I'd assume it should be automatically done (in the cosign code) when providing a specific rekor-url flag, so I don't need to provide the rekor-url and set the env variable.

[hectorj2f]

We also realized that any restart of the rekor instance changed the public key value, so that looks like one more reason to get the public key from the specified instance when set.

[asraa]

Hey Hector! Maybe I could clarify documentation for the flag -- this is where the client should be talking to for the log information, but trusted that log would mean that you have no out of band trust pinned in the client. Otherwise, there would be no need to verify any signature from Rekor.

[asraa]

We also realized that any restart of the rekor instance changed the public key value, so that looks like one more reason to get the public key from the specified instance l when set.

A rekor server deployment can also be specified with a particular signer, that'll avoid a creation of an in-memory key pair: https://github.com/sigstore/rekor/blob/ed585a3385f9d6447f886d6948554e261288bc6a/config/rekor.yaml#L59

[haydentherapper]

A couple more thoughts:

We should avoid pulling the key directly from the log because it opens us up to various attacks. This could include man in the middle, where an attacker injects their own key material and inclusion proofs and signed tree heads. Pinning a key out of band would make this detectable. Much like with PKI where you pin a root certificate that you trust, you need to start the trust root somewhere for an inclusion proof. If we ask the log for its key before verifying, a signature is pretty much unnecessary.

The SIGSTORE_REKOR_PUBLIC_KEY flag was meant for testing. Users for Cosign should get the trusted verification material from TUF. I'd like to take the stance that TUF is the only way to use Cosign as a CLI (Cosign as a library is a different story, it's up to the users of those libraries how they want to inject key material).

[asraa]

Closing in favor of documenting the out of band one #2122

Eventually we will remove this. See sigstore/scaffolding#211

Scaffolding is WIP to create a TUF server, people should use scaffolding, create their own custom TUF repo, OR use SIGSTORE_REKOR_PUBLIC_KEY in worst case scenario

[hectorj2f]

Awesome! Thanks @asraa