There are lots of scenarios in which additional work must be performed on an electronic form document after a digital signature is affixed. For example, suppose you are filling out a form that has an "office use only" section in it. When you're done, you want to sign the document to authenticate yourself and authorize the signed content. But those "office" people still has work to do to fill out that office-use-only section after you sign and submit the form to them. Another easy example is the multiple signer scenario. For a simple signer/co-signer loan, the loan applicant has to sign the document, and then the co-signer signs it.
In cases like those above, it is clear that the office-use-only section of the form was blank whent he signer signed or that the co-signer had not yet signed when the loan applicant signed. But if you modify the document after the first signature is affixed to fill out the office-use-only section or to add another signature, this seems to be indistinguishable from tampering with the document. The document hash in the digital signature would detect the change, and the user would be told not to trust the document any more.
Fortunately, the XML digital signature world has a solution for this problem. It is called a digital signature filter. A filter allows the document hash in the signature to cover part of the document instead of the whole document. This makes it easy to create a digital signature which logically covers the whole document except for the office-use-only section or the co-signer signature.
Unfortunately, there is a bit of a tendency in the wild to misuse digital signature filters, and the result is forms that do not provide nearly as much security. A proper digital signature filter should almost always use exclusive logic. The digital signature filter should say "sign the whole document except ...". The elided part that forms the exception should, as precisely as possible, indicate the part of the document over which additional work must be performed. For example, "sign the whole document except for the office-use-only section" or "sign the whole document except the co-signer signature".
Almost always, a digital signature filter that uses inclusive logic is evil. People have a natural tendency of wanting to say "sign this and this and this" rather than saying "sign everything except for this and this and this", but the former inclusive logic statement has far less power than the latter exclusive logic statement. The reason has to do with the fundamental principle of digital signatures: What you see is what you sign. For the visually impaired, the word 'see' is being used metaphorically, of course, but the point is that users do not care about octet stream security. They care about whether or not the technology has secured the on-the-glass appearance of the document.
So, when an inclusive signature filter identifies markup for what must be signed, it implicitly omits anything else that might be in the document. This means an attacker can add, change or delete any other content before or after the signature creation occurs. The problem is that such arbitrary content can include commands like 'position me over top of the real terms and conditions of this contract'. So, even though the digital signature continues to validate, the end-user would no longer be looking at the same terms and conditions that the signer saw when he signed the document.
An exclusive signature filter does not allow arbitrary content to be added, changed or deleted. The only additions, changes or deletions allowed are those that are explicitly spelled out in the exclusive signature filter. It is easy to only allow the data and not the layout of the office-use-only section to be changed in the document after a signature is affixed. And it is easy to have the loan applicant signature sign the whole document except for allowing the co-signer signature to be added, again with no changes of the overall form layout. Everybody knows that these things were empty when the first signature was affixed, so the exclusive filter allows only the changes that are reasonably expected of the document.
There is a viable use case for an inclusive signature filter. It is useful as an optimization when a signature is co-signing over a second signature. For example, in the signer/co-signer scenario, the first signature covers the whole document less the second signature. The second signature could cover the whole document, but it really only needs to cover itself plus the first signature because the first signature already covers everything else with an exclusive signature filter. However, the whole signature validation step is fast enough that it is rare for this optimization to make a meaningful improvement, and it will certainly never be more than twice as fast as just signing the whole document a second time. This is why I recommend that people should simply never use inclusive signature filters.
To be honest, the greatest disservice of inclusive signature filters is not even to signers who may be duped by the unscrupulous into authorizing transactions that they don't really approve of. The greater disservice is to the organization that deploys a security system with the understanding that it will reduce the risk of transaction repudiation. A signer can simply show that it is possible to attack a signature containing an inclusive filter, so no one has to even change a single byte before or after the signing event and the signature can still be repudiated! Again, this is why I recommend that people simply should never use inclusive signature filters. By which I mean, just don't ever use inclusive signature filters. And Happy Holidays.