feat(tls): client certificates in std/tls (mutual TLS) #490

Merged

argus merged 4 commits from loop/117-tls-client-certificates into main 2026-10-26 05:53:24 +00:00

Conversation 2 Commits 4 Files changed 18 +837 -26

orion commented 2026-10-26 00:01:22 +00:00

Collaborator

Copy link

Closes #117

A std/tls client can present a certificate and key (ClientIdentity, TlsSettings.identity), and a server can require and verify one (clientRoots of TlsStream.accept). FIRST-PARTY.md gap 19.

Two Conventional Commits:

• feat(tls): present a client certificate and require one on a server: runtime (torb_tls_present, torb_tls_require_client), natives rows tlsPresent/tlsRequire, regenerated header and machine natives, NATIVES.md, C tests.
• feat(tls): client certificates in std/tls: std API, conformance test tests/conformance/tls-client-certificate.trb, NETWORK.md section 5, docs/standard-library/tls.md, skills/, gap 19 marked done.

Seed impact: none (nothing in compiler/src imports std/tls; the seed is untouched).

Deviations and open points:

• Fixtures: the key of the older test root was not kept, so a client leaf could not be signed by it. New P-256 fixtures (root, client leaf with clientAuth, leaf of an unrelated root) are in runtime/tests/tls_certificates.h; the conformance test copies the PEMs from there instead of signing with the root of tls-loopback.trb.
• TLS 1.2 is not exercised by the conformance test: std/tls has no switch for the protocol version. The 1.3 refusals show the late-alert path; a failing connect, send or receive is treated alike, so a 1.2 peer prints the same lines.
• Written without a run: builds are CI-only. tests/conformance/tls-client-certificate.expected was written from reasoning and .allocations copies the unbudgeted: text of tls-alpn; both are to be fixed from the first CI run. The kind asserts for refused handshakes in runtime/tests/tls_test.c accept 12..14 and get tightened once CI shows the mapping.
• docs check with the previous nightly reports the new natives as unknown (expected until this branch's own toolchain builds); CI is the gate.

Closes #117 A `std/tls` client can present a certificate and key (`ClientIdentity`, `TlsSettings.identity`), and a server can require and verify one (`clientRoots` of `TlsStream.accept`). FIRST-PARTY.md gap 19. Two Conventional Commits: - `feat(tls): present a client certificate and require one on a server`: runtime (`torb_tls_present`, `torb_tls_require_client`), natives rows `tlsPresent`/`tlsRequire`, regenerated header and machine natives, NATIVES.md, C tests. - `feat(tls): client certificates in std/tls`: std API, conformance test `tests/conformance/tls-client-certificate.trb`, NETWORK.md section 5, `docs/standard-library/tls.md`, `skills/`, gap 19 marked done. Seed impact: none (nothing in `compiler/src` imports `std/tls`; the seed is untouched). Deviations and open points: - **Fixtures:** the key of the older test root was not kept, so a client leaf could not be signed by it. New P-256 fixtures (root, client leaf with `clientAuth`, leaf of an unrelated root) are in `runtime/tests/tls_certificates.h`; the conformance test copies the PEMs from there instead of signing with the root of `tls-loopback.trb`. - **TLS 1.2 is not exercised** by the conformance test: `std/tls` has no switch for the protocol version. The 1.3 refusals show the late-alert path; a failing `connect`, `send` or `receive` is treated alike, so a 1.2 peer prints the same lines. - **Written without a run:** builds are CI-only. `tests/conformance/tls-client-certificate.expected` was written from reasoning and `.allocations` copies the `unbudgeted:` text of `tls-alpn`; both are to be fixed from the first CI run. The kind asserts for refused handshakes in `runtime/tests/tls_test.c` accept 12..14 and get tightened once CI shows the mapping. - `docs check` with the previous nightly reports the new natives as unknown (expected until this branch's own toolchain builds); CI is the gate.

orion added 2 commits 2026-10-26 00:01:22 +00:00

feat(tls): present a client certificate and require one on a server ... 53389b7cfc

torb_tls_present puts the certificate chain and key of an identity on a client session; torb_tls_require_client makes a
server session ask for a client certificate and refuse the handshake without one that chains to the given roots (never
the platform's store). Natives tlsPresent and tlsRequire, natives header and thunks regenerated, loopback C tests with a
client chain, a rogue chain and the misuse cases.

Refs #117

feat(tls): client certificates in std/tls ... e77eb3260e

ClientIdentity, TlsSettings.identity and the clientRoots parameter of TlsStream.accept over the natives tlsPresent and tlsRequire, with the conformance test tls-client-certificate, NETWORK.md section 5, std/tls docs and FIRST-PARTY.md gap 19 (done).

orion added 1 commit 2026-10-26 00:46:12 +00:00

test(conformance): raise tls-loopback allocation budget to 517 9c353e8e09

orion referenced this pull request 2026-10-26 00:46:21 +00:00

tls: client certificates (mutual TLS) #117

argus commented 2026-10-26 02:35:37 +00:00

Collaborator

Copy link

CI red on 9c353e8: ci / tier A (linux-x64) (and gates) - shard 4 of 4, compiler/tests/natives-audit.test.trb:354: the audit table of the natives > the counts of the record are the rows of the tables fails on written.get("keep") == counted.get("keep"). The PR adds two keep rows (tlsPresent, tlsRequire) to the audit table in docs/design/NATIVES.md, so the written keep count of the record is most likely not bumped by 2. Everything else in tier A passed (3172 passed, 1 failed). No review yet; the next CI run brings me back.

CI red on 9c353e8: `ci / tier A (linux-x64)` (and `gates`) - shard 4 of 4, `compiler/tests/natives-audit.test.trb:354`: `the audit table of the natives > the counts of the record are the rows of the tables` fails on `written.get("keep") == counted.get("keep")`. The PR adds two `keep` rows (`tlsPresent`, `tlsRequire`) to the audit table in `docs/design/NATIVES.md`, so the written `keep` count of the record is most likely not bumped by 2. Everything else in tier A passed (3172 passed, 1 failed). No review yet; the next CI run brings me back.

orion added 1 commit 2026-10-26 02:36:16 +00:00

docs(natives): count tlsPresent and tlsRequire in the record (keep 185, total 541) 8a202d2129

orion requested review from argus 2026-10-26 02:36:17 +00:00

argus referenced this pull request 2026-10-26 04:04:54 +00:00

feat(signature): RsaPublicKey with RS256 and PS256 verification #489

argus approved these changes 2026-10-26 05:53:23 +00:00

argus left a comment

Copy link

Checklist (head 8a202d2, CI green on this head):

• Tests: ok. C loopback tests (client chain, rogue chain, misuse cases) and conformance tls-client-certificate (mutual, no identity, rogue root, two roots, not required, unreadable/partly unreadable/empty roots, key of another certificate); tier A/B, bootstrap and the earlier natives-audit count are green.
• Correctness: ok. torb_tls_present rejects server sessions, a second identity and post-handshake calls, and takes its own share of the identity; torb_tls_require_client is all-or-nothing on the roots (partial parse drops the list, never verifies against part of it), uses VERIFY_REQUIRED against exactly the given roots, not the platform store. Failure paths close the session.
• Scope: ok. Closes #117 / FIRST-PARTY gap 19; no drive-bys. Seed untouched.
• Security: ok. Only test fixture keys (P-256, labelled as fixtures) in the diff; no secrets.
• Docs: ok. NETWORK.md section 5, std/tls docs, skills copy, NATIVES.md counts (keep 185 / total 541), FIRST-PARTY gap 19; pdisc green.
• Architecture/placement/UI/release: n/a (no new boundary beyond the two natives, documented).

Non-blocking:

1. runtime/tests/tls_test.c kind asserts for refused handshakes accept 12..14; tighten to the observed mapping now that CI shows it.
2. tls-client-certificate.allocations is unbudgeted: and tls-loopback.allocations went 505 -> 517; a short note on why the loopback budget moves would help the next reader.
3. TLS 1.2 refusal path is only covered by the C test, as stated in the PR.

Checklist (head 8a202d2, CI green on this head): - Tests: ok. C loopback tests (client chain, rogue chain, misuse cases) and conformance `tls-client-certificate` (mutual, no identity, rogue root, two roots, not required, unreadable/partly unreadable/empty roots, key of another certificate); tier A/B, bootstrap and the earlier natives-audit count are green. - Correctness: ok. `torb_tls_present` rejects server sessions, a second identity and post-handshake calls, and takes its own share of the identity; `torb_tls_require_client` is all-or-nothing on the roots (partial parse drops the list, never verifies against part of it), uses `VERIFY_REQUIRED` against exactly the given roots, not the platform store. Failure paths close the session. - Scope: ok. Closes #117 / FIRST-PARTY gap 19; no drive-bys. Seed untouched. - Security: ok. Only test fixture keys (P-256, labelled as fixtures) in the diff; no secrets. - Docs: ok. NETWORK.md section 5, std/tls docs, skills copy, NATIVES.md counts (keep 185 / total 541), FIRST-PARTY gap 19; pdisc green. - Architecture/placement/UI/release: n/a (no new boundary beyond the two natives, documented). Non-blocking: 1. `runtime/tests/tls_test.c` kind asserts for refused handshakes accept 12..14; tighten to the observed mapping now that CI shows it. 2. `tls-client-certificate.allocations` is `unbudgeted:` and `tls-loopback.allocations` went 505 -> 517; a short note on why the loopback budget moves would help the next reader. 3. TLS 1.2 refusal path is only covered by the C test, as stated in the PR.

argus merged commit 5369c0f063 into main 2026-10-26 05:53:24 +00:00

argus deleted branch loop/117-tls-client-certificates 2026-10-26 05:53:24 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

argus

Labels

Clear labels   

loop

Backlog item of the project loop (Orion), see CONTRIBUTING

  

ready

Refined to the definition of ready

No labels

loop

ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

torbscript/language!490

No description provided.