Document integrity

Every seal is mathematically tamper-evident

A professional seal stops being meaningful the moment a single byte of the document can change without detection. We layer four published standards — SHA-256 content hashing, X.509 PKI signing, RFC 3161 trusted timestamps, and PDF/A archival — so altering the document, the seal, or the time it was applied is mathematically detectable, not merely policy-discouraged.

Executive summary

Every sealed document carries a SHA-256 hash of its bytes, embedded in an X.509 PKI digital signature, anchored to a real-world clock by an RFC 3161 trusted timestamp from a third-party authority. Change one byte and verification fails.

The sealed file is converted to PDF/A archival format (ISO 19005) so the document remains visually identical decades from now — fonts, color profiles, and structure are embedded, not referenced. The seal isn't a sticker on the file; it's a cryptographic property of the file.

Our commitments

Five rules for every sealed document

If any one of these breaks, the seal is invalid. There is no "valid but slightly tampered."

The hash is over the bytes, not a representation

We hash the raw PDF stream. Re-saving, re-flattening, or rewriting metadata changes bytes — and breaks the hash. We don't allow normalized hashing that papers over modifications.

The timestamp is from a third-party clock

The seal time is signed by an external RFC 3161 Time Stamp Authority (DigiCert) — not our server clock. We can't backdate or alter when a seal was applied even if we wanted to.

The signature is X.509 PKI, not proprietary

The signature is verifiable with any X.509-aware tool. Acrobat, openssl, your CA, your IT team — anyone can independently confirm the seal without trusting EngineeringID to confirm it.

The archival format is open and self-contained

PDF/A-2b embeds every font, color profile, and structural element. The document renders identically a decade from now without depending on external resources or proprietary readers.

Verification works without us

Anyone with the document can verify it offline using public-key cryptography. Our infrastructure can disappear and the seal remains independently checkable.

Implementation — content hashing

The hash is the document's fingerprint

Algorithm SHA-256 NIST FIPS 180-4

Implementation Streaming Elixir hash Bounded memory regardless of file size

Surface hashed Raw PDF bytes Not a re-rendered or normalized representation

Verification path Constant-time compare Prevents timing oracles on hash equality

Embedded in seal DocumentVersion.file_hash Per-version, immutable; new seal = new version

Implementation — digital signature

X.509 PKI, not security theater

The signature is a public-private key operation, not a stored "approved" flag in our database.

Signature algorithm RSA-PSS RFC 8017 (PKCS #1 v2.2)

Certificate format X.509 v3 RFC 5280

Key length RSA-4096 default 2048 / 3072 / 4096 supported

Private key storage AES-256-GCM encrypted at rest Never decrypted outside the signing path; redact: true on schema

Embedded format PKCS #7 / CMS detached RFC 5652 — standard PDF signature container

Verification tools Acrobat, openssl, your CA Any X.509-aware verifier works; no EngineeringID dependency

Bring your own cert Customer-uploaded supported Use your own CA-issued cert; we never see the private key for those signatures

Implementation — trusted timestamp

A clock we cannot move

Standard RFC 3161 IETF X.509 Internet PKI Time-Stamp Protocol

TSA provider DigiCert (default) Customer-configurable; any RFC 3161 TSA accepted

Token format DER-encoded TimeStampToken ASN.1 binary, embedded in the signature

Embedded surface SHA-256 of document The TSA signs the hash, not the document — preserves confidentiality

Network behavior Circuit-breaker protected TSA outage triggers a fast fail, not a hung seal

Offline verification Yes, with TSA cert The TSA's public cert is enough to verify the timestamp years later

The full picture

What's built, what's being built, and what we chose not to build

Document integrity is the product. We are explicit about every boundary.

Live today

SHA-256 streaming hash

Live

Bounded memory regardless of file size.

X.509 PKI signatures with PKCS #7 embedding

Live

Verifiable with Acrobat, openssl, or any X.509 tool — no EngineeringID runtime dependency.

RFC 3161 trusted timestamps from DigiCert TSA

Live

External clock proves when the seal was applied, not just our server's view of when.

PDF/A-2b archival conversion (ISO 19005-2)

Live

Embedded fonts, ICC color profiles, self-contained structure. Renders identically forever.

Bring-your-own-certificate

Live

Upload an X.509 cert from your own CA; we never see the private key for those signatures.

Public verification API

Live

POST /v1/verify/pdf accepts a hash + verification code; rate-limited; CORS-permissive on this route only.

Building now

Long-Term Validation (LTV) signature embedding

Building now

ETSI PAdES B-LTA — embed the full revocation chain in the document so it remains verifiable after the signing certificate expires or is revoked.

Target: this quarter.

Customer TSA configuration

Building now

Org admins choose their own RFC 3161 TSA endpoint instead of the default DigiCert. Useful for regulated industries with TSA preferences.

Roadmap

Post-quantum hybrid signatures

Roadmap

CRYSTALS-Dilithium primitives are compiled into the Rust NIF. Production signing callers and schema columns are not yet wired.

Tracking the cryptographic community's adoption curve before defaulting it on.

Hardware-backed signing keys (HSM / KMS)

Roadmap

Per-customer KMS-resident signing keys so private material never leaves the customer's HSM. See Key Management for the BYO-KMS roadmap.

On-document QR verification code

Roadmap

Embed a QR code on the visible seal that resolves to the verification page. Optional — many engineers prefer the seal's existing visual cleanliness.

Considered & rejected

Blockchain anchoring of document hashes

Considered & rejected

A SHA-256 hash plus an RFC 3161 third-party timestamp gives the same tamper-evidence at zero cost per seal.

Why we rejected it: blockchains optimize for the case where you don't trust any single party, by paying every time you write. RFC 3161 already gives you a signed timestamp from a CA-grade third party — which is the exact trust property you want, without per-write cost, latency, or probabilistic finality. Customers who need multi-party consensus can use multiple TSAs; that's a stronger guarantee than a single chain anyway.

Visual-only watermarks as integrity proof

Considered & rejected

A watermark survives until the first screenshot. Cryptographic hashes don't survive even one bit change.

Why we rejected it as integrity: we use visual elements (the engineer's stamp, signature image) for human recognizability. We do not pretend they are tamper-detection. The hash + signature is the integrity. The visual is presentation.

AI-based forgery detection

Considered & rejected

A probabilistic check is exactly the wrong tool when one false negative means a forged engineering seal is accepted.

Why we rejected it: AI introduces "we think it's real" where deterministic crypto gives "it's mathematically real or it isn't." For a regulated act with legal consequences, the probabilistic answer is malpractice. We may use ML to flag suspicious workflows, but never as the verification primitive.

Modifying or "normalizing" the PDF before hashing

Considered & rejected

A normalized hash that's stable across "harmless" edits is, definitionally, a hash that hides edits.

Why we rejected it: every "normalization" rule is a way to silently accept some changes. The right answer is: hash the bytes. If the document changes, the hash changes. If you want to seal a different version, seal it explicitly.

Custom signature format

Considered & rejected

An open standard your auditor's tool already speaks beats any "improvement" we could ship.

Why we rejected it: regulators and reviewers verify with the tools they already have. A signature only EngineeringID can verify is a signature with one verifier. A PKCS #7 / X.509 signature has every verifier ever built.

Compliance mappings

Controls this surface satisfies

SOC 2 CC7.1

System Operations — Detection of Anomalies

Hash mismatch is an immediate, deterministic anomaly signal

ISO 27001 A.10.1.1

Cryptographic controls

SHA-256, RSA-PSS, RFC 3161 — all NIST/IETF-standardized

ISO 27001 A.12.2.1

Controls against malware

Tampered files fail signature verification before they can be served

21 CFR Part 11 11.10(e)

Audit trail — secure, computer-generated

Hash chain of seal events; non-repudiation via X.509 signature

ESIGN Act §101(d)(1)

Retention of contracts and records

PDF/A-2b archival format meets long-term retention requirements

For compliance teams

Questions you don't need to call to ask

What changes invalidate a seal?

Any change to the byte sequence of the PDF. Re-saving in Acrobat, flattening forms, optimizing for web view, even adding a comment — all of these change bytes and break the hash. The seal is intentionally fragile in this direction.

Can a verifier check the seal without internet access?

Yes. The signature is X.509 PKI; the timestamp token is self-contained. With the document, the signing certificate, and the TSA certificate (both publicly available), verification is fully offline. The verification code lookup against the public API is a convenience, not a requirement.

What happens to seals when the signing certificate expires?

Verification still succeeds for seals applied while the certificate was valid, because the RFC 3161 timestamp proves when the signature was made. LTV embedding (in progress) bakes the revocation status into the document at seal time so verification remains strong even after the issuing CA goes offline.

Do you store the original document hash, or compute it on demand?

Both. The hash is computed and stored at seal time on the DocumentVersion record. On verification, we recompute the hash from the bytes you submit and constant-time compare against the stored value.

Is the verification page rate-limited?

Yes — 60 requests per minute per IP on the :verify_api bucket. The CORS policy is permissive on this route so any third-party tool (Acrobat plugin, Chrome extension, your IT team's verification script) can call it. No other EngineeringID route allows cross-origin POST.

What's your retention policy for sealed documents and their hashes?

DocumentVersion records (which carry the hash, signature, and timestamp) are retained per your organization's audit retention policy. The default is "indefinite" — sealed records are part of your professional record and we treat them as such.

Can two documents collide on SHA-256?

In principle, yes — SHA-256 has a finite output space. In practice, no SHA-256 collision has been demonstrated in 20 years of attacks, and a chosen-prefix collision against an arbitrary file is a research-grade, multi-million-dollar undertaking. The integrity guarantee is "computationally infeasible to forge," not "metaphysically impossible to have collided."

The seal is the math, not the sticker

See the verification flow in action, or talk to our security team about the cryptographic boundaries.

Try verification Talk to security team