celuchmarek
commented
4 months ago Z Jiry DSS projektu priamo od maintainera:
The size of /Contents dictionary is pre-computed before the CMS signature is created. This is required in order to compute digest of the PDF document's /ByteRange before the SignatureValue/CMS computation. The PDF revision (and the /Contents dictionary consequently) cannot be modified after, as it will break the target signature.
The CMS size depends not only on the signature parameters but also on the provided embedded material, such as certificate chain or/and timestamp. As you create a T-level signature, the size of the CMS signature is much bigger in comparison with the B-level as you have a signature-timestamp. The signature-timestamp is computed after the PDF and SignatureValue creation, therefore it is impossible to determine the required size of /Contents dictionary in advance.
As you can see in the PAdESSignatureParameters the default CMS size is set to 9472 characters for a hex-encoded CMS signed data. You need to increase the PAdESSignatureParameters.setContentSize(...) value to be big enough to incorporate your signature to the PDF document (try to increase it to 1.5 times or 2 times for the beginning). The value should be sufficient but not too large, as it will increase the size of the created PDF document.
Alternatively, you may try to create a B-level signature and extend it to T+ level after using PAdESService.extend(...) method. When extending a PDF signature, the computed signature-timestamp is not being embedded to a CMS signature, but added within a new PDF revision. This should allow you to not modify the signature size property. However, please note that the size of the created PDF document will be even bigger with the #extend method, as it requires a creation of a new PDF revision.
jsuchal
Malo by riešiť #383 (a teda nie len na Mac OS, ale na každom systéme). Treba ešte otestovať, či stačí ten content size meniť iba pri TS alebo aj bez nej. Podľa mojich doterajších zistení stačí iba pri TS.