Production e-signature architecture: a reference design

The problem: every piece works, and the platform still fails

Articles 1 to 7 gave each piece a standard: hash, certificate, HSM, revocation, authorization, PAdES, timestamps.

A production platform can use every one of those correctly and still sign a document nobody approved. The HSM signs whatever hash it is given. The archive stays safe only until the algorithm under its last timestamp ages. The failures live in the seams between components.

This article assembles the pieces into one reference architecture, derived from the ETSI and Cloud Signature Consortium texts for remote signing, not from any product. Then it tests the design against a sourced threat model and a readiness checklist.

The standards map for server signing

Three documents divide the work, one layer each.

ETSI TS 119 431-1 sets policy and security requirements for a trust service provider (TSP, the organization that runs the service) “operating a remote Signature Creation Device (SCDev)”, with extra requirements when that device is a remote QSCD, the qualified signature creation device of the EU’s eIDAS regulation (Article 3 quotes its definition of the remote qualified device). The service it describes, a server signing application plus the device, is a Server Signing Application Service (SSAS) (TS 119 431-1, §1). Its companion, TS 119 431-2, covers the other half: the component that builds the AdES signature around the signature value (TS 119 431-2, §1).

TS 119 431-1 “does not specify protocols used to access the SSAS” and points to ETSI TS 119 432 for them (§1, NOTE 5). TS 119 432 is “limited to remote server signing, i.e. the signing key is held in a remote shared service”. It mandates no protocol binding, and reuses CSC API JSON and OASIS DSS-X XML constructs where it can (TS 119 432, §1). Version 1.3.1 references the CSC API v2.2.0.0 normatively (§2.1).

The CSC API is the interoperable interface. It leaves out TSP policy (ETSI’s area), signature formats, signature validation, and HSM security evaluation, which it says is “being standardized by CEN in Europe and FIPS in the USA” (CSC, §1).

For time, TS 119 312 lists the algorithms fit for new signatures (TS 119 312, §1), and TS 119 511 covers long-term preservation: keeping a signature checkable “even if later the signing key becomes compromised, the certificate expires, or cryptographic attacks become feasible” (TS 119 511, §1).

The reference architecture

TS 119 432 splits signing into two services (§4.2):

• The Signature Creation Application Service Component (SCASC) takes the document, or its hash, and returns the signed document.
• The Server Signing Application Service Component (SSASC) takes a Data To Be Signed Representation (DTBS/R) and returns a signature value. It holds the keys.

The CSC API uses different words for similar roles: a driving application that talks to the signer, a signature creation application that builds the CMS or PAdES structure, a signature creation device that produces the value, an OAuth 2.0 authorization server, and the Remote Signing Service Provider (RSSP) that runs the device (CSC, §6.1). An RSSP “typically operates an HSM (or functionally equivalent multi-user secure device) and an authentication service” (§4.1, Note 9).

Identity and enrollment registers the signer and links a signing key to them. TS 119 431-1 splits the service into component services, from key generation and identity linking to activation and deletion, and “places no restrictions on any subdivision of an implementation” (§4.4).

Signature creation builds the signed object. It assembles the document hash and the signed-attribute hashes into the DTBS, hashes that into the DTBS/R, sends only the DTBS/R to the signing side, and composes the final PAdES file from the value that comes back (TS 119 432, §4.3.2–4.3.4). Sending only the hash “limits threats to confidentiality”, at the cost of features such as visible signature appearances (§4.3.1).

The activation module and the key store are the core. The key store is an HSM (PKCS#11) or a KMS. In front of it sits a signature activation module (SAM): “a software component using the Signature Activation Data (SAD) for enforcing sole control” (§4.4.1.2). In the certified draft protection profile, the SAD “binds together three elements”: signer authentication, the signing key and the DTBS/R. The SAM checks that binding before it activates the key, and both sit in a tamper-protected environment (prEN 419 241-2 v0.16, §3.3). This is Article 3’s “an HSM is not authorization” at architecture scale.

The evidence store keeps the audit trail. Preservation keeps old signatures verifiable. CA, TSA and OCSP/CRL are external services, and the verifier needs only the signed file and their own trust anchors, plus revocation data unless the file carries it.

Enrollment: a key, a certificate, a person

Under TS 119 431-1’s Normalized policy, the signer’s key “shall be generated and used in a SCDev certified conformant to EN 419221-5” (GEN-6.2.1-02A). The key is linked to an eID means, which is linked to the identity; only one-time keys may link directly to the identity. The provider “shall protect the integrity of links between signer’s signing key and its eID means reference” (§6.2.2 NOTE 1; LNK-6.2.2-10A), and the identity behind the eID means must be “the same as the one linked to the subject of the associated certificate” (LNK-6.2.2-05). Identity proofing itself follows EN 419 241-1 Annex A “for assurance level substantial or higher” (LNK-6.2.2-02A); “substantial” names a level of identity assurance. That annex was not read, so this article does not say what the level demands; Article 2 introduced identity proofing.

Enrollment also fixes the tenancy model: TS 119 431-1 has one key per signer. Article 1’s single organization-wide key shows only that the organization signed. On the CSC’s “multi-user secure device”, the key-to-signer links become security-critical data.

A one-time key “shall be bound to exactly one signature session” and deleted “immediately after the end of the signature session” (GEN-6.2.1-09; DEL-6.3.2-05). If a certificate is revoked, its key “shall be destroyed”, and it is also destroyed on the signer’s request (DEL-6.3.2-01, -02).

Signing, and what “sole control” means

TS 119 432 considers two sole-control assurance levels “as defined in EN 419 241-1” (§4.4.1.2):

• At SCAL1, keys are used “with a low level of confidence” under the signer’s sole control. The signing side authenticates the signer, and activation “can remain for a given period and/or for a given number of signatures”. A NOTE adds that SCAL1 implementations are not expected to “meet the requirements of sole control as it would be expected for a stand-alone QSCD”.
• At SCAL2, keys are used “with a high level of confidence”. The SAM enforces use through SAD that the signer supplies “to sign specific documents”.

§5.3.1 makes the difference concrete. SCAL1 “typically relies on basic authentication mechanisms (e.g. username/password or PIN)” with “no cryptographic binding between the Signature Activation Data (SAD) and the data to be signed”. SCAL2 needs “stronger authentication (e.g. multi-factor, cryptographic challenge-response)” and a cryptographic binding between the SAD and the data to be signed. The CSC API says the same (CSC, §8.1.4).

The CSC API offers two authorization styles. credentials/authorize is explicit: the application collects the PIN or OTP. oauth2/authorize returns an OAuth 2.0 token with scope “credential” (§8.1.4). The OAuth route can hand authentication to FIDO/WebAuthn, an OpenID Connect provider or an EUDI Wallet-based provider (§6.1). TS 119 432 says factors collected inside the driving application “should not be suitable to satisfy SCAL2 requirements” (§5.3.2 NOTE).

The binding is a request parameter in both styles. credentials/authorize takes hashes, which “allows the server to bind the SAD to the hash(es), thus preventing an authorization to be used to sign a different content” (§11.8). With OAuth, oauth2/authorize takes hashes or authorization_details, and at SCAL “2” one of them “SHALL be specified” (§8.2.2). The SAD or token returns to the application, which sends it with the hashes to signatures/signHash (§11.13). The service “SHALL prevent signature applications from creating more signatures than authorized” (§9). Article 5 built the same binding by hand (citing CSC v2.0).

TS 119 431-1 adds two service-side rules. “Signing keys shall be usable in only those cases for which the signer’s consent has been obtained”, and the provider “should ensure that the public key certificate is valid” before using the key (SIG-6.3.1-09, -08). Under the Normalized policy, for a natural person whose authentication is linked directly to the identity, approval needs “an explicit action (not just a checkbox)”, such as scrolling to the end or typing “I agree to sign this contract” (SIG-6.3.1-15, EXAMPLE 2).

Verification: the platform is not in the loop

Verification needs no new standard: the ByteRange and CMS checks of Article 6, the chain and revocation checks of Articles 2 and 4, the timestamp checks of Article 7. The CSC API leaves validation out of scope (§1).

The verifier trusts their own anchors, not the platform’s verdict. A platform’s verification page is a convenience; the proof is in the file.

Archival renewal: B-LTA is a schedule, not a stamp

B-LTA “aims to tackle the long term availability and integrity of the validation material” and can help validate a signature past events such as “the weakness of used cryptographic algorithms, or expiration of validation data” (EN 319 142-1, §6.1). Protection is extended “beyond the life-time of the last document time-stamp” by adding DSS data that validates that timestamp, then a new document timestamp. Each DSS update “should contain the values from the previous DSS Dictionary” (§5.4.1). When the last timestamp’s validation data or cryptography becomes “at risk”, the update is repeated “using the same LTV methodology” (§5.4.3).

TS 119 312’s informative Annex B puts it plainly: “The sooner the process is applied, the better.” For the post-quantum transition it recommends archive timestamps from TSAs using hash-based or hybrid signatures, and larger hashes such as SHA-384 (Annex B). A preservation service under TS 119 511 “shall monitor the strength of every cryptographic algorithm” and augment evidence before it stops working (§7.14). One design trap: if the service received only a hash, it “cannot recompute on its own a new hash” (Annex D.1, NOTE 2). Keep the documents, or accept that renewal depends on the old hash staying strong.

Choosing algorithms for new signatures

TS 119 312 V2.1.1 says only ECCG recommended mechanisms “should be used to generate new signatures and seals”; legacy ones stay usable for interoperability “as long as they remain agreed” (§4). For a platform designed today:

• Hashes: SHA-256, -384 and -512 and the SHA3 equivalents are recommended; SHA-224 is legacy until 2028 (§5.1). A timestamp imprint hash “should never be a legacy mechanism” (§9.2).
• RSA: RSASSA-PSS “shall be used”; PKCS#1 v1.5 is legacy (§6.2.2.1). RSA keys from 1,900 to under 3,000 bits, RSA-2048 included, “shall not be used to issue new certificates after 2026-12-31”, and such certificates must expire by 2028-12-31 (§8.4).
• ECDSA on P-256, P-384, P-521 and the Brainpool curves, and EdDSA, are recommended (§6.2.2.3–4). ML-DSA and SLH-DSA are recommended, with hybrid ML-DSA use advised (§6.2.2.5). For SLH-DSA in CMS-based formats such as PAdES, “only pure SLH-DSA shall be used”, not the pre-hash variant (§6.2.2.6).
• Where quantum protection is needed, for example for signatures that must stay valid “beyond 2030”, RSA, ECDSA and EdDSA must be used in a hybrid scheme or replaced. TS 119 312 sets no migration deadlines; a separate document “currently under development” will (§1 NOTE 1, §8.5).

PAdES defers to TS 119 312, which “can be superseded by national recommendations” (EN 319 142-1, §6.2.1).

Operations: privilege, logs, recovery

EN 319 401 covers the operational layer around the cryptography (EN 319 401):

• Privilege separation. Access follows “need-to-know, least privilege and separation of duties”, and systems must separate “security administration and operation functions”. Privileged accounts need strong authentication “such as multi-factor authentication”, and their rights are reviewed at planned intervals (§7.4).
• Key controls. Keys, algorithms and devices are controlled “throughout their lifecycle”, and the crypto policy is reviewed “taking into account the state of the art” (§7.5).
• Monitoring and logs. TS 119 431-1 wants “all security events” logged, from policy changes and crashes to SSAS access attempts (OVR-6.4.5-02). EN 319 401 wants log time “synchronized with UTC at least once a day”, and logs that cannot be “easily deleted or destroyed” (§7.10). A hash chain sealed into the document, as in Article 5, makes tampering detectable.
• Retention. TS 119 431-1 keeps audit records “for at least seven years after any certificate based on these records ceases to be valid” (OVR-6.4.6-01). Guinea’s law on electronic transactions sets 10 years (L/2016/035/AN, art. 37). Local law comes first; this is not legal advice. For the Guinean texts, see what Guinean law says about electronic signature.
• Compromise and recovery. After a disaster, “including compromise of a private signing key”, operations are restored within the continuity plan’s delay, “having addressed any cause for the disaster which may recur” (§7.11). Timestamps added earlier keep prior signatures verifiable after a key compromise (TS 119 312, Annex B). Key backups “shall not exceed the minimum needed to ensure continuity” (GEN-6.3.3-04).

Testing follows from the same texts. EN 319 401 wants backups integrity-checked and recovery tested at planned intervals, with documented results (§7.11). Our advice: test the negative paths too, as Articles 5 to 7 did. Replay an authorization, swap the hash, revoke a certificate, let a timestamp age, and check each one fails.

Threat model

A starting selection, not a complete threat model. The first eleven rows are drawn from the SAM threats of the certified draft protection profile, some merged (prEN 419 241-2 v0.16, §5.3); see the profile for the full list. The last two rows come from the ETSI texts.

Readiness checklist

What a production platform should be able to show, each line sourced. Passing it is a design review, not a certification.

Mariama signs, Ibrahima checks

Back to the loan contract, on a platform built to this reference architecture.

1. Mariama enrolls once. The signing service generates her key in its key store, a CA certifies it, and the service records the link between the key and her.
2. Ibrahima’s company sends the 5,000,000 GNF contract. The signing app computes the DTBS/R and shows her the document.
3. Mariama authenticates with the SAM side and approves. Her SAD names that hash and no other.
4. The SAM checks the SAD and activates her key. The app assembles a PAdES signature with a timestamp, and every step goes into the audit trail.
5. Ibrahima validates the PDF against his own trust anchors.
6. Years later, the preservation service adds fresh validation data and a new document timestamp before the old one ages.

A contract swapped for a 9,000,000 GNF version no longer matches the SAD, so the SAM refuses it.

Where SEDEYA fits

Four boxes map onto a true SEDEYA claim; the mapping says nothing about the others, which are roles the architecture names. The key store: SEDEYA’s signing keys are held in an HSM (PKCS#11) or a KMS. Signature creation: SEDEYA signs PDFs in PAdES, up to the B-LTA level, with RFC 3161 timestamps and the validation data embedded in the file, for envelopes signed in sequence or in parallel. The evidence store: each signing transaction goes into a hash-chained audit trail sealed into the signed PDF. Verification: Ibrahima can validate the file with his own tools, and SEDEYA also offers a public verification page, by upload or QR code, as a convenience the proof does not depend on. For the buyer’s side of the same review, see what to ask an e-signature provider before you sign up.

Risks and misconceptions

Summary

• TS 119 431-1 sets the service policy, TS 119 432 the protocols, and the CSC API the interface.
• The architecture separates signature creation (builds the PDF) from the signing side (holds the keys), with a SAM between the signer and the key.
• SCAL2, as TS 119 432 describes it, needs strong authentication and SAD bound to the data to be signed. An HSM alone gives neither.
• In TS 119 431-1’s model, enrollment links one key to one signer; revocation destroys the key.
• B-LTA stays useful only if someone keeps renewing it, on algorithms TS 119 312 still recommends.

Check your understanding

Check your understanding

A vendor says its keys are in an HSM, so only the signer can sign. What question do you ask?

Show the answer

What activates the key. An HSM signs any hash it is given. Ask whether a SAM checks signature activation data that binds the signer’s authentication to the exact DTBS/R, and where the signer’s factors are collected.

Check your understanding

Your platform issues RSA-2048 signer certificates. What changes on 1 January 2027 under TS 119 312 V2.1.1?

Show the answer

No new certificates with RSA keys between 1,900 and 3,000 bits may be issued after 2026-12-31, and existing ones must expire by 2028-12-31. Move to RSA-PSS with at least 3,000 bits or a recommended scheme such as ECDSA P-256.

Check your understanding

The preservation service stores only document hashes, not documents. What risk does that carry?

Show the answer

If the hash algorithm weakens, the service “cannot recompute on its own a new hash” (TS 119 511, Annex D.1), and proof that the data existed then falls outside what the service can vouch for.

Next step

This is the last article in the series. Talk to us and we will walk through a SEDEYA-signed PDF: its PAdES structure, timestamps and embedded validation data, and how anyone can verify it.