signature is invalid in revision 2 - caused by attachmens

Question

I've just write code that attaches files to PDF Document. I've seen the code in PDFBox page.

PDEmbeddedFilesNameTreeNode efTree = new PDEmbeddedFilesNameTreeNode();

PDComplexFileSpecification fs = new PDComplexFileSpecification();
fs.setFile( "Test.txt" );
InputStream is = ...;
PDEmbeddedFile ef = new PDEmbeddedFile(doc, is );
ef.setSubtype( "test/plain" );
ef.setSize( data.length );
ef.setCreationDate( new GregorianCalendar() );
fs.setEmbeddedFile( ef );
Map efMap = new HashMap();
efMap.put( "My first attachment", fs );
efTree.setNames( efMap );
PDDocumentNameDictionary names = new PDDocumentNameDictionary( doc.getDocumentCatalog() );
names.setEmbeddedFiles( efTree );
doc.getDocumentCatalog().setNames( names );
doc.save("attachedPDF"); 

that, works.

Then, I've attached files, and sign document. result is that -everything works!

Then, I get the signed document (which have attachments), and then sign the document with another attachment (I create revision 2. In the other words, I attach another files to signed document and sign again). The result was that, there was no old file. New file have overwrite old files (signature become invalid too , because of changing hash- that's correct);

So, I've done so that I get oldFiles from PDEmbeddedFilesNameTreeNode and add to new file map.

PDEmbeddedFilesNameTreeNode oldFiles=names.getEmbeddedFiles();
        if(oldFiles!=null){
            Map oldFilesMap = oldFiles.getNames();
            Iterator iterator = oldFilesMap.entrySet().iterator();
            while (iterator.hasNext()) {
                Map.Entry mapEntry = (Map.Entry) iterator.next();
                System.out.println("The key is: " + mapEntry.getKey()+ ",value is :" + mapEntry.getValue());
                efMap.put(mapEntry.getKey(),  mapEntry.getValue());
            }

        }
efTree.setNames(efMap);

that works. but signature is again invalid when I create second revision. I think, The main problem is that, when I add new files to the same file NameDictionary, the hash of the document changes.

So, I think, I should create new NameDictionary in the next revision , may be I am wrong (I must not use existed NameDictionary). I dont understand. what can I do know? what do you think?

By the way, I think that is incorrect for me, for next revision

PDDocumentNameDictionary names = new PDDocumentNameDictionary(doc.getDocumentCatalog());

that's my sample documents

Answer 1

Then, I get the signed document (which have attachments), and then sign the document with another attachment (I create revision 2. In the other words, I attach another files to signed document and sign again).

Whatever your other problems are you have trying this, this undertaking itself already is doomed. Even if you do that as an incremental update, this is not an allowed operation on a signed document.

The operations allowed on previously signed documents are either restricted by specification (in case of certification signatures) or by extrapolation from the certification rules (in case of approval signatures only).

In case of certification signatures (DocMDP signatures), the P value in the DocMDP transform parameters dictionary selects the set of operations allowed on the document:

(Optional) The access permissions granted for this document. Valid values shall be:

1 No changes to the document shall be permitted; any change to the document shall invalidate the signature.

2 Permitted changes shall be filling in forms, instantiating page templates, and signing; other changes shall invalidate the signature.

3 Permitted changes shall be the same as for 2, as well as annotation creation, deletion, and modification; other changes shall invalidate the signature.

Default value: 2.

(section 12.8.2.2.2 in ISO 32000-1)

As you see, attaching files is not among them.

Unfortunately the specification does not clearly say which changes shall be permitted if there is no certification signature (DocMDP signature); therefore, one might be tempted to assume everything is allowed.

Actually, though, current PDF viewers, especially the dominant Adobe Reader, assume differently and extrapolate a set of permitted changes. In case the Adobe Reader these are (cf. this answer for details) the same as for DocMDP with P = 3 plus adding signature fields. (It is assumed that the author did not really consider the signing use case and, therefore, likely forgot adding empty signature fields; otherwise, though, the set of allowed changes was considered apropos.)

Thus, no attaching of files either.

If you want to handle multiple attachments and multiple signatures, you may consider to supplement an already signed PDF by creating a new PDF, adding the original PDF and the new files as attachments (and setting the enw PDF to display the original PDF by default), and then sign the whole construct.

PS: Concerning your actual attempt: When trying to manipulate the already signed document DOC-signed.pdf, you seem to have started by reading and writing it using PDFBox; I assume this because DOC-signed.pdf is not a starting piece of DOC-signed-signed.pdf but that latter document indeed contains the new attachment and the second signature in an incremental update.

This caused the original file to be internally reorganized and the original signature to be broken in the process. You should instead start by creating an identical copy of the file and add the second signature as an incremental update.