Support verifying offline Rekor bundles

[haydentherapper]

Description

As described in the specification, a Rekor response can be stored and verified without hitting the log. The client should:

• Verify the SET
• Verify that the signature over the blob matches what's in the payload's body
• Compare the integrated time against the certificate
• Compare hashes of the Rekor payload body to the provided blob

See code in Cosign for more details.

[woodruffw]

Just sketching this out a bit: I think we'll probably want an --offline flag for sigstore verify.

When --offline is passed, sigstore verify will look for {input}.bundle, similar to how it currently looks for {input}.sig and {input}.crt. It'll then verify the contents of that bundle as a Rekor response, rather than hitting the log.

[haydentherapper]

Once the bundle contains the sig and crt, should offline be the default?

[woodruffw]

Once the bundle contains the sig and crt, should offline be the default?

I see no reason why not!

[woodruffw]

Double-checking myself: do we not do the Merkle inclusion proof for offline bundles? I can't find it in the cosign source code, and it looks like the bundle JSON itself doesn't contain the inclusionProof attribute that Rekor responses normally contain.

[haydentherapper]

Correct - The inclusion proof is an alternative to the bundle - https://github.com/sigstore/rekor/blob/main/openapi.yaml#L448-L457

In terms of security properties, they're roughly equivalent. The SET is a "promise" that needs to be verified via an online lookup, and is a commitment by the log since it's signed. The inclusion proof could always be forked (split view attack) and needs to be verified online, and is also a commitment by the log since the proof includes a signed checkpoint/root hash.

[woodruffw]

In terms of security properties, they're roughly equivalent. The SET is a "promise" that needs to be verified via an online lookup, and is a commitment by the log since it's signed. The inclusion proof could always be forked (split view attack) and needs to be verified online, and is also a commitment by the log since the proof includes a signed checkpoint/root hash.

Makes sense, thank you! I couldn't wrap my head around what an offline inclusion proof would establish anyways, so that explains it neatly.