Align Client Fallback Behavior for Deprecated ECDSA Algorithms in v3 Bundles

[SequeI]

Some v3 bundles were created using ECDSA key types (P384, P521) paired with SHA-2 hash functions that are not considered standard or recommended. These combinations (e.g., P384 with SHA256, P521 with SHA256) are now considered deprecated as shown here

Currently:

sigstore-go has implemented a fallback strategy (see sigstore/sigstore-go#424) that attempts multiple hash combinations (e.g., SHA256 and SHA384 for P521).

sigstore-python and potentially other clients do not implement this fallback, and fail to verify certain valid v3 bundles signed with these combinations.

We should consider implementing the same fallback logic across clients to ensure consistent verification behavior for existing v3 bundles.

Specifically:

For P384: try both SHA256 and SHA384

For P521: try both SHA256 and SHA512

Discussion Points
Do we want to add fallback to sigstore-python?

Should fallback be the standard behavior for v3 clients?

Is it worth standardizing this behavior in the spec to avoid ambiguity?

[jku]

what a mess. I see @woodruffw had this opinion in March:

I was thinking about this a bit, and I think we can do this in a compatible and non-sketchy/brittle way:

1. Perform the "normal" pairing verification flow: P256+SHA256, P384+SHA384, etc.
2. If the key/cert conveys a P384 key but the SHA384 image doesn't verify, then additionally compute the SHA256 image and attempt verification with that.

I think this would retain compatibility at the cost of a small amount of additional client complexity during verification flows (namely, clients would need to additionally compute a new digest over the input in the worst case). The security of this fallback depends on the assumption that SHA256 and SHA384 don't have overlapping image domains, which should be true both as a property of their cryptographic strength and their difference in digest size.

[jku]

Am I correct that this is not just about supporting "deprecated" combinations of key size and hash algo, but also that the signing certificates are just incorrect: they claim to be using another hash algorithm but actually use SHA-256?

[SequeI]

@jku Correct, specifically with Rekor on our side. But both are valid issues I believe

For example, within the signed target trust root we have PKIX_ECDSA_P384_SHA_384, but in actuality use PKIX_ECDSA_P384_SHA_256 (Rekor KeyDetails) which is deprecated unfortunately. A funny solution I have come across is just changing P384 to P256 within the key details and it 'works' but ofcourse this is not the intended way to do this