Security commitments

Summary. This page is the security assurance model of WKL TrustBridge. It states each security commitment as a verifiable claim and names the assumptions under which it holds, the procedure by which it is verified, and the residual risk. The page keeps three levels explicitly apart: the cryptographic property of a mechanism, the requirement on operations or the relying party under which it takes effect, and the commitment about the behavior of the overall system. Every commitment holds only under its assumptions.

Terms

Commitment – a statement about the behavior of the overall system that can be tested with the stated procedure.
Assumption – a condition that must be met outside the commitment; if it fails, the commitment no longer holds.
Verification procedure – a test, measurement, exercise, or review that confirms or refutes the commitment.

Commitments

S-01 No issuance without authorization


Commitment	A certificate is issued only if valid approvals from the number of people prescribed in the rule set, or a valid enrollment attestation, exist for exactly this order
Assumptions	Integrity of the worker host, rule set, and ledger; approval keys not compromised; the HSM accepts signing requests only from the worker; in the Managed model, the operating partner holds no approval key
Verification procedure	Worker tests with one order per check rule that must be rejected (no approval, someone else's approval, approval over another hash, expired deadline, canceled order, second execution); tampering test on the database; reconciling the HSM's signature counters against the ledger
Residual risk	Collusion: an approver who also controls management or the database, in classes with a single approval; the worker host's administrator with access to the rule set

S-02 No valid certificate outside the namespace


Commitment	A relying party that follows the relying-party contract accepts no certificate for a name outside the issuing CA's namespace
Assumptions	The relying party enforces `nameConstraints`, as the TLS adapter does; the CA certificate was created with the fixed content from the root tool
Verification procedure	Test certificates with forbidden names that must be rejected; review of the root tool
Residual risk	Relying parties without a TLS adapter that enforce name constraints incompletely or not at all; the commitment does not apply there

S-03 CA keys never leave the HSM


Commitment	No private CA key exists outside an HSM or its protected backup
Assumptions	The HSM is certified, correctly configured, and generates keys as non-exportable
Verification procedure	The worker's startup check for non-exportability; ceremony record with witnesses; configuration review of the HSM
Residual risk	Vulnerabilities in the HSM itself

S-04 Revocation takes effect within a bounded time


Commitment	Once a revocation is recorded in the ledger, every contract-compliant relying party rejects the certificate after its next fetch cycle at the latest, that is, within about six hours plus publication time
Assumptions	Worker and distribution are running; the relying party fetches on the mandated schedule
Verification procedure	Measuring from ledger entry to rejection at a test relying party
Residual risk	Relying parties with a longer fetch interval; caches in the network

S-05 Status information survives a worker outage


Commitment	After a worker outage, a valid CRL remains retrievable for at least 66 hours
Assumptions	The last list was published before the outage; distribution is running
Verification procedure	Failure drill with the worker stopped
Residual risk	An outage of worker and standby lasting more than 66 hours leads to every validation being rejected (fail closed)

S-06 Every issuance can be proven to third parties


Commitment	For every issued certificate, it can be shown without the database which order with which approvals under which version of the rule set it was based on, up to the last external anchor
Assumptions	The external anchor is out of the administrators' reach; the ledger is backed up
Verification procedure	Third-party verification procedure (see Audit and evidence) on a sample
Residual risk	Entries after the last anchor are protected only against casual modification until the next anchor

S-07 Exactly once per order


Commitment	An order leads to at most one certificate; crashes produce neither duplicate issuance nor gaps in the evidence chain
Assumptions	The exclusive lock on the ledger works; exactly one worker per CA
Verification procedure	Tests with forced aborts at every point between intent and projection; starting a second worker
Residual risk	Restoring the ledger from a backup that is too old

S-08 Tenant separation on read


Commitment	A person sees only data of the tenants within their visibility scope
Assumptions	Row-level security policies are complete; people are correctly assigned to visibility scopes
Verification procedure	Tests with several tenants on every entity set and every command, including filter and grouping queries
Residual risk	A compromised management service can read within its own access

S-09 PQ authentication only where verification is required


Cryptographic property	As far as is known today, an ML-DSA signature cannot be forged, even by an attacker with a quantum computer
Requirement on the relying party	It must verify the alternative signature of every link in the chain and treat a missing or invalid one as an error
Commitment	A relying party that requires this verification accepts no chain whose ML-DSA signatures do not come from the CA keys, even if the classical signatures are forged
No commitment	For relying parties that verify only the classical signature; they get no PQ authentication, because the alternative signature can be stripped
Verification procedure	Test chains with a missing, tampered, and foreign alternative signature

S-10 Two factors for every person at the management interface


Commitment	No access to the management API without a personal key and a valid session established with a second factor
Assumptions	Sessions are bound to person and key; withdrawal takes effect on the next request
Verification procedure	Tests: without a key, without a session, with someone else's session, after the key is revoked, after a permission is withdrawn
Residual risk	Malware on the workstation can piggyback on an open session; see the analysis in Interfaces and integration. Approvals are affected only if the approval key is usable on the same device without the person's confirmation

S-11 No passing on of trust


Commitment	A TLS adapter of organization A accepts only chains up to trust anchors that A itself has added to an active relationship; a relationship between B and C gives C no access at A
Assumptions	A's trust bundle is signed with the key of A's CA worker; the adapter uses only this bundle
Verification procedure	Tests with chains from C's hierarchy, with a certificate issued by B for one of C's names, and with an unsigned or outdated bundle; all must be rejected
Residual risk	B can run systems within its own namespace on C's behalf; B is accountable to A for that under their contract

S-12 Additional post-quantum secret in every relationship connection


Cryptographic property	The TLS 1.3 key schedule derives all traffic keys from the external PSK and from the result of the hybrid key agreement; an attacker must know both
Requirement on operations	The relationship policy requires the additional secret; session resumption and 0-RTT are disabled
Commitment	A connection within a relationship that requires the additional secret is established only if both TLS adapters use the same current secret from their key agents; without a confirmed RFC 9973 extension, the adapter aborts
No commitment	Authentication through the PSK; that stays with the certificates (S-09)
Verification procedure	Capture of handshakes in both directions: extension in ClientHello and ServerHello, `psk_dhe_ke` mode, hybrid group; a wrong PSK leads to an abort; a suppressed extension leads to an abort; independent analysis of the combination of agent protocol and TLS key schedule
Residual risk	Bugs in the adapter's TLS implementation; a compromised host at one of the two endpoints

S-13 Relationship revocation takes effect within a defined time


Commitment	Once a direction is revoked in the ledger, no new connections or key exchanges for this relationship are established from that moment on; existing connections end no later than the period set in the policy
Assumptions	The revoking organization's TLS adapters receive the new trust bundle; the key agent deletes the relationship's secrets
Verification procedure	Exercise: revocation during live traffic, measured until new connections are rejected and until the last existing one ends
Residual risk	Adapters that do not receive the new bundle keep accepting new connections until the old bundle expires; the bundle's lifetime bounds this period

What is explicitly not committed

Protection against a compromised HSM or a compromised offline root.
The effect of the name constraint at relying parties without a TLS adapter that do not enforce it.
PQ authentication at relying parties that verify only classically.
Protection of CA keys against side channels beyond the HSM's certification.
Confidentiality of traffic that does not pass through a TLS adapter, and of the local leg between adapter and application.
An authorization. What a partner may do with a verified identity is decided by the target application.