Sealing

The seal is a property of the bytes

A wet stamp on a printed page is one stamper, one moment, one piece of paper. A digital seal must be all of that — plus verifiable by anyone, decades from now, without trusting us to confirm it. We layer four published cryptographic standards so the seal survives copy-paste, server outages, and EngineeringID itself going away.

Executive summary

One sealing operation produces a SHA-256 hash of the document bytes, an X.509 PKI digital signature over that hash, an RFC 3161 timestamp from a third-party authority, and a PDF/A archival conversion. Any change to a single byte breaks the hash; the seal becomes mathematically invalid.

Sealing requires MFA, a current credential, and an active session — the gate is at the moment of signing, not at login. A stolen session cookie cannot produce a forged seal. A leaked password cannot produce a forged seal. The friction is the feature.

Our commitments

Five rules for the sealing operation

The hash is over the bytes, not a representation

We hash the raw PDF stream, not a normalized rendering. Re-saving, flattening, or rewriting metadata changes bytes and invalidates the seal.

The timestamp is from an external clock — on every seal

Every seal carries an RFC 3161 timestamp from DigiCert's public TSA, embedded in the PDF and stored on the seal record. The seal time is signed by an independent third party — we cannot backdate or alter it after the fact.

MFA gates every seal

Even on a fully trusted device with an active session, sealing requires a fresh TOTP. The gate is at the moment of signing, not at login.

The credential must be current at seal time

An expired or suspended license fails the gate before the cryptographic operation runs. Backdated seals against expired licenses are not possible.

Verification works without us

The seal is a PKCS #7 / X.509 container — verifiable with Acrobat, openssl, or any standard tool. Our infrastructure can disappear and the seal still verifies.

Implementation — the seal envelope

What sealing actually does

Content hash SHA-256 NIST FIPS 180-4; streaming Elixir implementation

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

Certificate format X.509 v3 RFC 5280; customer or platform-issued

Signature container PKCS #7 / CMS detached RFC 5652 — embedded in the PDF

Trusted timestamp RFC 3161 on every seal DigiCert public TSA. Token is embedded in the PDF's PKCS#7 SignerInfo and persisted on the seal record; best-effort — if the TSA is unreachable the signature remains valid and the seal still issues.

Archival conversion PDF/A-2b ISO 19005-2 — embedded fonts and ICC profiles

MFA gate TOTP at seal time No "remember device" bypass; runs on every seal

Credential check Current at seal time Expired/suspended licenses fail the gate before signing

Versioning DocumentVersion record Every seal produces an immutable version with content_hash

Verification code Base32-encoded short ID Points to public verification page

Implementation — batch sealing

When you need to seal a hundred at once

Engine Oban background queue Per-document jobs; retries with exponential backoff

Progress Real-time via PubSub LiveView subscribes; progress bar updates without polling

State machine :pending → :processing → :completed Per-item; partial failures don't block the batch

MFA gate Once per batch session One TOTP authorizes the batch; individual seals don't re-prompt

Atomicity Per-document A failed seal doesn't corrupt others; retry is per-item

Concurrency limit Per-org Oban queue size Configurable; protects database under heavy load

The full picture

What is built, what is being built, and what we chose not to build

Live today

Single-document sealing with the full envelope

Live

SHA-256 + X.509 + RFC 3161 + PDF/A-2b in a single operation. The DigiCert TSA token is embedded in the PDF's PKCS#7 SignerInfo and persisted on the seal record on every seal (KMS and BYO-key).

Batch sealing via Oban

Live

Multi-document with per-item retry, real-time progress, partial-failure tolerance.

Cloud storage post-commit upload

Live

Sealed documents auto-sync to S3 / Azure / Google Drive / SharePoint / Box / etc.

Public verification API

Live

POST /v1/verify/pdf — anyone can confirm authenticity without an account.

Bring-your-own X.509 certificate

Live

Use a cert from your existing CA; we never see the private key for those signatures.

Building now

Long-Term Validation (LTV) embedding

Building now

ETSI PAdES B-LTA — embed the full revocation chain so seals stay verifiable after the signing cert expires.

Target: this quarter.

Multi-page seal placement controls

Building now

Per-page seal positioning rules instead of single-page default.

Roadmap

Customer-configurable RFC 3161 TSA endpoint

Roadmap

Org-level TSA selection — point seals at your compliance team's pre-approved authority instead of the platform default. Today the TSA is set platform-wide via the TSA_URL environment variable.

Hardware-backed signing keys (BYO KMS)

Roadmap

Per-customer KMS-resident signing keys so private material never leaves the customer's HSM.

Post-quantum hybrid signatures

Roadmap

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

On-document QR verification code

Roadmap

Optional embedded QR linking directly to the verification page.

Considered & rejected

Blockchain-anchored seals

Considered & rejected

A SHA-256 hash plus an RFC 3161 timestamp from a CA-grade authority gives the same tamper evidence at zero per-seal cost.

Why we rejected it: blockchain solves "no trusted third party exists." We have one — the TSA. RFC 3161 is the eIDAS / 21 CFR Part 11 / common-law-evidence answer to "prove this was unmodified at this time." Blockchain adds latency, unbounded cost, and probabilistic finality without solving any problem we have.

"Normalized" PDF hashing

Considered & rejected

A hash that is stable across "harmless" edits is, by definition, 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.

Persistent "MFA bypass for sealing" for power users

Considered & rejected

The MFA prompt at seal time is the entire point. A bypass collapses the gate to login-only.

Why we rejected it: we accept the friction of one TOTP code per seal. The cost is six digits; the benefit is that a stolen session cannot produce a forged engineering seal.

Visual-only watermarks as integrity proof

Considered & rejected

Watermarks survive until the first screenshot. Cryptographic hashes do not survive even one bit change.

Why we rejected it as integrity: the visual stamp is for human recognizability. The cryptographic surface is the integrity. They are different layers — we do not pretend a watermark is tamper detection.

Compliance mappings

Controls this surface satisfies

SOC 2 CC7.1

Detection of Anomalies

Hash mismatch is a deterministic anomaly signal

ISO 27001 A.10.1.1

Cryptographic controls

NIST/IETF-standardized primitives end-to-end

21 CFR Part 11 11.10(a)

Validation of systems

Documented controls and audit trail for electronic records

ESIGN Act §101(d)(1)

Retention of contracts and records

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

UETA §7

Legal recognition of electronic signatures

Attribution + intent to sign + consumer disclosure

For compliance teams

Questions you do not need to call to ask

What changes invalidate a seal?

Any byte-level change to the PDF. Re-saving in Acrobat, flattening forms, optimizing for web, or rewriting metadata all change bytes and break the hash. The seal is intentionally fragile in that direction.

Can a verifier check a seal offline?

Yes. The X.509 signature, the RFC 3161 timestamp, and the embedded certificates make verification fully offline-capable. Our infrastructure is not in the verification path.

What happens to seals when the signing certificate expires?

Verification still passes for seals applied while the cert was valid, because the RFC 3161 timestamp proves when the signature was made. LTV embedding (in progress) bakes the revocation status in at seal time.

How does sealing fail safely?

Cryptographic operations are wrapped in panic-catching primitives at the NIF boundary. A signing failure rolls back the transaction; the document remains in its pre-seal state. No partial seals.

Can we use our own signing certificate?

Yes — upload a CA-issued cert; we never see the private key for those signatures. Customer-uploaded certs are stored encrypted at rest.

What's the verification rate limit?

60 requests per minute per IP on the public :verify_api bucket. CORS-permissive on this route only so any third-party tool (Acrobat plugin, Chrome extension, your IT script) can call it.

Sealing that holds up to its own audit

Read the deeper document-integrity story or talk to our team about your specific control requirements.

Get Started See document integrity