Security issue, merge signed documents results in a new pdf witch is signed

[ikerib]

Hi, we are using this project a lot in our city council, thanks!

We see a problem: If we take two different pdf which are digitally signed and merge them, the result is a new document with the two signatures. Which is not correct, it should be a new document without signatures.

Thank you!

[kintaro1981]

I work for an Italian municipality and this is going to stop us to is it. 🙁

[Frooodle]

Should this be a flag like on/off for this or should it always remove the signatures? Sorry for getting to this so late

[ikerib]

The resulting pdf can’t be signed. Someone can add pages to a signed document… El 4 ene 2024, 18:33 +0100, Anthony Stirling @.***>, escribió:

Should this be a flag like on/off for this or should it always remove the signatures? Sorry for getting to this so late — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[pr-apes]

@ikerib,

many thanks for your report. Could you please elaborate it further?

Sorry, but this is an image of a PDF doc signed with Acrobat (just in case it might help, there is a sample certificate for testing purposes)[^test]

What you have on the page is what many people call a “visible signature”. But the digital signature is what is displayed on the right (signature) pane.

Merging documents with Stirling-PDF adds both the annotation signature (the image displayed on the page) and the digital signature (displayed on the signature pane).

BTW, the signed document I use as sample in the next images (from the Spanish gazette) is signed without visible signature (as many PDF documents are). This is totally OK.

What do you want to be removed, just the digital signature or the image on the page?

Just a comment, since it is an image (or it is displayed as such), faking what people call a “visible signature” is an extremely simple task.

So adding pages to a signed document is possible, but it is not so easy without invalidating the signature (and it is impossible without amending the document [adding data outside the range of signed data]).

@Frooodle, in any case, the signature object must be removed when merging documents, because otherwise signatures will be corrupted (as it cannot be otherwise [if signed data have changed, signature must be different or just invalid).

This is a valid signature from a document which I took as a sample:

Merging this document with a copy of the same document, gives two invalid (corrupt) signatures:

Signatures should be removed. Otherwise the resulting document would seem to be a forged one (because of the signatures).

Just in case it helps.

[^test]: Just in case you need it, use JustCheckingIt.pfx.txt (removing the .txt extension first). Password is ABBAabba.

[pr-apes]

@Frooodle,

on a second thought, it may be wiser to remove always both signature object and signature annotation (digital and “visible” signature) from signed documents in the merged output.

Otherwise, this may lead to confusion (the merged document may be wrongly considered as digitally signed).

I hope it helps. Many thanks for your help.

[Frooodle]

Removed a visual signature is not always possible as the visual isnt always linked.

Would i be acceptable to remove digital but keep visual in this usecase?

[Frooodle]

Also as a spinoff from this but probably good to have a standalone method to remove all signatures regardless #1138

[pr-apes]

Removed a visual signature is not always possible as the visual isn't always linked.

Would it be acceptable to remove digital but keep visual in this use case?

In my opinion, it is essential to remove the “visible signature” in all possible cases.

I have made an experiment of signing a document with Acrobat (and the already provided test certificate).

At least with Acrobat, there is a widget annotation with entry /FT /Sig that when detached from its references (moving object from its number to a non-referenced number[^detach]), no “visible signature” will be displayed.

This is consistent with what the publicly available PDF spec tells about “visible signatures” (if needed, I can elaborate further on this).

So, removing the widget annotation with entry /FT /Sig seems to be the way to remove “visible signatures”.

In other cases, I cannot imagine how a “visible signature” cannot be linked to a digital signature.

Also as a spinoff from this but probably good to have a standalone method to remove all signatures regardless (#1138).

This may cause problems to so many people that have a hard time to see that a “visible signature” may not be a digital signature at all.

Sorry, I have no doubts that your are moved by best intentions, but think twice before this implementation (not to give ideas on how to forge documents).

[^detach]: In my sample, the widget annotation was 23 0 obj. Renumbering it to 1123 0 obj (since there is no 1123 0 R), does the trick.

[ikerib]

in our case, we think that both elements should be deleted.

This is the problem:

• Person A creates a pdf and signs it => Document A (And it has its purpose, another procedure).
• Person B creates a pdf and signs it => Document B (And it has its purpose, another procedure).

Now, we have a 3º procedure, in which we attach those two pdf files with sterling, the result should be without any signature, because this third document has not been signed neither by person A nor by person B as a whole (they have only signed their part) and this can bring legal responsibilities.

[pr-apes]

in our case, we think that both elements should be deleted.

Many thanks for explaining your use case, @ikerib.

I think both signature and its visible element should be deleted when a signed document is merged (in any case).

This is the problem:

* Person A creates a pdf and signs it => Document A (And it has its purpose, another procedure).

* Person B creates a pdf and signs it => Document B (And it has its purpose, another procedure).

Now, we have a 3º procedure, in which we attach those two pdf files with sterling, the result should be without any signature,

I'm afraid it is a really bad idea to add contents to an already signed document.

From your description, I cannot see the gain in merging those signed documents.

Wouldn't it be possible to merge the unsigned versions of those required documents?

For the case you describe (having to merge already signed documents), you could deploy a PDF tool that doesn't copy annotations (speedata Publisher would be one of the tools).

Excuse the following comment, but I think it may be relevant. In any case, I'm not being picky.

Attaching files (embedding them in) to a PDF document is the way to include those files, without modifying them at all.[^sample]

[^sample]: Here you have a sample document with three embedded documents (documents are linked and they have to be browsed with Acrobat [or Firefox, but it won't display any info about signatures]).

Actually, the embedded document is only one, but embedded three times (it makes no difference for your case).

The sample PDF was generated with [_speedata Publisher_](https://github.com/speedata/publisher) (mentioned before).

@Frooodle, maybe attachments (embedded files) would be an interesting feature to add to Stirling-PDF.

Because this third document has not been signed neither by person A nor by person B as a whole (they have only signed their part) and this can bring legal responsibilities.

Sorry, but I'm afraid that PDF signatures may not work exactly that way.

PDF documents are signed as a whole (and not partially).

If you merge signed documents, it is fairly easy to end up invalidating signatures.

Liable should (and I think would) be the one creating such a merged document, not any who previously signed complete documents.

If you need more than one signed documents in a single PDF document, proper embedding in the PDF document is the way to go.

Let us know whether this might fit your needs.

BTW, if you feel more confident (and @Frooodle doesn't have problems with that), we can discuss the issue in Spanish.