I have a theoretical question about PAdES. I want to know if it is possible to revoke a signature in PDF or remove it?
I don't know what exactly you technically mean by revoking a signature.
But it clearly is possible to remove a signature: An integrated PDF signature usually consists of a signature form field with a value that contains a CMS signature container.
You have the choice of either removing only that value or the whole field with the value.
The former option leaves an empty signature field, which can easily be used for a new signature with a visualization at the same location as your original signature (if it has any to start with).
The latter option removes your signature completely.
Two caveats, though:
If you don't merely want the signature not to appear anymore, make sure that
you don't save this edit as an incremental update - if it was done as an incremental update, the document version with your signature could easily be restored;
you don't merely remove the reference to the the value from the signature field but that you actually clear the value object - the signature value object might be referenced from other locations in the PDF, too, so if you don't clear it, its information might remain accessible inside the PDF.
If your PDF contains multiple signatures or document timestamps, and if the signature you want to remove is not the newest one, manipulating it will break at least all newer signatures / time stamps. This is due to the way multiple signatures are applied to PDFs:
As you can recognize in this sketch, the bytes signed by newer signatures contain all older signatures.
In such a situation, therefore, don't only implement "remove a single target signature" but instead "remove all signature starting at a single target signature".
For some more technical backgrounds on integrated PDF signatures cf. this answer and documents referenced from there.
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.
Preamble: I am not trying to merge different PDFs.
I was wondering. Does the signature of a PDF modify the signed portion of the document or is it appended to some other section of the file?
If the signed portion of the document does not include the signatures, it should be possible to transfer the signature of a document to another file containing the exact same document:
In practice, sending identical PDF to person A and B or signing, I get PDF[A] and PDF[B] back, I can then transfer signature of B to PDF[A], getting PDF[A, B].
Is that theoretically possible? Has someone already tried it?
First of all, I assume you mean a special case of electronic signatures which often are referred to as digital signatures: These signatures allow verification using the hash of the bytes signed by the signature.
Furthermore, I assume you mean the interoperable types of digital PDF signatures as specified in the PDF specifications and related documents with the extra condition that the signed bytes encompass the whole signed revision except only the placeholder for the signature container. (The PDF specification allows to sign less but common validators forbid that.)
Under these assumptions:
No, what you want to do is not possible.
Signing does not merely append a signature container somewhere; instead it first extends the PDF with some extra objects to represent the signature and hold its signature container, and then it creates a signature for that prepared PDF, not for the original one.
The preparations by two different persons A and B most likely are not identical, so the ranges signed by them differ.
Furthermore, real "parallel signing" of the identical content is not possible in interoperable digital PDF signing, only a consecutive, serial signing. Thus, if you have a PDF with multiple signatures, the bytes signed by the second one actually include the first signature:
Thus, you cannot simply transfer the signature of B as a second signature to the PDF already signed by A because a second signature has to sign something completely different than a first one.
(That being said, there is a larger signing software house whose software used to create signed PDFs with multiple SignerInfos in a single signature container; this is forbidden in the PDF specification for interoperable signatures but a situation validators seldom check for. During validation Adobe Acrobat here only validated the first SignerInfo; some other software only validated the last; in the end this only caused a lot of confusion.)
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 am using PKCS#1 2.0 (OAEP) standard (signature with appendix), but there are some issues not clear to me.
What is the physical object that is beeing signed? I know it's hash function value and so on (I do know the algorithm), but is it calculated from the binary fform of the file, no matter what is the content?
What is the physical result of signing? A file containing the signed hash? Should this file be placed in a specified location? What is the format or extension of such thing?
If I have several files that I want to sign, should this operation be performed separately for each of them? Or should they be concatenated? Once again - what is the result of such operation (file?) ?
PKCS#1 is sometimes called 'raw RSA' and is a low-level cryptographic primitive: it doesn't work on files and doesn't produce files, it works on raw data: input is a number smaller than the public key and output is a number of the size of the public key (e.g. 1024 bit for RSA-1024).
If you want a signature file, you probably want to use PKCS#7/CMS format, as that's the most used signature format both for attached and detached signatures (even signatures in PDF files are usually PKCS#7 envelopes actually).
PS: I don't know much about OAEP, but from what I read it seems to be a padding scheme (something you do to data before the raw signature) so my argument should be still valid.