Sign Document: new signatures lock all form fields (breaks signature chains in Acrobat); please add certifying signatures ("No changes allowed")

[RIPWPIN]

This is a text and explanation created via AI > just more convenient than writing everything by yourself :)

Summary

Two related points about Sign Document in SumatraPDF 3.7 pre release:

1. Bug: every new signature created by Sign Document locks all form fields. Any later
   signature then invalidates the earlier one in Adobe Acrobat, so multi-signature workflows
   don't work. There is no setting to turn this off.
2. Feature request: support certifying signatures with the permission "No changes
   allowed" (Acrobat: Certify with Visible Signature), which fully locks the document.

Version: SumatraPDF 3.7 pre-release 3.7.22653 64-bit (behaviour also present in current master).

---

1. Bug: new signatures lock all form fields

Steps to reproduce

1. Open any PDF without signature fields.
2. Sign Document → "New signature on page 1" → place the signature → save.
3. Open the saved file and sign again (second person, new signature box) → save.
4. Open the result in Adobe Acrobat Reader → Signatures panel.

Actual result

• Rev. 1: red cross, "Document Locked by SumatraSignature1"
• Rev. 2: valid

The first signature is cryptographically intact, but Acrobat treats the second signature as a
change forbidden by the first signature's field lock. pyHanko's validator agrees: first signature
intact=True, valid=True, modification level OTHER, "not allowed because the form field … is
locked".

Expected result

A later approval signature should not invalidate an earlier one. Acrobat doesn't lock form fields
when signing unless explicitly asked to.

Cause

src/shared/PdfSign.cpp (EngineMupdfSignDocument) creates the field with
pdf_create_signature_widget(), which in MuPDF (ext/mupdf/source/pdf/pdf-form.c) always adds:

lock = pdf_dict_put_dict(ctx, obj, PDF_NAME(Lock), 1);
pdf_dict_put(ctx, lock, PDF_NAME(Action), PDF_NAME(All));

pdf_signature_set_value() copies Lock/Action /All into the signature's FieldMDP
TransformParams, so every SumatraPDF signature formally locks all fields.

When signing an existing empty signature field without /Lock, MuPDF writes
/Action /Include /Fields [] (locks nothing), and signature chains validate correctly.

Proposed fix

• Default: remove the /Lock entry after pdf_create_signature_widget() in
  EngineMupdfSignDocument, e.g. pdf_dict_del(ctx, pdf_annot_obj(ctx, widget), PDF_NAME(Lock));
• Optional: a "Lock form fields after signing" checkbox (off by default) for the current behaviour.

---

2. Feature request: certifying signatures ("No changes allowed")

Use case

Documents are signed with personal certificates (Windows certificate store / USB tokens) in
SumatraPDF. For final documents we need the protection of Acrobat's certification: after
certifying, any change – markups, form changes, further signatures – is reported as a violation.
We'd like this without requiring Acrobat on every PC.

Proposal

In the Sign Document dialog, a choice of signature type:

• Approval signature (current behaviour, default)
• Certify the document, with the permitted changes:
  • No changes allowed (DocMDP P 1)
  • Form filling and signing (P 2)
  • Form filling, signing and annotations (P 3)

Behaviour:

• Certify is only offered when the document has no signature yet (a certifying signature must be
  the first one); otherwise it's disabled with a short explanation.
• Before certifying with "No changes allowed", a confirmation: "This locks the document. No further
  changes or signatures are possible."
• For an already certified document, Properties (Ctrl+D) shows the certification level, and Sign
  Document warns before adding anything the certification doesn't permit.
• Optionally as a command argument, e.g. [CmdSignDocument certify], for the toolbar.

Implementation notes

In addition to what Sign Document writes today, a certifying signature needs:

• the catalog entry /Perms << /DocMDP <signature dictionary> >>
• in the signature dictionary, /Reference [ << /Type /SigRef /TransformMethod /DocMDP /TransformParams << /Type /TransformParams /P 1 /V /1.2 >> >> ]

MuPDF's pdf_signature_set_value() writes a FieldMDP reference only, so this needs an addition
there (as an ext/patches entry) plus the /Perms entry. Reference implementations: Adobe
Acrobat; pyHanko (PdfSignatureMetadata(certify=True, docmdp_permissions=MDPPerm.NO_CHANGES)).

---

Related (smaller)

• Last-signer lock: a certifying signature must come first, so in a chain of several signers
  "No changes allowed" can't be used. The matching feature for chains is the PDF 2.0 field lock
  "Lock document after signing" (/Lock with /P 1, plus /P 1 in the FieldMDP
  TransformParams), applied by the last signer. It could share the confirmation and UI of
  part 2.
• Properties wording: "The document was changed since the signature was applied" appears for
  every earlier signature as soon as anything is appended
  (pdf_signature_incremental_change_since_signing compares file length only). Distinguishing
  "later signatures added" from "content changed" would avoid alarming users in normal chains.

[GitHubRulesOK]

Hmmm I know this will raise objections as is always the case but IMHO there should be NO second signing no adjustments of any sort the ONE combined document should be held in trust like the Magna Carta was !!!!! and that was not upheld by the pope of the time.

Digital signatures rely on cryptographic techniques, such as public-key infrastructure (PKI), where a unique private key signs the document, and a corresponding public key verifies it. When a document is signed, a hash—a fixed-length string representing the document's content—is generated and encrypted with the signer's private key. Any subsequent change, even as minor as adding a space or altering a comma, alters the hash, breaking the signature's validity. Platforms like those discussed later enforce this by locking the document post-signing, preventing edits while allowing annotations or metadata additions in some cases, but never core content changes.

From a business perspective, this immutability reduces disputes and fraud risks. For instance, in supply chain agreements or financial contracts, knowing that signed terms cannot be retroactively modified builds confidence among parties. However, users must understand the nuances: while the signed version is protected, original drafts can be edited before signing, and some tools offer version histories or audit trails to track pre-signature changes. If modifications are needed after signing, the standard practice is to void the signature, create a new version, and re-sign, ensuring transparency.

[RIPWPIN]

The objection as ordered, any contract is requiring the conformation of all the parties, in my country you need for example a minimum of 3 and a maximum of 5 signatures to get married. So, a multi person agreement, verification and witness conformation is a natural thing in our modern world...

The current signature tool status allows annotation after signing > so you agree on the second point to add a full lock?

[GitHubRulesOK]

I was married in a church with witnesses thus understand the point it is one gods witness was that documents authority.
not the contractors since we divorced without joint witnesses and only one judicial official signed, thus on both occasions.
The documents are in state trust. Just like India portal or English wills repositories etc. one single signed indisputable source.