Created attachment 166560 [details] Test document and signed result SUMMARY When creating a digital signature with Okular, the signature dictionary is not referenced in the AcroForm as required by the PDF/A Signature Tech Note [1]. This leads to problems in various signature validation software [2,3,4], namely that the signature is not found. [1] https://pdfa.org/wp-content/uploads/2011/08/tn0006_digital_signatures_in_pdfa-1_2008-03-141.pdf [2] https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation [3] https://service.exceet.cloud/signature-check/web [4] https://sws.firmacerta.it/SignEngineWeb/verifier.xhtml STEPS TO REPRODUCE 1. Sign a PDF document with Okular 2. Verify with an external verification tool OBSERVED RESULT Signature is not found in external verification tools EXPECTED RESULT Signature is found and successfully validated SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian unstable (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Poppler Version: 22.12.0 ADDITIONAL INFORMATION The unsigned and signed document are attached for reference. When inspecting the PDF specifications, the situation is more complicated. The used test document is a PDF 1.4 document, so the signature field must be an interactive form field, meaning it has to be referenced in the AcroForm. The PDF 1.7 introduces non-interactive forms which, to my understanding, don't need the AcroForm entry. The signature field section (12.7.5.5 in PDF 2.0) does not state whether an interactive or a non-interactive form field needs to be used. While this explains while poppler and Adobe Acrobat Reader find the signature and validate it successfully, thereby at least ignoring the undefined non-interactive form type in PDF 1.4. However there is still the PDF/A Signature Tech Report which should be taken into account when creating signatures.
Hi Tobias Any chance you can try again with an okular built with a less ancient poppler ? Note that quite some work have gotten into digital signatures in both okular and poppler over the last year, and your poppler library is from december 1st, 2022. I just uploaded a signed test pdf to the europa.eu link, and except for it disliking my custom certificate authority chain, it was all green ?
(In reply to Sune Vuorela from comment #1) > Hi Tobias > > Any chance you can try again with an okular built with a less ancient > poppler ? > > Note that quite some work have gotten into digital signatures in both okular > and poppler over the last year, and your poppler library is from december > 1st, 2022. > > I just uploaded a signed test pdf to the europa.eu link, and except for it > disliking my custom certificate authority chain, it was all green ? Fair point. At the moment I only have the debian packages at my disposal. The okular version 23.08.1 is the latest in the repo. It is using libpoppler-qt5-1 which I can update to 24.02.0 from deb experimental. With that I get the same result. I have to build the programs myself to see for sure, but given fact, that the newer poppler version shows the same behaviour, it is probably something that is related to the okular code and has been fixed there already okular code. Just to make sure it's not related to my test document, have you tried signing this and checking in the EU validator?
I did some further testing and the document seems to be the problem. I created a new PDF without the form fields, so the PDF does not contain the AcroForm dictionary before singing. When I sign this document, the AcroForm is created and the signature is referenced there. In the document, which already contains the AcroForm, the dictionary is not updated accordingly. I also tried the build from flathub, which I guess is more recent than the one debian. It shows the same behaviour.
(In reply to Tobias Wich from comment #2) > (In reply to Sune Vuorela from comment #1) > > Hi Tobias > > > > Any chance you can try again with an okular built with a less ancient > > poppler ? > > > > Note that quite some work have gotten into digital signatures in both okular > > and poppler over the last year, and your poppler library is from december > > 1st, 2022. > > > > I just uploaded a signed test pdf to the europa.eu link, and except for it > > disliking my custom certificate authority chain, it was all green ? > > Fair point. At the moment I only have the debian packages at my disposal. > The okular version 23.08.1 is the latest in the repo. It is using > libpoppler-qt5-1 which I can update to 24.02.0 from deb experimental. With > that I get the same result. > > I have to build the programs myself to see for sure, but given fact, that > the newer poppler version shows the same behaviour, it is probably something > that is related to the okular code and has been fixed there already okular > code. > > Just to make sure it's not related to my test document, have you tried > signing this and checking in the EU validator? I have now tried signing your document and checking it in the eu validator, and I see it complaining quite a bit. I have tried another simple document with forms and signing that, and that was validated quite okay I think (except certificate chain)
Created attachment 166594 [details] Unsigned document with form I guess we should investigate how this form differs from your form ...
(In reply to Sune Vuorela from comment #5) > Created attachment 166594 [details] > Unsigned document with form > > I guess we should investigate how this form differs from your form ... I see several differences. I will refer to doc A for my document and doc B for yours. 1) Doc A embeds the AcroForm as a nested object in the Catalog dict, while doc B puts the AcroForm into an indirect object and references it in the Catalog 2) Doc B contains NeedAppearances=true in the AcroForm, while A lacks this property 3) Doc B contains a DA property, doc A not 4) Doc A has DR as an object reference, doc B embeds the object 5) Doc B contains an unsigned signature field (/FT=/Sig), while A does not I think 1) is a good candidate to look further, as it certainly makes a difference in the implementation if the AcroForm is just an object which can be rewritten in the increment, or if the parent element containing the AcroForm has to be modified as well. In doc B it makes no difference whether I sign the existing signature field, or if I let Okular add a new one. In both cases the signature entry is either updated, or added in the AcroForm, so it validates just fine. Btw, I created the document with LibreOffice 6.3 quite some time ago. The current LibreOffice (24.2.0.3) yields the same structure. So maybe having a document built in this way is maybe not completely out of the ordinary.
(Note to the other okular people; This is most probably an issue in poppler, and I'm looking at that. While it would be most correct to close the bug here and reopen it in poppler ( https://gitlab.freedesktop.org/poppler/poppler/ ), I'm keeping the bug open here 'cause that's where the user are)
> I'm keeping the bug open here 'cause that's where the user are) I disagree, if there's nothing to fix in Okular, it's not an Okular bug and this should be closed.
Hi Tobias After much investigation, I think I'm heading towards rejecting this bug report. When the AcroForm section is embedded directly into the Catalog dict, Poppler must rewrite the entire Catalog dict in order to update it. (As I understand PDF spec ISO 32000-2:2020 section 7.5.6 about incremental updates) Your signed form is seen with Adobe Reader. I'm writing a bug report to the ec.europa.eu validator to check this, and also filing a issue with LibreOffice to suggest them to always do the indirect references for the AcroForm.
https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1545