Add data structure and convention associating multiple messages with an artifact

[MarkLodato]

We need a data structure and file naming convention to associate multiple signed messages to a single software artifact.

Motivating use case: in-toto

Suppose file foo.out is associated with two links, both of which are required by the layout of foo.out:

• Provenance: the build system generates a link saying that foo.out was produced from material foo.c.
• Vulnerability scan: a scanner generates a link saying that foo.out is free of known vulnerabilities.

The build system and the scanner need to know where to place the links on the filesystem, and the verifier needs to know how to find those links when evaluating foo.out.

Suggested strategy

1. Define a "bundle" data structure containing multiple signed messages. Example: ZIP file with a particular naming convention.
2. Define a file naming convention for how to find the bundle given a filesystem path. Example: foo.out.sig

[MarkLodato]

First question: should this be specific to in-toto (and thus move this issue to that repo) or should this be generic for all signed messages (and just stay here).

[TomHennen]

I propose leaving it here.

1. There is likely value in being able to have a standard method of encoding multiple signed messages in a single file.
2. The method of encoding multiple signed messages necessarily involves understanding the outer wrapper being encoded. While ITE-6 currently defines using this signing-spec it's conceivable that it could change to support some other method of signing in the future. That new method might not be compatible with whatever method of serializing multiple messages in a single file is proposed in ITE-6.

Proposal:

1. Define the format in Signing-Spec
2. Use Line Delimited JSON https://en.wikipedia.org/wiki/JSON_streaming#Line-delimited_JSON

[MarkLodato]

I propose moving it to the new https://github.com/in-toto/attestation. The only use case we know of is attestations, so my inclination is to keep it specific until we know that we need a more general solution.

Counterpoint to Tom's #2: I believe there is value in having the Bundle be independent of the Envelope. The Bundle could then wrap any type of envelope and indicate its type.

(See https://github.com/slsa-framework/slsa-controls/blob/main/attestations.md for Bundle vs Envelope)

[MarkLodato]

In the interest of keeping this signing spec as simple as possible, I'm going to move this issue now.