Digital signatures not working properly with certificates with different cryptografy

[Elis24149315m28y]

Adobe Reader and Acrobat have problems with creation of PAdES digital signature when I use a TEST certificate that has RSA 2K private kay, and this certificate was issued by TEST CA (not on EU trusted list, but this is not the issue) that signed this certificate with sha384ECDSA.

Adobe makes a signature and validates it successfully, but EU ETSI EN 319 102 compliant validation reports SIG-CRYPTO-FAILURE. Other signer programs and services, that are compliant with EU standards, do not have this issue.

I think this is a bug. I am considering to instruct the users not to use Adobe programs for signature creation and to use our signing service or any other EU compatible publicly available signature service such as EU DSS, if I do not get this issue solved. It looks like Adobe is confused by different crypto algorithms in certificate private key (RSA) and CA signature on certificate (ECDSA).

Attached are 2 signed PDFs, one signature is created by Adobe Acrobat Pro 2020,  version 2020.005.30334 (it says it is ut to date (TestCERTILIA_novi_Acrobat), and one by EU ETSI EN 319 102 compliant DSS service (Test_novi_TESTCERTILIA_-signed-pades-baseline-b).

Any suggestions?

Thank you!

[MikelKlink · Accepted solution]

Indeed, the signature container in "TestCERTILIA_novi_Acrobat.pdf" is malformed, its SignerInfo object claims the signing algorithm to be SHA386withECDSA but it obviously (if you know the formats) cannot be an ECDSA signature:

SEQUENCE (2 elem)
    OBJECT IDENTIFIER 1.2.840.10045.4.3.3 ecdsaWithSHA384 (ANSI X9.62 ECDSA algorithm with SHA384)
    OBJECT IDENTIFIER 1.3.132.0.34 secp384r1 (SECG (Certicom) named elliptic curve)
OCTET STRING (256 byte) 1FC255E02813F73D43ABF046CDCACC4EBC66B98D408CD07607F585066B17E19C62F59…

(Strictly speaking, this signature algorithm value already by itself is questionable as it has a parameter denoting the curve used while e.g. RFC 5480 states:

   -- ECDSA with SHA-384
   -- Parameters are ABSENT

   ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
     ecdsa-with-SHA2(3) 3 }

i.e. that the algorithm OID is used without parameter.)

The reason why Adobe Acrobat validates this signature positively in spite of this incorrectness is a well known Acrobat error: For signature validation it ignores the contents of the signature algorithm field of the signature container SignerInfo object and deduces the algorithm to use from the public key of the signer certificate.

It does use the contents of that field for displaying an alleged signature algorithm in the Signature Details (Signature Properties -> Advanced Properties), though, and so misleads users who want to check the strength of the used algorithm here!

Any suggestions?

You mention that the Acrobat version used to sign is from 2020. There have been relevant changes in the signature related Acrobat code at the beginning of this year. It is possible, therefore, that this issue has been fixed. Thus, try signing with your certificate using the current Acrobat Reader. If that works, you might consider upgrading your Acrobat version.
Other than that try to use only signer certificates with homogeonous signing algorithms in their chain. And if that isn't possible, don't use Acrobat for signing.

A question out of interest, if you sign using simple adbe.pkcs7.detached signatures instead of PAdES signatures, does the same problem occur or is the signature algorithm correct there? Another recent question seems to imply that the code for those two cases has diverged considerably.

[MikelKlink · Accepted solution]

Indeed, the signature container in "TestCERTILIA_novi_Acrobat.pdf" is malformed, its SignerInfo object claims the signing algorithm to be SHA386withECDSA but it obviously (if you know the formats) cannot be an ECDSA signature:

SEQUENCE (2 elem)
    OBJECT IDENTIFIER 1.2.840.10045.4.3.3 ecdsaWithSHA384 (ANSI X9.62 ECDSA algorithm with SHA384)
    OBJECT IDENTIFIER 1.3.132.0.34 secp384r1 (SECG (Certicom) named elliptic curve)
OCTET STRING (256 byte) 1FC255E02813F73D43ABF046CDCACC4EBC66B98D408CD07607F585066B17E19C62F59…

(Strictly speaking, this signature algorithm value already by itself is questionable as it has a parameter denoting the curve used while e.g. RFC 5480 states:

   -- ECDSA with SHA-384
   -- Parameters are ABSENT

   ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
     ecdsa-with-SHA2(3) 3 }

i.e. that the algorithm OID is used without parameter.)

The reason why Adobe Acrobat validates this signature positively in spite of this incorrectness is a well known Acrobat error: For signature validation it ignores the contents of the signature algorithm field of the signature container SignerInfo object and deduces the algorithm to use from the public key of the signer certificate.

It does use the contents of that field for displaying an alleged signature algorithm in the Signature Details (Signature Properties -> Advanced Properties), though, and so misleads users who want to check the strength of the used algorithm here!

Any suggestions?

You mention that the Acrobat version used to sign is from 2020. There have been relevant changes in the signature related Acrobat code at the beginning of this year. It is possible, therefore, that this issue has been fixed. Thus, try signing with your certificate using the current Acrobat Reader. If that works, you might consider upgrading your Acrobat version.
Other than that try to use only signer certificates with homogeonous signing algorithms in their chain. And if that isn't possible, don't use Acrobat for signing.

A question out of interest, if you sign using simple adbe.pkcs7.detached signatures instead of PAdES signatures, does the same problem occur or is the signature algorithm correct there? Another recent question seems to imply that the code for those two cases has diverged considerably.

[Elis24149315m28y]

The same is happening in Adobe Reader DC, latest version. The same is happening using simple adbe.pkcs7.detached signatures, but this is of no use in EU since qualified e-signature has to be in advanced format, for PDF this is defined as PAdES-BASELINE B, T, LT or LTA levels. Since the same problem is present in latest version of Reader I guess there is no use in upgrading Acrobat 2022. In fact, I gave Acrobat as an example since the Reader is not supported.

[MikelKlink · Accepted solution]

In that case my suggestions above burn down to try to use only signer certificates with homogeonous signing algorithms in their chain. And if that isn't possible, don't use Acrobat for signing.

Additionally consider reporting the error to https://www.adobe.com/products/wishform.html and try signing with your certificate every other month or so.