Architecture derivation

Summary. This page derives the architecture of WKL TrustBridge from its requirements, in four steps: requirements with their origin, the security goals that follow from them, the design principles that follow from the goals, and finally the individual architecture decisions with the alternatives that were weighed and their consequences. Where a decision has a weakness from an auditor's point of view, it is stated explicitly, together with how it is compensated.

graph TD
  R[Frameworks<br/>and scenarios] --> A[Requirements<br/>A-01 to A-24]
  A --> Z[Security goals<br/>Z-1 to Z-9]
  Z --> G[Design principles<br/>G-1 to G-11]
  G --> E[Decisions<br/>E-01 to E-21]
  E --> K[Components and flows]
  E --> N[Evidence]
  classDef s fill:#deecf9,stroke:#0078d4,color:#201f1e
  class R,A,Z,G,E,K,N s

Origin: L = law, T = technical recommendation or standard, S = scenario or protection need of the supply chain. The frameworks are explained on Foundations and requirements.

Every decision names the alternatives weighed and the consequences. „Assessment“ records where a decision has weaknesses from an auditor's point of view.

Decision. Only the CA worker signs. It never runs in the same process or under the same operating system account as a service with HTTP input, and it has no inbound network connection. It reads orders, checks them against a local rule set, and signs in the HSM.

Consequences. Issuance is asynchronous: a request creates an order, and the certificate is produced later. Interfaces must never wait for the signature. Satisfies: Z-1, Z-2 (G-1, G-4).

Decision. What may be issued is defined in the worker's local rule set (a file on its host): allowed CAs per profile class, approvers with their public keys, lifetimes, permitted extensions. What has been issued and revoked is recorded in its local, append-only ledger. The database holds orders and projections.

Consequences. Changes to the rule set are an operational procedure on the worker host, not a click in the management application. The ledger must be backed up and reconciled with the database after a restore. Assessment: The ledger becomes the single source of truth about issuance and revocation; losing it would be serious. Hence backups with an RPO close to zero and an external anchor for the head of the chain (see E-14). Satisfies: Z-1, Z-4 (G-2).

Decision. A manual order is approved when a person listed in the rule set signs the order's hash with their personal key. By default that is one person who is not the requester; security-relevant profile classes require two different people. Automatic profile classes instead require an attestation from enrollment with its service key.

Assessment. With a single approval, the rule „the requester is not the approver“ rests on information the worker cannot verify: someone who controls the management interface or the database and is also an approver can file a request under someone else's name and approve it. Separation of duties only becomes cryptographically robust with two approver signatures. For automatic classes, enrollment with its service key belongs to the trusted computing base, which is why those classes are limited to short lifetimes and the partner's namespace. Satisfies: Z-1, Z-4 (G-3).

Decision. An order is a fully resolved snapshot of all security-relevant content of the future certificate, created once as UTF-8 JSON and from then on stored, transmitted, and signed byte for byte. Its identifier is the SHA-256 of those bytes. The worker generates the serial number (at least 64 bits of randomness).

Consequences. What a person approves is, bit for bit, what gets issued. The management application must display the order from exactly the signed bytes. Satisfies: Z-1.

Decision. Every partner has at least one issuing CA of its own whose certificate fixes the partner's DNS namespace through a critical nameConstraints extension. A system is exactly one dNSName within it. Subject, CN, O, and custom OIDs are never security-relevant; other SAN types can only be issued if the CA certificate constrains them as well.

Consequences. The last line of defense is the relying party: it must enforce nameConstraints. Hence the relying-party contract. Assessment: Not every TLS library fully enforces name constraints; the relying-party contract has to become part of partner contracts and be testable with test certificates. Satisfies: Z-1, Z-5 (G-6).

Decision. Status is published through CRLs that the worker generates ahead of time: valid for 72 hours, regenerated every 6 hours and immediately after every revocation; CRL numbers strictly increasing from the ledger. Delta CRLs and OCSP are not offered.

Consequences. Up to six hours (the fetch interval) pass between revocation and the relying party learning of it. The 66-hour buffer (validity minus interval) is the time operations have to restore a failed worker. Satisfies: Z-3 (G-4, G-5).

Decision. CRLs reach distribution through the database and through a second path that bypasses it. Distribution holds no key, verifies every signature, and serves the highest valid CRL number. Revocation is also possible at the console of the worker host.

Alternative: a single path through the database, rejected because a database outage would then make every validation fail after 72 hours at the latest, and nobody could revoke. Satisfies: Z-3 (G-5).

Decision. A hybrid certificate carries a classical subject key and an ML-DSA key (subjectAltPublicKeyInfo, 2.5.29.72); the CA signs with ML-DSA in altSignatureValue (2.5.29.74) and then classically over the entire signed part. The extensions are non-critical.

Assessment. The alternative signature is separable: anyone able to forge the classical signature in the future can produce a certificate without the PQ extensions. Protection therefore exists only if the relying party requires the alternative signature and treats a missing link as invalid (item 9 of the relying-party contract, no silent fallback per G-8). Satisfies: Z-6.

Decision. CA keys are created in the HSM and stay there, non-exportable, classical and ML-DSA alike. There is no software key for a CA, not even temporarily. An HSM without non-exportable ML-DSA is not acceptable. At startup the worker checks fingerprint and non-exportability; one key belongs to exactly one CA.

Alternative: ML-DSA in software for the time being, rejected because a key that was once exportable cannot become trustworthy after the fact. Satisfies: Z-2.

Decision. The root CA is permanently offline. It signs issuing CAs only in a ceremony with named roles. Nothing it signs comes from the online system: keys and namespace are confirmed over a second channel, and only an exhaustively listed set of artifacts crosses the boundary. Satisfies: Z-2 (A-19).

Decision. In the certificate authority, post-quantum algorithms come from a shared .NET component built on OpenSSL (3.5 or later); classical algorithms (RSA, ECDSA, AES, hashes, ASN.1, X.509 types) stay with the .NET framework's cryptography. The endpoint components are standalone native programs with a TLS library that supports RFC 9973.

Satisfies: Z-6, A-06.

Decision. An organization's staff and its operating partner's staff use an Access application that talks exclusively to the management API over HTTPS: lists as OData v4 entity sets through an ODBC driver that speaks only HTTP, commands through a VBA class. A database connection from the client is ruled out.

Satisfies: Z-5, A-10, A-20.

Decision. Partner systems speak standard protocols (ACME, EST), whose adapters implement the protocol completely and delegate business decisions to a shared core. Management and automation use the same business API (OData v4 with actions) and the same permissions.

Satisfies: A-13, A-20 (G-7).

Decision. An operations log (no evidentiary value), a security audit log in the database (chained per tenant, copied externally on an ongoing basis), and the tamper-evident ledger of the worker and the root. Chain heads go periodically to append-only storage outside the database and the worker host.

Alternative: chain heads signed with a dedicated key, rejected because append-only external storage achieves the same without an additional key. Satisfies: Z-4.

Decision. Business foreign keys carry the tenant; in addition, row-level security filters on read. People receive named visibility scopes (all tenants, a group, one tenant), so that both support with logged access and a supply chain's internal permission model can be represented. Satisfies: Z-5.

Decision. WKL TrustBridge comprises each organization's certificate authority, the bilateral trust relationships, the key agents with their local key broker, the TLS adapter, and the integration with target applications such as the Database Gateway. It does not include authorization inside target applications, SPIFFE workload identities, or sign-in services for people.

Rationale. A certificate authority alone supplies identities but no cooperation: between organizations you need the relationship, enforcement at the connection, and protection of the traffic. The certificate authority's security rules stay unchanged: it generates no keys for others and knows no session secret (G-11). SPIFFE identities are URI names, which the identity model (exactly one DNS name per system) does not provide for. Satisfies: Z-8, Z-9.

Decision. Organizations recognize the other side's trust anchors per relationship. The approved relationship reaches the TLS adapters and key agents as a trust bundle signed by the organization's CA worker, with an increasing sequence number and a limited lifetime.

Consequences. Each organization maintains its own relationships; new partners need an agreement with every organization they work with. Satisfies: Z-8 (G-2, G-9).

Decision. Key agents agree on one secret per relationship and pair of hosts through ML-KEM, authenticated with ML-DSA agent certificates. The TLS adapter feeds it into the TLS 1.3 handshake as an external PSK with the tls_cert_with_extern_psk extension (RFC 9973), in psk_dhe_ke mode with a hybrid group and mutual certificate authentication.

Assessment. RFC 9973 explicitly does not count the PSK as authentication. Authentication remains with the hybrid certificates (E-08); the additional secret strengthens confidentiality and binds the connection to the relationship. Satisfies: Z-9 (G-8, G-11).

Decision. The secret travels from the key agent to the TLS adapter through a key broker on the same host. It never leaves the host and is never written to storage.

Alternative: a central key service that distributes secrets to endpoints, rejected because it would know every connection and thus extend the trusted computing base by an online target of the highest value. Satisfies: Z-9 (G-1, G-11).

Decision. TLS 1.3 takes in a new external secret only when a connection is established. The TLS adapter therefore replaces connections once they reach the relationship's maximum lifetime, opening new ones with the current secret before the old ones end. Session resumption is disabled for relationship connections.

Satisfies: Z-9.

Decision. In the Managed model, an operating partner runs an organization's installation. Approvers and custodians are exclusively the organization's own people; CA keys live in an HSM or a partition assigned to that organization alone. A change of operator runs through a new CA generation, not through a key export.

Alternative: the operating partner as approver on the organization's behalf, rejected because it could then issue in the organization's namespace without the organization taking part. Satisfies: Z-1, Z-2.

• Effectiveness. Whether a decision achieves its goal is shown by the verification procedure of the corresponding commitment on Security commitments.
• Completeness of the requirements. The requirements come from the frameworks and scenarios on Foundations and requirements, not from every conceivable obligation of a customer.