Allow pinning trust for verifying keyless signatures

[xopham]

Description
Trust pinning should be implemented for Keyless signatures by adding an optional -email parameter to the cosign verify. This email can then be used as a trust anchor to validate the keyless signature and returned error code is 0 if the Certificate subject contains the email or 1 if not.
In case the optional -email is not specified, Cosign should always return 1 as the intent of cosign cannot be fulfilled (secure by default)

Context

When verifying with Cosign, one provides a key and the signature data is validated against that key and the valid digest returned:

$ cosign verify -key cosign.pub xoph/demo:co-signed

Verification for xoph/demo:co-signed --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
  - Any certificates were verified against the Fulcio roots.
{"critical":{"identity":{"docker-reference":"index.docker.io/xoph/demo"},"image":{"docker-manifest-digest":"sha256:c5327b291d702719a26c6cf8cc93f72e7902df46547106a9930feda2c002a4a7"},"type":"cosign container image signature"},"optional":null}

For keyless signatures, we break with this flow and one just asks to verify an image upon which one gets both trust root and digest returned and now as a user I decide whether I like the email handle I see.

$ COSIGN_EXPERIMENTAL=1 cosign verify xoph/demo:co-signed

Verification for xoph/demo:co-signed --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - Any certificates were verified against the Fulcio roots.
Certificate subject:  [[email protected]]
{"critical":{"identity":{"docker-reference":"index.docker.io/xoph/demo"},"image":{"docker-manifest-digest":"sha256:e7e0f847265b6d729c718d0b778a4e15c0bce7078d7042b2a4b90e9998794e67"},"type":"cosign container image signature"},"optional":null}

It would be better to pin the trust to a trust anchor (and also move the certificate subject to the json):

$ COSIGN_EXPERIMENTAL=1 cosign verify -email [email protected] xoph/demo:co-signed

Verification for xoph/demo:co-signed --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - Any certificates were verified against the Fulcio roots.
{"critical":{"identity":{"docker-reference":"index.docker.io/xoph/demo"},"image":{"docker-manifest-digest":"sha256:e7e0f847265b6d729c718d0b778a4e15c0bce7078d7042b2a4b90e9998794e67"},"type":"cosign container image signature"},"optional":{"certificate subject":"[email protected]"}}

[xopham]

FYI @dlorenc @asraa

[asraa]

+1 I like the idea of moving the certificate subject into the JSON, i want to add a delegation name into the JSON when we verify against sigstore delegations

Also consider making it an n-values flag where... any one of? the emails can be used to verify? I'm not sure. that might make things confusing in case someone intends it to be all of them.

[dekkagaijin]

We'll want to come up with a solution to ensure that either a) email domains are uniquely linked to identity providers or b) somehow namespace these IDs to identity providers when a given email is shared across multiple

[dlorenc]

Sorry! We came up with a lightweight improvement here: https://sigstore.slack.com/archives/C01PZKDL4DP/p1629399218104900?thread_ts=1629399218.104900&cid=C01PZKDL4DP

[dlorenc]

The tldr is to add an -email flag to verify, and one exit 0 if that email is present and verified. If the flag isn't passed, exit 1 but continue displaying all signatures.

[xopham]

@dekkagaijin interesting point! While a question separate from the specific issue here, I think that is an important discussion for keyless signatures: Technically, GitHub cannot guarantee for [email protected], but only really for the GitHub handle @john.doe and there can be multiple other instances, e.g. Azure or Google, that could OIDC for the same email which significantly broadens the threat landscape. Any of the OIDC providers failing to protect identities, being used with weak authentication or a rogue IDP would risk the main identity.
Would it be possible to just use the identity providers identifier for OIDC? Then keyless would not be emails, but 'handles'. (actually have some separate thoughts on general identity beyond email)

[xopham]

if that is of interest, we could open a separate issue...

[lukehinds]

Unless I am missing something, this makes me nervous to be honest. We are reducing the trust model down to some text (email) which will be set in a CI job. An attacker need then just compromise the script / yaml file etc in a GH action (or whichever CI is used) and the headlines say 'sigstore hacked'.

Just to add, the current implementation was only temporary, this will be superseded by TUF policy. I think it makes better sense to direct users to implementing that, as that way they sign over the policy and the artifact and no trust pin to an email is needed.

[dlorenc]

I think there's some confusion here. I'll try to summarize the confusing slack thread here a little later today.

[dekkagaijin]

For now what I'm thinking is that we'll add support for asserting an expected subject (email) and then add in support for also asserting the identity provider behind that subject once supported by fulcio: sigstore/fulcio#44

I don't know if we'll ever want to support arbitrary ID providers, but the threat of ambiguous authority over an email is called out in that thread as well: sigstore/fulcio#44 (comment)