Sobamail Platform PKI¶

Table of contents¶

1. Overview
2. Architecture
3. Cryptographic standards
4. Certificate profiles
5. Name Constraints
6. Rotation and revocation
7. Trust
8. Blast radius

Overview¶

The Sobamail PKI is a closed, operator-controlled private certificate hierarchy that provides cryptographic identity for four distinct roles: TLS authentication of Sobamail servers, email data signing by users, TLS client authentication of mailbox replicas toward the ink servers, and platform code signing. Every authenticated interaction terminates in identities issued under this PKI: servers authenticate with Server-branch certificates, and replicas authenticate with Peer-branch credentials. The hierarchy stands on its own: every Sobamail certificate validates against the Sobamail roots, which relying parties receive from Sobamail (see Trust anchors).

The PKI is designed around four explicit constraints:

• Per-replica cryptographic isolation. A compromise of one replica's keys stays confined to that replica. Every other replica, every user, the central infrastructure and every other identity within the system stay out of its reach.
• Role separation by hierarchy branch. Distinct cryptographic functions (server TLS authentication, S/MIME data signing, replica client authentication, code signing) live in separate sub-CA branches, with EKU-enforced boundaries between them.
• Modern cryptography throughout. Every cert in the hierarchy uses the same algorithm family (ECDSA on P-256 with SHA-256), which keeps algorithm-related compatibility concessions out of the design.
• Structural defense over policy. Security properties are enforced by cert extensions (Name Constraints, EKU chaining, path length, criticality), so they hold independently of operator discipline. A compromised issuance pipeline is bound by the same constraints, since every validator checks the shape of every cert.

This document describes the PKI's structure, its certificate profiles, the operational procedures that maintain it, and the integration with NSS that backs both issuance and validation.

Architecture¶

The PKI is a hierarchy with four parallel sub-CA branches sharing a single offline root. The diagram shows the 2027 set, the one new issuance uses; the 2025 and 2026 vintages stay in every store for validation (see Trust).

---
title: Current Certificate Hierarchy
---
flowchart TD
    root["<b>Root 2027</b><br/>offline"]

    server["<b>Server</b><br/>intermediate"]
    data["<b>Data</b><br/>intermediate"]
    peer["<b>Peer</b><br/>intermediate"]
    codesign["<b>Codesign</b><br/>intermediate<br/>(reserved)"]

    serverleaf["Server TLS<br/>leaf"]
    dataleaf["Data-signing<br/>leaf"]
    localca["Local CA<br/>(one per replica)"]
    clientleaf["Replica TLS<br/>client leaf"]

    root --> server --> serverleaf
    root --> data --> dataleaf
    root --> peer --> localca --> clientleaf
    root --> codesign

The boxes abbreviate: the root's subject is CN=Sobamail Root 2027, C=TR, an intermediate's CN=Sobamail <Branch> Intermediate 2027, C=TR with <Branch> spelled out as Server Authentication, Data Authentication, Peer Authentication or Codesign. Each branch's EKU is in Branch separation below, every leaf lives ~33 days, and the local CA is confined to its replica's own DN subtree by Name Constraints with a path length of 0.

Root is offline. Its private key lives in hardware (HSM or smartcard with hardware attestation) and comes online for the scheduled annual ceremony alone, in which a new root is generated and the oldest root still in its three-year signing window signs the year's sub-roots.

Issuing intermediates are online. They are reissued annually under a new sub-root cert signed with the oldest root still inside its three-year signing window. Each handles issuance for exactly one branch:

• Server issues TLS server certificates for Sobamail infrastructure, and that alone. It is an operator-only CA: every certificate (and private key) issued under this branch stays in operator custody, because this branch is what relying parties use to decide "this is a genuine Sobamail server". A Server-branch credential in anyone else's hands is the ability to impersonate Sobamail servers.
• Data issues data-signing leaves directly to users, so users can sign their email.
• Peer issues local certificate authorities to user replicas. Each local CA in turn issues its replica's own client certificate toward the ink servers.
• Codesign is reserved for signing platform binaries, such as the Windows .exe installer. It is dormant for now: signing the installer starts to pay off once platform trust stores recognize the signer, and a private CA has yet to earn that recognition.

Local CAs exist only in the Peer branch. Each replica has its own dedicated CA, scoped by a critical Name Constraints extension to that replica's own DN subtree and a path constraint value of 0. This is the layer that provides per-replica cryptographic isolation: a replica's local CA mints credentials for that one replica alone, whatever happens to its key, and every other replica, user and central service stays out of its reach.

Leaves carry the actual operational identities. They are short-lived (nominally 33 days) and rotated automatically. Their short validity is the system's primary, passive revocation mechanism (signed CRLs over email cover the faster cases, see Revocation): a leaf compromise has a worst-case useful lifetime bounded by the cert's notAfter, after which it stops validating on its own.

Replica authentication¶

Each replica operates a local CA, issued by the Peer Authentication Intermediate, whose Name Constraints confine it to the replica's own DN subtree. The local CA signs the replica's own TLS client certificate, used to authenticate the replica to the ink servers. This is a standard clientAuth chain (leaf → local CA → Peer Authentication Intermediate → root) that the ink server validates against the trust store; the local CA's Name Constraints guarantee the asserted identity lies inside the replica's own subtree, so the cert identifies exactly one replica of one user.

Outside the Server branch, validation reads the UID and DC attributes of the subject, which the Name Constraints pin to the replica's own subtree; the CN value is free text there.

Branch separation¶

The four branches are deliberately independent, with role boundaries enforced by EKU chaining at every level:

A Peer-branch leaf signs TLS handshakes, and that alone, since its EKU is clientAuth; a Data-branch leaf signs data, and that alone. EKU chaining is enforced at every level, so a CA produces valid certs for its own branch's role only, whoever holds its key.

The Peer branch declares both serverAuth and clientAuth, and the local CAs under it carry both as well. Identity toward Sobamail infrastructure is the Server branch's alone, and its credentials stay in operator custody.

Cryptographic standards¶

The PKI is exclusively EC-based: every cert in the hierarchy carries a P-256 key, and every validation path requires one. This is a deliberate choice with several consequences:

• One meaning per key usage bit. EC keys agree on keys, so encryption-recipient roles use keyAgreement, and a keyEncipherment bit (RSA key transport) is a profile error wherever it appears.
• A smaller attack surface. The RSA-PKCS#1-v1.5 family of attacks (Bleichenbacher and descendants) needs RSA padding to work on, and the PKI consists of EC signatures throughout.
• Single algorithm pipeline. Every signature operation, validation operation, and key-management procedure uses the same algorithm. This simplifies tooling, audit, and operational training.
• Smaller certs and signatures. ~64-byte signatures and ~91-byte EC public keys reduce cert chain size on the wire, relevant for handshake performance and message-bundled chains.

Certificate profiles¶

Every cert in the PKI conforms to one of the role profiles below. Profiles are enforced at issuance: the signer takes the profile by name and writes that profile's Key Usage, Extended Key Usage and Basic Constraints (all critical, path length included), and leaves the CSR's extensionRequest attribute unread. A CSR that asks for CA:TRUE, a wider EKU or a SAN gets a certificate shaped by the profile alone. The subject comes from the CSR verbatim, so it is validated, attribute by attribute, before anything is signed: the attributes the profile names and those alone, spelling out the requesting user.

Throughout, DC=example, DC=com stands for the deployment's actual domain components.

Serial numbers encode the certificate's generation time as a tick count since a Sobamail-specific epoch. Serials only need to be unique per issuer; the issuance pipeline guards against two issuances landing in the same tick.

Root CA profile¶

The root's Key Usage is keyCertSign and cRLSign, by design. The key signs sub-root certs and the CRLs covering them, and that is the whole of its work. Least privilege at the root level bounds a compromise to issuing rogue certs; signed messages that appear to come from the CA, for example, stay out of reach.

The explicit EKU has one operational consequence: the set of branch roles a root can authorize is frozen at its generation. A new branch EKU goes on the next annual root, which, after its three-year soak, starts signing three years later. A new branch role therefore has a built-in lead time of roughly three years; an out-of-cycle ceremony that re-issues the in-window roots with the extended EKU set is the shortcut.

Issuing intermediate (sub-CA) profile¶

The 16 months are derived: an annual intermediate signs for the twelve months it is current, the longest-lived thing it signs is a local CA (3 months), and one month rounds the sum up. That is the one place where this PKI keeps slack. Downstream, every CA-issued certificate is clamped to its issuer's notAfter exactly, and renewals are triggered by the certificate's age alone, so a certificate shortened by the clamp renews on the same schedule as a full-length one.

Intermediates leave the path length open. The Peer Authentication branch alone has a CA tier below this point (the local CAs), and depth bounding there is enforced one level down, by the local CA's own pathLenConstraint: 0; the Server, Data and Codesign branches issue leaves directly. The open path length is also what permits scoped sub-intermediates: an intermediate can sign a further intermediate of its own branch, restricted by critical Name Constraints (see the Data branch profile for the supported pattern).

The critical EKU is the load-bearing mechanism for branch separation: trust-store validation for a given role succeeds only when every CA in the chain declares that role, so a cert claiming a different role from this branch fails EKU-chaining validation regardless of who signed it. The Peer Authentication Intermediate declares both serverAuth and clientAuth.

Server TLS leaf profile (Server branch)¶

Server-branch certs are issued exclusively to operator-controlled infrastructure, and their private keys stay in operator custody. This is hard policy: the Server branch is the trust basis for "this endpoint is a genuine Sobamail server", so a Server-branch credential outside operator control enables server impersonation against every client. The security of this branch is partly custodial, alone among the branches: structure (EKU) confines a leaked server cert to the TLS server role, and custody is what keeps it from impersonating infrastructure until it expires or a CRL revokes it.

This is the one branch where the value of the CN= attribute matters; everywhere else, validation reads the UID and DC attributes.

Data-signing leaf profile (Data branch)¶

Data-signing leaves let users sign their email. They are issued directly by the central Data Authentication Intermediate: the branch is two tiers deep, intermediate and leaf.

Scoped sub-intermediates. The Data Authentication Intermediate can also sign a further data intermediate restricted to a DN subtree by a critical Name Constraints extension, for example a sub-intermediate constrained to DC=example, DC=com that can issue data-signing leaves only for users of that domain. The sub-intermediate carries the same profile as its parent (critical emailProtection EKU, critical keyCertSign + cRLSign KU, CA:TRUE), plus critical permittedSubtrees naming the delegated subtree. A leaf whose subject falls outside the subtree can still be signed mechanically; every compliant validator then rejects the resulting chain, the same structural enforcement that protects the Peer branch's local CAs. This is the building block for delegated, domain-scoped issuance that keeps the branch-wide intermediate key at home.

All of this is manual: CSRs for name-constrained intermediates are reviewed by a person, case by case, and signed by hand.

The Data Authentication Intermediate stays in operator control, under the same custody as every other intermediate. Like the trust bootstrap of every replica, this branch rests on operator honesty: Sobamail signs data certificates for the requesting user alone. The custody framing also bounds the threat analysis: since all intermediates share the same operator infrastructure, a scenario in which the Data Authentication Intermediate is compromised is a scenario in which the whole intermediate tier is compromised, and its security equals the tier's.

nonRepudiation (RFC 5280 contentCommitment) is present here because data-signing signatures are intended as durable evidence: a signed message may be presented later as proof of the sender's authorship. This is the bit that authorizes that semantic, distinct from digitalSignature which covers ephemeral authentication signatures.

Signed data format¶

Signed data travels in one of two formats, both made with the sender's data-signing leaf. A message for Sobamail recipients carries the Sobamail envelope; a message for recipients on other mail clients carries, beside it, an S/MIME rendition those clients verify.

The Sobamail envelope is a structured object holding the sender address, the format tags of its payload, the payload itself (MessagePack), the signing certificate, the ecdsa-with-SHA256 signature over the payload and, when one was obtained, timestamps attesting when the signature existed. The envelope ships with its signing certificate alone. On reception, the certificate is validated against the local certificate store, the signature is checked against the payload, and the message's From is held to the certificate: it must equal the certificate's UID@DC or an rfc822Name its issuer attested, so a signed body travels under its signer's address alone. When the envelope carries timestamps, each is verified against its own signer's certificate and the earliest one anchors the check, so the signature is held to the instant it already existed; an envelope without one is checked against the current clock. If everything verifies, the envelope is stored together with the whole validating certificate chain in the local message database. The Sobamail message store deduplicates blobs, so the chain costs its bytes once. The archived chain is what keeps old signatures verifiable long after the issuing certificates expire and their roots leave the codebase.

The S/MIME rendition is an RFC 8551 multipart/signed of protocol application/pkcs7-signature with micalg=sha-256. Its first part, the Cryptographic Payload, is the whole message in canonical form (CRLF, 7-bit): every body part and attachment, a structured message's envelope as its Message-Structure attachment, and a copy of every header but Bcc, with hp="clear" on the root Content-Type (RFC 9788 header protection). Its second part is a detached CMS SignedData (smime.p7s) carrying the signing leaf and the intermediates above it, short of the root, and a signingTime equal to the message's Date, which for a delayed send is its delivery time. The Message-ID and Date are fixed before signing, so the copies a server regenerates equal the signed bytes. A verifier outside Sobamail needs the roots from Trust anchors; the message brings the rest of the chain along, and the signature verifies in any client that implements RFC 8551 with ECDSA P-256. On reception, Sobamail parses an S/MIME message whose payload protects its headers as that payload.

Local CA profile (Peer branch)¶

The Name Constraints base is identical to the CA's own subject DN: every cert this CA issues must have a subject inside the replica's own OU=peer subtree. This is the per-replica isolation mechanism: a local CA's private key, compromised or whole, mints credentials within its own replica's namespace alone, and chain validation holds every other replica and user out of its reach.

pathLenConstraint: 0 means this CA issues leaves, and leaves alone.

The EKU carries both clientAuth and serverAuth, matching the Peer Authentication Intermediate above it.

Replica TLS client leaf profile (Peer branch)¶

Presented by the replica to authenticate itself to the ink servers. This is a standard clientAuth chain (leaf → local CA → Peer Authentication Intermediate → root), validated by the server as certificateUsageSSLClient; the local CA's Name Constraints guarantee the asserted identity sits inside the replica's own subtree. The CN attribute carries the ink domain as a human-readable label; validation reads the UID and DC attributes, as everywhere outside the Server branch.

digitalSignature is the one KU bit set: for modern TLS (1.3 and ECDHE_ECDSA in 1.2), client authentication is signature-based and this is the one bit exercised. keyEncipherment is meaningless on an EC key, and TLS handshake signatures are ephemeral authentication, so nonRepudiation stays with the durable evidentiary commitments of the Data branch.

Codesign profile (Codesign branch)¶

Reserved: the leaf profile is defined and awaits activation. Leaves will carry KU digitalSignature and critical EKU codeSigning, for signing platform binaries such as the Windows installer. The branch exists in the hierarchy and rotates on the same annual calendar as the others, so activating it is a leaf-level change; it stays dormant until platform trust stores recognize the signer, which is when its signatures start improving the install experience.

Extension criticality summary¶

All security-relevant extensions are marked critical across all profiles. The intent is that a validator unable to process the extension rejects the cert, so the constraint holds everywhere:

• keyUsage: critical everywhere
• extKeyUsage: critical everywhere (deliberate; locks down role)
• basicConstraints: critical everywhere
• nameConstraints: critical on local CAs (RFC 5280 §4.2.1.10 mandates it, and the critical flag is what makes every validator honor the constraint)

subjectKeyIdentifier and authorityKeyIdentifier are non-critical per RFC 5280.

Name Constraints¶

Name Constraints provide compartmentalization beyond what EKU chaining offers. Where EKU bounds what kinds of certs a CA can issue, Name Constraints bound what names it can put in those certs.

Constraint scope¶

Local CAs in the Peer branch carry permittedSubtrees constraints whose base is the CA's own subject DN, the replica's OU=peer subtree. The constraint takes this form:

NameConstraints ::= SEQUENCE {
    permittedSubtrees [0] SEQUENCE OF GeneralSubtree {
        SEQUENCE {
            base [4] EXPLICIT Name {
                /* RDNSequence corresponding to:
                 * OU=<replica-UUID>, OU=peer, UID=<user>, DC=example, DC=com */
            }
        }
    }
}

The [4] EXPLICIT tag is used because directoryName wraps a Name CHOICE; X.680 requires explicit tagging over CHOICE base types, and several validators (Apple's stack among them) reject mis-tagged constraints.

The Peer Authentication Intermediate above also carries (or should carry, per roadmap) a broader constraint scoped to the deployment's DC space, providing defense in depth: should per-replica NC enforcement ever be bypassed, the chain is still confined to the Sobamail DN space.

Enforcement¶

Name Constraints are validated automatically by CERT_VerifyCertificate and CERT_PKIXVerifyCert in NSS, by OpenSSL's verify and the equivalent API surface, and by Apple's Security framework. The critical flag makes a validator without NC enforcement reject the cert, so the constraint holds everywhere.

A leaf with a subject DN outside its issuing CA's permitted subtree produces SEC_ERROR_CERT_NAME_CONSTRAINT_VIOLATION from NSS, with the verify log identifying which CA in the chain enforced the constraint.

What this prevents¶

The concrete attacks that Name Constraints structurally blocks:

• A compromised local CA is confined to its own replica's identity. It can sign a cert naming another replica, another user, or a central service, and every compliant validator rejects the resulting chain.
• An issuance-pipeline bug that constructs a leaf with the wrong subject DN is caught at the next validation, before it yields a usable credential.

Rotation and revocation¶

Every rotation in the PKI issues a fresh keypair, from the root down to the leaves, so a relying party has to receive each new root before the chains anchored to it validate.

Roots and intermediates are generated mid-year, ship with the next release, and become valid on the following January 1st, so clients hold them before the issuance pipeline starts using them. A root signs intermediates for its first three years and stays in every store for validation until the end of its fifth year, when it leaves the codebase; a new root therefore propagates for three years before it signs anything. An intermediate is valid for 16 months, January 1st to around April 27th of the following year, so consecutive intermediates overlap by about four months and the population below migrates onto the new one through its own renewals.

Local CAs and leaves renew on their own, on a one-third-of-validity cadence: a 33-day leaf attempts renewal around day 11 and day 22, and the 3-month local CA monthly, so a failed attempt leaves a further one and a full third of the lifetime before expiry. Every renewal is a fresh keypair; the outgoing certificate stays in the store until the last thing it signed expires.

Revocation¶

Revocation is in-band, on two mechanisms:

• Short validity (passive). A leaf is valid for 33 days, after which it stops validating regardless of operator action. This covers the expected case, a leaf compromise.
• Signed CRLs over email (active). For faster revocation, a CRL signed by the issuer's cRLSign-bearing key is distributed by email to relying parties, which import it into their local validation state. Each tier revokes the tier below it: a local CA its leaves, the Peer Authentication Intermediate a local CA, any intermediate its own leaves, and the root an intermediate.

The root is a self-signed trust anchor, so recovering from a root compromise means replacing the anchor in every relying party's store. A relying party outside Sobamail has the same two mechanisms: expiry, and the CRLs it receives by mail.

Trust¶

Every client store is loaded on every start with the retained roots (2025, 2026 and 2027) and the 2026 and 2027 intermediates of every branch. The retained roots anchor every purpose; each intermediate is trusted for its own branch's purpose alone (Server for TLS servers, Peer for TLS clients, Data for email, Codesign for object signing), which is what keeps the branches apart in the store as well as in the chain. The 2025 and 2026 vintages predate the EKU extension, which is why new issuance uses the 2027 set, and they stay trusted until retention retires them so that what they signed keeps validating.

Trust anchors¶

The retained roots, as DER-encoded X.509 certificates, exactly as the client bundles them. Sobamail runs its PKI apart from the public trust stores mail programs and operating systems ship with, so a relying party outside Sobamail installs these roots; a signed message brings its leaf and the intermediates along, and the root is the one piece the recipient has to hold.

The fingerprint is the SHA-256 of the DER file. Check it after downloading:

sha256sum ca_2027.der
openssl x509 -inform DER -in ca_2027.der -noout -subject -dates -fingerprint -sha256

Install all three: which one anchors a given signature depends on when its intermediate was issued, and each chain validates through its own vintage. The set changes once a year, when a new root enters and the oldest leaves retention; this table follows the client's bundle.

For an NSS store (Thunderbird, Firefox, or a certutil database), trusting a root for email signatures:

certutil -A -n "Sobamail Root 2027" -t ',C,' -i ca_2027.der -d sql:<dbdir>

For OpenSSL, convert to PEM and name it as a trusted CA:

openssl x509 -inform DER -in ca_2027.der -out ca_2027.pem
openssl cms -verify -in message.eml -CAfile ca_2027.pem -purpose smimesign

Windows takes a DER file directly into the current user's trusted root store (certutil -addstore -user Root ca_2027.der), and macOS through Keychain Access or security add-trusted-cert. Trust granted this way is trust in Sobamail as an operator: the roots sign Sobamail's own intermediates, and those alone, so the trust extends exactly as far as Sobamail's own hierarchy.

Blast radius¶

A compromise of any key in the hierarchy is bounded by every structural constraint at once: Key Usage limits what the key signs, EKU chaining limits the role its certs validate for, the path length limits the depth it can build, Name Constraints limit the names it can assert, and validity limits how long any of it lasts.

The expected event is a leaf compromise, which the design absorbs: 33-day validity bounds the window and rotation is automatic. Three things rest on others: the integrity of the relying party's host, the strength of P-256 and SHA-256, and the conduct of whoever holds an issuing key. Their mitigations are host hardening, a migration path to post-quantum algorithms, and HSM-protected keys with audited, multi-party ceremonies.