Repository navigation
[BUG] Valid PKCS#7 ECDSA signature reported as invalid in Bouncy Castle C# 2.6.x #676
Description
Description
After upgrading from Bouncy Castle C# 2.5.x to 2.6.x, PKCS#7 signature verification for ECDSA signatures appears to have regressed. A signature that verifies successfully in 2.5.x is reported as invalid in 2.6.x, while using identical input data, signature, and certificate.
Observed Behavior
- Verification succeeds in 2.5.x
- Verification fails in 2.6.x
- A
CmsExceptionis thrown with the message:unrecognised signature parameters provided
Expected Behavior
- The PKCS#7 ECDSA signature should verify successfully, identical to the behavior in 2.5.x.
Signature Details
- Signature algorithm: ECDSA with SHA‑256
- Algorithm OID: 1.2.840.10045.4.3.2
- The signature algorithm parameters are present and valid in the PKCS#7 object.
Minimal Reproducible Example
public bool VerifyPkcs7(byte[] data, byte[] signature, byte[] signerCertificate)
{
var parser = new X509CertificateParser();
var certificate = parser.ReadCertificate(signerCertificate);
var cmsProcessableByteArray = new CmsProcessableByteArray(data);
var cms = new CmsSignedData(cmsProcessableByteArray, signature);
var signer = cms.GetSignerInfos().GetSigners().First();
return signer.Verify(certificate);
}- This code verifies the signature successfully in 2.5.x
- The same call fails in 2.6.x, throwing the exception mentioned above
Analysis / Suspected Root Cause
The failure appears to originate in SignerInformation.cs, around line 461:
if (!X509Utilities.IsAbsentParameters(sigAlgParams))X509Utilities.IsAbsentParameters(sigAlgParams)returns false when valid algorithm parameters are present.- Due to the negation (
!), the condition evaluates to true when parameters are present. - This leads to a
CmsExceptionstating
unrecognised signature parameters provided, even though the parameters are valid for ECDSA with SHA‑256 (OID 1.2.840.10045.4.3.2).
As written, the condition effectively checks for presence rather than absence of parameters.
Possible Fix
Remove the negation so that the condition correctly triggers only when parameters are absent:
if (X509Utilities.IsAbsentParameters(sigAlgParams))This change restores the behavior observed in 2.5.x and allows valid PKCS#7 ECDSA signatures using SHA‑2 to verify successfully.
Additional Notes
- This appears to be a regression introduced between versions 2.5.x and 2.6.x.
- Please let me know if this behavior change was intentional.
- I would be happy to provide a regression test or submit a pull request if this aligns with the expected behavior.
Activity
peterdettman commentedon Apr 29, 2026
It's hard to know the exact issue without the
SignatureAlgorithmvalue. For ECDSA with SHA-256 I would expect to see the OID 1.2.840.10045.4.3.2 insigAlgOid, andsigAlgParamsSHOULD be absent (i.e.sigAlgParams== null), although for historical reasons we tolerate an ASN.1 NULL insigAlgParamsinstead. What is theSignatureAlgorithmin your case (i.e.sigAlgOidandsigAlgParamsvalues)?Note that the IsAbsentParameters call is as intended; we avoid proceeding with parameters present that we don't understand.
Gumbagubanga commentedon May 6, 2026
sigAlgOid= 1.2.840.10045.4.3.2sigAlgParams= 1.2.840.10045.3.1.7I understand, that the IsAbsentParameters call is required here. What I don't understand is the negation in
if (!X509aUtilities.IsAbsentParameters(sigAlgParams)).Looking at the implementation of IsAbsentParameters as
parametersis not null and the checkDerNull.Instance.Equals(parameters)is also false it seems to me that the parameter is valid.peterdettman commentedon May 6, 2026
So the
sigAlgOidis named ecdsa-with-SHA256 and thesigAlgParamsname the curve prime256v1 (a.k.a P-256).According to RFC 5753, when the signatureAlgorithm of a SignerInfo is ecdsa-with-SHA256, then the parameters are absent. So we confirm they are absent (we allow also NULL for legacy reasons).
The error is raised because we find instead the prime256v1 OID, which does not belong there. ECDSA is done with the curve of the EC key involved; it cannot be configured separately in the
signatureAlgorithm.However a curve OID is typically provided as parameters (
ECParameters/namedCurve) for an EC public key AlgorithmIdentifier (e.g. in a certificate), so perhaps there is some confusion between the two AlgorithmIdentifiers in the code that generated this message.Gumbagubanga commentedon May 6, 2026
The signatures were afaik generated using 'SecSigner' by SecCommerce using D-Trust or Telesec signature cards.
I'd have to pull some data from production servers to see whether my tests are flawed.
peterdettman commentedon Sep 21, 2026
Not considered a bug as described - invalid signatureAlgorithm parameters should not be accepted.