Define a "processing hint" attribute to improve supply chain adoption experience

[AdamZWu]

The attestation "bundle" provides a good mechanism to generalize, allowing supply chain components to handle all kinds of attestations in a homogeneous way, which is great when the components don't want to care about attestation types.

However, there are also cases where supply chain components do want to care. For example, certain supply chain hops may want to prune attestations from their bundle according to certain criteria, such as:

• Stripping certain attestation types that could contain enterprise proprietary data before release, or
• Remove attestations for transitive dependencies that are too "remote" and considered irrelevant for subsequent supply chain processing, etc.

Today, this is a rather painstaking process, because there is nothing directly usable at the envelope layer -- pruners will have to: 1) parse DSSE layer, 2) base64 decode the payload, 3) parse the in-toto statement, before they can have even a basic understanding of the kind of data in the attestation. And they have to repeat this for every attestation in a bundle.

I received some consult earlier from collaborators adopting in-toto, asking whether they could use the MIME type (DSSE _type field) to distinguish attestations, for example, application/vnd.in-toto+json.provenance, application/vnd.in-toto+json.vuln. At first I thought it was a great idea... until I found in-toto currently mandates the MIME type to be a single uniform value.

Opening up the MIME type value space would definitely help, but it is not a general solution.

I wonder, since DSSE specs do allow custom attributes, if in-toto could define an unauthenticated field in the DSSE layer, which can be used to convey "hints" for the supply chain components to optionally use to guide their attestation processing?

The unauthenticated field does not expose security holes, thanks to the monotonic principle conformance required by in-toto -- malicious attackers can leverage this mechanism is to prune out legit attestations, but that should not lead to insecure verification decision; they cannot use it to inject malicious data, because all attestations are signature checked during verification.