feat: Verification of VSA

[laurentsimon]

See VSA https://slsa.dev/verification_summary/v0.2

High-level verification in CLI:

$ slsa-verifier verify-vsa <artifact> --vsa-path <vsa-file> verifier-id google.com [--resource-uri <purl>] --policy-level X

[laurentsimon]

Note: we may need to differentiate between containers and non-containers, maybe via --artifact-type image... or artifact-storage [file:registry] ... or verify-vsa [file | registry]:path?

[asraa]

What if it were verify-artifact --vsa?

[laurentsimon]

May work. You're right the my proposal deviates from the current convention that our commands follow verify-<artifact-type>, not verify-<attestation-type>.

One limitation is that it mangles verify different verification routines into one command line option, so we'd lose namespaces? Eg: builder-id becomes verifier-id, etc... but maybe that's still better?:

... verify-artifact --vsa-path ...

Maybe verify-artifact-vsa? Does not seem ideal either.

/cc @ianlewis @mihaimaruseac

[asraa]

Ah true - yes, I only say this because I worry that for each command we'll have a (artifact/image) pathway like cosign.

Hmmm

Yeah, VSAs definitely seem like a different pathway altogether.

I've usually liked detecting the resource type depending on file://blah or gcr.io/blah URI, but I'm not sure it's good to be implicit about types..

[laurentsimon]

I'm also worried about implicit detection.

[laurentsimon]

Another option could be to create another sub-namespace:

$ slsa-verifier verify-artifact --with-provenance \ # that's a new namespace
                                             --provenance-path  <provenance-specific-args>
$ slsa-verifier verify-artifact --with-vsa \ # that's a new namespace
                                            --vsa-path  <vsa-specific-args>

This would allow us to keep the existing namespaces.

[ianlewis]

I think it's ok to have flags that are mutually exclusive. Though, maybe --with-vsa and --with-provenance are redundant. We know they want one or the other based on whether --vsa-path or --provenance-path is given.

[laurentsimon]

there are also corner cases, e.g. for containers where provenance and vsa may be stored on the registry. For Sigstore, users need not provide it to us, we infer this based on builderID.

[ianlewis]

Right, those options can vary by the type of artifact (e.g. the command, verify-artifact vs. verify-image) though right?

[laurentsimon]

I think so.

[laurentsimon]

I may have found a better way: https://github.com/spf13/cobra/issues/1327 This lets you group flags. Essentially, it keeps the commands as-is, but we can group commands in the --help command so that its clear to users that vsa commands != provenance commands, etc:

Provenance flags:
  -provenance-path
  -source-uri ...

VSA flags:
  -vsa-path ...
  -resource-uri ...

The link above has a bunch of code example to implement it.

[mihaimaruseac]

Grouping is nice, but is only for documentation. From my experiments, if you want to enforce only flags from a single group, you need to write code to validate that.

[laurentsimon]

+1, I'm planning to have a manual validation to ensure no flags overlap with different groups. Besides this downside, that seems like a good direction?

[mihaimaruseac]

Yes, I like it!

Was looking over that during the last end of year break when updating the verifier flags but didn't get a chance to do something. I think doing it as part of the VSA verification work is great

[laurentsimon]

So the above was for verification of artifacts with a VSA.

To support custom digests https://github.com/in-toto/attestation/pull/338, I think we need a dedicated API verify-vsa which will only verify the VSA claims from the attestation (but does nothing to verify the image itself). If we were to re-use the verify-artifact -vsa for custom digests, this would expose an unsafe / misleading API because verification does not do anything about the artifact / container, ie we're just matching fields in the VSA against user-provided values. Keeping the artifact argument would make users believe we're doing some verification with it, yet we are not.

Eventually, I think all this can be backed by a set of APIs https://github.com/slsa-framework/slsa-verifier/issues/756:

• verify-artifact computes expected claims (digest, etc) and calls
• verify-vsa (which matches attestation claims against caller-provided claims) which calls
• inspect-vsa (verifies signature and outputs verifiied metadata like subject, verifier id, levels, etc)

For the CLI, we don't need this level of re-factoring, zo.

@haydentherapper

[laurentsimon]

First step towards supporting VSA verification is to add e2e tests in https://github.com/laurentsimon/slsa-verifier/tree/feat/vsa and merge. Second step will be to support to add the verify-vsa command.