I am verifying a PDF with two signatures (Adobe Acrobat), both valid. One of them has a text say "cambio(s) varios" (my Adobe Acrobat is in Spanish) translating to Enghish "change(s) various", my question is I don´t know what it mean. Signatures are valid and the PDF is correct.
Thanks in advance
First of all, to outline what this is about, the Adobe Acrobat Reader signature panel looks like this for the document at hand
and the question is about the
1 Miscellaneous Change(s)
in-between.
According to Adobe Documentation
In a number of documents Adobe enumerates possible modification entries and characterizes "Miscellaneous Change(s)" like this:
Miscellaneous: Some changes which occur in memory or cannot be explicitly listed are labelled miscellaneous.
(e.g. in "Digital Signatures Workflow Guide for the Adobe® Acrobat Family of Products")
Now this documentation obviously is no help at all...
According to Adobe Acrobat
Fortunately Adobe Acrobat can be asked to show "Document Integrity Properties":
(Adobe Acrobat 9.5 output on "Signature Properties" - "Legal" - "View Document Integrity Properties...")
I assume it is this detail that makes Adobe Reader warn about miscellaneous changes.
In Your Document
Looking for a transfer function use in your document one quickly indeed finds one in a ExtGState resource of page 1:
The TR entry in that graphics state dictionary sets the transfer function here.
Interestingly the transfer function used is the Identity function! I assume that in most normal use cases setting the transfer function to Identity changes nothing...
What to Do
Thus, I would propose you change your original document creation to not include transfer functions, in particular not Identity transfer functions. Alternatively pre-process your documents before applying the first signature and remove such functions.
Related
I want to place same externally signed signature container (signature value) at multiple places in a PDF.
I have referred the page 'How to place the Same Digital signatures to Multiple places in PDF using itextsharp.net'.
While working with the above mentioned work-around, I observed that whenever I tried to place multiple signatures on single page like 4-5 times, it never worked. Always shows only one valid signature field and other fields as unsigned (unsigned PDF form fields). So couldn't understand the problem.
Now I wanted to know whether any reference material is available to see how PdfLiteral and PdfIndirectReference works? I have gone through the itextsharp reference document but couldn't get enough information. In addition to this is there any limitation on how many annotations/signature fields one can add in a PDF?
And If I have to use BlankSignatureContainer and MakeSignature.SignDeferred then how the signature will get attached to all the fields because in,
MakeSignature.SignDeferred(pdfreader, "Sig", output, externalcontainer)
we have to pass only one signature field name.
Thank you.
You are asking for something of which mkl wrote:
Beware: While this procedure creates something which does not violate
the letter of the PDF specifications (which only forbid the cases
where the same field object is referenced from multiple pages, be it
via the same or via distinct widgets), it clearly does violate its
intent, its spirit. Thus, this procedure might also become forbidden as part of a Corrigenda document for the specification.
Actually, what you are asking does violate the specification. See section 12.7.5.5 of the ISO standard for PDF:
Allow me to repeat the last line of this screen shot:
signature fields shall never refer to more than one annotation.
There is a shall in this sentence, not a should. A should isn't normative. It means that you should or shouldn't do something, but that you are not in violation with the spec if don't or do. Not respecting results in a PDF document that is in violation with the PDF specification, and that in the strict sense isn't a real PDF file.
That is a path you don't want to go, because being in violation with the PDF specification voids your right to use a series of PDF patents owned by Adobe. Adobe owns patents that can be used by everyone for free (perpetual, non-exclusive, royalty-free,...) on condition that you respect the ISO specification.
For that reason, please do not expect an answer to your question, except for the recommendation to abandon your requirement. PDF viewers that comply with the PDF specification won't expect a single signature to be placed at different locations because that's not allowed by the spec, so even if you would adapt your software to create more than one widget annotation / appearance for a single signature field, there is no guarantee that a PDF viewer will understand what you're trying to do.
I was going through the official PDF spec. I came across a digitally signed PDF here. While I was analyzing its catalog dictionary, I saw this:
The digital signature is in the form of a signature field, which specifies the byte range of the content to which the signature applies. Any content added on top of it, like annotation, notes, etc. should go in as incremental updates, so the validity of the original content should continue to hold true (excluding direct editing of the content, like changing the Sample word to Sample2). However, when I open the file in Nitro, add some highlight or notes to it, save it and open it in Acrobat, it now says that the signature is invalid. Which brings me to my questions:
Why is Acrobat showing it as invalid? The signature field does not enforce prevention from adding incremental updates, why exactly is it invalid?
Why is Acrobat not allowing addition of notes or highlights? Nitro allows it, for example. There is no Perms dictionary which would specify a DocMDP level restriction, so what exactly it is that Adobe is interpreting as a document level lock?
As already explained in my answer to your previous question on this topic, the file you call "the official PDF spec" is everything but. The official PDF specification is ISO 32000-1 (since 2008) and ISO 32000-2 (the 2017 update).
That answer also points out the origin of the P entry in the FieldMDP transform dictionary your sreenshot shows:
It comes from the Lock dictionary of the same signature dictionary and is defined in Adobe supplement to ISO 32000, extension level 3, (which being from Adobe unfortunately indeed references the PDF Reference 1.7 instead of ISO 32000-1):
P number *(Optional; Extension Level 3) The access permissions granted for this document. Valid values follow:
1, no changes to the document are permitted; any change to the document invalidates the signature.
This extension to ISO 32000-1 has been added to the standard ISO 32000-2.
Thus,
Why is Acrobat showing it as invalid? The signature field does not enforce prevention from adding incremental updates, why exactly is it invalid?
Because it does enforce prevention of any change, see above.
Why is Acrobat not allowing addition of notes or highlights? Nitro allows it, for example. There is no Perms dictionary which would specify a DocMDP level restriction, so what exactly it is that Adobe is interpreting as a document level lock?
Because Nitro (at least the version you tested) does probably merely support ISO 32000-1 but not Adobe's extension 3 to it let alone ISO 32000-2.
My company has requested a Java web service implementation of extracting data from PDF forms to initiate straight through processing capabilities for client operations using Apache PDFBox. Easy enough. The tough part is that forms are being submitted from clients of my firm on behalf of end customers, but the end customer signature has to be validated.
The business case for signing these forms is through informal electronic signature (digital representation of a wet signature) processes like the signature "stamp" in Adobe Reader with an image of the customer's signature, or touch screen drawing on an iPad. So far, I have been unable to consistently validate this type of signature, and even been unable to consistently maintain the PDF state such that it can still be read by PDFBox after this type of signature ceremony.
Validating signatures through the digital signature form field is trivial, and I have communicated that to our business. However, since the signer in those cases is typically the owner of the digital cert on whatever machine is being used and the assumption is that most of these interactions will take place in the client office.
I've got a few choices here:
Figure out how to identify electronic signatures consistently and reproduce the lossless signing ceremony for client education.
Make a change to the digital signature form field if possible to accept electronic signatures, if that's even possible.
I have a slight workaround using the most recent release of Acrobat in putting an image form field over the signature area, which works great except for one thing: all the software I've tried reads this form field type as a button. Is there any way to force it to recognize an image, or any PDF reading software that is more up to date and can detect those fields?
I would like to upload a couple sample PDFs, but of course they're all company proprietary information. Suffice it to say that we don't have any wizards doing amazing things with the forms... they are all your basic AcroForms and I'm trying to figure out how to configure the signature area.
Thank you.
Concerning your actual question:
I have a slight workaround using the most recent release of Acrobat in putting an image form field over the signature area, which works great except for one thing: all the software I've tried reads this form field type as a button. Is there any way to force it to recognize an image, or any PDF reading software that is more up to date and can detect those fields?
Any PDF reading software that recognizes those fields as a button is up-to-date, at least in that respect, because... there are no "image form fields" in the PDF file format!
Some PDF creators emulate image form fields using a button form field which by means of JavaScript gets the behavior of an image form field. This emulation is incomplete, of course. In particular the image in such a field is not the value of the form field but merely its appearance.
Thus, if you want to implement reading the value from such an emulated image form field, you have to extract the appearance of the button.
Some remarks on the whole scenario:
... the end customer signature has to be validated.
The business case for signing these forms is through informal electronic signature (digital representation of a wet signature) processes
In contrast to certificate based digital signatures you can hardly do anything with such signatures that deserves to be called "Validation".
Ok, you can look for an image in the PDF in some emulated image field, but you have no guarantee that the person whose wet signature can be seen on that image backs the data in that form let alone has indeed signed it personally. Just as likely someone else simply has scanned that person's signature from some different hand-signed document and filled the form using that scan...
So far, I have been unable to consistently validate this type of signature
It should be possible to extract most such wet signatures
either as bitmap images added directly or indirectly to the page content,
or as bitmap images added directly or indirectly to some annotation appearance (e.g. a button),
or as an InkList or Path of an Ink annotation,
or as the Vertices or Path of a PolyLine annotation.
In case of bitmap images don't forget to also extract the image mask if applicable. Numerous applications fill the base image with the pen color and contain the actual signature graph in the mask.
and even been unable to consistently maintain the PDF state such that it can still be read by PDFBox after this type of signature ceremony.
That sounds like a misbehavior of the software that executed that signing ceremony. Unless you share examples for that, though, one can hardly help you analyze the problem.
I've two pdf documents certified (signed and validated with the same mechanism based on Itext 7 ) and when i use adobe reader DC to check their validity, only one has the green mark.
the good one:
https://1drv.ms/b/s!AkF6t4TavwMvgxWaidlUqvPvHH1r
the bad one:
https://1drv.ms/b/s!AkF6t4TavwMvgxQCMdGY61S1EvUh
Regards
David L
This is not an Adobe bug, it's a feature. (And an iText bug)
When Adobe performs the cryptographic validation, it will also perform additional checks to see if a signature was attacked or not. It analyses several suspects and if that analysis turns out negative, Adobe will show you an error message. This is Adobe misreporting the analysis and validity. However, there is a work around for these hidden requirements.
First of, iText was used in non-append mode to modify the document:
Unfortunately, in specific cases iText 7, when used in non-append mode, introduces changes that are disallowed by the specification. The issue is that iText introduces subsections. That is something the specification allows you to do, but this is explicitly disallowed for the first revision:
Section 7.5.4 Cross-Reference Table
[...] For a file that has never been incrementally updated, the cross-reference section shall contain only one subsection, whose object numbering begins at 0. [...]
Below you'll find the xref of the first revision after iText was used in non-append mode, every colored rectangle is a new subsection. To be compliant there should only be one rectangle.
This will be fixed in the upcoming 7.0.4 release, planned for end of July.
Since multiple other tools validate these two documents without any issue ...we may think that's an adobe reader bug.
In particular as Adobe Acrobat is itself is torn:
I have a simple one page PDF document.
Using Adobe Acrobat X (10.1.4), I added 2 graphical annotations (Ink). So far so good.
Now I opened the document in Notepad++ to inspect it. Everything seemed fine. There was the annotations array, and both annotations. All good.
Then I randomly entered one space char " " in the xref table to make the document "invalid".
When I opened it in Adobe Acrobat X (Version 10.1.4), it was capable of displaying everything like it was (apparently after automatically repairing the document) and asked me then, wether I would like to save the new version to disk. I did.
Now I opened the document in Notepad++ again, just to find, that it looks completely different, than it looked like before I did the modifications.
The most weird thing is, that most of the objects just vanished from the document! There were still references to them, but the actual objects are not there.
In addition there were a bunch of flate-decoded stuff.
Is it possible, that the Adobe Acrobat reader not only compresses streams, but also whole objects including there "x y obj" and "endobj" tags?
As of PDF 1.5 object streams have been introduced to the PDF format, cf. section 7.5.7 of the current PDF specification ISO 32000-1:2008:
An object stream, is a stream object in which a sequence of indirect objects may be stored, as an alternative to their being stored at the outermost file level.
NOTE 1 Object streams are first introduced in PDF 1.5. The purpose of object streams is to allow indirect objects other than streams to be stored more compactly by using the facilities provided by stream compression filters.
By allowing Adobe Acrobat to save the repaired version of your document, you implicitly allowed it to do that in its perferred format which due to compactness uses object streams