1

I am testing several PKCS12 keystores with ECC type keys, generated by a CA with RSA key, to sign PDF documents. I have also tested with my own certificates from a demo CA certificate. I use Adobe Acrobat Reader DC 2022.001.20085 on Windows 10 to generate document signatures. I have noticed that when I load the certificate identifier from the Windows store to sign the PDF, Adobe indicates SHA256 in the Signature algorithm field of the signature in Advanced Properties and RSA PKCS#1 v1.5, but when I load the certificate identifier directly from the PKCS12 file (from file system) the signature correctly indicates SHA256 ECDSA.

If the CA's certificate is of the ECC type, then I always obtain the ECDSA signature algorithm correctly in the PDF documents. Apparently when the certificate chain is on the Windows store Adobe assumes that the signature type identifier used to sign the certificates by the CA (RSA) is the same as the one used by the user certificate to sign the PDF (ECDSA), which seems wrong to me from any point of view.

The only reference to the same topic that I have found is 1 but it doesn't show any convincing answers.

So, I would like to know if this is an Adobe bug or I'm missing something, and if anyone has a reference to official documentation on the subject or can clarify this question for me. Thanks in advance.

I add this example with a test certificate. In the first image I show the CA certificate in which it can be seen that its key is of the RSA type. In the second image you can see that the user's certificate is of type ECC.

CA certificate data

User certificate data

Importing ID to sign from PKCS12 file

Now I sign a PDF document with the digital ID loaded from the .p12 file and we can see that the signature algorithm is ECDSA, which is correct because it is the type of key that contains the user's certificate (little dialog on the right side).

Signature result from .p12 file

Now I sign the document with the same digital ID but loaded from the Windows certificate store, and we can see that the type of signature algorithm has changed even though the private key used for the signature is the same, because apparently it has taken the algorithm RSA that is used by the CA to sign the user's certificate, but is not used by the user to sign the documents, because the user's certificate is of type ECC.

Signature result with the same private key, but from Windows Certificate Store (importing PKCS12 on Windows)

When trying to verify this digital signature with a third-party library such as Apache PDF Box, an exception is obtained in the type of key, apparently because the algorithm indicates RSA but the public key that contains the certificate and the format of the signature is ECDSA.

RobertGG
  • 47
  • 4
  • I know certificates quite well, but I am not familiar with the Acrobat Reader interface for signing PDFs. Can you provide screenshots to help me understand your description? – Mike Ounsworth Apr 27 '22 at 23:59
  • @MikeOunsworth I added some pictures, I hope it is useful. – RobertGG Apr 28 '22 at 23:26

1 Answers1

1

That's totally weird. I completely agree with you: this seems like a bug in Adobe when it creates the signature.

It seems like:

  • It correctly uses the provided private key to create an ECC signature.
  • It incorrectly copies the signature algorithm identifier (algID) of the CA certificate, not of the actual signature used.

So it seems like the document is correctly signed with ECC, but it indicates that it is RSA.

I wonder if Adobe has a way for you to report this bug?

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 1
    Ok then we both agree. I think Adobe is verifying the signature checking directly the format of the value (maybe the ASN.1 structure) and not the algorithm OID. I will try to report this to Adobe. If I get a response from Adobe I will add my own response here to clarify this to others. – RobertGG Apr 29 '22 at 02:49
  • @RobertGG Heh, if it's ignoring the algorithm OID and "sniffing" the signature type, that could be a CVE in itself if you can find a case where a given signature value is simultaneously valid for two different signature algorithms / padding schemes. – Mike Ounsworth Apr 29 '22 at 15:27