Require inclusion proofs, make promises optional

[haydentherapper]

The log always generates inclusion proofs, so we will make it a requirement that clients verify the proof. Promises will be deprecated over time, but for now, we'll make them optional.

Fixes #82
Ref sigstore/rekor#1566

Summary

Release Note

Documentation

[feelepxyz]

Just a quick drive by comment, could we also do a major version bump of the mime type version? Clients could then choose to key a verification strategy off this.

[haydentherapper]

@feelepxyz, can you check the last commit to make sure that's correct? Haven't done a version bump before.

[znewman01]

LGTM. A little weird that we're requiring clients to verify inclusion promises if present, but intending to totally get rid of them. I understand why though.

+1 to bumping the minor version.

[haydentherapper]

Probably should mention how to handle older bundles. Maybe something like: "Older bundles will contain only an inclusion promise, which must be verified if present." We could also mark the field as deprecated, or hold off for a little before doing so. Thoughts?

[znewman01]

We have to be a little careful about "downgrade attacks" here (in scare quotes because the inclusion promise should still not be possible to get for an attacker). Maybe something like:

Client verification libraries MAY provide an option to support v0.1 bundles for backwards compatibility, which sometimes contain an inclusion promise and not an inclusion proof. In this case, validate the promise.

Verifiers SHOULD NOT allow v0.1 bundles if they're used in an ecosystem which never produced them

[haydentherapper]

Added a comment in the bundle, and updated the comment for inclusion_promise. PTAL

[woodruffw]

LGTM!

[kommendorkapten]

LGTM