If I understand you correctly, your solution consists of removing both the
modification date and the ID.
The ISO PDF spec says about ModDate:
(Required if PieceInfo is present in the document catalogue;
otherwise optional; PDF 1.1) The date and time the document
was most recently modified, in human-readable form (see
7.9.4, “Dates”).
If present, PieceInfo in the catalogue contains a page-piece dictionary
associated with the document which may be used to hold private conforming
product data.
Thus, if you have a PDF containing a PieceInfo in the document catalogue,
removing the modification date makes it invalid. Even though chances are no
program will complain about that, it is invalid.
The ISO PDF spec says about ID:
(Required if an Encrypt entry is present; optional otherwise;
PDF 1.1) An array of two byte-strings constituting a file
identifier (see 14.4, "File Identifiers") for the file. If
there is an Encrypt entry this array and the two byte-strings
shall be direct objects and shall be unencrypted.
NOTE 1 Because the ID entries are not encrypted it is possible
to check the ID key to assure that the correct file is being
accessed without decrypting the file. The restrictions that
the string be a direct object and not be encrypted assure that
this is possible.
NOTE 2 Although this entry is optional, its absence might
prevent the file from functioning in some workflows that
depend on files being uniquely identified.
NOTE 3 The values of the ID strings are used as input to the
encryption algorithm. If these strings were indirect, or if
the ID array were indirect, these strings would be encrypted
when written. This would result in a circular condition for a
reader: the ID strings must be decrypted in order to use them
to decrypt strings, including the ID strings themselves. The
preceding restriction prevents this circular condition.
In a generic signing context the files to sign generally are not encrypted,
therefore that likely wont be a problem for you.
If on the other hand the documents you sign contained ID entries to start with
and your customers actually use these ID values, you might destroy their
document flows; this might render them unhappy.
Removing document ID information generally is quite a bad idea.
Additionally, if your customers expect you to generate PDF/A output documents
if the input documents were PDF/A (let alone you promised them this), you might
be in trouble:
The ISO PDF/A spec says:
The file trailer dictionary shall contain the ID keyword.
If a conforming file is changed in any way, even if only
by the addition of an xmpMM:History entry as described
in 6.7.7, then the changing identifier part of the file
trailer dictionary ID key should be modified as described
in PDF Reference 9.3.
If you want to follow the recommendations on digital signatures in PDF/A
documents by the PDF/A Competence Center, you might also want to consider the
following:
PDF/A conformant signature tools should record the signing
process as an action in the xmpMM:History entry in the
document's XMP metadata. The softwareAgent field should be
specified, and the action field should be specified as signed.
The mandatory when field does contain a timestamp, too, implying the same kind
of problem as you had with ModDate.
Regards, Michael.
-----Original Message-----
From: amarianoelaide [mailto:[email protected]]
Sent: Thursday, April 02, 2009 9:50 AM
To: [email protected]
Subject: Re: [iText-questions] Hash computation problem
Thank you again Paulo.
Yes it's true, I need to realize a deferred signature.
So I tried to "adapt" iText to my needs and I modified the src code.
The differences between two consecutive hash computations are caused by:
- the file ID (md5 of date, free space and a sequence)
- the ModDate that it's impossible to eliminate also using this code (while
it's possible for CreationDate):
HashMap<String, String> info = (HashMap<String, String>)pdfReader.getInfo();
info.put("ModDate", null);
Now that I have reached my goal, I'd like gently to know which are the
problems that these changes can cause?
Obviously I won't be aligned with future versions of iText but will my pdf
files be valid and
will they respect the Adobe standards (Acrobat doesn't find anything wrong)?
10x
--
View this message in context:
http://www.nabble.com/Hash-computation-problem-tp22801988p22842675.html
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
------------------------------------------------------------------------------
_______________________________________________
iText-questions mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.1t3xt.com/docs/book.php
