Using TSA causes a extra xref size

[Jacq]

I am testing the TSA feature (set_tsa and not set_ltv) with a dompdf generated pdf, after the signing I load again the PDF with "$pdfDoc = PDFDoc::from_string($pdfSigned);" doing this several times with the same input sometimes $pdfDoc returns true;

The error is related to "xref tag not found at position", I checked the signed pdf buffer and in some cases the xref_pos size is different, when using TSA feature sometimes it adds 4 chars to the xref_pos, this is an example of PDF signed with TSA and checked correctly with startxref 17394:

endobj
xref
0 2
0000000000 65535 f 
0000001723 00000 n 
5 2
0000001335 00000 n 
0000001613 00000 n 
10 3
0000001476 00000 n 
0000001501 00000 n 
0000001822 00000 n 
trailer
<</Size 13/Root 1 0 R/Info 5 0 R/ID[<1a3d216a394bb6ba74fb5cc1fd4391fe> <1a3d216a394bb6ba74fb5cc1fd4391fe>]/Prev 984>>
startxref
17394
%%EOF
'

and this is the same PDF signed again that reports startxref 17398 bytes:

endobj
xref
0 2
0000000000 65535 f 
0000001723 00000 n 
5 2
0000001335 00000 n 
0000001613 00000 n 
10 3
0000001476 00000 n 
0000001501 00000 n 
0000001822 00000 n 
trailer
<</Size 13/Root 1 0 R/Info 5 0 R/ID[<454c825cf55cc68453eea7ab2eb1315b> <454c825cf55cc68453eea7ab2eb1315b>]/Prev 984>>
startxref
17398
%%EOF
'

In the second case the function "public static function get_xref_1_4" xref_line starts in "obj\n" instead of "xref\n" and the code reports the "xref tag not found at position".

I could fix the code to detect this 4 bytes shift when searching the xref anchor but the bug itself is probably upstream when applying the TSA signature, as the documents have the same exact sizes with different signatures, any ideas?.

I have repeat the test several times without set_tsa, or with set_ltv and it only triggers with set_tsa, I am testing with the digicert timestap service.
Cheers
Jacq

[dealfonso]

Hi,

I also had some glitches when testing TSA, but I thought it was my fault... let's debug

[parallels999]

CC: @hidasw, related #70

• There was another PR for TSA, maybe you could compare it to see where the problem is, Support timestamp #52

Maybe it's not because __SIGNATURE MAX_LENGTH is now variable, and performs a pre-signature to calculate the size

[hidasw]

CC: @hidasw, related #70

• There was another PR for TSA, maybe you could compare it to see where the problem is, Support timestamp #52

Maybe it's not because __SIGNATURE MAX_LENGTH is now variable, and performs a pre-signature to calculate the size

I'm currently away from computer and not possible to analyze it soon.
but you can try to pre defined __SIGNATURE MAX_LENGTH to 20000 or above.
I suggest to set at about 32000.
let me know what happen.

[Jacq]

It was already at 27742, increasing it to 32000 does not look to mitigate the issue, it still fails every one or two successes.
Cheers
Jacq

[dealfonso]

any update on this?

[hidasw]

any update on this?

If what is meant is about the change in size due to one tsa request and another,
Then what I know is that some tsa responses are not fixed in size.
maybe because they use accuracy up to milliseconds or microseconds so the number of digits in accuracy also changes.

I don't really understand this question because it is related to the pdf structure (outside of cryptography issues).

• how can I reproduce this problem.
• can I get a pdf file or other related sample to test.
• what is the expected result.

I plan to do the next update for some improvements, also by including ecc certificate support.