No u don't. See how that's causing u issues.
Marek: keep in mind what disarm really does: given an object/document (in this case PDF) it tears apart the document and re-builds it, leaving out the potential attack vectors. The protection it affords is via re-structuring and re-building the document, NOT by "searching" for malicious content based on some set of rules, or signatures. This is how you get the "day zero" protection.
With that in mind, now think about what you are asking for: preserving the digital signature to a file that is significantly different than the one that was originally signed. Even if this were possible (e.g. SMG had access to the signer's key), doing that would amount to "digital fraud", just as much as if I had a paper document notorized, or filed at the local courthouse, then modified it, post recording, and represented it as if it were the same as the notarized/recorded copy, it bypasses/subverts the whole point of the digitially signing a document in the first place. ("I" composed and sent this message and take responsiblity for it's contents).
I know this all comes across as "theory", and we all have more practical considerations (i.e. help-desk tickets of users complaining that things arrived "un-signed"), so might I suggest you open an enhancement request to add a "signing" or "proxy signing" feature to the SMG product?
As a follow-up on my own post above, I found an outstanding article at
which re-enforces the point I was trying to make above regarding "preserving" digitial signatures in content that has been altered. While it is "do-able" (at least until vendors fix security flaws in their PDF viewers), it actually represents and attack vector and is NOT desirable behavior. Hopefully you can use this information to convince your users. Also, as I thought aobut this more, it occured to me that rather than asking for local/proxy sigining on the SMG, the feature you are really looking for might be a signature verification action in the policy engine.
Email arrives with a "signed" PDF as an attachment. Your policy logic might go something like:
If (attachment is PDF && SIGNED ) then
ANNOTATE indicating original PDF was signed and valid
Do something else <block/delete attachment whatever you like>
Of course you would have to "translate" the above logic into something comprehensible by the policy UI, but you get the idea.
You could apply the policy to "inbound" email. For outbound (which we are assuming is "safe" so you don't disarm ) you can skip the whole thing.
If (attachment is PDF && SIGNED ) then VALIDATE-SIGNATURE If SIG-IS-VALID DISARM-THE-PDF ANNOTATE indicating original PDF was signed and valid DELIVER normally Else Do something else <block/delete attachment whatever you like> endif endif
The idea of setting some indication that the signature was validated prior to reconstruction and adding a header to indicate that fact sounds interesting and worthy of some research on our part.
And in my experience, across the larger SMG community, it has been one the most successful and effective technologies from day one. The primary/widespread issue we had was related to font removal for PDFs. We provided education on how to avoid that problem, but we also provided an option to not strip the fonts.
As always, we try to make the most effective product we can, while providing as much flexibility as possible to adapt things for your individual needs.
Original Message:Sent: Sep 19, 2023 04:50 PMFrom: Andrey FyodorovSubject: Disarm in pdf documentIn our experience, the Disarm broke a lot of attachments to the point where they couldn't even be opened anymore. It didn't rebuild them properly after ripping out the potential attack vector components.Original Message:Sent: 9/19/2023 3:52:00 PMFrom: Thomas AndersonSubject: RE: Disarm in pdf document
Hi All and thank you for your replies.
Although I have disabled the Disarm function due to the issues we experienced with the digital signatures, I got your point and I totally agree it plays a major role in defending against malicious documents. However, I would still expect that instead of rebuilding any PDF it would scan PDFs for selected objects and remove them only in case such objects exist. Or at least having the user decide the behaviour.