Page 21 of "PAdES baseline signatures" specification from
<http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf>
says:
"The Signature Dictionary shall contain a value of ETSI.CAdES.detached
for the key SubFilter."
So in case the UI has the adescompliant checkbox enabled, write that
value instead of the Adobe default.
Change-Id: I69e606a32fb09bebd5e9b25b32150d1b8672f544
This was the last problem to be able to counter-sign Acrobat-created PDF
1.6 signatures unlimited number of times.
Change-Id: I24ab80c8516b6fe9c08d57c08907bec70384dc28
Reviewed-on: https://gerrit.libreoffice.org/30757
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
The problem: an object stream provies obj#1 and obj#2, then an
incremental updates provides an updated obj#1'. Then we look up obj#2,
parse the stored objects on-demand, so at the end when later we look up
the first object, we find obj#1, not obj#1'.
An easy workaround would be to never update already existing objects
from object streams, but that would break when an incremental update
provides an object stream.
Fix the problem by parsing stored objects right after tokenizing the
object stream, and not later, on-demand, when we no longer have the
context what objects should be ignored.
This is needed (but not enough) to correctly append a signature at the
end of a PDF file that has both object streams and incremental updates.
Change-Id: I3c1fae5ac26804c8e8cc1984511f43cfa881c97b
This is especially needed, as we don't bother compressing updated
objects into sections on signing, we simply use a separate section for
each updated object.
Work towards supporting xref streams and incremental updates at the same
time.
Change-Id: Ie9759edbba816991615fafc6602cdd440141b989
With this our xref stream output is close enough to Acrobat so that the
existing signature verifier runs without any problems.
Change-Id: I6eca7966890365759c269b465e4bf4d86d335219
So that when we have a single signature with ID="Signature2", then we
use "Signature3" for the next ID, not "Signature2". (Acrobat uses that ID
for the first signature.)
Change-Id: I7032fbf014184da2a5be24730a92abc32a9a1258
Reviewed-on: https://gerrit.libreoffice.org/30725
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
In case the input document used a PDF 1.5 xref stream, not an old xref
table, then write that as part of the incremental update. Acrobat seems
to require this.
Change-Id: I9f1f73140c26308f8720aa1ffe1b905d0e60ede0
Reviewed-on: https://gerrit.libreoffice.org/30724
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Normally it's a direct dictionary, but it's OK to have it as a reference, and
then the referenced object is a dictionary.
Change-Id: If09edaf23501883be68148e430c42e721ec68247
Reviewed-on: https://gerrit.libreoffice.org/30719
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
In case our xref table doesn't have an entry for "free" object types,
then the table size won't provide a valid id for a next object. That
resulted in creating all new objects with the same ID.
With this, our verifier at least can see the new signature when
appending one to a signed PDF 1.6 file.
Change-Id: Iac39a400706cfcd23dd814d2b81cb8b950c69fc6
Reviewed-on: https://gerrit.libreoffice.org/30704
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
SHA1_WITH_RSA is a signing algorithm, not a digest one, but let's
accept it, so LO on Linux can verify a signature generated by LO on
Windows.
It's annoying that equivalent mapping in NSS is not part of their public
API.
Change-Id: I97186fcc1d118f922e5ee3cb472aa5b52bc4b5ca
And use it in xmlsecurity when signing an existing PDF. This is
especially important on Windows, where the PKCS#7 blob doesn't have an
(unsigned) timestamp.
Change-Id: I4051dc19a43f8f8114d9f4d02309f28d6754e9ae
Now that the mscrypto part of PDFDocument::ValidateSignature() is
implemented it's possible to run these tests on Windows as well,
provided the machine has at least one signing certificate installed.
Also fix a race, where the workdir of the signing test was used by the
pdfsigning test.
Change-Id: I80bbfbb5dc4baa400f9a6b85961883a247b0f22b
The timestamp isn't extracted yet, but the digest match is already
checked correctly and the certificate is exposed.
Change-Id: Ieca002a5c4ca0b96f4dc397c460adb7f88f5ffc7
Reviewed-on: https://gerrit.libreoffice.org/30499
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Adobe Acrobat uses object streams (PDF 1.6) when it signs a PDF exported
from LO (PDF 1.4), with this we can verify that signature.
If the PDF had at least one signature in LO, then the doc is not
upgraded from PDF 1.4, so that was working already.
Change-Id: I54b4447ca965a8ba1ffc69bde228ab6f0bda59ee
This is needed (but not enough) to verify PDF 1.5 signatures. What's
missing next is support for object streams.
Change-Id: I5afec0a77839ffabe0aaa07e367064210535a1a9
This adds support for cross-reference streams (which can be used instead
of plain-text cross-reference tables) + also one stream predictor.
The actual parsed data is still not used, though.
Change-Id: Ia806abd8a97636a1bd25dfdafea377b088800f00
The signature date can be placed as the value of the "M" key, and also
inside the signed PKCS#7 binary. When the later is missing show what's
described in the previous.
Change-Id: Idb40d91adb70486bc1f19d4755a3f8e17d35e9e9
Each pdf signature is mentioned in the Annots key of a page object.
Usually the key contains an array value. But it's valid for the key to
contain a reference to an object, where the object contains the actual
array, so support this case as well.
Also:
- stop parsing name tokens on the first seen '(' character (usually
there is a whitespace between the two, but that's not required)
- handle \0 characters in the last 1024 bytes of the document by using
std::search() instead of strstr().
Change-Id: I3a167b23340230f99f1ae4112473ed10e1c96b09
Previously we only managed to verify a signature in case the certificate
was already imported in the local NSS db. Don't depend on that by
(temporarily) importing certificates from the PDF signature.
Also adjust a test file that failed previously (the test DB has only an
"Alice" cert imported, intentionally sign the file as "Bob" as well).
Change-Id: Id8440acc31915f5a1718ea48129b950bb67e7486
We can mandate that the byte range end is the end of the file for the
last signature only.
With this, signing a previously unsigned file multiple times works, so
add a matching testcase for that as well.
Change-Id: I8fe5482890fca4dab8da6305aa7fc7f60df612d8
We used to just dump all the object offsets in the xref of the
incremental update, but Adobe Acrobat doesn't like that, and considers
that a second signature invalidates the first. If we properly only
mention new and changed objects in the xref, then this doesn't happen.
This requires actually parsing incremental updates, the previous code
depended on LO writing not-really-incremental xrefs at the end of
incremental updates.
Change-Id: Icdd73fe0a3eab16f8c5a62f1355edbb49f6e73de
Reviewed-on: https://gerrit.libreoffice.org/30288
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Similar to the Page object's Annots key, but here we want to append our
reference to the nested AcroForm/Fields key, so that needs more
infrastructure.
This is also needed (but not enough) to be able to sign a PDF document
multiple times.
Change-Id: I4d5e2aa8f49d2181a15cbf7c4e27577fc98b547d
Reviewed-on: https://gerrit.libreoffice.org/30267
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Previously we assumed that the Page object's dictionary has no Annots
key. Now detect if that's not true, and in that case don't just copy of
the whole dictionary (as part of the incremental update), instead copy
it in two steps, so we can insert our reference in the middle.
This is needed (but not enough alone) to be able to sign a PDF document
multiple times.
Change-Id: Ia5bf993320428eef80551e7e9cc7bfb2b858db7f
Reviewed-on: https://gerrit.libreoffice.org/30257
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
The pdfdocument problem is present only on 32bit.
The pdfsigning problem is present on RHEL6, but not on RHEL7, for some
reason NSS fails to parse the provided profile (generated by a bit newer
NSS). Just return early in that case, we want to test the PDF code
there, not NSS.
Change-Id: I1123865d4b2176676a8fdaf648222fda8ca0b923
Reviewed-on: https://gerrit.libreoffice.org/30229
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
It's not exactly clear how one should guess what was file end before
signing, for now assume the followings:
- the file ended with a %%EOF, an optional \r, and a \n
- the number of incremental updates is the same as the number of
signatures
When the later is not the case, don't attempt to remove the signature.
Change-Id: I203a7b0605fc061ec6aacfde3a8eedc4736379f2
Reviewed-on: https://gerrit.libreoffice.org/30140
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
"In addition, the added trailer dictionary shall contain a Prev entry
giving the location of the previous cross-reference section."
(ISO-32000-1, section 7.5.6). Add it, even if it seems Adobe Acrobat can
live with not writing it.
Change-Id: I1f53e75ebe7dba4b45b3cf1908b2d3b031ef6b02
Reviewed-on: https://gerrit.libreoffice.org/30133
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
The use case is different in vcl and xmlsecurity: vcl creates a new PDF
(possibly with a signature), while xmlsecurity signs an existing PDF,
but this part can be shared between the two.
So far in vcl only the nss part is moved, not touching mscrypto yet.
Change-Id: Ie776f622c1a4a3a18e79e78f68722a2fa219a83b
Reviewed-on: https://gerrit.libreoffice.org/30063
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
The VCL pdf export writes a space after the in-use entry, and turns out
Adobe Acrobat starts to "repair" the file if there is no such space.
Which means the signature is validated against the repaired document,
resulting in a "The signature byte range is invalid" error message,
hiding the root cause.
Not that ISO-32000 7.5.4 "Cross-References Table" would mention the need
for such whitespace at the end of the lines.
Change-Id: I165b57809550f184f374c00f28426a3cd813c63f
I plan to use this for signing purposes, but so far what's implemented
just writes out an incremental update at the end of the file, without
actually updating much (just an unreferenced appearance object).
Change-Id: I1cb40430ade6af0a25ff914ba4df670a77fcf457
For ODF signatures we require that all streams of the storage are
signed. The PDF equivalent of this is to ensure that the byte range is
the entire file, including the signature dictionary but excluding the
signature value itself.
Change-Id: Ie47f42913e2aa960f35079eb981768cd47fb9f92
Reviewed-on: https://gerrit.libreoffice.org/29890
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Currently the only non-ZIP-based import filter that declares the
SUPPORTSSIGNING flag is PDF, so if we get a stream without a storage, we
assume it's PDF.
If any other non-ZIP-based format would add that flag in the future,
that would mean PDFDocument::Read() gets that as an input. That means it
makes sense to at least check the file header early in the tokenizer,
and return early when that doesn't match.
Change-Id: I8760d130c4211f37be705e03b22814825042cac8
Reviewed-on: https://gerrit.libreoffice.org/29888
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
