8000 Align Client Fallback Behavior for Deprecated ECDSA Algorithms in v3 Bundles · Issue #1415 · sigstore/sigstore-python · GitHub
[go: up one dir, main page]
Skip to content

Align Client Fallback Behavior for Deprecated ECDSA Algorithms in v3 Bundles #1415

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
SequeI opened this issue May 27, 2025 · 3 comments
Open

Align Client Fallback Behavior for Deprecated ECDSA Algorithms in v3 Bundles #1415

SequeI opened this issue May 27, 2025 · 3 comments
Labels
enhancement New feature or request

Comments

@SequeI
Copy link
Contributor
SequeI commented May 27, 2025

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?
@SequeI SequeI added the enhancement New feature or request label May 27, 2025
@jku
Copy link
Member
jku commented May 27, 2025

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
Copy link
Member
jku commented May 27, 2025

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
Copy link
Contributor Author
SequeI commented May 27, 2025 •
edited
Loading

@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

@SequeI SequeI mentioned this issue May 28, 2025
Open
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jku @SequeI
0