[feature] harden verification

[laurentsimon]

we currently don't verify the cert in the bundle is the same as the one in the rekor entry, we only verify the signatures are the same https://github.com/slsa-framework/slsa-verifier/blob/main/verifiers/internal/gha/bundle.go#L175-L183

We should probably verify the certs match as well.

NOTE: apprently cosign does not perform this verification either

[ianlewis]

Is there a real possibility that the two signatures would be exactly the same but that multiple certificates would be able to verify it? I suppose that there aren't necessarily any cryptographic guarantees but I wonder if this is actually exploitable in practice.

I would think that would be pretty problematic since it would imply that the multiple public keys (including some completely different, potentially attacker-controlled key) would be able to pass signature verification.

[asraa]

Yes, technically the signatures matching is the only requirement - although this is a "SHOULD" as an extra robustness pass. Verifying the sigs match implicitly verifies the public key of the cert, since, except at very statistically improbable events, no two pks should give the same sigs on the same given message (the attestation).

It is possible the cert content may be different with the public key the same, and that's indicating a key compromise during the 10 min window where the Fulcio cert is valid (which we cannot protect against) or Fulcio misbehavior.

[laurentsimon]

Verifying the sigs match implicitly verifies the public key of the cert, since, except at very statistically improbable events, no two pks should give the same sigs on the same given message (the attestation).

I don't think that's necessarily true. It's not a property of signature schemes, in particular if an attacker can select the public key. With ECDSA for example, it's easy to compute signature collision; I think it's just a matter of re-arranging the equation with the pubKey as the unknown variable and solving it