document key roation and a way to find a key without being vulnerable to a third party

[JanZerebecki]

Currently the README.md neither suggests how someone can get the key for verification of signatures without being vulnerable to a third party nor will there be a way to rotate the key to ensure one can reduce the risk of the key having been compromised or recover from it.

Is that correct, or did I miss something?

There are two well known ways to solve this: TUF and Web of Trust. And a way that is not realistic, which is always obtaining the rotated key in person. A widely observed log for the public keys can help less widely observed projects but has the same problem itself again. There are other implementations of the same concepts.
Are there any noteworthy other concepts to solve this?

Obtaining a fingerprint or similar of the public key in person from the owner is simply unrealistic. While it happens that people do this, it that needs to last for multiple decades (from my experience of projects where people use GPG Web of Trust), but key rotation needs to happen perhaps more often than yearly. The tools we use should also strive to automatically do this, e.g. before doing a signature, or where people desire harder compartmentalization prompt the user for a rotated key and refuse to sign until then.

TUF solves this by signing rotated keys with previous ones creating a chain of them. Then if you managed the expense of obtaining a fingerprint or similar of the key in person from the owner, you do not need to do that again on rotation, but instead follow the chain of key rotations.
The issue for TUF integration was closed: #86
Should that be reopened?

Web of Trust as known from OpenPGP solves this by obtaining a personal public key in person from someone you know, signing and publishing a statement that you did do so. To get to a public key for someone you did not meet you'd then follow this web constructed by these statements to the one you need. If someone rotates their key you do the previous again. AFAIK there is currently no implementation of a Web of Trust that has good usability and I'll omit a list of potential solutions for that here. Though it still manages to do better than only obtaining a key from some website.

As cosign supports creating keys, is it in scope to support key rotation?

[znewman01]

The tools we use should also strive to automatically do this, e.g. before doing a signature, or where people desire harder compartmentalization prompt the user for a rotated key and refuse to sign until then.

I want to echo this sentiment: we don't want users to be doing this themselves. But I think Cosign is the wrong tool for key management. I'll quote myself from #677 :

I view key compromise as largely external to the Sigstore project. Sigstore aims to provide a secure mapping from signatures to identities ("artifact X was signed by [email protected] at time T"). Revocation seems to be more about whether (and when) you should trust a particular key/identity.

Any use of Sigstore needs to answer questions of that form ("whom should I trust?") for itself. The (currently draft) blog post Signatus, ergo Securus? (you may need to join [email protected] for access) describes potential policies of that form in a few contexts (package repositories, internal to an organization). But that's the level at which to handle revocation. So if you use TUF (as recommended in that post), you should use TUF's support for revocation. If you hard-code a key/identity for verification, you need to support revocation at the point of hard-coding (Don't Panic walks through an example of what that might look like). These all follow the broad philosophy of "revoke artifacts, not keys".

Now, just because this is external to Sigstore doesn't mean that the Sigstore project should stay silent here, so I'm not going to recommend closing this issue quite yet. But I think this is going to fall under the bucket of "advice for adding Sigstore to your setting" and not "documentation about Sigstore itself."

I think everything I said about key compromise or revocation applies similarly to rotation, and in fact I'm somewhat inclined to close this issue as a duplicate and concentrate conversation on this issue over to #677 unless you think there's something different here.

The issue for TUF integration was closed: #86
Should that be reopened?

It's a good question. IMO I want to scope down what cosign actually does itself, and the answer might instead be to add Sigstore support to TUF, as proposed in this TAP. This makes more sense as a direction to me: you can sign things using a Sigstore/Fulcio identity, and your TUF client would check that and check that signatures were in Rekor.

[JanZerebecki]

Makes sense to deal with it in #677 , my searches didn't find that. Thank you.

IMO I want to scope down what cosign actually does itself

Then we probably want to discourage people from generating keys with cosign, but instead add how get a key elsewhere in the README.md .

[znewman01]

Then we probably want to discourage people from generating keys with cosign, but instead add how get a key elsewhere in the README.md .

I don't think that follows. Plenty of tools allow generating keys but don't prescribe a complete solution for distributing them (ssh-keygen, for one).

[JanZerebecki]

It doesn't follow that we should repeat the mistakes others made, just because widely used tools have grave errors in their security design. Other examples of projects where the foot-gun and assembly-needed approach is widely recognized as mistakes: openssl, x509 in https, OpenPGP.

Especially the first example of how to use the project should be one that is secure.

I didn't try, but I think it is possible to generate a key with TUF and use it with cosign, but AFAIK that is nowhere documented. If that is too complicated for the first example of cosign, I see that as an indication, that better UI is needed.