Trust model

Summary. The trust model defines whom TrustBridge trusts, whom it protects itself against, and what an attacker who takes over a single component can achieve. At its core, each organization has a small trusted computing base made up of the CA worker, the HSM, the offline root, and the personal approval keys. Database, management, distribution, and web services sit outside it; compromising them leads to delay or disclosure, not to unauthorized certificates. Between organizations, trust is two-sided, defined per direction, and never passed on through third parties. And a certificate is not an authorization: it shows who is speaking, not what is allowed.

• Asset – something that has to be protected.
• Trusted computing base – the components whose compromise allows an unauthorized issuance or status statement.
• Trust anchor – a certificate that a relying party trusts without further checks; in TrustBridge, an organization's root certificate, or an issuing CA's certificate that a trust relationship explicitly admits.
• Name constraint – the nameConstraints extension (RFC 5280, Section 4.2.1.10) in a CA certificate, which defines which names subordinate certificates may carry.
• Trust relationship – an agreement between exactly two organizations to recognize the other side's trust anchors for specific services and purposes.
• Relationship policy – an organization's settings for one direction of a trust relationship: services, purpose, cryptographic requirements, duration, right to change, revocation.
• Authorization – a target application's decision whether a specific operation is allowed for a verified identity.
• Relying-party contract – the rules a relying party must follow for the security commitments to hold on its side.

Out of scope: Web PKI requirements, arbitrary internet participants as requesters, load attacks from the internet on issuance.

graph TD
  subgraph AUS [Outside the trusted computing base]
    ADM[Management application] --> VW[Management]
    EN[Protocol adapters]
    VW --> DB[(Database)]
    EN --> DB
    VT[Distribution]
  end
  subgraph TCB [Trusted computing base]
    RW[Rule set]
    FS[Personal<br/>approval keys]
    EA[Enrollment attestation<br/>automatic classes only]
    RT[Offline root]
    WK[CA worker<br/>host, account, clock]
    REG[Ledger]
    HSM[HSM]
  end
  PRF[Relying party<br/>last line]
  DB -->|unverified input| WK
  RW --> WK
  FS ==>|approval| WK
  EA ==>|attestation| WK
  RT -.->|CA certificate| WK
  WK --> REG
  WK ==>|signs| HSM
  WK -->|CRL| VT
  VT --> PRF
  classDef tcb fill:#fde7e9,stroke:#a4262c,color:#201f1e
  classDef aus fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  class WK,RW,REG,HSM,FS,RT,EA tcb
  class DB,VW,EN,VT aus
  class ADM,PRF par
  style AUS fill:#ffffff,stroke:#8a8886,color:#201f1e
  style TCB fill:#ffffff,stroke:#8a8886,color:#201f1e

Every organization has its own trusted computing base. One organization's trusted computing base is never part of another's: a relationship only recognizes trust anchors; it shares no keys, approvers, or ledgers.

The relying party is the last line: the name constraint in the CA certificate only works if it is enforced there. The TrustBridge TLS adapter enforces it itself.

graph TD
  G[Attacker's goal:<br/>valid certificate for someone else's name] --> P1[Create an order in the database]
  P1 --> C1{Approval signature<br/>from a person listed<br/>in the rule set?}
  C1 -- no --> X1[Worker rejects]
  C1 -- yes, stolen --> C2{Name within the namespace<br/>of the chosen CA?}
  C2 -- no --> X2[Worker rejects]
  C2 -- no, worker bypassed --> X3[Relying party rejects:<br/>nameConstraints]
  C2 -- yes --> R[Certificate only in<br/>its own namespace]
  classDef x fill:#dff6dd,stroke:#107c10,color:#201f1e
  classDef r fill:#fde7e9,stroke:#a4262c,color:#201f1e
  class X1,X2,X3 x
  class R r
  classDef neu fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  class C1,C2,G,P1 neu

The chain of reasoning step by step:

1. A certificate only comes into being when the worker signs. The worker cannot be reached from outside; an attacker can only put orders in front of it through the database.
2. The worker trusts no content of the database. It verifies the approval signature with public keys from its local rule set. Whoever controls the database cannot add an approver.
3. An approval applies to exactly one order hash. Carrying an old approval over to a new order fails, because the hash changes; every order is executed at most once and has an expiry.
4. The worker checks the name against the CA's namespace. Even if the worker has a bug, the name constraint in the CA certificate takes effect at the relying party.
5. Revocations are monotonic in the ledger. A database that “forgets” a revocation does not change the next CRL; distribution serves only correctly signed lists with increasing numbers.

Limits of this argument. It does not hold against: an approver who also controls management or the database, in classes with a single approval; the worker host's administrator, who can change the rule set; a relying party that does not enforce nameConstraints. These residual risks are contained organizationally (two-person rule, four-eyes principle on the worker host, relying-party contract with test certificates).

A valid certificate answers a single question: who is speaking? Whether what that identity wants to do is allowed is not for TrustBridge to decide. Six things are therefore kept apart:

graph TD
  V[Connection from B] --> K1{Chain up to an<br/>anchor of the relationship?}
  K1 -- no --> X1[TLS adapter rejects]
  K1 -- yes --> K2{Service and purpose in<br/>A's policy?}
  K2 -- no --> X2[TLS adapter rejects]
  K2 -- yes --> K3{Operation authorized<br/>for this identity?}
  K3 -- no --> X3[Application rejects]
  K3 -- yes --> OK[Operation executed<br/>and logged]
  classDef onl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef auth fill:#fff4ce,stroke:#8a6d00,color:#201f1e
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef x fill:#dff6dd,stroke:#107c10,color:#201f1e
  class V par
  class K1,K2 onl
  class K3,OK auth
  class X1,X2,X3 x

Only the third check opens data. Anyone who steals a valid certificate without the private key fails at the signature in the handshake; anyone who steals a certificate together with its key gets only what the target application allows that identity, and only until revocation.

The following scenarios test the security commitments against attacks that go beyond compromising a single component. The commitments are described on Security commitments.

Every relying party that verifies TrustBridge certificates must:

1. validate the complete chain up to a trust anchor of the relationship;
2. check basicConstraints and pathLenConstraint;
3. actually enforce the nameConstraints of every CA certificate;
4. identify the partner exclusively through the issuing CA;
5. identify the system exclusively through the dNSName;
6. check keyUsage and extendedKeyUsage;
7. check the validity of the entire chain;
8. evaluate the issuing CA's CRL and reject when no valid CRL is available;
9. where PQ protection has been agreed, also verify the ML-DSA alternative signature of every certificate in the chain, and reject a chain without a matching alternative signature;
10. reload the CRL on the generation schedule (6 hours), not only when it expires.

The TrustBridge TLS adapter meets all ten items. For relying parties without a TLS adapter, TrustBridge supplies test certificates, including certificates with forbidden names, an expired chain, a revoked status, and a missing alternative signature, all of which a correctly configured relying party must reject.

CA keys are used exclusively within the HSM; TrustBridge itself performs no operation with secret CA keys. Protecting those keys against timing, cache, and power side channels is a property of the certified HSM and a criterion for choosing it. The key agents use constant-time implementations for ML-KEM and ML-DSA.

TrustBridge offers two ways to connect a partner. Both lead to the same check at the TLS adapter.

graph TD
  subgraph A [Partner CA in the customer's hierarchy]
    WA[Customer root] --> CA1[CA partner 1<br/>nameConstraints]
    WA --> CA2[CA partner 2<br/>nameConstraints]
  end
  subgraph B [Own hierarchy, bilateral recognition]
    W1[Root organization 1] --> CB1[CA organization 1]
    W2[Root organization 2] --> CB2[CA organization 2]
  end
  CB1 -.->|anchor in the relationship,<br/>limited to namespace| CB2
  classDef s fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  class WA,CA1,CA2,W1,W2,CB1,CB2 s
  style A fill:#ffffff,stroke:#8a8886,color:#201f1e
  style B fill:#ffffff,stroke:#8a8886,color:#201f1e

A partner can switch from the first path to the second when it sets up its own installation; its systems then receive certificates from its own hierarchy, and the relationship switches anchors.

Before a system receives its first certificate, TrustBridge has to be sure it is talking to the right system. The profile class defines which proof is required:

A signed software artifact on its own does not prove a secure runtime state; every proof has an explicit verification rule in the rule set.

• Authorizations. Which operation a partner may perform is defined by the target application.
• Any proof of the provenance or state of a partner's software; that is not a PKI's job.
• Identity provisioning for short-lived workloads inside a data center (such as SPIFFE); TrustBridge identifies systems and services between organizations.
• Protection at relying parties that neither implement the relying-party contract nor use a TLS adapter.