Make more VSA fields optional, add verification section

[MarkLodato]

Similar to #875, I would like to fix a few issues with VSA v1.0 as well for a v1.1 release.

A VSA is a claim by verifier that subject was passed the policy for resourceUri. That's the bare minimum, and those field MUST be specified or else it doesn't make sense. In particular:

• verifier is required for the same reason as builder.id (Provenance v1.1+: remove builder.id? #622).
• resourceUri is required to ensure that an artifact that passed for one resource cannot be applied to a different resource (i.e. a confusion attack). For example, if a particular container image is allowed to be published as name "foo", you should not be able to take a VSA and claim that it can be published as "bar".

Actions:

• Add a "how to verify" section to explain this, with examples.
  • done: content: How to verify VSAs #964
• Fix the intro to better explain this, and to remove bundle which is not present in the VSA.

All other fields should be OPTIONAL. Specifically:

• policy: While recommended, it should not be required to indicate which policy was verified. You could imagine a situation where a closed source organization does not want to leak the identifier of its own internal policy.
• policy.uri: If a policy is specified, I don't see why a URI is required. What if you just want to include a digest?
• verifiedLevels: An organization might want to claim that a particular artifact passed its internal policies without making any public claim about what those policies were. The use case here would be something like CompanyX publishes a container image with a VSA saying the image is OK, and clients verify this. They don't need to know the level, just that CompanyX blessed it. (This is akin to a classic code signing case.)
• timeVerified: Nice to have, but I don't see why it's strictly required.
  • done: content: How to verify VSAs #964

[joshuagl]

#964 addresses 2 & 3 but omits 1 (making more of the fields optional). Should we pop that into a separate issue?

[MarkLodato]

#964 addresses 2 & 3 but omits 1 (making more of the fields optional). Should we pop that into a separate issue?

I'm inclined to just leave it as part of this issue, even if multiple PRs address separately.

[MarkLodato]

Reopened and updated the list of tasks in the top post to list what still needs to be done. Alternatively, if we decide not to do an item, I'll update it to check it off and explain why we decided not to do that.

[joshuagl]

Hi @kpk47, do you plan to work on the remaining items in this issue for the v1.1 release or would you like us to find another owner?

[ramonpetgrave64]

I think I mostly agree with what's there now:

1. This part should be removed from the intro "... by evaluating the artifact and a bundle of attestations against some policy."
2. policy should not be required for verification.
3. policy.uri i think is needed, but not the digest, because even a URI can include a digest. The user won't be consuming the policy for verification-purposes, so it only needs to be some kind of unique identifier, which can be a URI.
4. No need for virifiedLevels.

[joshuagl]

Thanks Ramon. Are you suggesting verifiedLevels becomes optional, or that they are removed entirely?

[jeffvaughan-google]

Ramon, Can you elaborate on why policy.uri would be needed? Would the policy.uri be used in verification some way, even if the policy contents are not?

[AdamZWu]

✋ I have some concerns regarding the proposal on these two fields: verifiedLevels and timeVerified.

• For verifiedLevels:

To my understanding, VSA is essentially an endorsement statement. Hence it is rather important to declare what attributes the statement endorses; Because without the declaration, a statement is subject to any sorts of misinterpretation, which effectively turns its value to zero.

IMO to SLSA's advantage, it has already defined several attribute tracks, i.e. the BUILD track and SOURCE track. So even for organizations who do not want to disclose their internal attributes, maybe they could at least disclose the SLSA track attributes?

(If they don't want to disclose anything, even SLSA tracks, then why bother creating the statement? Just use code signing instead. :P)

• For timeVerified:

I think it is generally a good idea to associate a VSA (or any attestation for that matter) with a time reference, because otherwise it becomes a "perpetual statement" -- no one knows when it is issued, no one can define how long it is good for.

Or maybe there will be a proposal to make time-stamping a more general feature in the in-toto statement layer, hence removing the redundancy here? If that's the case then I am OK.

[ramonpetgrave64]

@joshuagl I meant to say that verifiedLevels should be optional. Thanks for checking.

@jeffvaughan-google As far as slsa-verifier's ability to verify policy, it can only be as far as matching that the URI in the VSA is the same as what the user expects, and not concerning the policy's content. It's still going to be up to the user to know the meaning of their policy, and trust the producer's compliance to their policy.

With that, policy.uri's effectiveness is similar to verifiedLevels. But while the Source Track and other tracks are still in progress to be more finalized, I think we need to allow more OSS orgs the flexibility to get started on their own supply-chain specs without necessarily deciding on levels of said specs.

@AdamZWu Back to verifiedLevels, I still agree that public consumption of VSAs from closed-source producers are not much better than code-signing, in terms of verification. Even L1 might not be practical for a closed-source producer that consumes from other closed-source producers. For those cases, it's not good for us to insist that producers put SLSA_BUILD_LEVEL_0.

[AdamZWu]

@ramonpetgrave64 I don't quite get your concerns about "closed-source producer that consumes from other closed-source producers". To my understanding, the builder requirements are not recursive or transitive.

That is, the build level a builder qualifies is not affected by the build level of any of the prebuilt dependencies or their transitive dependencies. A builder can qualify SLSA Build L3 even if it consumes binaries produced by lower level builders (including L0, i.e. builders who did not meet any SLSA requirements). Artifacts produced by such a build could rightfully claim SLSA_BUILD_L3 in verifiedLevels. (The fact its dependencies are at lower SLSA Build level is separately reflected in the dependencyLevels attribute, which is orthogonal to verifiedLevels.)

[TomHennen]

@jeffvaughan-google As far as slsa-verifier's ability to verify policy, it can only be as far as matching that the URI in the VSA is the same as what the user expects, and not concerning the policy's content. It's still going to be up to the user to know the meaning of their policy, and trust the producer's compliance to their policy.

Users aren't meant to check the policy URI itself, instead they're meant to check the resourceUri: https://slsa.dev/spec/v1.1/verification_summary#how-to-verify:~:text=Verify%20that%20the%20value%20for%20resourceUri%20in%20the%20VSA%20matches%20the%20expected%20value.%20This%20step%20ensures%20that%20the%20consumer%20is%20using%20the%20VSA%20for%20the%20producer%E2%80%99s%20intended%20purpose.

[ramonpetgrave64]

@TomHennen For verification, yes. And that's the current implementation in the pending VSA support in slsa-verifier. But I believe the user should still have the field in lieu for situations where there is a lack of a meaningful verifiedLevels.

@AdamZWu I mean SLSA_BUILD_L1 only in the sense that it says that some type of build provenance must exist. That's a self-certification, if producers are unwilling to share their provenance or share their process for documenting provenances.

I agree that SLSA_BUILD_L1 should be standard, but having it be a minimum required level for VSAs is too much if we mean to get VSA adoption. Even a VSA is a kind of provenance, if not a build provenance.

[AdamZWu]

@ramonpetgrave64 Ah I think we misunderstood each other. :)

By requiring at least some SLSA track attributes, I don't mean placing any "minimum bar" on the ladder (e.g. must be at least L1). SLSA_BUILD_L0 is a legitimate attribute.

I totally agree having SLSA_BUILD_L0 won't inspire too much trust for users who see the VSA. But I think that is exactly working as intended -- it basically conveys that "the creator of this attestation is only willing to endorse the artifact at such a level." I think semantically is much clearer than a VSA without verifiedLevels -- the endorsement is explicit, not susceptible to deliberate or inadvertent misinterpretation.

Imagine someone taking a VSA and telling a less SLSA-knowledgeable user: "Look! This is a valid signed SLSA VSA, which certifies it meets all SLSA requirements!" And the user looks at the predicate and cannot find any contrary evidence -- because there is no verifiedLevels field!

---

As to the concern of self-certification, my understanding is that, the entire VSA is just a self-certification, so whether the attribute is SLSA_BUILD_L0, SLSA_BUILD_L1 or SLSA_BUILD_L3 doesn't matter.

The whole point of publishing VSA instead of build provenance is to allow organizations to self-certify their SLSA compliance, without disclosing their internal process or knowledge.

[TomHennen]

There had previously been some that didn't want to make any statements about the SLSA level something met, but might have been happy to publish a VSA with an empty verifiedLevels field. It might not seem satisfying but it does allow a 'generic' method of code signing that can be expanded to other things in the future once folks are ready for it.

Also, if/when the VSA moves to in-toto it wouldn't make sense to require any SLSA specific things.

[ramonpetgrave64]

I totally agree having SLSA_BUILD_L0 won't inspire too much trust for users who see the VSA. But I think that is exactly working as intended -- it basically conveys that "the creator of this attestation is only willing to endorse the artifact at such a level."

I think that admission is too big of a first step for many potential producers. I wish I could back up my opinion but here's one example. Like @TomHennen says it might be a better signal to require verifiedLevels be present and allow it to be empty. wdyt?

• https://github.com/oracle/macaron/blob/eb4936f905b29ea5cf95655cdcfd4712efd0d00c/tests/vsa/integration/example-maven-project/vsa_payload.json#L31

[AdamZWu]

Yes, an empty verifiedLevels is a bit better than completely not having this field (in terms of defending against misinterpretation).

Would you entertain the idea that SLSA introduces an explicit level token of "non-certification"? e.g. for organizations who do not want to endorse artifacts on any SLSA level ladder, they should set a value like SLSA_LEVELS_UNDISCLOSED or SLSA_LEVELS_PRIVATE?

[ramonpetgrave64]

I would definitely entertain it. Personally, I wouldn't tie the SLSA ladder to VSAs in that way, but I think the decision is up to a committee.

[jeffvaughan-google]

@ramonpetgrave64 Is the following about policy.uri?

.... I believe the user should still have the field in lieu for situations where there is a lack of a meaningful verifiedLevels.

If so, I disagree. I don't think it's the case that policy.uri can always be resolvable or read, and then I don't think it adds enough value to the spec. (There's some complexity here. Suppose policy.uri is required: what should verification do with a "uri" that's the empty string? not rfc3986 formatted? pointing to a non existing location?)