0

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

grep
  • 5,465
  • 12
  • 60
  • 112

1 Answers1

2

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.

Community
  • 1
  • 1
mkl
  • 90,588
  • 15
  • 125
  • 265
  • As I understand, you mean that: First of all , I must add attachments to the signed document as an incremental update (which will create new PDF document). And then add the second signature to the document as an incremental update too. is it correct? – grep Aug 15 '13 at 09:07
  • No, not exactly. First of all, **adding an attachment to a signed PDF does not work, it always breaks that first signature** because adding attachments is never a permitted change after signing. But even if it was, you did something else wrong because you unnecessarily changed the original signed document. – mkl Aug 15 '13 at 10:00
  • Finally, your answer is that: If I have signed document with an attachment. There is **no way** to add second revision 2 to this document **with** another attachments. (document with 2 signature, each revision it's attachment). am I correct? :-) – grep Aug 15 '13 at 10:37
  • Right, as long as you want the original signature to remain valid. – mkl Aug 15 '13 at 11:24
  • And while we're at it, there's a reference in PAdES-Part 5 that DocMDP could be used to modify embedded XML later, even though DocMDP should in theory not allow changes to embedded files. – jmd Mar 19 '14 at 14:29
  • @mkl I wonder what you mean by setting the original embedded PDF to be displayed by default. I don't believe the 'ViewerPreferences' entry can really be used for that, it can select select a page and zoom level, not an embedded document, right ? And while we're at it, there's a reference in PAdES-Part 5 that DocMDP could be used to modify embedded XML later, even though DocMDP should in theory not allow changes to embedded files. – jmd Mar 19 '14 at 14:57
  • @jmd *reference in PAdES-Part 5 that DocMDP...* - one has to decide whether one wants to support ISO 32000-1 as is or ISO 32000-1 updated by PAdES-4 and/or PAdES-5; in the latter case the interpretation of DocMDP will differ as described in PAdES. – mkl Mar 19 '14 at 15:38
  • @jmd *I wonder what you mean by setting the original embedded PDF to be displayed by default.* - I was thinking about what Adobe calls portfolios: You can e.g. create the new PDF as a portfolio which displays the original PDF in its preview area by default. – mkl Mar 19 '14 at 15:47
  • @mkl yes, there's the explicit PAdES change in -4 which says LTV is allowed with P=1, but the text in both -1 and -5 that says changes to *embedded* file are possible is not further clarified. Thanks for the portfolio info, I didn't know they had that option. – jmd Mar 19 '14 at 17:42
  • I have to admit i have not yet dealt with part 5. Maybe one should ask etsi to clarify this. Our maybe the committee for the upcoming pdf-2 might be asked to say something. .. – mkl Mar 19 '14 at 17:50