https://bugs.freedesktop.org/show_bug.cgi?id=66701
--- Comment #25 from Markus Wernig <pub...@wernig.net> ---
Michael
I have now run a couple of tests, trying to create signed PDFs with three
different certificates:
- Soft certificate ("softtoken"). This was a plain PKCS#12 file imported into
the Mozilla NSS DB store.
- Advanced certificate ("hardtoken"). This was a plain PKCS#7 certificate on
an RSA token with associated private key on the token. Key usage was
authentication/signing (i.e. no encryption).
- Qualified certificate ("qualified hardtoken"). This was a PKCS#7 certificate
stored in the SigG partition of the same RSA key, together with its private
key.
Both "hardtoken" certificates were visible through the NSS DB, where the token
had been added and the appropriate PKCS#11 library configured (libCVP11 and
libCVP11LCB respectively). This library is used by the NSS DB to communicate
with the RSA token and handles all token commands, prompting for PINs through
own helper programs if necessary, etc. The token works in both Thunderbird and
Mozilla.
The Acrobat version I used was Adobe Reader 9, Version 9.5.5 04/26/2013 on
Linux amd64. It would of course be necessary to verify the attached PDFs in a
newer version on other OSes (Tamas, could you do that on Win, maybe?).
The results already look better than we thought in the beginning, but there
are some errors that might be hard to track down.
Here's what I've found (The build was still 4.4.0.0-alpha0 with debug symbols)
1) Softtoken: The signature operation creates a signed PDF. It remains unclear
though, what the purpose of the "Certificate Password" field in the
certificate selection page is. Since the NSS DB store is already unlocked in a
separate dialog, I don't see any purpose in entering an additional (which??)
password, and leaving it empty made no difference.
The signature can be validated by Adobe Acrobat and any other tool that I got
my hands on! The only point was that Adobe has to have the root CA of the
signing certificate imported and trusted.
So the PDF signature seems to work per se, but the dialog could be improved to
make the options clearer (a help page would also be very useful!)
I created both signed PDF and PDF/A. See files sigtest.pdf and sigtest-a.pdf.
2) Hardtoken: After inserting the token, I first ran the program normally
(i.e. without gdb or valgrind).
The NSS dialog now correctly asked for two token passwords (one for the
internal NSS DB store and one for the token), then all certificates (from
softstore and token) showed up in the list. I selected the "normal"
authentication certificate from the hardtoken, and the signature was made
successfully. It also could be validated in Adobe! See file
sigtest-a-adv-sig.pdf.
Then i tried to repeat the procedure, and got this error on the console (where
I had started soffice.bin), when I clicked the "Select" button on the "Digital
Signatures" tab:
(process:26412): GLib-CRITICAL **: g_slice_set_config: assertion
'sys_page_size == 0' failed
The program then stopped responding and froze. It had to be killed.
I tried to reproduce this under valgrind, but unfortunately, it didn't freeze
under valgrind. I've attached the trace nevertheless:
valgrind-trace-4.4.0.0-nocrash-ok-advanced-sig-hardwaretoken-with-dbg.txt
3) Qualified hardtoken: First, without gdb/valgrind. Everything was the same
as above, with the libCVP11 correctly launching an external program
(/usr/local/bin/swisssign-pin-entry via /bin/sh) in order to request the
signature PIN of the SigG partition. After selecting the file to write, the
program crashed again with the output captured in
output-4.4.0.0-crash-qual-sig.txt.
Then the same under valgrind: As before, the program didn't crash and produced
a PDF. But the signature PIN was never asked for (most likely a valgrind
artefact), and the resulting PDF shows to be signed, some non-cryptographic
attributes of the signature (date, comment) are present. But the signature
itself is completely broken and cannot be validated in any program.
Actually, it even crashes most of the programs I've tried to validate it with.
One produced a Java stacktrace, from which I'd guessed that the signature was
not even a valid structure:
java.lang.IllegalArgumentException: can't decode PKCS7SignedData object at
com.itextpdf.text.pdf.PdfPKCS7. (PdfPKCS7.java:434)
Which makes sense, since the signature PIN was not requested (seems the helper
program segfaulted under valgrind).
Actually, the resulting signature is all zeroes (see lines 285ff. of
sigtest-a-qual-sig.pdf).
Looking at the Signature Properties -> Verification error in Adobe Acrobat, I
get the same (totally inconclusive) message as Tamas did in his original post:
Error during signature verification.
Error encountered while BER decoding:
The output from that is in
valgrind-trace-4.4.0.0-nocrash-broken-qualified-sig-hardwaretoken-with-dbg.txt
So we seem to have different conditions under which LO still crashes when
trying to sign the PDF.
Currently, I believe that the broken "qualified hardtoken" signature is only
due to the fact that the external helper program has aborted. In that case, LO
should really not try to create the document at all, as the signature
operation through NSS must surely have failed.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
