Document security and authenticity (PDF Days Europe 2025)

Summary

This presentation examines why a PDF can follow a reasonable interpretation of the specification yet still be marked invalid by a major viewer or validator. The speakers focus on signature validation and incremental updates, where the specification allows differing interpretations. Their practical message to PDF and SDK developers is to test against real-world viewers and validators rather than rely on the specification alone.

Three Cases

1. DocMDP and tagged PDFs: DocMDP sets limits on changes allowed after a document is signed. In the example, a later visible timestamp signature was added—an update the speakers understood to be permitted. Because the PDF was tagged, adding the timestamp also required updating the structure tree. Some viewers treated that structural change as an unauthorized modification and marked the earlier signature invalid. Avoiding the structure-tree update may prevent the warning, but can leave the timestamp untagged or not visible.

2. FieldMDP and later signatures: FieldMDP controls which form fields are locked. A customer locked all existing fields after the first signature, then added a new signature field and signed again. Several tools considered the first signature invalid. Their results suggested that “lock all” applies to fields added later too, although the specification does not make that interpretation clear. Developers need to test sequential-signature workflows across different tools.

3. PAdES B-LT and allowed updates: A signature can be cryptographically sound while not covering the entire latest revision of a PDF. In the example, later incremental updates added validation information to the DSS dictionary and a timestamp, along with other changes such as metadata or the PDF version. Some tools reported the document as valid and unmodified; another flagged that the signature did not cover the whole document. The speakers note that such additions can be part of long-term signature validation, but tools differ in how they report them.

Takeaways

• Incremental updates are fundamental to workflows such as adding signatures and long-term validation data, but they also create ambiguity about which later changes are acceptable.
• A cryptographically valid signature does not, by itself, establish that every later revision is trustworthy.
• Developers should analyze problematic revisions step by step and test documents across multiple viewers and validation tools.
• The speakers suggest creating an agreed corpus of example PDFs and shared guidance for interpreting and communicating signature status. In the discussion, an industry representative noted that such efforts have repeatedly been proposed but lack volunteers, and that some companies see validation rules as business-specific.
• The Q&A raised the risk of malicious incremental updates, including a well-known example involving a purported trillion-dollar Amazon refund. Participants agreed that the key issue is not simply whether a later revision exists, but what it contains and how it is validated.

Reviews, Guides, or Tutorials

This is a technical conference presentation and discussion; it does not review products or provide a step-by-step tutorial.

Main Speakers and Sources

Eugene presented the first two cases. An unnamed co-presenter presented the FieldMDP customer scenario and the PAdES B-LT case. Audience participants included Julian, who raised the incremental-update security concern.