Trust model

SignBona signatures meet the requirements of the federal ESIGN Act (15 U.S.C. §7001 et seq.) and the UETA: they uniquely identify the signer, are linked to the signed data such that any subsequent modification is detectable, and are generated using means under the signer's sole control (their verified email plus an OTP code). Each signature additionally includes robust cryptographic evidence (PAdES, RFC 3161 timestamp and HMAC audit chain) that exceeds the legal minimum.

Certain documents are excluded by law from electronic signature (wills, certain family law matters, transactions governed by the UCC other than §§1-107, 1-206, 2 and 2A, and documents requiring notarial acknowledgement). For those cases you must use a wet-ink signature or a notary public.

Each signed PDF embeds a PKCS#7 (CMS) object in PAdES BASELINE-T format:

• Signature algorithm: RSA-SHA256 (2048-bit key).
• Document hash: SHA-256 over the full ByteRange of the PDF, excluding the space reserved for the signature.
• signing-certificate-v2 attribute (RFC 5035 / ESS) binding the signature to the signer's certificate.
• SubFilter = ETSI.CAdES.detached for correct PAdES classification by external validators.
• Qualified RFC 3161 timestamp embedded as the unsigned signature-time-stamp attribute, proving the signature existed at the exact instant of sealing.

SignBona operates its own self-issued CA. Each signature is performed with an ephemeral X.509 certificate generated on the spot, bound to the signer's verified email and signed by the platform's CA. This CA is not included in the Adobe Approved Trust List (AATL).

Practical consequence: when opening a signed PDF in Adobe Acrobat Reader, you will see a yellow triangle of "signer identity unknown" until the verifier manually adds SignBona's CA to their trust store, or uses the public verification page (see verification section).

This does not affect the legal validity of the signature under the ESIGN Act or UETA — neither law requires the certificate to chain to a specific public root. Integrity and authorship are proven by the cryptographic signature and the audit chain, not by recognition of the certificate's issuer.

You can download the public CA certificate at /api/ca/sign-ca.cer and the revocation list at /api/crl/sign-ca.crl.

The CA's private key is stored encrypted at rest with AES-256-GCM. The encryption key lives exclusively as an environment variable on the hosting provider (Vercel) and is never accessible from the database.

The operator additionally keeps a GPG-encrypted (AES-256) offline copy in at least two distinct physical locations. This allows recovery if the database row is lost without compromising security: even a full DB dump would not let an attacker forge signatures retroactively.

Each signature includes an RFC 3161 timestamp issued by an external timestamping authority (TSA). The TSA receives only the cryptographic digest (SHA-256) of the signature; never the document content.

The timestamp proves the signature existed at the recorded instant, neutralising disputes about the actual signing date even if SignBona's server clock were compromised. The TSA operates under the international RFC 3161 standard, recognized by PAdES validators and accepted as evidence in U.S. court proceedings.

Each event in the envelope's lifecycle (created, sent, viewed, OTP requested, OTP verified, signed, completed, declined, voided) is recorded in a table guarded by triggers that block UPDATE and DELETE. Each event includes a chained hash:

• chain_hash[n] = HMAC-SHA256(secret, chain_hash[n-1] || event_payload[n])
• The HMAC secret is stored outside the database as an environment variable and as a PostgreSQL GUC.
• Any alteration or reordering of events breaks the chain at the altered event, and the verifier detects the tampering with the exact index of the first broken event.

Additionally, an integrity table (envelope_integrity_log) stores SHA-256 hashes of the document's critical milestones — original snapshot, stamped PDF, PAdES-signed PDF, TSA-sealed — forming a second cross-evidence.

There are three independent paths to verify a SignBona-signed document:

The following providers participate in delivering the service. All are bound by a data processing agreement (DPA); specific details appear in the privacy policy:

• Supabase — PostgreSQL database, authentication, storage. Encrypted at rest and in transit.
• Vercel — application hosting and function execution.
• Resend — transactional email delivery (invitations, OTPs, reminders).
• Timestamping authority (TSA, RFC 3161) — receives only the SHA-256 hash of the signature.
• Sentry (when configured) — technical error collection. Does not receive document content.

As part of our transparency commitment, we list the technical limitations of the service in its current form:

• No long-term archival (LTV / B-LTA): signatures are generated at BASELINE-T level. We don't embed OCSP/CRL responses or apply periodic post-timestamps. For cryptographic preservation beyond the validity of the signer's certificate (10 years), keep an additional copy outside the service.
• Identity verification based on email + OTP only: we don't perform biometric or ID-document verification. For cases requiring stronger KYC (KBA or ID verification), consider an additional specialized service.
• Self-issued CA, not AATL: see section 3.
• No own OCSP responder: revocation checks happen via CRL distributed at /api/crl/sign-ca.crl.

For technical questions about the trust model, write to support@signbona.com. For data protection matters, privacy@signbona.com. Legal matters are handled at legal@signbona.com.