Allow uploading detached signatures over in-toto statements with `--type=intoto`

[rbehjati]

Currently when uploading artefacts to Rekor using rekor-cli upload --type intoto only in-toto attestations in the form of DSSE Envelopes can be uploaded. (This is based on my current understanding. I was not able to upload anything else, but also I am not an expert in in-toto).

It would be nice to be able to upload in-toto statements with detached signatures. For instance, currently one could upload an in-toto statement (for instance a SLSA provenance file), with a detached signature with the following command: rekor-cli upload --type rekord --artifact provenance.json --signature provenance.sig --pki-format=x509 --public-key=pub.pem However, since the type in this case is not intoto the subject and the materials in the provenance files are not indexed.

Alternatively, is it possible to implement indexing similar to #792 for artefacts that, as in the example above, are in-toto statements, but are not DSSE Envelopes with an attached signature (and therefore are not uploaded with --type intoto)?

[asraa]

@lumjjb @SantiagoTorres For your opinions: Is it better to consider that a rekord/hashedrekord type can be a (SLSA) provenance, or loosen the --type intoto to allow for signatures on intoto attestations but may not be DSSE envelopes?

[SantiagoTorres]

Hmm, I think there are a couple of separate problems in there. You can still use x509 sigs/keyids on DSSE as far as I'm aware. Either way, if we wanted to separate the envelope from the type on in-toto we could do that, but that will become a problem later when we actually want to index things no?

[dlorenc]

This is important but not sure it should block GA.

[dlorenc]

Will https://github.com/sigstore/rekor/pull/973 fix this one?

[asraa]

Will https://github.com/sigstore/rekor/pull/973 fix this one?

@rbehjati took a review on this PR: This PR would allow you to upload the following proposed entry to Rekor in code:

re := V002Entry{
        IntotoObj: models.IntotoV002Schema{
            Content: &models.IntotoV002SchemaContent{
                Envelope: &models.IntotoV002SchemaContentEnvelope{
            Payload: {YOUR_B64_ENCODED_PROVENANCE.JSON},
            PayloadType: {YOUR_PAYLOAD_TYPE},
           Signatures: {YOUR_KEY_IDs, SIG, PUBLICKEY},
},
            },
        }}

That PR's implementation of artifact creation via CLI flags assumes that artifact is a JSON envelope. If would be a little complicated logic to modify, but could be done. @pxp928 You would need to do the following in CreateFromArtifactProperties:

1. If signature is present, assume that this is the re.IntotoObj.ContentEnvelope.Signatures and that artifact in this case is not the whole envelope but just the re.IntotoObj.Content.Envelope.Payload.
2. The function verifyEnvelope currently works on an entire envelope. Parth would need to modify verify to work on, let's say, the common re.IntotoObj.

@rbehjati how would you communicate the payloadType in your CLI invocation?

[rbehjati]

@rbehjati how would you communicate the payloadType in your CLI invocation?

We use rekor-cli upload with --type rekord. If you are referring to the payload type in the envelope, it should be "application/vnd.in-toto+json" I think. But we don't directly use or generate DSSE envelopes. Does that answer the question?

Do you recommend using the upload functionality programatically instead of using the CLI?