WKL TrustBridge – Overview

Summary. WKL TrustBridge is a private, federated infrastructure for mutual cryptographic trust between independent organizations in a supply chain. Each organization keeps its own identities, keys, and rules. Two organizations agree on a trust relationship that is limited in scope, tied to a purpose, and revocable at any time. Their systems then authenticate each other with certificates and open a TLS 1.3 connection that is additionally protected by an independently generated post-quantum secret. A certificate is not an authorization: what a partner may actually do is still decided by the application it connects to, such as the WKL Database Gateway. The security model rests on a small, explicitly bounded trusted computing base. Exactly one service signs: only with keys held in a hardware security module, and only orders that an authorized person has approved cryptographically.

Pick a deployment scenario → Choose an operating model → Agree on a relationship → Connect a supplier

For the whole path in one example, with each party's responsibilities, see the Case study: onboarding a supplier.

• How do I connect a supplier to Database Gateway?
• How do I approve a certificate order?
• How do I revoke a certificate, even without the database?
• How do I end the cooperation with a partner?
• How do I show an auditor who approved an issuance?
• What do I do if a CA key is compromised?

All tasks are listed under How-to guides.

graph TD
  subgraph ORGA [Organization A, customer]
    APA[Database Gateway<br/>or another application]
    ADA[TLS adapter A]
    KAA[Key agent A<br/>with key broker]
    CAA[Certificate authority A<br/>CA worker, HSM]
    RLA[Relationship policy A]
  end
  subgraph ORGB [Organization B, supplier]
    APB[Supplier application]
    ADB[TLS adapter B]
    KAB[Key agent B<br/>with key broker]
    CAB[Certificate authority B<br/>CA worker, HSM]
    RLB[Relationship policy B]
  end
  CAA -.->|trust anchor A| RLB
  CAB -.->|trust anchor B| RLA
  KAB ==>|additional PQ secret| KAA
  KAA ==>|external PSK| ADA
  KAB ==>|external PSK| ADB
  APB --> ADB
  ADB -->|TLS 1.3, mutually authenticated| ADA
  ADA -->|verified identity| APA
  classDef tcb fill:#fde7e9,stroke:#a4262c,color:#201f1e
  classDef onl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef pq fill:#dff6dd,stroke:#107c10,color:#201f1e
  classDef auth fill:#fff4ce,stroke:#8a6d00,color:#201f1e
  class CAA,CAB tcb
  class ADA,ADB,RLA,RLB onl
  class KAA,KAB pq
  class APB par
  class APA auth
  style ORGA fill:#ffffff,stroke:#8a8886,color:#201f1e
  style ORGB fill:#ffffff,stroke:#8a8886,color:#201f1e

Working together takes four steps:

1. Agree on the relationship. A and B exchange trust anchors. Each side defines, for its own direction, which of the other side's services it trusts, for what purpose, under which cryptographic requirements, and for how long.
2. Issue identities. Each organization issues certificates to its own systems, either automatically through ACME or EST, or after an authorized person approves the order.
3. Protect the connection. The key agents on both sides agree on an additional post-quantum secret. The TLS adapters use it to open a mutually authenticated TLS 1.3 connection in which the secret enters the key schedule as an external pre-shared key.
4. Authorize the operation. The target application receives the partner's verified identity, decides against its own permissions whether the requested operation is allowed, and logs it.

Every connection therefore passes six layers of protection, and each one checks something different:

How a certificate comes into being inside one organization is described in PKI and certificate lifecycle. How two organizations come to trust each other is described in Federation and bilateral trust.

The colors and arrows in all diagrams are explained in the diagram conventions.

Each organization runs its own certificate authority. Signing happens only in the CA worker, with keys in the HSM, and only for orders that an authorized person approved or that enrollment confirmed; the database and management sit outside this trusted computing base. Two organizations trust each other through a relationship with a policy per direction, which the CA worker hands to the TLS adapters as a signed trust bundle. The key agents add an additional post-quantum secret to every connection. Why it's built this way is explained in Trust model, System architecture, and PQ key exchange for TLS.

• People and access – invitations, roles, lockouts, notifications
• Lift a person's lockout
• Reset a person's second factor
• Review sign-ins
• Operations and emergencies – failure domains, recovery, default values

• No new connections to a partner
• The handshake aborts because the server doesn't confirm the external PSK
• Connections to a partner end suddenly
• A certificate request is refused with 400
• A command is refused with 409

All symptoms are listed under Troubleshooting.

• Interfaces and integration – ACME, EST, CMP, management API, TLS adapter
• System architecture – components, network directions, security profiles
• Architecture derivation – from requirements to decisions

The pages in the order they build on each other: first what it's for and in which model, then why and how it's built, then the tasks, and finally the reference pages.