How a signature holds up

ShareSign provides simple electronic signatures under eIDAS and electronic signatures under ESIGN and UETA. Under those laws a signature is not denied effect only because it is electronic; what carries it is the evidence that a particular person meant to sign a particular document. That is what everything below exists to show. The legal effect of any one signature depends on the law that applies to your agreement, and some documents in some places call for a higher grade of signature or for a witness. ShareSign does not give legal advice; the terms say the same.

Before a signer’s first mark is recorded they confirm, in a sentence on the screen, that their electronic signature is the legal equivalent of their handwritten one, and they are told that the time, their network address and their device will be kept with the document. The signature itself is not recorded before that consent; that the document was opened is, so a sender can see it was read.

When the last signer signs, the field values are drawn into the PDF and a certificate is appended as the final page of the same file. It travels with the document wherever it is emailed or downloaded. It states:

• The document’s title and its ShareSign document ID.
• The SHA-256 hash of each original file, so the file you uploaded can be matched to what was signed.
• When the document was completed, in UTC.
• For each recipient: name and email; for signers, the time they signed, their network address and their browser; for people copied, that they received a copy.
• Where anyone can check it: a link to sharesign.co/verify with the document’s own code, and the same as a QR code for a printed copy.

To check that a file on your disk is the original the certificate names, compute its hash and compare:

shasum -a 256 contract.pdf

The signed PDF’s own hash is recorded at completion and returned by the API, so a copy that has been altered after signing can be told from the one ShareSign produced. Anyone can make that comparison at sharesign.co/verify.

Anyone holding a signed PDF, or the closing record of a data room, can drop it on sharesign.co/verify and see whether it is exactly what ShareSign sealed. They need no account. The file never leaves their device: their browser works out its SHA-256 and only those 64 characters are sent.

A check shows that a file is byte for byte what ShareSign sealed and that nothing in our record of it has changed since. It does not say whether an agreement is valid for a given purpose, or who a signer was beyond what the certificate records. The sender sees on the document’s page how many times it has been checked, and when last; never who checked it.

Each night at 00:15 UTC, ShareSign asks two authorities it does not run, DigiCert and Sectigo, to timestamp a single fingerprint that covers the day’s seals. That fingerprint says nothing about any document. Each timestamp is the authority’s own signed RFC 3161 token, and a document’s proof carries both.

A checked file’s result offers its proof: the file’s fingerprint, its path to that night’s root, and the two tokens. With the proof, anybody can show the file existed by that night, using a few lines of any language and OpenSSL, without asking ShareSign anything, and whether or not ShareSign is still here.

First, the path. A leaf is the SHA-256 of the byte 0 and the fingerprint; each step joins with the byte 1, on the side the step names. It must end at the root:

python3 - proof.json <<'EOF'
import hashlib, json, sys
p = json.load(open(sys.argv[1]))
h = hashlib.sha256(b"\x00" + bytes.fromhex(p["fingerprint"])).digest()
for step in p["path"]:
    s = bytes.fromhex(step["hash"])
    h = hashlib.sha256(b"\x01" + (s + h if step["side"] == "left" else h + s)).digest()
print("path leads to the root:", h.hex() == p["root"])
EOF

Then each token, saved from its download address, against the root and your computer’s trusted certificates (on Debian and Ubuntu they are in /etc/ssl/certs/ca-certificates.crt):

openssl ts -verify -digest <root> -in digicert.tsr -CAfile /etc/ssl/cert.pem
Verification: OK

And the fingerprint is the file’s own: shasum -a 256 on the file must print the proof’s fingerprint. A seal made today is timestamped tonight; until then its result says so.

Every event above is a row in an append-only table: the database itself refuses to update or delete a row, for us as much as for anyone. Each row carries a SHA-256 hash of the previous row’s hash together with its own contents, so the trail is a chain. Change one row, or remove one, and every hash after it stops matching; a break is detectable, and a trail that verifies is one that has not been touched since it was written.

The trail is shown on the document page as its activity, and returned by the API at GET /v1/documents/{id}/audit with each row’s hash, so you can keep a copy and verify it yourself. It can also be downloaded as a spreadsheet.

The trail can be downloaded as a CSV file that opens in Excel, Numbers or Google Sheets, on every plan. For one document, use Download as CSV beside its activity. For every document between two days, up to a year at a time, an owner or admin uses Settings, Data. Deleted documents are left out, and taking the whole trail out is itself recorded in the workspace’s activity.

ShareSign does not yet issue advanced (PAdES) signatures sealed with a hardware-backed key, or qualified electronic signatures through a qualified trust service provider. Both are planned. If your agreement requires one of them today, ShareSign is not the right tool for that document, and we would rather say so here than on the day it matters.

Where the data lives, how it is encrypted, and how long it is kept is on data and regions; the one-page summary with links to every underlying document is the trust page.