Skip to main content
V
VLADIMIR32729610icok
Participant
October 5, 2023
Answered

Invalidated first signature for PDF\A 2-B document after addition of the signature timestamp

  • October 5, 2023
  • 2 replies
  • 1003 views

Dear Adobe team,


we have an issue with the PDF\A 2-B document. We have the following flow:

  1. the document is created with a custom metadata
  2. the document is signed with the ETSI signature (at this moment signature is OK - there is only root certificate trust problem)
  3. timestamp is added to the document (at this moment the first signature is validated as altered or corrupted. Please see an attached screenshot)


This kind of behavior in the validation process we can see only in the Acrobat Reader. We have tried other tools to validate the signature and timestamp as well. In that validation tools we see positive validation result of the first signature. We have also used reference validation tool of EU https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/home. We have also doublechecked if a binary content has been changed after adding timestamp.

Versions of Acrobat Reader are as follows:
Continuous Release: Version 2023.006.20320 64bit
Core Version: 23.1536 64bit
Version File: 23.006.20320.0
AGM Version: 7.001.00001 64bit
CoolType Version: 8.003.00002 64bit
JP2K Version: 4.000.00000.52671 64bit

Please find the sample document attached.

    This topic has been closed for replies.
    Correct answer MikelKlink

    The issue essentially is the same as in this thread, this thread, and this thread (and other answers elsewhere referenced from there): There is a small error in the original version of the document that usually is ignored by PDF viewers (including Acrobat) but that makes Acrobat reject signatures not covering the full document.

    The original revision of your document claims to have been generated by Aspose.PDF for .NET 22.6. Aspose PDF components at least since version 11 have had the issue that they created broken object cross reference tables, see for example this thread on the Aspose support forum. There Aspose personal claimed for different 17.x versions that the bug had been fixed but at least for some versions 19.x the bug has been observed again and now also for 22.x in your case.

    The current Aspose.PDF version appears to be a 23.x. Possibly they meanwhile do have fixed the issue for good. Thus, you may want to try updating to a current Aspose.PDF version for creation of the original revision. If that doesn't help, consider applying the first signature not as incremental update. 

     

    The error in detail:

    The cross reference table section of the first revision of your document consists of multiple subsections:

    xref
0 80
0000000000 65535 f
...
0001951497 00000 n
81 27
0001951519 00000 n
...
0001952148 00000 n

    Furthermore, there is an object numbers in the applicable range without any mapping: 80.

    According to the PDF specification, though, for a PDF file that has never been incrementally updated, the cross-reference section shall contain only one subsection, whose object numbering begins at 0, and the cross-reference table (comprising the original cross-reference section and all update sections) shall contain one entry for each object number from 0 to the maximum object number defined in the PDF file, even if one or more of the object numbers in this range do not actually occur in the PDF file.

     

    2 replies

    MikelKlink
    MikelKlinkCorrect answer
    Participating Frequently
    October 5, 2023

    The issue essentially is the same as in this thread, this thread, and this thread (and other answers elsewhere referenced from there): There is a small error in the original version of the document that usually is ignored by PDF viewers (including Acrobat) but that makes Acrobat reject signatures not covering the full document.

    The original revision of your document claims to have been generated by Aspose.PDF for .NET 22.6. Aspose PDF components at least since version 11 have had the issue that they created broken object cross reference tables, see for example this thread on the Aspose support forum. There Aspose personal claimed for different 17.x versions that the bug had been fixed but at least for some versions 19.x the bug has been observed again and now also for 22.x in your case.

    The current Aspose.PDF version appears to be a 23.x. Possibly they meanwhile do have fixed the issue for good. Thus, you may want to try updating to a current Aspose.PDF version for creation of the original revision. If that doesn't help, consider applying the first signature not as incremental update. 

     

    The error in detail:

    The cross reference table section of the first revision of your document consists of multiple subsections:

    xref
0 80
0000000000 65535 f
...
0001951497 00000 n
81 27
0001951519 00000 n
...
0001952148 00000 n

    Furthermore, there is an object numbers in the applicable range without any mapping: 80.

    According to the PDF specification, though, for a PDF file that has never been incrementally updated, the cross-reference section shall contain only one subsection, whose object numbering begins at 0, and the cross-reference table (comprising the original cross-reference section and all update sections) shall contain one entry for each object number from 0 to the maximum object number defined in the PDF file, even if one or more of the object numbers in this range do not actually occur in the PDF file.

     

    V
    VLADIMIR32729610icokAuthor
    Participant
    October 5, 2023
    hb_vadny.pdf
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices