[FEATURE]: DocMDP (“No changes allowed”) + UI notice “modified after signing”

[DeBaschdi]

Is your feature request related to a problem? Please describe.

Motivation

• Users expect Adobe-like clarity:
  Valid, Valid but modified after signing, or Invalid (tampered / policy violation).
• Today LibreSign primarily reports cryptographic validity; it does not explicitly surface post-signature modifications or DocMDP policy violations.
• Enforcing and surfacing DocMDP makes LibreSign suitable for regulated workflows where post-sign edits must be forbidden.

Describe the solution you'd like

Feature Request: DocMDP (“No changes allowed”) + UI notice “modified after signing”

Summary

Please add to LibreSign (Nextcloud app):

1. An option to apply a certifying signature (DocMDP) at signing time — especially the level “No changes allowed” (P=1), with additional levels for allowed changes (P=2, P=3).
2. Enhanced validation & UI:
   • If a signed PDF has any later revision, show a clear “Document was modified after signing” notice.
   • If a later change violates the DocMDP policy (e.g., P=1), mark the signature Invalid (DocMDP violation).

Motivation

• Users expect Adobe-like clarity:
  Valid, Valid but modified after signing, or Invalid (tampered / policy violation).
• Today LibreSign primarily reports cryptographic validity; it does not explicitly surface post-signature modifications or DocMDP policy violations.
• Enforcing and surfacing DocMDP makes LibreSign suitable for regulated workflows where post-sign edits must be forbidden.

Proposed UX / UI

Signing dialog (web UI)

• Section: Certification (DocMDP)
  • Dropdown Certification level:
    • No changes allowed (P=1)
    • Form fill-in allowed (P=2)
    • Form fill-in & annotations allowed (P=3)
  • [Optional] Checkbox: Make this my default
  • Tooltip explaining what each level permits.
• If the document already contains a certifying signature, disable DocMDP selection and show:
  “This document is already certified. You can only add approval signatures.”

File sidebar / LibreSign panel (validation view)

• Status badge for each signature:
  • Valid
  • Valid — modified after signing (info icon links to details)
  • Invalid (DocMDP violation)
  • Invalid (integrity failed)
• Details drawer shows:
  • Signing time, signer identity, certificate chain/LTV info (if available)
  • DocMDP level (P=1/2/3)
  • Whether later revisions exist and what category they fall into (form fill, annotations, other)
  • Which rule triggered invalidation (for DocMDP violations)

Validation behavior (server-side)

1. Always perform standard signature verification (digest, certificate path, revocation/LTV if configured).
2. Determine if the file has incremental updates after each signature (revision > signed ByteRange).
3. If no DocMDP:
   • If later revisions exist → show “Valid — modified after signing.”
4. If DocMDP present:
   • Classify the later changes (form fields, annotations, others).
   • If changes are outside the permitted set for P=2 or P=3, or any change exists for P=1 → mark Invalid (DocMDP violation).
   • If changes are permitted → still show “Valid — modified after signing.”
5. Multiple signatures:
   • Respect PDF rules that certifying signature must be first; block selecting DocMDP if a certifying signature already exists.
   • Validate each signature against the revision it covers; display per-signature results and an overall document status (worst-case).

Acceptance criteria

• ✅ New DocMDP selector in the signing UI with P=1/2/3.
• ✅ A document signed with P=1 becomes Invalid (DocMDP violation) if any later revision is added.
• ✅ A document with later allowed changes (per P=2/P=3) shows “Valid — modified after signing.”
• ✅ Documents with later changes but no DocMDP show “Valid — modified after signing.”
• ✅ Clear, non-technical wording and badges in the sidebar and LibreSign panel.
• ✅ OCC/REST: ability to set DocMDP level programmatically (e.g., --docmdp=1|2|3).

Configuration & defaults

• Admin setting: Default DocMDP level for the instance (overrideable per sign action).
• Per-user preference: Remember last used DocMDP level.
• Compatibility mode: Off by default; when on, validation is tolerant but still shows the “modified after signing” notice.

Backward compatibility

• Existing signatures continue to validate as before.
• New UI is additive; if a PDF already has a certifying signature, LibreSign prevents adding another and informs the user.

Implementation notes (high-level)

• When signing as certifying signature:
  • Add /Reference with /TransformMethod /DocMDP and /TransformParams << /P 1|2|3 >> to the signature dictionary.
  • Ensure this is the first signature in the file; otherwise present an error.
• For detection of revisions/allowed changes, analyze incremental updates and object types touched (forms, annotations, page content).
• Consider leveraging existing PDF libraries’ DocMDP/permission checks where available.

Out of scope (for this request)

• Field-level permissions (FieldMDP) and granular lock flags (could be a follow-up).
• UI for advanced PAdES/LTV configuration (nice to have but not required to deliver the core feature).

---

Describe alternatives you've considered

No response

Additional context

No response

[vitormattos]

Thank you for such a well-structured and thoughtful feature request. It’s an excellent proposal with solid technical details that will greatly help in implementing this feature.

The DocMDP (certifying signature with “no changes allowed” / P=1–3) functionality fits perfectly within LibreSign’s roadmap toward stronger compliance and transparency in signature validation, just as you described.

From a technical perspective, this feature will require coordinated changes across the stack:

• Frontend: new selector and tooltips for DocMDP levels in the signing dialog, and validation changes in the validation screen.

  • Prototype validation changes
  • Prototype admin settings
  • Prototype changes in the signature request flow
  • Implement validation changes
  • Implement admin settings
  • Implement signature request flow changes

• Backend:

  • Validation to extract and return each signature’s /TransformParams /P level
  • Storage of admin settings
  • Enforcement logic at signing time
  • Adaptation of the signing engine to include the certification level when signing the document, considering the current level (no certification) as the default
  • Storage of per-request settings
  • Adjustment of the signing flow to consider per-signer settings instead of only admin and/or default settings

Our first milestone would likely be the backend validation, so existing documents can already report the certification level used for each signature.

This implementation will require dedicated development time (around 4–5 weeks). Since LibreSign is a cooperative and community-sustained project, we depend on partners who understand the importance of funding open-source development.

If you’re interested, we’d be happy to discuss how to support or co-fund this feature, either through a one-time sponsorship (to prioritize its implementation) or through ongoing support to ensure maintenance and continuous improvement. If you can’t fully fund this feature, any recurring contribution via GitHub Sponsors is also greatly appreciated.

Additionally, we would really appreciate it if you could give us 5 stars and a positive comment on the Nextcloud App Store and platforms like AlternativeTo. ⭐

Thank you again for helping make LibreSign better with this excellent feature suggestion. Contributions like this truly move the project forward. 💚