alkdev/alknet
6
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(arch): resolve OQ-59 (fingerprint stays in core) + ADR-084 (aws-lc-rs crypto provider)

Browse Source 
OQ-59 resolved to Option A: fingerprint.rs stays in alknet-core. The
client-side FingerprintPinVerifier in alknet-call uses fingerprint
functions and must not depend on alknet-tls (which would pull TLS setup
infra into client-only deployments). The rustls dep in core is narrow —
production fingerprint code uses only sha2 + manual DER parsing; the
rustls::sign usage is a test helper only. alknet-tls re-exports the
fingerprint functions for convenience.

ADR-084: aws-lc-rs as the TLS crypto provider on all server + client
config paths. Records the decision that was already in the code (to
match iroh's tls-aws-lc-rs feature) but had no ADR. FIPS-capable, broad
platform support, consistent across quinn/iroh/TCP+TLS/client. Switching
to ring or process-default requires a new ADR. ADR-082's
behavior-preservation invariant now references ADR-084 for the decision
record.
This commit is contained in:
glm-5.2 committed 2026-07-14 09:53:43 +00:00
1 parent 2abe8f1872
commit 34729c7846
6 files changed
+189 -53
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/architecture/crates/tls/README.md
+8 -7
View File
@@ -371,18 +371,19 @@ All design decisions are documented as ADRs in
|-----|----------|---------|
| [082](../../decisions/082-alknet-tls-extraction.md) | alknet-tls crate extraction | Extract TLS setup from alknet-core/endpoint.rs; `TlsServerConfig` shareable across quinn + TCP+TLS + iroh; one ACME state machine |
| [083](../../decisions/083-endpoint-as-accept-loop-runner.md) | Endpoint as multi-transport accept-loop runner | `AlknetEndpoint` takes no TLS config; TCP+TLS is an owned transport (`with_tcp_tls`); `dispatch` public for SSH/WT; `acme-tls/1` guard moves to shared `dispatch` |
| [084](../../decisions/084-aws-lc-rs-crypto-provider.md) | aws-lc-rs crypto provider | `rustls::crypto::aws_lc_rs::default_provider()` on all server + client config paths; matches iroh; FIPS-capable; do not switch to `ring` or process-default without a new ADR |
## Open Questions
See [open-questions.md](../../open-questions.md) for full details.
- **OQ-59** (open): Should `fingerprint.rs` stay in `alknet-core` or move
to `alknet-tls`? It uses `rustls::pki_types` and `rustls::sign` types,
which creates a `rustls` dep in core. If it moves to `alknet-tls`, the
client-side `FingerprintPinVerifier` (in `alknet-call`) would depend
on `alknet-tls` — a new dep edge. If it stays, core keeps a narrow
`rustls` dep. Decision-ready — the answer depends on whether we want
core to be `rustls`-free.
- **OQ-59** (resolved): `fingerprint.rs` stays in `alknet-core`. The
client-side `FingerprintPinVerifier` (in `alknet-call`) uses fingerprint
functions and must not depend on `alknet-tls` (which would pull TLS
setup infra into client-only deployments). The `rustls` dep in core is
narrow — production fingerprint code uses only `sha2` + manual DER; the
`rustls::sign` usage is a test helper. `alknet-tls` re-exports the
fingerprint functions for convenience.
- **OQ-60** (resolved): Where does transport construction live? The
TCP+TLS accept loop lives in `alknet-core` behind a `tcp` feature as
an owned endpoint transport (`with_tcp_tls`). Builder functions are