What Corsac Sign does not do
Electronic signing is a field with a lot of implied certification in it. This page is the list of things Corsac Sign is not, written down before anyone has to ask.
It is not a qualified — or advanced — signature service
“The seal on this document is a cryptographic tamper-evidence seal applied by [organisation] via Corsac Sign (fingerprint …). It is not an eIDAS advanced or qualified electronic seal.”
— printed on every certificate of completion we generate.
There is also no such thing as “eIDAS certified software” or “21 CFR Part 11 certified software”. Under eIDAS, qualification attaches to a trust service provider admitted to an EU Trusted List — never to a product a customer installs. Part 11 describes how a regulated organisation operates a system, including the parts of it no vendor touches; it is not a badge a vendor can hold on your behalf. A supplier claiming either is describing a certificate that does not exist.
What a signature validator will say — and what it means
Put a Corsac-sealed PDF through the EU DSS validator and the report reads INDETERMINATE / NO_CERTIFICATE_CHAIN_FOUND. That is the correct and expected verdict for a well-formed advanced signature whose signer is not on an EU Trusted List. It says: the signature is structurally sound and the digest checks out, but I cannot place this certificate under a qualified trust anchor.
It does not say the signature is invalid, and it does not say the file was altered — an altered file fails on the digest, which is a different finding entirely. Read INDETERMINATE as “not qualified”, not as “not valid”.
The seal is self-signed unless you bring your own certificate
An instance generates its own sealing key and certificate on first boot, and publishes every fingerprint it has ever sealed with at /.well-known/corsac-seal. Nothing external vouches for that certificate — it is a tamper-evidence anchor, not an identity assertion.
An operator can import a PKCS #12 bundle from a certificate authority instead, and from that point the seal chains to whatever that authority is worth. Corsac does not supply the certificate and does not pretend to be the authority.
The timestamp is verified; the timestamp authority is not pinned
Every RFC 3161 token is checked in full before it is trusted: token signature, message imprint against the bytes we asked to have stamped, the id-kp-timeStamping extended key usage, ESSCertID, and the stamped time falling inside the signer certificate's validity window.
“this does NOT chain the cert to a pinned TSA trust anchor, so it does not by itself stop a token signed by an attacker-minted cert on a MITM'd http TSA.”
— the comment above that check, in the code that performs it.
An anchor proves a prefix, not an absence
“This anchor proves the events up to seq N existed as recorded when this certificate was generated; later events must extend it (prefix inclusion). It does not by itself prove absence of later events — terminal anchors and counterparty copies do.”
— printed beside the head hash on every certificate.
If every timestamp authority is unreachable, the time is ours alone
“Sealed without trusted timestamp — every configured timestamp authority failed. The seal is valid; the sealing time is server-asserted only.”
— shown on the public verification page when that happens.
The evidence export carries each signer's IP address and browser
Deliberately, and without an API key in front of it. Those bytes are inside the hash the evidence chain covers: stripping them would change the hash of every document already sealed, and gating them behind a credential would break the one promise the export exists to keep — that it re-verifies with no access to our systems.
The exposure is bounded by the verification link, which only ever travels with the executed document. Every export is rate-limited and written to that document's access log.
What we can tell you about a PDF you upload — four answers, none of them “valid”
Hand us bytes and we will say what this instance can attest about them, and nothing more. There is no plain “valid” verdict, because a bare yes would be a claim we cannot support.
| Verdict | What it means |
|---|---|
| revision_match | Byte-for-byte a revision we recorded. Reported with the document's terminal status and whether a later revision supersedes it. |
| valid_augmented | Our seal verifies over the signed prefix and the tail carries only benign additions of our own — a document timestamp or a validation-data store. |
| sealed_then_modified | Our seal verifies over the prefix, but the tail carries content. This is what a shadow attack looks like. |
| unknown | No revision match and no signer we know. Not a claim that the file is forged — only that we can say nothing about it. |
When a valid seal of ours covers bytes we never recorded, the document's identity is reported as unrecorded rather than guessed. This check runs today at POST /api/verify; it has no page of its own yet, so reaching it needs an HTTP client.