cli: allow DSSE verification

[woodruffw]

This allows for a very limited form of DSSE verification via the sigstore CLI. In particular, it allows a DSSE-containing bundle to be verified, but only if:

• The DSSE payload is JSON;
• The JSON is an in-toto statement;
• The in-toto statement has at least one subject matching the input file's digest.

This limited form is compatible with what GitHub Artifact Attestations is doing and, in particular, is compatible with how gh attestation verify behaves.

WIP while I clean things up a little.

Closes #999.

Closes #780.

[woodruffw]

Flagging: this is consistent with what gh attestation verify does, but I think it's potentially susceptible to misuse: in most contexts you also care about the name assigned to each subject, to prevent domain confusion attacks (e.g. where you request foo==1.2.3, but the attacker gives you an old, vulnerable foo==1.0.0 with a valid signature for that older version).

The argument in this case for not doing that is that gh attestation verify doesn't bother to do it either, plus the pre-existing hashedrekord-based verification can't do it (since it was only over the input bytes, not the input name). So as-is there's no degradation in the security model, but it's worth highlighting and thinking about in the future.

[jku]

DSSE parts look fine. The verify github change seems a bit fishy in that we no longer make sure the issuer is github -- maybe we should change policy.Identity to accept identity: str | None, issuer: str as args and then use that in _verify_github, or alternatively have a separate policy.Issuer that only checks the issuer?

[woodruffw]

DSSE parts look fine. The verify github change seems a bit fishy in that we no longer make sure the issuer is github -- maybe we should change policy.Identity to accept identity: str | None, issuer: str as args and then use that in _verify_github, or alternatively have a separate policy.Issuer that only checks the issuer?

Ah yeah, good catch -- I think we can re-use the already existing policy.OIDCIssuer for this 🙂

[woodruffw]

Flagging: right now we allow any of the CLI options to be a "sufficient" option for verification with sigstore verify github, which is potentially misleading or insufficient.

For example, a user could do sigstore verify github ... --name foo, which would only check the workflow's name and allow any GitHub user/org and repo, which probably isn't what they intended.

Given that, should be restrict this to a few sufficient combinations? Some ideas:

• --cert-identity, as before, to bind the full user/repo and workflow path
• --repository, to bind the user/repo
• Others, from the "V2" extensions?

[woodruffw]

Tweaked this with 41d3fc9 -- we now require --cert-identity OR --repository, which should be misuse-resistant without being burdensome.

[woodruffw]

(This is more or less consistent with what gh attestation verify does, although they also allow just --owner)

[jku]

41d3fc9 seems quite reasonable.

[jku]

Looks great, thanks for all the work on this. Reasoning for required options seems good to me.

Suggestions for docs (could file additional issues for these):

• The README examples of github verification are now not completely up to date: we should add a --repository example (maybe as the first one)
• there is no "body text" in sigstore verify github --help: A description that mentions the required flags would make sense

[jku]

nit: "below" here and "above" a few lines earlier are now a bit confusing