Allow non intoto media types to be verified

[puerco]

Description

When verifying a bundle, the Verifier will reject any data wrapped in a DSSE envelope that is not an intoto attestation (ie the DSSE payloadType != application/vnd.in-toto+json):

sigstore-go/pkg/bundle/signature_content.go

Lines 55 to 57 in d20c39f

	if e.PayloadType != IntotoMediaType {
	return nil, ErrUnsupportedMediaType
	}

This makes it impossible to verify bundles wrapping other kinds of data

Proposal

I would like to modify the verification logic to verify any other types of payload. If it's something else, than an attestation, the VerificationResult Statement field would empty:

sigstore-go/pkg/verify/signed_entity.go

Lines 211 to 217 in d20c39f

	type VerificationResult struct {
	MediaType string `json:"mediaType"`
	Statement *in_toto.Statement `json:"statement,omitempty"`
	Signature *SignatureVerificationResult `json:"signature,omitempty"`
	VerifiedTimestamps []TimestampVerificationResult `json:"verifiedTimestamps"`
	VerifiedIdentity *CertificateIdentity `json:"verifiedIdentity,omitempty"`
	}

... or, if we want to return the data in the results, we could include the payload contents in the original base64 blob in a new field.

I'm working on a patch, let me know if there are any objections :)

[steiza]

Hey @puerco! I definitely want to hear more about what the use-case is here.

The two modes we intend to support with sigstore-go are:

• A message signature
• DSSE containing an in-toto statement

This is a deliberate decision! For the past 18 months or so I've been encouraging people to standardize on in-toto statements whenever possible. This standardization is part of what's helped make Sigstore implementations interoperable across client libraries (Python, Go, JS, Java, Ruby, ...) but also "deployments" (npm provenance, PyPI attestations, Homebrew build provenance, model signing across Kaggle and NVIDIA, ...)

So it's not as simple as modifying an if statement : ) That's not to say we'd never consider a change here, but that a propose change might have wider consequences that we need to consider.

[puerco]

I definitely want to hear more about what the use-case is here.

Of course, my main use case is that I need to bundle Ampel policies (see an example here) to distribute them signed.

For clarity's sake (i know this is obvious), this proposal would not break the existing support for in-toto predicates in any way. It it would just let the DSSE be used as it was designed to sign any data by lifting the constraints put on it.

In my case, the document is a policy for in-toto attestations, so it does not really match the statement semantics, architecturally it would replace the whole statement in the DSSE payload.

TBH I'm really surprised no other use cases have come up so far.

[puerco]

Now, to be fair, I have been trying to convince myself not to wrap the policies in a synthesized in-toto statement because, even when it does not make sense (as mentioned above), doing so would let me treat them as any other attestation and benefit from all infrastructure that supports in-toto statements.

So, if it makes sense I'm happy to change this behavior. If it's too disruptive I think I can come up with a hack around it. I think it makes sense to allow any payload, but since apparently no one has needed it so fiar, perhaps we can avoid setting the chaos monkey loose :)

[puerco]

Something to point out is that sigstore-go will happily sign and bundle other payload types. It's just the verification that's restricted to attestations.

[Hayden-IO]

As I talked about in sigstore/cosign#4019 (comment), I'd like to see Sigstore libraries be unopinionated. They should be signature verifiers, and going up the stack, there should be DSSE verifiers, intoto verifiers, SLSA verifiers, etc. These individual verifiers don't exist currently, so I think it's reasonable for Sigstore libraries/Cosign to provide some of this functionality, such as in-toto subject verification, delegating any further verification to another policy verification tool.

If you have a DSSE whose payload is not in-toto, could your tool parse the DSSE and provide the signature and artifact hash (the PAE) to sigstore-go for verification? Effectively, build the "DSSE verifier" that leverages sigstore-go only for signature verification.

[steiza]

Ah, I think I need to understand more about Ampel

• Where are policies being constructed? By humans or by machines in a workflow?
• What key material are you using to sign Ampel policies?
• Other than the standard Sigstore bundle verification / integrity checks, do I do any additional verification on the Ampel policy itself? Like in the case of build provenance, you want to check that it came from the platform and identities you were expecting.
• Does the Ampel policy need to be in the Sigstore bundle? If the Ampel policy is outside of the bundle, then you would just use a message signature instead of DSSE. But it seems like you want the policy itself to be embedded in the bundle? Is there a particular reason for that?

[puerco]

@haydentherapper :

• 1 on non opinionated libs. My thinking is that the sigstore library's should should stop (and include) the DSSE bundle as it is the delivery pacakge of the signature and key. I think other envelopes at this level of the stack should be managed by the library.

could your tool parse the DSSE and provide the signature and artifact hash

Yes, I think this would be useful for some cases but also, the libraries al already signing for me the payload, I don't even have to provide the hash. I think that is functionality the library should do for me , unless I want to handle signing myself.

Verifying the in-toto subjects is really handy but I would argue it should be something else's job. Even more so other things as you go up the stack (SLSA for example). I would support though having a pluggable verifier interface so that one call to the sigstore verifier can also look deeper as in in-toto subjects > slsa predicate, etc.

[puerco]

oops I typed this on the metro and just realized it didn't go out...

---

@steiza happy to provide more context, although for this case think of the policies as just another json document. This is all external to the sigstore library/client . The sigstore signature here just checks the policy integrity and provides the identity to verify it's origin.

Where are policies being constructed? By humans or by machines in a workflow?

Both, the is a community repo. Folks upload policies and they will be signed by an action, I also have other plans to generate them on the fly by machines.

I do any additional verification on the Ampel policy itself? Like in the case of build provenance, you want to check that it came from the platform and identities you were expecting.

Exactly! ampel has a mechanism for that, imagine like a baby TUF. And the policy wrapped in the sigstore bundle provides the identity.

Does the Ampel policy need to be in the Sigstore bundle?
Yes that is the idea. I want the policy reference to be a single file/URL to simplify specs, command line flags, and referencing them in other policies and policy sets

[kommendorkapten]

Very good discussion!

The current Verify function is almost there, IIRC it's the Statement function that breaks DSSE with no in-toto payloads as @puerco mentioned.

In the protobuf specs, we don't constrain the payload type, so I think we should allow any kind of payload in sigstore-go too.

A simple way could be to modify the Envelope type with a function

func (e *Envelope) Payload() ([]byte, error) {
    return e.DecodeB64Payload()
}

Add []byte payload to the verification result struct.

And modify the Verify function too:

	// SignatureContent can be either an Envelope or a MessageSignature.
	// If it's an Envelope, let's pop the Statement for our results:
	if envelope := sigContent.EnvelopeContent(); envelope != nil {
		stmt, err := envelope.Statement()
		if err == nil {
			result.Statement = stmt
		}  else {
                        result.Payload, err = envelope.Payload() // TODO add error checking
                }
	}

This way, the client will always get the parsed payload back after verifiation, to avoid any peeking into the bundle that could lead to bugs where data is extracted prematurely (i.e before the signature has been verified)

I don't think this would be that disruptive for a code change.

The only question is if this would lead to a situation where multi MB/GB bundles are sent around? For larger files a detached mechanism like hashed rekord is preferable. I guess this would be an issue to tackle per ecosystem, and not a decision we take in the library?