TrustBridge Certificate Authority

Certificate Policy / Certification Practice Statement

Version 0.3, effective 2026-09-21. TrustBridge is not yet independently audited; this document describes current practice, not a compliance attestation. Structured after RFC 3647 so it's directly comparable to a public CA's CP/CPS, even while operating as a private CA.

1. Introduction

TrustBridge is a certificate authority operated by Jeff Parrish PC Services LLC ("JPPS"). It issues four classes of end-entity certificate — TLS server, code-signing, S/MIME (secure email), and client-authentication — each against its own dedicated provisioner with its own duration limits and extended key usage. TrustBridge operates a two-tier hierarchy: an offline root CA and one online intermediate CA. Only the intermediate ever signs end-entity certificates — the root's private key has been removed from every network-connected system (confirmed 2026-09-21; the running CA's configuration references only the intermediate key).

2. Publication & repository

Root and intermediate certificates, and their SHA-256 fingerprints, are published at /roots. This policy document is published at /policies. A certificate revocation list is published at ca.pki.jpps.us/crl (regenerated on every revocation, cached 24h), and a live OCSP responder is available at ocsp.pki.jpps.us for real-time status checks. A full audit trail of logins, issuances, and revocations is kept internally (not yet published externally) — see §6. A future public issuance log is planned but not yet implemented — see §9.

3. Identification & authentication

Two issuance paths exist, with different assurance levels:

• Portal issuance (/portal) — authenticated by an admin session, issued individually to a named person. There is no domain-validation step here; trust is rooted entirely in who holds a portal account, which is why portal accounts are issued sparingly (see /portal's admin management page). This path is meant for infrastructure the operator directly controls, and is the only path for code-signing, S/MIME, and client-authentication certificates.
• ACME issuance (ca.pki.jpps.us) — standard ACME protocol (RFC 8555), the same domain-validation model Let's Encrypt uses. A client proves control of a domain via a challenge before a TLS certificate is issued. This is the appropriate path for anything not already under direct operator control. Currently TLS-only — no equivalent automated identity-vetting exists yet for the other three certificate types.

4. Certificate lifecycle

• Issuance: a portal admin submits a request (hostnames for TLS, a subject name for code-signing, an email address for S/MIME, a person/device name for client-auth); the portal builds the request and forwards it to step-ca's REST API, authenticated with a dedicated provisioner key held only by the portal process — a separate provisioner per certificate type, each with its own duration cap and certificate template granting the correct extended key usage.
• Validity — CA/Browser Forum Baseline Requirements followed even though not yet required, on a schedule that keeps tightening:
  • TLS: default 90 days, hard-capped at 200 days — the current phase of CABF's approved schedule (Ballot SC-081v3), which steps down further to 100 days on 2027-03-15 and 47 days on 2029-03-15.
  • Code-signing: default 730 days, capped at 1095 days (3 years) — the CABF Code Signing BR maximum.
  • S/MIME: default 365 days, capped at 825 days — the CABF S/MIME BR maximum for a mailbox-validated certificate.
  • Client-authentication: default 365 days, capped at 730 days — no CABF requirement applies (client certs are outside public Web PKI scope); this is a sane default, not a mandated figure.
• Code-signing key generation is software-based, not HSM-backed — a known, permanent limitation on public trust, independent of validity length. Since 2023-06-01, the CABF Code Signing Baseline Requirements mandate that any publicly-trusted code-signing private key (EV or non-EV) be generated and held on a FIPS 140-2 Level 2 / Common Criteria EAL 4+ hardware module, non-exportable. TrustBridge offers both a software-key path (private key generated on the server, shown once, clearly labeled lower-assurance) and a hardware-backed path (the requester generates the key on their own token, e.g. a YubiKey PIV slot, and submits only a CSR — the private key never touches TrustBridge at all). Only the hardware-backed path can ever meet the CABF requirement.
• Revocation: supported for every certificate type. The portal's dashboard has a Revoke button per certificate, which calls step-ca's revocation API, adds the certificate's serial to the published CRL, and marks it revoked for OCSP. Revocation is immediate; CRL cache is at most 24h stale, OCSP responses are refreshed at most every 5 minutes.
• Key custody: for the software-key issuance paths, the private key is shown once, at issuance time, and is not retained by TrustBridge — losing it means requesting a new certificate, not recovering the old one. For the hardware-backed code-signing path, TrustBridge never possesses the private key at all.

5. Facility, management & operational controls

step-ca and the TrustBridge portal run on a dedicated, minimal LXC container, separate from every other service TrustBridge doesn't need to share a host with. The root CA's private key has been removed from that host entirely, encrypted-at-rest in an offline backup — see §1.

6. Technical security controls

The intermediate CA's signing key lives only on the dedicated CA host. Each provisioner's key (used to authorize signing requests to step-ca, not a CA key itself) is held in the portal process's environment, not committed to source control or logged. Portal sessions are HMAC-signed (constant-time verified), HttpOnly, 12-hour tokens. The portal's HTTP client is pinned to TrustBridge's own root certificate rather than trusting the system store or disabling verification. Every login (success and failure), issuance, revocation, and admin-account change is recorded in an append-only audit log with actor, timestamp, and source IP.

7. Certificate, CRL & OCSP profiles

TLS certificates: server-auth EKU, SANs as requested. Code-signing: codeSigning EKU only. S/MIME: emailProtection EKU, an email-address SAN. Client-authentication: clientAuth EKU, no SAN. All ECDSA P-256, each via its own dedicated certificate template. A CRL is published and regenerated on every revocation. A live OCSP responder answers real-time status queries, signed directly by the intermediate CA key, with its status index regenerated from TrustBridge's own issuance records every 2 minutes.

8. Compliance audit

None performed. This is the primary remaining gap between "private CA with good practices" and "publicly trusted CA," and isn't a quick fix — a WebTrust or ETSI audit against an established CA/Browser Forum baseline is a multi-year undertaking requiring an accredited external auditor, not something that can be done in-house. Documented here as the honest current state, not a near-term roadmap item.

9. Known gaps / roadmap

• No public Certificate Transparency logging. CT exists so browsers and monitors can detect certificates a publicly-trusted CA issued without the domain owner's knowledge — it has no purpose for a private root nobody's browser trusts or checks by default, so this isn't planned unless/until public trust becomes a real goal.
• No independent audit — see §8.
• Code-signing hardware-key path requires the requester's own token — TrustBridge doesn't provide or manage the hardware itself, and the software-key fallback remains available for lower-assurance use (see §4).
• ACME domain validation only covers TLS, not the other three certificate types (see §3) — no automated identity-vetting equivalent exists yet for them.
• The audit log (§6) is internal only — not yet published or exportable outside the portal's own admin view.