Proposal: Include raw Rekor Bundle in TransparencyLogEntry

[codysoyland]

Description

The bundle spec includes transparency log entries. In earlier discussions and the unmerged verification documentation, I think we agreed that IF a log entry is provided in the bundle, we MUST perform a successful SET verification (inclusion promise).

The SET verification requires 6 pieces of data:

• canonicalized Rekor entry
• integrated time
• log index
• log id
• Rekor's public key
• signature (known as the SET)

All of the above fields are included in the bundle except for the canonicalized Rekor entry. It was decided in the original proposal to reconstruct it from other data in the bundle, and by adding KindVersion to hint to the verifier which entry version to reconstruct. I believe this decision was made due to the fact that the intoto type would duplicate the DSSE in the bundle, producing a larger file size due to the redundant data.

Unfortunately, we still lack enough information to deterministically reproduce all Rekor entries. This was called out in the original proposal, but it was believed that we could reconstruct hashedRekord and intoto entries, which I understand to be the only supported entry types for the bundle. In fact, the intoto type still has an ambiguous field, the hash value which is calculated over the DSSE envelope. Rekor does not enforce any canonicalization of the DSSE used to produce the hash in the intoto v0.0.2 type, therefore, current intoto v0.0.2 entries cannot be verified without the raw bytes of the DSSE, which are not included in the bundle.

Additionally, it is a large burden to place on non-Go clients to reproduce the behavior of all the supported Rekor entry types, and I believe this will lead to verifiers that don't follow spec.

In my opinion, we should just capture the raw Rekor entry in the TransparencyLogEntry.

Alternatives:

• We can just leave it as-is and require online verification for Rekor entries, but that kinda breaks the goal of offline verification of these bundles.
• We can use TSA countersignatures to verify the signature was produced while the certificate was valid, which offers much of the same level of authenticity

[codysoyland]

Just saw that Bob did acknowledge that the user-supplied hash in intoto v0.0.2 is a bug and should be fixed in v0.0.3: sigstore/rekor#1162 (comment)

[kommendorkapten]

Another thing that @bdehamer found that will make it hard to reconstruct the Rekor entry: sigstore/rekor#1170

[asraa]

Maybe this is a 2 step:

1.Capture the canoncalized rekor entry in the bundle. Tell clients to validate the signatures are equal to prove "matching bundle".
2. In Rekor v2, we may change this either by simplifying types OR by simplifying the SET content.