Adobe Acrobat/Reader changes font object when doing a signature which invalidates previous signature

[Stuck Mojo]

We just notcied a strange behavior of Acrobat/Adobe Reader (DC 2019.021.20056) and found the root cause:

There's a generated PDF that uses standard fonts which are referenced through the AcroForm default resources entry, too. Strangely the font has a Name entry in its dictionary:

3 0 obj
<</Type/Font/Subtype/Type1/BaseFont/Helvetica/Name/F1/Encoding/WinAnsiEncoding>>
endobj

We add 2 signature fields with our own tool and certify/sign one field. This results in a valid document, which you can download here. Do not wonder, there's really only a single line on the page.

When you open this document in Adobe Acrobat or Reader and sign the left field the new signature is fine but the previous one is invalid because of changes which were not allowed. The resulting document is available here.

We tracked it down that Adobe Acrobat/Reader simply removes the Name entry from the font dictionary which invalidates the first signature:

3 0 obj
<</BaseFont/Helvetica/Encoding/WinAnsiEncoding/Subtype/Type1/Type/Font>>
endobj

If we remove the Name key before we add the signature fields and the first signature everything runs without any issue.

So from my point of view this seems to be a bug in Acrobat, or? Not to say that the generation library should omit the Name entry, too.

[ls_rbls]

Hi,

As I  am not an expert in this area, but at this time I think this is not a bug, but a security mechanism that you are trying to circumvent.

You may be able to work around this issue if you configure the appropriate time stamp servers that are needed to complete the certificate revocation checks when the digital signature is applied and stamped with the current time:  See here: 

https://helpx.adobe.com/sign/using/custom-time-stamp-providers.html

And here for other insightful links provided in the following thread: https://community.adobe.com/t5/acrobat/signature-invalid-problem/td-p/10188484

These were my findings:

• The PDF generated document that you shared was created using open source software; the source software is TCPDF
• When the Acrobat PDF checks for certificate revocation for The signature applied in the signed document, the certificate path is valid but not the time stamping and the key usage
• The digital signature was applied with the use of another PDF creation software demo or template (SetaPDF-Demo); it also indicates that an older version of Adobe Acrobat XI was used (this got me lost here as there are occasions that a newer version of Acrobat may not validate signatures if they were applied with an older version)---> So I really don't know what you're trying to test here.
• When you click on View Report for the signed version of the document you shared, it lists as the first item: Code 4000  "Unrecognized PDF Content
• I was able to trust the signature by going to Edit--Preferences--Securtity and Security Enhanced
• You need to configure the timestamp server settings and see if that works: going to Edit--Preferences--Signatures and referring to the first  link that I shared above for guidance; be advised that the GlobalSign root certificate provider has different policies and legal disclaimer for third-parties
• Adobe also has legal disclaimer for third-parties and specifies about pre-qualified timestamp providers.
• FreeTSA.org and Demo Timestamp Service from SetaPDF are not pre-qualifed timestamp providers under Adobe terms. This is specified in the link provided above.

[Stuck Mojo]

All your findings are correct but not related to this issue at all. They all doesn't matter in this case, because the issue has nothing todo with trust or missing verification information.

Again: Adobe Acrobat/Reader simply rewrites and changes a standard font dictionary if the second free signature field is signed, which is simply not allowed and recognized as an unallowed change by Adobe Acrobat/Reader itself. We tracked it down and it is reproducable on our end. If this:

3 0 obj
<</Type/Font/Subtype/Type1/BaseFont/Helvetica/Name/F1/Encoding/WinAnsiEncoding>>
endobj

get's not rewritten to or is rewritten before adding the signature fields to:

3 0 obj
<</BaseFont/Helvetica/Encoding/WinAnsiEncoding/Subtype/Type1/Type/Font>>
endobj

everything is fine.

[ls_rbls]

Again: I am not an expert in this area and this is a user to user forum; frequently an Adobe employee may or will  assist with guidance here. 

But, if  none of my input is related  to this issue and If your finding actually indicates that this a bug, then you get a better shot of voicing your observations  here: https://www.adobe.com/products/wishform.html

Hopefully a more qualified person will assist and the engineering team will become aware to work on the issue.

[Stuck Mojo]

There was a time when Adobe employees visited the forums - I hope that will happen again. The "wishform" feels like a black hole to me... everything I send through it was lost and gone (at least for me) and I never heard of it anymore... 🙂

[Stuck Mojo]

Ok... they'd changed the "wishform" and it is publicly now, great. I just filed the issue there, too: https://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/39185608--bug-ad...

[ls_rbls]

If it helps in anything, I've seen this issue with Adobe Acrobat forms too.

Mostly when a PDF document has some sort of editing restrictions or encryption. You will be able to see it more clearly if the document is refried and try to edit the postscripted document signature field by copying and pasting text into another document.