signature revokation support or approach

[Rajpratik71]

Question

Is signature revocation supported in "cosign"?

if yes, how to achieve that?

[znewman01]

Revocation is a notoriously tricky problem. In general, at signature verification time, the verifier needs to fetch an up-to-date list of the things that have been revoked (keys, identities, etc.) and check that the signature is still valid. There are a number of approaches here and it's still an area of active research.

In Sigstore, our philosophy is broadly: "revoke artifacts, not keys". The idea is that identities are long-lived (like your Gmail account); we generally don't want to burn those to the ground every time a signature needs to be revoked. If we use a new key pair for each signature, then we can revoke specific artifacts from a signer without revoking everything that signer has ever signed. (In some cases, you do want to revoke everything from a particular signer. That's supported by removing the identity from your list of trusted identities, but it's a different operation.)

How you achieve this depends on how you're doing verification. We have a blog post that gives some specific examples for a homemade verification system (which makes the mechanics clearer). But you could achieve the same thing with sigstore/policy-controller or Kyverno.

Does that make sense? If you can share the scenario in which you're signing/verifying artifacts, we may be able to provide more specific advice.

[haydentherapper]

Revocation is hard - How do you build such a list? How do you authorize who can upload a revoked artifact to a public list for Sigstore? How should a client poll for updates to a list? Where does a client store this list? How do you prevent this list from growing too large?

Echoing @znewman01, I would try to solve this through a verification policy rather than design a revocation mechanism. Specify what identities you trust for which artifacts for example, and update that mapping if an identity needs to be "revoked".

[Rajpratik71]

A similar approach which the "Notary v1" or "docker trust" command does to sign and revoke the signature of an artifact tag, can be used/implemented to achieve a bit level of signature revocation.

[Rajpratik71]

Does cosign clean described at https://github.com/sigstore/cosign/blob/main/USAGE.md#signature-location-and-management , can be used to achieve revocation of signature?

[znewman01]

Does cosign clean at https://github.com/sigstore/cosign/blob/main/USAGE.md#signature-location-and-management , can be used to achieve revocation of signature?

I would strongly advise against considering "deleting the signature" to imply "revoking the signature." If anyone has stored that signature, they can still convince you to consider the image valid. This may happen maliciously (an attacker) or accidentally (caching).

A similar approach which the "Notary v1" or "docker trust" command does to sign and revoke the signature of an artifact tag, can be used/implemented to achieve a bit level of signature revocation.

Based on the docker trust docs, it does something pretty analgous to cosign clean. I would consider revoke to be a very misleading name for that command.

[Rajpratik71]

Hmm ok.

One other major operation of the lifecycle is "signature verification".

I have gone through the approaches provided by sigstore/policy-controller or Kyverno which are fine for K8S based environment.

But for simple docker or docker-compose or any other CLI like 'nerdctl' or any other based on 'containerd', how to automatically verify images for signature on the client side while deployment?

Instead of doing cosign verify .

[znewman01]

Are you manually pulling/running images using docker run or nerdctl run? If so, I'd just stick a cosign verify call before you do that. If you have more sophisticated infrastructure, you'll need to use a policy engine there.

A couple of caveats:

• make sure to refer to images by digest (not tag) once you've resolved the image, since the tags are mutable (even on an immutable registry, it's possible for an attacker to change the tag).
• make sure when you call cosign verify you're passing either a key (--key foo.pub) or identity (--certificate-email me@example.com --certificate-oidc-issuer https://accounts.google.com (see Discourage (disallow?) naked cosign verify invocations #2056 for context)

Something like the following should work (stick hashes of revoke artifacts in $BAD_DIGESTS_FILE)

BAD_DIGESTS_FILE=/tmp/bad-digests
REPO=gcr.io/projectsigstore/cosign
EMAIL=keyless@projectsigstore.iam.gserviceaccount.com
ISSUER=https://accounts.google.com
TAG=v1.9.0
DIGEST=$(crane digest $REPO:$TAG)
grep $DIGEST $BAD_DIGESTS_FILE && exit 1
cosign verify $REPO@$DIGEST \
        --certificate-email $EMAIL \
        --certificate-oidc-issuer $ISSUER
if [ $? -eq 0 ]; then
    docker run $REPO@$DIGEST
else
    echo "Bad signature!"
fi

Edit: added revocation

[Rajpratik71]

Manually i tried. but mainly i am looking for automation.

Policy controller or Kyverno is fine for K8S based environment.

But for a CLI based environment like "docker" or "other CLI" or even in "compose" environments,

is there any way to achieve it and enforce it by default on system level through plugins in these environments ? or similar thing

[znewman01]

I believe OPA can work at the Docker level. You might be able to cobble something together there, though OPA and Sigstore integration isn't particularly mature at the moment.

But I'd argue that this is really outside the scope of what Docker on its own is meant for—Docker just runs the things you hand it. Making sure that those things are legitimate is the job of whoever's handing Docker the images in the first place.

[znewman01]

I'm going to close this out now, but feel free to comment here, open a new issue, or ask in Slack if you have further questions!

[Rajpratik71]

thanks @znewman01 @haydentherapper for support