Hi Folks !
As an European citizen seeking official and reliable information about
secure document signing, I conducted an investigation which indicates
the following
Best//JP :
Secure and Certified PDF Signing in the European Union
/(Legal and Technical Background)/
1. Scope and Purpose
This appendix outlines the *legal, technical, and infrastructural
requirements* for secure PDF signing within the European Union, with
specific attention to standards compliance, trust-chain integrity, and
platform-level constraints. It clarifies the respective roles of
*document production systems* and *signature tools*, and situates Okular
as a technically coherent signing solution in this context.
2. Regulatory Framework
2.1 eIDAS Regulation
*eIDAS* (/Electronic IDentification, Authentication and trust Services/)
is defined by Regulation /(EU) No 910/2014/. It establishes a unified
legal framework for electronic signatures, seals, timestamps, and trust
services across all EU Member States.
eIDAS distinguishes three legal levels of electronic signatures:
*
*SES* (/Simple Electronic Signature/),
*
*AdES* (/Advanced Electronic Signature/),
*
*QES* (/Qualified Electronic Signature/), the latter being legally
equivalent to a handwritten signature.
Legal validity under eIDAS depends on *identity assurance*, *document
integrity*, and *non-repudiation*, all of which rely on cryptographic
mechanisms and trusted certification authorities rather than on document
layout or visual appearance.
3. PDF Signature Standard
3.1 PAdES
*PAdES* (/PDF Advanced Electronic Signatures/) is specified in *ETSI EN
319 142*. It defines how cryptographic signatures are embedded into PDF
documents in a manner compatible with long-term validation and legal
verification.
Common profiles include:
*
*PAdES-B* (/Basic/),
*
*PAdES-T* (/Timestamped/),
*
*PAdES-LT* (/Long-Term Validation/),
*
*PAdES-LTA* (/Long-Term Archival/).
For professional and institutional use, *PAdES-T* or *PAdES-LT* are
generally required.
4. Chain of Trust Requirements
A legally valid electronic signature presupposes an *unbroken chain of
trust*:
1.
The document is signed using a private cryptographic key.
2.
The associated *X.509* certificate is valid and not revoked.
3.
The certificate is issued by a recognized *CA* (/Certification
Authority/).
4.
The trust chain terminates at a root authority listed by the EU.
5.
For *QES*, the private key must reside in a *QSCD* (/Qualified
Signature Creation Device/).
Failure at any level invalidates the legal standing of the signature.
5. Platform Considerations
5.1 Linux and Windows
Both platforms provide:
*
mature *PKI* (/Public Key Infrastructure/) stacks,
*
robust *PKCS #11* (/Public-Key Cryptography Standards/) support for
smart cards and hardware tokens,
*
wide compatibility with national eID systems and *QTSPs* (/Qualified
Trust Service Providers/).
As a result, they are consistently recommended by European trust service
providers for advanced and qualified signatures.
5.2 macOS
macOS relies on proprietary key management mechanisms with limited and
inconsistent *PKCS #11* integration. Vendor support for qualified
devices is weaker, and interoperability with EU eID ecosystems is often
incomplete. This constrains its suitability for high-assurance signing
workflows.
6. Okular as a Signing Tool
Okular implements *PAdES* in strict compliance with ETSI specifications
and leverages system-level cryptographic libraries. It provides
transparent access to:
*
certificate identity,
*
validation status,
*
revocation information,
*
signature integrity.
Its native integration with Linux and solid support on Windows make it
well suited for eIDAS-compliant signing, particularly in environments
using hardware-backed certificates.
7. ConTeXt and the Limits of Document Production
ConTeXt is a document composition system that produces *technically
robust and standards-compliant PDF files*, including structured metadata
where required. It may define signature fields within a PDF but does not
perform cryptographic signing.
This limitation is deliberate and appropriate: secure electronic signing
requires controlled access to private keys, trusted hardware, and
system-level certificate stores—functions that properly belong to
specialized signing tools rather than to a typesetting engine.
8. Recommended Workflow
1.
*ConTeXt*: generate the final PDF (optionally PDF/A, with metadata).
2.
*Okular*: apply a *PAdES* signature using an advanced or qualified
certificate.
3.
*Verification*: validate the signature and trust chain using a
standards-compliant reader.
This separation of responsibilities ensures legal conformity, technical
robustness, and auditability.
9. Conclusion
Secure PDF signing under EU law is governed by *eIDAS* and implemented
through *PAdES*. Legal validity depends on cryptographic trust chains
and certified devices, not on document authoring tools. Linux and
Windows provide the most reliable infrastructures for such workflows,
while Okular stands out as a transparent and standards-respecting
signing application. ConTeXt, for its part, excels at producing
high-quality PDFs and integrates naturally into this legally sound
signing chain.
And (last but not least) LibreOffice can produce reliable electronic
signatures that comply with European standards and are suitable for
everyday professional use, but it is not the ideal tool when legal
traceability, qualified signatures, or detailed analysis of the chain of
trust are critical.
Le 16/12/2025 à 17:01, Pablo Rodriguez via ntg-context a écrit :
On 12/16/25 15:39, Hans Hagen via ntg-context wrote:
I don’t know that these root keys are. If they are root certificates,
leaf/user certificates are signed in chain, so root certificates need to
be there to verify the certificate chain (from a trusted CA).
yes but having them compiled into a viewer ... well ...
Most web browsers contain root certificates (at least, Firefox/LibreWolf
contain a bunch of them).
In fact, `poppler` should benefit from that (although Firefox doesn’t
include all [or probably most] EUTL certificates).
Once I have checked all, I only ask you to include the patch for
signature fields I will eventually send (if it’s ok, of course).
i can have a look at the patch but can't test it
Testing the patch and complaints are on me.
Many thanks for your help,
Pablo
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist :[email protected]
/https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage :https://www.pragma-ade.nl /https://context.aanhet.net (mirror)
archive :https://github.com/contextgarden/context
wiki :https://wiki.contextgarden.net
___________________________________________________________________________________
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : [email protected] /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___________________________________________________________________________________
