Update conformance testing interface to support attestation

[aaronlew02]

Description

In order for sigstore-conformance to test DSSE signing (sigstore/sigstore-conformance#145), clients are required to accept from the conformance test suite an in-toto statement and sign it as an attestation.

Ideally, this should be supported with a call to sign_dsse(statement) for a given statement. This may require an update to the attest CLI command, such as a --statement or --in-toto flag mutually exclusive with the existing flags.

Another option is to have the conformance wrapper deconstruct the given statement and pass its parts, along with a corresponding artifact asset, directly to attest, which is a less direct approach.

[woodruffw]

Another option is to have the conformance wrapper deconstruct the given statement and pass its parts, along with a corresponding artifact asset, directly to attest, which is a less direct approach.

Hmm, I think we probably want to do this. It's a little less direct like you say, but I'm kind of wary of adding new public CLI surface purely for integration testing purposes.

[aaronlew02]

That's an understandable concern. Perhaps modifying the CLI to include support for a statement input (much like Cosign's attest-blob) would be useful in the long term, as it supports users with a pre-existing statement and shifts the responsibility of constructing the statement away from the client (@Hayden-IO may have more to say about the latter).

[woodruffw]

Perhaps modifying the CLI to include support for a statement input (much like Cosign's attest-blob) would be useful in the long term, as it supports users with a pre-existing statement and shifts the responsibility of constructing the statement away from the client (@Hayden-IO may have more to say about the latter).

Possibly, although IIRC one of our reasons for not doing that originally is because it isn't a huge responsibility for the client to take on (given that we'd need to validate the DSSE envelope before signing it anyways), and the composition of a predicate into the signing to made more sense at the time (since DSSE is essentially an implementation detail, whereas predicates are the actual thing the user is expressing a signing intent over).

But yeah, it's interesting to learn that sigstore-go supports a statement input! +1 to hearing what @Hayden-IO thinks 🙂

[Hayden-IO]

I'm supportive of adding a --statement flag to the attest command. I think this has utility outside of just testing and aligns with Cosign's CLI as well (I know we have no conformance requirements for CLIs, but alignment where possible seems best). Though if you do add this, you'll likely need to also update the verification options to support providing an arbitrary subject digest/alg, which I know differs from previous conversations about supporting a fixed set of digests.

The motivation for adding in-toto statement signing support to Cosign was to not be opinionated on a statement's subject, to support Git (with sha1 digests) for the SLSA source track. I've mentioned this in other venues before, but I think at its core, Sigstore tooling shouldn't be opinionated on what it signs. If I wanted to sign an in-toto attestation or even just a DSSE, I could provide just a PAE (I'm ignoring that we have two different Rekor types for now). But because there's not a lot of CLI tooling to generate attestations, having the Sigstore tooling construct the attestation is a good approach.

So the question is, how opinionated should Sigstore tooling be on the attestation format? We're already opinionated that it must be a DSSE, which arguably we could relax, e.g. to support COSE. Do we need to be opinionated on the in-toto subject as well? I think no - it's fine to provide a path that takes a subject + predicate, but if someone knows what they want to sign over, I'd support providing an in-toto statement as well.

[jku]

We should arguably rename the issue (or file another one) if that is the goal: this is not about updating the conformance testing wrapper but about adding new CLI surface to be more compatible with cosign CLI (not a goal I'm generally supportive of but this time may be different) and to support users who want to sign custom intoto statements but don't want to use the API to do that.

In other words, let's not change CLI because a test suite wants it but let's do it if we believe the more complex surface better serves real users.

[jku]

support users who want to sign custom intoto statements but don't want to use the API to do that.

I'll add a bit of detail for the italics here: It's still unclear to me how these use cases operate

• Something has to be building these statements (I assume it's not the users themselves), should that component also be controlling the signing? If yes, then I don't think they should be using the sigstore-python CLI todo that, they should be calling the API.
• How does the verification flow work -- if the caller is just using the the CLI sigstore-python CLI, how do they verify the contents of the intoto statement after the signature has been verified? (this is not a problem specific to this proposal, I just don't quite understand this)

Are there examples to look at for the "git for slsa source track" case?

[aaronlew02]

I support moving the matter of CLI functionality into a different issue.

In terms of conformance testing, another option is to call sign_dsse directly within the wrapper. This would require a separate codepath, however, as we wouldn't be interacting with the CLI as with any other conformance command.

[jku]

In terms of conformance testing, another option is to call sign_dsse directly within the wrapper. This would require a separate codepath, however, as we wouldn't be interacting with the CLI as with any other conformance command.

Yeah this is an option -- it's basically the same as what non-CLI clients like sigstore-java do: just do the API call in the conformance client (I'm simplifying the java approach a bit but you get the point). I have not looked at how much scaffold code this needs but it should work.