DOMAIN:EU_REGULATION:DIGITAL_SIGNATURES

OWNER: eric, julian
ALSO_USED_BY: aimee, margot, ALL dev agents building document signing features
UPDATED: 2026-03-26
SCOPE: practical implementation guide for digital signing in GE projects

---

OVERVIEW

This page covers the practical implementation of digital signatures in GE projects —
from contract signing workflows to technical format choices, long-term validation,
and integration patterns. For the legal framework (eIDAS, signature levels, providers),
see domains/eu-regulation/eidas.md.

WHY_GE_CARES: GE builds software that handles contracts, invoices, and regulated documents.
Digital signing is a core feature requirement. GE also signs its own client contracts.
Getting the implementation wrong creates legal risk for GE and its clients.

---

CONTRACT SIGNING WORKFLOW

STANDARD_FLOW

1. DRAFT → document created (PDF/A-3 or structured data)
2. REVIEW → all parties review content
3. APPROVE → internal approval (may require multiple approvers)
4. SIGN → each party applies their electronic signature
5. COUNTER-SIGN → other party/parties sign
6. TIMESTAMP → qualified timestamp applied
7. ARCHIVE → signed document stored with hash and audit trail

MULTI-PARTY_SIGNING_ORDER

For contracts with multiple signatories, define the signing order:

SEQUENTIAL: Party A signs first, then Party B, then Party C.
Each signer sees previous signatures. Common for contracts.

PARALLEL: all parties sign independently. Signatures collected and merged.
Common for NDAs, consent forms.

HYBRID: some signers sequential (internal approval chain),
then parallel for external parties.

IMPLEMENTATION: most e-signature providers (Scrive, ZealID, ValidSign) support
configurable signing orders via their API. Define the flow at document creation time.

---

SIGNATURE FORMATS — TECHNICAL

THREE_STANDARD_FORMATS

The EU recognises three digital signature formats under eIDAS. Each is standardised
by ETSI and maps to specific document types.

PAdES — PDF_ADVANCED_ELECTRONIC_SIGNATURES:
- STANDARD: ETSI EN 319 142
- DOCUMENT_TYPE: PDF documents
- HOW: signature embedded directly in the PDF structure
- VISUAL: can include visible signature field on the PDF page
- USE_WHEN: contracts, invoices (PDF), any document where visual representation matters
- PROFILES: PAdES-B (basic), PAdES-T (timestamped), PAdES-LT (long-term), PAdES-LTA (archival)
- MANDATORY_FOR: Italy (e-invoicing), Spain (government filings), general PDF workflows
- RECOMMENDATION: use PAdES for all PDF-based signing. It is the most widely understood format.

XAdES — XML_ADVANCED_ELECTRONIC_SIGNATURES:
- STANDARD: ETSI EN 319 132
- DOCUMENT_TYPE: XML documents
- HOW: signature in XML Digital Signature (XMLDSig) format, embedded or detached
- USE_WHEN: e-invoicing (UBL/Peppol), EDI, government filings, structured data exchange
- PROFILES: XAdES-B, XAdES-T, XAdES-LT, XAdES-LTA
- DOMINANT_IN: Germany, Netherlands (for XML-heavy public sector exchanges like XRechnung)
- RECOMMENDATION: use XAdES when signing XML documents, especially Peppol invoices.

CAdES — CMS_ADVANCED_ELECTRONIC_SIGNATURES:
- STANDARD: ETSI EN 319 122
- DOCUMENT_TYPE: any binary file (detached signature)
- HOW: signature in CMS (Cryptographic Message Syntax) format
- USE_WHEN: signing arbitrary file types, email (S/MIME), financial messaging
- DOMINANT_IN: France (RGS standard)
- RECOMMENDATION: use CAdES only when PAdES and XAdES do not apply.

PROFILE_LEVELS (applies to all three formats)

B_LEVEL (BASELINE): basic signature. Contains signed data + signer certificate.
No timestamp. Validity depends on certificate validity period.
SUITABLE_FOR: short-lived signatures where immediate verification is enough.

T_LEVEL (TIMESTAMPED): adds a trusted timestamp to the signature.
Proves the signature existed at a specific time.
SUITABLE_FOR: most business use cases. Minimum recommended level.

LT_LEVEL (LONG_TERM): adds all validation data (certificates, CRLs, OCSP responses)
to the signature. Allows offline validation even after certificate expiry.
SUITABLE_FOR: documents that must remain verifiable for years.

LTA_LEVEL (LONG_TERM_ARCHIVAL): adds archival timestamps.
Protects against algorithm obsolescence. Can be re-timestamped periodically.
SUITABLE_FOR: legal archives, regulatory retention (7+ years).

PROFILE_DECISION

document needs verification for < 1 year? → B or T level
document needs verification for 1-7 years? → LT level minimum
document needs verification for 7+ years? → LTA level
regulated industry / legal archive? → LTA level

RECOMMENDATION: default to T level minimum. Use LTA for anything with legal retention.

ASiC — ASSOCIATED_SIGNATURE_CONTAINERS

When signing multiple files together, use ASiC containers:
- ASiC-S: one signature covering one data object
- ASiC-E: one or more signatures covering one or more data objects
- based on ZIP format
- contains the signed documents + detached signatures (XAdES or CAdES)

USE_WHEN: signing a package of related documents (contract + annexes + evidence).

---

PDF/A-3 — THE ARCHIVAL FORMAT

WHY_PDF_A_3

PDF/A-3 (ISO 19005-3) is the archival PDF format that allows embedding arbitrary files.
This is critical for e-invoicing (embed the UBL XML inside the PDF) and for
long-term document preservation.

ADVANTAGES:
- self-contained: all fonts, images, colour profiles embedded
- embeds arbitrary files (XML invoices, attachments)
- guaranteed renderability for decades
- accepted by archives and regulatory bodies
- supports PAdES signatures natively

WHEN_TO_USE:
- all contracts generated by GE projects
- all invoices (PDF representation of Peppol UBL data)
- all documents requiring long-term archival
- regulatory filings

EMBEDDED_SIGNATURE_IN_PDF_A_3

A PAdES signature in a PDF/A-3 document:
1. does not break PDF/A conformance (if correctly implemented)
2. embeds the signature in an incremental update to the PDF
3. visual signature appearance can be configured (position, size, appearance)
4. multiple signatures supported (each as incremental update)

TOOL: use a PDF library that supports both PDF/A-3 generation AND PAdES signing.
Apache PDFBox (Java), iText (Java/.NET, AGPL/commercial), pdf-lib (JS, limited signing).

---

LONG-TERM VALIDATION (LTV)

THE_PROBLEM

Digital signatures rely on certificates with expiry dates and revocation lists.
After certificate expiry, the signature becomes unverifiable unless you preserved
all validation data at signing time.

THE_SOLUTION — LTV

Long-Term Validation embeds all necessary validation data in the signed document:
1. signer certificate and full certificate chain up to root CA
2. CRL (Certificate Revocation List) or OCSP response proving non-revocation
3. qualified timestamp proving when the signature was made

WITH_LTV: the signature can be verified offline, years after the certificate expired,
because all evidence of validity at signing time is embedded in the document.

IMPLEMENTATION_STEPS

1. create signature (PAdES-B)
2. add timestamp from TSA (→ PAdES-T)
3. collect validation data:
   a. full certificate chain
   b. OCSP responses for each certificate in the chain
   c. CRL snapshots (alternative to OCSP)
4. embed validation data in DSS (Document Security Store) of PDF (→ PAdES-LT)
5. add archival timestamp over entire document including DSS (→ PAdES-LTA)

TSA = TIME_STAMP_AUTHORITY: qualified TSAs are listed on the EU Trusted List.
Use a qualified TSA for timestamps that need legal recognition.

RE-TIMESTAMPING

For very long retention (15+ years), algorithms may become weak.
PAdES-LTA supports re-timestamping: adding a new archival timestamp with
a current algorithm over the entire document. This extends the validation
window indefinitely.

SCHEDULE: re-timestamp every 5 years or when cryptographic guidance changes.
Track ETSI and BSI recommendations for algorithm deprecation.

---

BULK SIGNING PATTERNS

USE_CASES

• monthly invoice batch: hundreds of invoices signed with organisation seal
• HR document generation: contracts, payslips, certificates
• regulatory filings: batch submission of reports

ORGANISATIONAL_SEAL vs PERSONAL_SIGNATURE

SEAL: used for legal person (organisation). Does not identify an individual.
Proves origin and integrity. Ideal for automated/bulk signing.
EXAMPLE: GE applies its electronic seal to all generated invoices.

SIGNATURE: identifies a natural person. Requires individual consent per signing act.
Not suitable for fully automated batch processing.

IMPLEMENTATION

FOR_SEALS (automated):

1. GE obtains qualified electronic seal certificate from QTSP
2. seal creation device (HSM or cloud HSM) holds the private key
3. batch process iterates over documents
4. each document gets: seal + timestamp + LTV data
5. no human interaction required per document

FOR_SIGNATURES (semi-automated):

1. batch prepared with all documents
2. signer reviews batch summary
3. signer authenticates once (2FA/eID)
4. single approval covers the entire batch
5. system applies signature to each document
6. individual audit trail per document

PROVIDER_SUPPORT: ZealID and Signicat support batch signing via API.
Check rate limits and pricing for high-volume use.

---

GE CONTRACT SIGNING FLOW

CURRENT_PROCESS

Eric generates contracts for new clients. The flow should be:

1. Eric creates contract from template (PDF/A-3)
2. contract reviewed internally (Aimee for scope accuracy, Julian for compliance)
3. contract sent to client via secure channel (NOT email attachment)
4. client reviews and signs (AES minimum)
5. Eric counter-signs on behalf of GE (AES minimum)
6. qualified timestamp applied
7. signed contract archived:
   a. cryptographic hash (SHA-256) recorded
   b. stored in GE document management system
   c. backup copy in separate location
   d. retention: minimum 7 years after contract end
8. audit trail preserved:
   a. who signed (identity verified to AES level)
   b. when (qualified timestamp)
   c. from where (IP, device metadata)
   d. which version (document hash)

INTEGRATION_WITH_PEPPOL

For invoices that require both Peppol compliance and digital signing:

1. generate invoice data (structured, from billing system)
2. create UBL 2.1 XML (Peppol BIS 3.0 compliant)
3. create PDF/A-3 representation with embedded UBL XML
4. apply XAdES signature to UBL XML (optional — Peppol transport handles integrity)
5. apply PAdES signature to PDF/A-3 (recommended for archival)
6. apply GE electronic seal
7. send UBL via Peppol Access Point
8. archive signed PDF/A-3 with LTV

NOTE: Peppol transport (AS4) provides message-level integrity and authenticity.
Document-level signatures are ADDITIONAL assurance for archival purposes.
The Peppol network itself does not require document-level signatures.

---

SIGNATURE VERIFICATION IN APPLICATIONS

VERIFICATION_FLOW

When a GE-built application receives a signed document:

1. extract signature from document
2. determine format (PAdES/XAdES/CAdES)
3. verify signature integrity (hash matches signed data)
4. extract signer certificate
5. build certificate chain to root CA
6. check certificate revocation (OCSP/CRL)
7. if qualified: verify QTSP is on EU Trusted List
8. if timestamped: verify timestamp from qualified TSA
9. if LTV: use embedded validation data for offline verification
10. return verification result with level (SES/AES/QES)

TOOLS

DSS_LIBRARY (EU Digital Building Blocks):
- open-source Java library for signature creation and validation
- supports PAdES, XAdES, CAdES, ASiC
- supports EU Trusted List validation
- maintained by the European Commission
- RECOMMENDED for server-side verification

BROWSER_VALIDATION:
- PDF.js does NOT validate digital signatures
- Adobe Acrobat Reader validates PAdES signatures against Adobe's trusted list
- for web apps, use server-side validation via DSS library

---

EVIDENCE PRESERVATION FOR LEGAL DISPUTES

WHAT_TO_PRESERVE

In case of legal dispute over a digitally signed document, you need:

1. THE_SIGNED_DOCUMENT: the exact byte-level original with embedded signature
2. CERTIFICATE_CHAIN: all certificates from signer to root CA
3. REVOCATION_DATA: OCSP responses or CRLs valid at signing time
4. TIMESTAMP_TOKEN: qualified timestamp proving when signature was made
5. AUDIT_TRAIL: logs of the signing process (who, when, how, from where)
6. IDENTITY_EVIDENCE: how the signer's identity was verified (for AES/QES)

IF_USING_LTA: items 2-4 are embedded in the document. Still preserve audit trail separately.

QUALIFIED_TIMESTAMPS

A qualified timestamp from a QTSP on the EU Trusted List has legal presumption
of accuracy of the date and time (Art. 41(1) eIDAS). This means:
- the timestamp is presumed correct unless proven otherwise
- burden of proof shifts to the party challenging the timestamp
- accepted as evidence in all EU Member States

ALWAYS apply a qualified timestamp to signed documents. The marginal cost
(typically < EUR 0.10 per timestamp) is negligible compared to the legal protection.

AUDIT_TRAIL_REQUIREMENTS

The audit trail for a signing event should contain:

{
  "event": "document_signed",
  "document_hash": "sha256:abc123...",
  "signer_id": "verified_identity_reference",
  "signature_level": "AES",
  "provider": "scrive",
  "timestamp": "2026-03-26T14:30:00Z",
  "timestamp_qualified": true,
  "timestamp_tsa": "qtsp_name",
  "ip_address": "192.168.x.x",
  "user_agent": "Mozilla/5.0...",
  "consent_method": "click_to_sign",
  "document_version": "v2.1",
  "signing_order_position": 2,
  "certificate_serial": "1234567890"
}

RETENTION: same as the document itself. Minimum 7 years after contract end.
Store audit trails in append-only storage (database with no DELETE permission).

---

MOBILE SIGNING

CURRENT_STATE (2026)

Mobile signing is possible through:
- provider apps: ZealID app, Signicat app, Scrive app
- national eID apps: DigiD app (NL, but not QES level), BankID app (NO/SE)
- SMS OTP-based signing: lower assurance, SES level only

EUDI_WALLET (from late 2026 / 2027)

The EUDI Wallet will enable mobile QES for all EU citizens:
- wallet stores qualified certificates
- signing initiated from any application via OIDC4VP
- biometric unlock on device acts as QSCD
- no separate app per provider needed
- FREE for natural persons

IMPACT: mobile QES becomes mass-market. Currently QES is mostly enterprise/regulated.
EUDI Wallet makes it accessible to every EU citizen.

DESIGN_FOR: when building signing flows for client projects launching in 2027+,
design for EUDI Wallet as a first-class signing method.

---

ANTI_PATTERNS AND FIXES

ANTI_PATTERN: storing only the signed PDF and discarding the audit trail
FIX: the audit trail is critical evidence in disputes. Store it alongside
the document with the same retention policy. Use append-only storage.

ANTI_PATTERN: using PAdES-B (no timestamp) for contracts
FIX: without a timestamp, you cannot prove WHEN the document was signed.
Use PAdES-T minimum. Prefer PAdES-LT or PAdES-LTA for contracts.

ANTI_PATTERN: generating PDF (not PDF/A) for archival documents
FIX: standard PDF may use external fonts, ICC profiles, or JavaScript
that become unavailable over time. Use PDF/A-3 for guaranteed renderability.

ANTI_PATTERN: verifying signatures only against Adobe's trust list
FIX: Adobe's trust list is NOT the EU Trusted List. A signature may be
valid under eIDAS but not show as valid in Adobe Reader (and vice versa).
Use the DSS library with EU Trusted List for authoritative verification.

ANTI_PATTERN: implementing signature verification in the browser
FIX: client-side verification is untrusted. Always verify signatures
server-side. Show the verification result to the user, but perform
the cryptographic verification on your server with DSS library.

ANTI_PATTERN: not re-timestamping archived documents
FIX: cryptographic algorithms weaken over time. SHA-1 was once standard,
now broken. PAdES-LTA documents should be re-timestamped every 5 years
with current algorithms. Build this into the archival process.

ANTI_PATTERN: using self-signed certificates for "digital signatures"
FIX: a self-signed certificate provides zero trust. It proves nothing
about the signer's identity. Use certificates from recognised CAs,
and from QTSPs for qualified signatures.

---

READ_ALSO:
- domains/eu-regulation/eidas.md
- domains/eu-regulation/peppol-e-invoicing.md
- domains/compliance-frameworks/gdpr-implementation.md
- domains/security/vault-secrets.md