Legal class
SES, not QES — what the seal proves and what it doesn't.
NoSign produces a Simple Electronic Signature (SES) with a strong, provable audit trail. It is deliberately not a Qualified Electronic Signature (QES) or an Advanced Electronic Signature (AES) under the eIDAS framework.
What the seal is
After the last signer, NoSign applies a PAdES-B-T cryptographic seal to the document. This seal is an organizational integrity and timestamp seal: it proves the document has not been modified since it was sealed and records when sealing occurred via an embedded RFC3161 timestamp.
The seal certificate is issued by your NoSign instance (a self-signed organizational certificate). It is not issued by a qualified trust service provider and does not represent the cryptographic identity of any individual signer.
What the seal is not
- It is not the qualified identity of the signer. Signer identity is established through email verification (OTP / magic link) and is recorded in the audit trail — it is not embedded in the PDF certificate chain.
- It does not meet QES or AES requirements under eIDAS. If your use case legally requires a qualified signature, NoSign is not the right tool.
Embedded evidence and offline verification
Beyond the seal itself, every sealed PDF carries an evidence layer: a bilingual audit-certificate page and a machine-readable nosign-audit.json, both inside the signed bytes. A public /verify portal re-checks ByteRange integrity and the RFC3161 timestamp offline, so the proof is checkable by anyone — not only platforms that pre-trust the seal.
This is a concrete step toward long-term validation. Full PAdES-LTV and an AATL-trusted certificate remain a later drop-in; the seal class today is still SES.
Self-signed certificate and reader display
Because the seal certificate is self-signed by default, Adobe Reader and similar PDF readers display “validity unknown” for the signature. Your platform pre-trusts the certificate and can verify it programmatically.
Swapping in an AATL or commercially-trusted certificate (so that readers show a green checkmark for all users) is a later configuration step — a .p12 drop-in with no code change required.
Self-hosted TSA trade-off
The embedded RFC3161 timestamp is issued by a self-hosted TSA sidecar running alongside NoSign. This means the TSA is not an independent third party — it is operated by you, the same entity that runs NoSign.
This is an accepted trade-off for the “no external services” principle. For most SES use cases, a self-hosted TSA provides a credible, tamper-evident timestamp. For use cases requiring an independent third-party TSA, you would configure NoSign to point to an external RFC3161 endpoint.
Strength of the audit trail
While the seal class is SES, the audit trail is designed for provability:
- Every step is recorded with UTC timestamp, HMAC-hashed IP, user agent, actor, and document hash.
- Verbatim consent checkbox wording is stored — not a translation key, the exact rendered text.
- The byte-faithful HMAC webhook guarantees the bytes your platform verifies are exactly the bytes that were signed and sealed.