Product: GnuPG / gpgsm
Environment: Gpg4win, Kleopatra frontend, gpgsm backend
Component: X.509 certificate chain validation

Summary
gpgsm rejects an X.509 certificate chain because the issuer/root CA uses an ECC P-521 key and the certificate signature algorithm is ECDSA with SHA-384. The failure appears to come from a key-size-to-hash-size restriction in chain validation, even though ECDSA with SHA-384 is a defined X.509 signature algorithm and conforming clients must recognize it.

Observed behavior
During certificate dump / chain validation, gpgsm emits:

gpgsm: hash algo: 1.2.840.10045.4.3.3
gpgsm: a 384 bit hash is not valid for a 521 bit ECC key
gpgsm: DBG: gcry_pk_verify: Success
[GNUPG:] FAILURE gpgsm-exit 50331649

The important part is that gcry_pk_verify: Success is logged, but gpgsm still rejects the chain because it considers SHA-384 invalid for a 521-bit ECC key.

Expected behavior
gpgsm should accept the chain if the certificate signature algorithm is ecdsa-with-SHA384 (OID 1.2.840.10045.4.3.3) and the signature verifies correctly. RFC 5758 explicitly defines ecdsa-with-SHA384 and states that conforming client implementations processing ECDSA signatures in certificates and CRLs must recognize the corresponding SHA-2 ECDSA OIDs, including ecdsa-with-SHA384.

Why this looks like a bug
RFC 5758 defines the X.509 signature algorithm OIDs ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384, and ecdsa-with-SHA512 for ECDSA signatures in certificates and CRLs. The RFC text does not restrict ecdsa-with-SHA384 to only P-384 keys; it defines the signature algorithm identifier independently and requires clients to recognize it. The current gpgsm behavior appears to impose an additional restriction that rejects P-521 + SHA-384 even after the cryptographic signature verification succeeds.

Reproduction

1. Import or inspect a certificate chain in Kleopatra / gpgsm.
2. Use a root CA certificate with an ECC P-521 public key.
3. Use a certificate signature algorithm of ecdsa-with-SHA384 (1.2.840.10045.4.3.3) on the issuer/root and on the leaf certificate.
4. Run a certificate dump / validation path in gpgsm.
5. Observe chain validation failure with the message:

a 384 bit hash is not valid for a 521 bit ECC key

Relevant certificate details from debug output

Signature algorithm OID reported by gpgsm: 1.2.840.10045.4.3.3

gpgsm labels this as a 384-bit hash

Issuer/root key is ECC 521-bit gcry_pk_verify: Success is logged before final failure

Suspected cause
gpgsm appears to contain logic that rejects SHA-384 for ECC P-521 based on a fixed curve-size/hash-size pairing rule. That rule seems too strict for X.509 ECDSA signature validation and contradicts RFC 5758 recognition requirements for ecdsa-with-SHA384.

Impact
This prevents valid X.509 certificate chains from being accepted in Kleopatra/gpgsm when they use ECDSA P-521 keys with SHA-384 signatures. As a result, chain validation fails even though the signature verification step itself succeeds.

Suggested fix
Remove or relax the check that rejects ecdsa-with-SHA384 solely because the signing key is P-521. Validation should follow the certificate’s declared signature algorithm OID and accept ecdsa-with-SHA384 when the ASN.1 algorithm identifier is correct and the ECDSA signature verifies successfully, which RFC 5758 requires clients to recognize.

Reference text
RFC 5758 defines ecdsa-with-SHA384 as OID 1.2.840.10045.4.3.3 and says conforming client implementations processing ECDSA signatures in certificates and CRLs must recognize the corresponding SHA-2 ECDSA OIDs.