Reproducing the problem is easy:
- First, disable “Include signature’s revocation status” from the Signature Creation and Appearance Preferences.
- Then sign with any certificate the attached PDF.
- And finally “Add Verification Information” for this signature.
With a result like the following:
Now, the particularity of the attached PDF is that it includes an attachment with its file specification dictionary (/Filespec) added to the Names entry as a direct object:
8 0 obj
<<
/Names[
(attachment.txt)
<</AFRelationship/Unspecified
/EF<</F 4 0 R/UF 4 0 R>>
/F(attachment.txt)
/Type/Filespec
/UF(attachment.txt)>>
]
>>
endobj
Instead of using an indirect object reference as PDF 32000-1:2008, "7.9.6 Name Trees" recommends, but doesn't mandate:
7.9.6 Name Trees
A name tree serves a similar purpose to a dictionary—associating keys and values—but by different means.
...
• The values associated with the keys may be objects of any type. Stream objects shall be specified by indirect object references (7.3.8, "Stream Objects"). The dictionary, array, and string objects should be specified by indirect object references, and other PDF objects (nulls, numbers, booleans, and names) should be specified as direct objects.
Is this a bug in Adobe Acrobat?
PS: I’ve identified the cause for the previous problem by a painful trial and error process, so for future reference I would like to know if there is any way to make Adobe Acrobat to produce detailed logging during the processing of the PDF structure and digital signature validation. Having such a log would be a lifesaver for similar problems!
4
Replies
I doublechecked your example. Indeed, after signing your file applying any additional incremental update to it does break the signature. On the other hand, if one patches your file and refactors the direct file specification dictionary into an indirect object, applying incremental updates after signing does not break the signature as long as the updates contain only allowed changes.
Also I couldn't find anything in the PDF specs requiring file specification dictionaries in name tree values to be indirect.
I also think, therefore, that this is an Acrobat bug.
Acrobat's general behavior in this context - positively validating signatures in PDFs with certain small errors without warning as long as the signature covers the whole file but then suddenly negatively validating them after applying any incremental update, even if it containing only allowed changes - is questionable anyways. But the same behavior in case of your file without such an error is extreme.
PS: I’ve identified the cause for the previous problem by a painful trial and error process, so for future reference I would like to know if there is any way to make Adobe Acrobat to produce detailed logging during the processing of the PDF structure and digital signature validation. Having such a log would be a lifesaver for similar problems!
If there was such a log, I'd also love to know about it!
Probably one just needs to know the right registry values to set, like those for the Adobe ChainBuilder log.
Is this the correct place to report such type of bugs?
Well, at least you can try and discuss here whether it indeed is a bug. To post an actual bug report you should probably try the form pointed to by @Test Screen Name.
I wouldn't hope for a quick fix, though. There are known other cases in which Adobe Acrobat incorrectly fails validating signatures after incremental updates that Adobe has known about for more than a year, and those cases have not been fixed in a public release yet.
Maybe Adobe has become very cautious changing the validation code to allow more positive validations since the RUB started publishing incorrect positive validations on https://www.pdf-insecurity.org/ and elsewhere.
AdChoices