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.
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 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.
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 PDF document which is supposed to be PDF/A conform, but the metadata states that it is a PDF-1.3 document. Can a PDF-1.3 document be conform with the rules of PDF/A?
Note that the first version of PDF/A is based on PDF-1.4 - hence my confusion.
Thanks in advance!
The PDF/A-1 specification (ISO 19005 part 1) states
5.1 General
This part of ISO 19005 defines a file format for representing electronic documents known as “PDF/A-1.”
Conforming PDF/A-1 files shall adhere to all requirements of PDF Reference as modified by this part of
ISO 19005.
"PDF Reference" previously is defined as
4 Notation
...
For the purposes of this part of ISO 19005, references to the “PDF Reference” are to PDF Reference: Adobe
Portable Document Format, version 1.4, 3rd ed., as amended by Errata for PDF Reference, 3rd ed. [...]
Section 5.1 continues:
Neither the version number in the header of a PDF file nor the value of the Version key in the document catalog dictionary shall be used in determining whether a file is
in accordance with this part of ISO 19005.
As these are the only metadata that can state that it is a PDF-1.3 document, this statement of version MUST NOT be used in determining whether a file is PDF/A-1.
Thus, concerning your question:
stijndg> Can a PDF-1.3 document be conform with the rules of PDF/A?
Yes, it can.
It merely has to
adhere to all requirements of PDF Reference, version 1.4 and
adhere to the requirements of ISO 19005 part 1 of Level A conformance or Level B conformance.
Furthermore Section 5.1 recommends:
Features described in PDF specifications prior to Version 1.4 which are not explicitly
described in PDF Reference should not be used.
But "should" indicates that this is a recommendation, so if for some reason the use of such features cannot be prevented, this does not keep a PDF from being PDF/A conform.
Is it possible to stop any annotations and / or signatures being added after a PDF has had LTV added using LtvTimestamp?
I've tried adding PdfSignatureAppearance.CERTIFIED_NO_CHANGES_ALLOWED on the initial signing but adding LTV invalidates that signature.
Any help would be greatly appreciated.
In general
First of all, no, it is not possible to stop any annotations and / or signatures being added after a PDF has had LTV added in general because one can easily program a utility adding annotations or signature fields ignoring permissions.
So let's assume we are talking about tools respecting permissions. But even in that case the question is according to which specification the permissions are interpreted.
Permissions as in ISO 32000-1
What changes are or are not allowed in ISO 32000-1, has been described in this answer.
ISO 32000-1 does not know about PAdES-4 LTV information or document time stamps. it sees the latter as normal signatures using a non-interoperable format and has no interpretation for the former.
Thus, if the initial signature is a certification signature "with form fill-in and digital signatures allowed" and there already is exactly one empty signature field, you may add a document time stamp in that empty field and no later signatures or annotations are allowed.
Unfortunately, though, adding the validation related information (which is one major reason for LTV'ing after all) strictly speaking is not allowed in any certified document.
Thus, a tool interpreting permissions strictly according to ISO 32000-1 can be persuaded not to allow signature or annotation additions after the document time stamp. But such a tool likely is not your target tool as it neither allows LTV VRI nor is it likely to be able to handle document time stamps let alone interpret the whole as a "signed document with LTV".
Permissions as in ISO 32000-1 modified as per PAdES part 4
PAdES part 4 changes the situation by properly specifying document time stamps and LTV VRI, and by ruling
DocMDP restrictions (see ISO 32000-1 [1] clause 12.8.2.2) shall not apply to incremental updates to a PDF document containing a DSS dictionary and associated VRI, Certs, CRLs and OCSPs. [...]
When evaluating the DocMDP restrictions (see ISO 32000-1 [1], clause 12.8.2.2) the presence of a Document Timestamp dictionary item shall be ignored.
(ETSI TS 102 778-4 V1.1.2 "Annex A (normative): ISO 32000-1 LTV Extensions")
Thus, if a document which is
either "Certified with no changes allowed" with LTV validation related information and a document time stamp added
or "Certified with form fill-in and digital signatures allowed" with LTV validation related information and a document time stamp added without any remaining empty signature fields (probably enforced by field locking)
is processed by a tool interpreting permissions according to ISO 32000-1 modified as per PAdES part 4, this tool will:
accept the VRI addition and properly handle them and the document time stamp, and
not accept or create further signatures or annotations.
But it will accept further VRI and document time stamp additions!
Permissions as in ISO 32000-2 (draft)
The latest draft I have available here essentially integrates the PAdES part 4 additions. Thus, the situation is essentially the same as in case of ISO 32000-1 modified as per PAdES part 4.
The new option to change the MDP permissions as part of field locking may be used to have a more lax situation before adding the document time stamp.
Adobe Acrobat Reader DC V 2015.007.20033
How this software interprets permissions, has yet to be analyzed...