Deployment scenarios

Summary. This page describes why trust between organizations needs its own infrastructure, what it brings each audience, what WKL TrustBridge is used for, how the parties work together in typical flows, and what TrustBridge is explicitly not meant for. All scenarios start from the same situation: several independent organizations cooperate, each with its own systems, networks, and rules, and each wants to grant exactly as much trust as the cooperation needs, and to be able to take it back at any time.

• Partner – an organization in the supply chain, represented technically by its issuing CA.
• System – a host, service, or device belonging to a partner, identified by exactly one DNS name within the partner's namespace.
• Relying party – a system that receives and verifies a certificate, such as a server that requires a client certificate (mTLS); in TrustBridge this is usually the TLS adapter.
• Profile class – a category of certificates with fixed rules for content, lifetime, and approval. Manual classes require approval by a person; automatic classes require an attestation from enrollment.
• Trust relationship – a bilateral agreement between two organizations, with one relationship policy per direction.

In a supply chain, systems owned by different companies exchange data. A customer shares production data, a supplier maintains part of the business applications, a service provider looks after plant equipment. Today that cooperation usually rests on a mix of VPNs, trust in a shared network, central accounts, certificates from assorted sources, hand-maintained exceptions, and contracts. It works while there are only a few partners. With every new partner it gets harder to say who may access what, why, since when, and how to shut it off again.

Five reasons argue for managing this trust through dedicated infrastructure rather than as a side job:

1. Identity across company boundaries. A certificate from a public certificate authority proves control of a domain name, not that it belongs to a particular partner. A supply chain needs the second statement: this system belongs to partner A and may only appear within partner A's namespace. TrustBridge enforces that with a name constraint per partner (nameConstraints per RFC 5280).
2. Trust is two-sided, not a membership. If A trusts B and B trusts C, it does not follow that A trusts C. Every relationship is agreed between exactly two organizations and defined separately for each direction.
3. A legal duty to secure the supply chain. The EU NIS2 Directive and its German implementation, the BSI Act, require covered entities to govern the security of their supplier relationships and their use of cryptography (Section 30(2) nos. 4 and 8 BSIG). Issuance, approval, and revocation that can be proven give auditors a verifiable answer.
4. The move to post-quantum cryptography. The EU coordinated roadmap calls for high-risk use cases, PKI named explicitly among them, to move to quantum-safe algorithms by the end of 2030. Trust anchors often stay valid for ten to twenty years, and traffic recorded today can be decrypted later. That is why TrustBridge already protects connections with an additional post-quantum secret and issues hybrid certificates.
5. Control over keys and revocation. Anyone who works with partners must also be able to end that work without waiting on a third party, and must be able to show who granted which approval.

Zero trust and mutual trust are not opposites. Zero trust means never trusting a user, device, service, or network segment implicitly. Mutual trust, in TrustBridge, means that two organizations can verify agreed cryptographic identities and conditions. Even then, the target application authorizes every single operation on its own.

A supplier (partner A) maintains part of a customer's (partner B) business applications and pulls data automatically to do so. Until now that took a VPN account and database credentials. With TrustBridge the two agree on a relationship, and the supplier reaches exactly the released data through the Database Gateway.

sequenceDiagram
  participant A as stock.partner-a.example
  participant TA as TLS adapter partner A
  participant TB as TLS adapter partner B
  participant G as Database Gateway of B
  A->>TA: request
  TA->>TB: TLS 1.3, client certificate, additional PQ secret
  TB->>TB: chain up to the relationship anchor, nameConstraints, CRL
  TB->>TB: service and purpose in B's policy
  TB->>G: request with partner identity
  G->>G: check the rule for partner A
  G-->>TB: released data
  TB-->>TA: response
  TA-->>A: response

What carries the security. The customer does not recognize the supplier by its O or CN field but by the issuing CA it has added to the relationship. Because that CA is restricted to partner-a.example through nameConstraints, even a faulty or malicious issuance at A cannot produce a certificate for one of B's names that passes validation. What the supplier may read or change is decided by the gateway alone. Connecting the Database Gateway walks through the flow in detail.

A service provider (partner C) maintains one of the customer's plants for three months. It needs access to two services, for that purpose, and for that period.

1. The customer agrees on a relationship with C. In its direction it allows exactly those two services, sets the duration to three months, and requires the additional post-quantum secret.
2. C has no PKI of its own. It receives a partner CA within the customer's hierarchy; C's own staff approve the certificates for their systems through the partner portal.
3. After three months the relationship expires. New connections stop, without anyone having to lock an account or remove VPN access.
4. If the engagement ends earlier, the customer revokes its direction immediately.

A partner's industrial devices receive short-lived certificates and renew them on their own, without a person approving every renewal.

1. The device generates its own key pair and sends a CSR via EST (simpleenroll) or Lightweight CMP; for renewals it uses its current certificate.
2. For the first issuance it presents the proof its profile class requires: a pre-registered one-time value, its manufacturer certificate (IEEE 802.1AR), or a TPM attestation.
3. Enrollment checks that the request matches the automatic profile class and lies within the partner's namespace, builds the order, and attests it with its service key.
4. The CA worker checks the attestation against its rule set and issues.
5. Renewal starts once only a third of the lifetime remains; the minimum lifetime is three days, so that a one-day enrollment outage never lets a certificate expire.

One of partner A's servers is considered compromised; its certificate must become useless at once.

Limit. Up to six hours can pass between revocation and a relying party's next fetch. Anyone who needs a faster effect also revokes the relationship: the new trust bundle reaches the revoking organization's TLS adapters within an hour, or immediately on request.

Database outage. Revocation works without the database too: at the console of the worker host. The CRL reaches distribution through a second path that bypasses the database.

All of partner A's systems are to lose access at once.

Two partners agree that their connection must also be protected against future quantum computers. Two security goals need to be kept apart:

The first threat is more urgent, because the attack starts today. The second becomes urgent before a quantum computer exists, because trust anchors are long-lived. The relationship policy records both requirements, and the TLS adapter enforces them on every connection.

A partner runs an interface that serves arbitrary HTTPS clients as well as partner systems.

TrustBridge forces no proprietary component on an ordinary HTTPS client. Hybrid certificates stay readable for classical verifiers: the alternative signature sits in non-critical extensions, which a verifier without PQ support skips.

A single company uses TrustBridge for its own services and devices. It is then one tenant with one or more issuing CAs; relationships exist between business units or sites with their own namespaces.