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

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.

docs/architecture/README.md

@@ -268,6 +268,7 @@ adapter location map is now consistent: all HTTP-backed adapters
 | [081](decisions/081-channels-subcrate-decomposition.md) | channels Sub-Crate Decomposition | Accepted |
 | [082](decisions/082-alknet-tls-extraction.md) | alknet-tls Crate Extraction | Proposed (amended — endpoint signature superseded by ADR-083) |
 | [083](decisions/083-endpoint-as-accept-loop-runner.md) | Endpoint as Multi-Transport Accept-Loop Runner with Public Dispatch | Proposed (revised — TCP+TLS is an owned transport, not external) |
+| [084](decisions/084-aws-lc-rs-crypto-provider.md) | aws-lc-rs as the TLS Crypto Provider | Accepted |
 
 ## Open Questions
 

docs/architecture/crates/tls/README.md

@@ -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
+- **OQ-59** (resolved): `fingerprint.rs` stays in `alknet-core`. The
-  to `alknet-tls`? It uses `rustls::pki_types` and `rustls::sign` types,
+  client-side `FingerprintPinVerifier` (in `alknet-call`) uses fingerprint
-  which creates a `rustls` dep in core. If it moves to `alknet-tls`, the
+  functions and must not depend on `alknet-tls` (which would pull TLS
-  client-side `FingerprintPinVerifier` (in `alknet-call`) would depend
+  setup infra into client-only deployments). The `rustls` dep in core is
-  on `alknet-tls` — a new dep edge. If it stays, core keeps a narrow
+  narrow — production fingerprint code uses only `sha2` + manual DER; the
-  `rustls` dep. Decision-ready — the answer depends on whether we want
+  `rustls::sign` usage is a test helper. `alknet-tls` re-exports the
-  core to be `rustls`-free.
+  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

docs/architecture/decisions/082-alknet-tls-extraction.md

@@ -203,7 +203,8 @@ that compiles and passes type-checks but silently changes TLS behavior:
   Enables 0-RTT / early data. Omitting it silently breaks 0-RTT clients.
 - **`rustls::crypto::aws_lc_rs::default_provider()`** as the crypto
   provider on all paths. Matches iroh's `tls-aws-lc-rs` feature. Do not
-  switch to `ring` or the process-default provider without an ADR.
+  switch to `ring` or the process-default provider without an ADR —
+  this decision is now recorded as [ADR-084](084-aws-lc-rs-crypto-provider.md).
 - **`AcceptAnyCertVerifier`'s `supported_verify_schemes()`** returns
   ED25519 + ECDSA P-256/P-384 + RSA PSS/PKCS1 (SHA256/384/512). This
   list determines which client cert signature algorithms the server
@@ -274,7 +275,9 @@ details that can change without breaking the contract.
 - ADR-065 — `Connection::from_stream`/`from_bidi` (TCP+TLS path)
 - ADR-080 — `ChannelClient::from_connection` (transport-agnostic
   client; the pattern this ADR mirrors on the TLS side)
-- OQ-59 — should `fingerprint.rs` stay in core or move to `alknet-tls`?
+- OQ-59 — resolved: `fingerprint.rs` stays in `alknet-core` (the
+  client-side `FingerprintPinVerifier` in `alknet-call` must not depend
+  on `alknet-tls`; the `rustls` dep in core is test-only).
 - `crates/alknet-core/src/endpoint.rs` — the code being extracted
 - `crates/alknet-core/src/config.rs` — `TlsIdentity`, `Ed25519SecretKey`
   (staying in core)

docs/architecture/decisions/084-aws-lc-rs-crypto-provider.md

@@ -0,0 +1,138 @@
+# ADR-084: aws-lc-rs as the TLS Crypto Provider
+
+## Status
+
+Accepted
+
+## Context
+
+The TLS stack in alknet uses `rustls`, which requires a crypto provider.
+Rustls 0.23 made the crypto provider explicit — it is no longer a
+process-global default that gets set once and forgotten. Each
+`ServerConfig` / `ClientConfig` is built with a specific provider via
+`builder_with_provider(Arc<dyn CryptoProvider>)`.
+
+The current code (`alknet-core/endpoint.rs`, ADR-027, and the
+`alknet-tls` extraction in ADR-082) uses
+`rustls::crypto::aws_lc_rs::default_provider()` on all server config
+paths (X509, RawKey, SelfSigned, ACME). This choice was made during
+ADR-027's implementation to match iroh's `tls-aws-lc-rs` feature, but
+was never recorded as a decision. ADR-082's behavior-preservation
+invariants list says "do not switch to `ring` or the process-default
+provider without an ADR" — this ADR is that record.
+
+### Why this is load-bearing
+
+The crypto provider determines:
+
+- **FIPS status**: `aws-lc-rs` has a FIPS-certified build mode (via
+  AWS-LC). `ring` does not. If alknet ever needs FIPS compliance (e.g.,
+  for regulated deployments), `aws-lc-rs` is the path; `ring` would be a
+  dead end.
+- **Platform support**: `aws-lc-rs` supports a broad set of platforms
+  via its C/C++ build. `ring` has a different (historically narrower)
+  platform matrix. Switching providers changes which platforms compile.
+- **Cipher suite defaults**: `default_provider()` returns a provider
+  with a specific set of cipher suites and signature algorithms.
+  `AcceptAnyCertVerifier`'s `supported_verify_schemes()` (ED25519 +
+  ECDSA P-256/P-384 + RSA PSS/PKCS1) must be supported by the provider —
+  `aws_lc_rs` supports all of these; a provider that dropped one would
+  silently change which client cert signature algorithms the server
+  accepts.
+- **iroh compatibility**: iroh uses `aws-lc-rs` via its
+  `tls-aws-lc-rs` feature. If alknet's quinn/TCP+TLS path used a
+  different provider, the same Ed25519 key would produce TLS handshakes
+  with different crypto internals on the quinn path vs the iroh path —
+  a consistency risk for the fingerprint normalization (ADR-030 §6).
+
+### The options
+
+- **`aws_lc_rs::default_provider()`** (current): FIPS-capable, broad
+  platform support, matches iroh. The choice already in the code.
+- **`ring::default_provider()`**: simpler pure-Rust crate, no FIPS,
+  different platform matrix. Would break iroh provider consistency.
+- **Process-default provider** (`rustls::crypto::CryptoProvider::get_default()`):
+  relies on whoever set the process global first. Non-deterministic in a
+  library context — alknet crates shouldn't depend on the binary having
+  set the right global. Explicit per-config is the library-correct
+  pattern (and is what the current code does).
+
+## Decision
+
+**`rustls::crypto::aws_lc_rs::default_provider()` is alknet's TLS crypto
+provider on all server and client config paths.** This applies to
+`alknet-tls` (the `TlsServerConfig` construction paths: X509, RawKey,
+SelfSigned, ACME) and to `alknet-call`'s client-side verifier
+construction (which builds a `rustls::ClientConfig` with the same
+provider for consistency).
+
+The provider is constructed explicitly per config
+(`Arc::new(rustls::crypto::aws_lc_rs::default_provider())` passed to
+`builder_with_provider`), not via the process-default global. This
+keeps alknet crates correct as libraries — they don't depend on the
+binary having set a global.
+
+### What this means for `alknet-tls`
+
+The `TlsServerConfig::new` paths (X509, RawKey, SelfSigned, ACME) all
+construct their `rustls::ServerConfig` with
+`builder_with_provider(Arc::new(aws_lc_rs::default_provider()))`. This
+is already the case in the current code (ADR-082's
+behavior-preservation invariants record this); this ADR makes the
+*decision* explicit so that a future switch requires a new ADR.
+
+### What this means for `alknet-call`
+
+The client-side `rustls::ClientConfig` (used by `CallClient` for
+outgoing connections, with either `FingerprintPinVerifier` or
+`WebPkiServerVerifier`) must use the same provider. This ensures the
+client and server agree on cipher suites and signature algorithms — a
+mismatch could cause handshake failures or silent signature-algorithm
+changes.
+
+## Consequences
+
+**Positive:**
+- One crypto provider across all TLS paths (quinn, TCP+TLS, iroh's
+  built-in TLS, client-side). Consistent cipher suites, signature
+  algorithms, and FIPS status.
+- FIPS-capable: if a regulated deployment needs FIPS, `aws-lc-rs`'s
+  FIPS build mode is available without an ADR (it's a build-flag, not a
+  provider change).
+- Matches iroh's `tls-aws-lc-rs` feature — no provider mismatch between
+  alknet's quinn/TCP+TLS path and iroh's built-in TLS path.
+
+**Negative:**
+- `aws-lc-rs` is a C/C++ crate (built via `aws-lc`), not pure Rust. This
+  adds a C build dependency. `ring` is also C-backed, so this is not a
+  regression vs the alternative — but a pure-Rust provider (e.g., a
+  future `rustls` provider) would be lighter. Not switching now; the
+  FIPS and iroh-consistency benefits outweigh the build complexity.
+- A future switch to a different provider requires a new ADR (this is
+  already stated in ADR-082's invariants; this ADR makes the *current*
+  choice a recorded decision, not just an invariant).
+
+## Door type
+
+**One-way.** The provider choice is baked into every TLS config path.
+Switching providers after consumers exist requires updating every config
+construction site and verifying cipher-suite + signature-algorithm
+compatibility. The FIPS and iroh-consistency constraints make `ring`
+and the process-default provider non-viable — the decision is
+`aws_lc_rs` unless a future ADR records a different choice with
+rationale.
+
+## References
+
+- ADR-027: TLS Identity Redesign (where `aws_lc_rs` was first used, to
+  match iroh's `tls-aws-lc-rs` feature)
+- ADR-082: alknet-tls extraction (behavior-preservation invariants:
+  `aws_lc_rs::default_provider()` on all paths; "do not switch to `ring`
+  or the process-default provider without an ADR")
+- ADR-030 §6: fingerprint normalization (requires provider consistency
+  across quinn/iroh/TCP+TLS — the same Ed25519 key must produce the same
+  fingerprint regardless of transport)
+- `crates/alknet-core/src/endpoint.rs` — the current code using
+  `aws_lc_rs::default_provider()` on all server config paths
+- `crates/alknet-call/src/client/call_client.rs` — the client-side
+  `rustls::ClientConfig` construction (must use the same provider)

docs/architecture/open-questions.md

@@ -76,7 +76,7 @@ Door type is separate from whether a decision is made. A two-way door is a decis
 | [OQ-13](questions/013-operation-path-format-and-routing-scope.md) | Operation Path Format and Routing Scope | resolved | two | med |
 | [OQ-14](questions/014-batch-operation-semantics.md) | Batch Operation Semantics | resolved | two | low |
 | [OQ-55](questions/055-alknetclient-establishment-extraction.md) | AlknetClient / Client Establishment Extraction | deferred(scope) | two | med |
-| [OQ-59](questions/059-fingerprint-module-location.md) | Should `fingerprint.rs` Stay in Core or Move to `alknet-tls`? | open | two | med |
+| [OQ-59](questions/059-fingerprint-module-location.md) | Should `fingerprint.rs` Stay in Core or Move to `alknet-tls`? | resolved | two | med |
 | [OQ-60](questions/060-transport-construction-location.md) | Where Does Transport Construction Live? | resolved | one | high |
 | [OQ-61](questions/061-multi-owner-shutdown-coordination.md) | Multi-Owner Shutdown Coordination | dissolved | two | med |
 

docs/architecture/questions/059-fingerprint-module-location.md

@@ -2,55 +2,48 @@
 
 - **Origin**: `docs/architecture/crates/tls/README.md` (the crate spec),
   `docs/architecture/decisions/082-alknet-tls-extraction.md` (the ADR).
-- **Status**: open
+- **Status**: resolved
 - **Door type**: two-way (moving a module between crates is a refactor,
   not a wire-format change; the function signatures and types are
   unchanged)
 - **Priority**: medium
-- **Blocked on**: nothing structural — the question is a dependency-edge
+- **Resolution**: **Option A — `fingerprint.rs` stays in `alknet-core`.**
-  trade-off, not a missing capability. The existing code works in either
-  location. The decision is about which dep edge is cleaner.
-- **Resolution**: Not yet decided. The trade-off:
 
-  **Option A: `fingerprint.rs` stays in `alknet-core`.**
+  The fingerprint functions are used by two paths with different dep
-  - `alknet-core` keeps a narrow `rustls` dep (uses
+  profiles:
-    `rustls::pki_types::CertificateDer` and `rustls::sign::public_key_to_spki`
-    in tests; the production code uses only `sha2` and manual DER parsing,
-    but the test helper `build_ed25519_spki_der` uses `rustls::sign`).
-  - `alknet-call`'s client-side `FingerprintPinVerifier` depends on
-    `alknet-core` (existing edge, no new dep).
-  - `alknet-tls` depends on `alknet-core` and re-exports the fingerprint
-    functions for convenience.
-  - Core is not `rustls`-free, but the dep is narrow (pki-types + sign
-    types, not the full TLS stack).
-  - This is the lower-friction option — no dep edges change.
 
-  **Option B: `fingerprint.rs` moves to `alknet-tls`.**
+  - **Server path** (`alknet-core::endpoint` → `alknet-tls`): extracts the
-  - `alknet-core` becomes `rustls`-free (loses the `rustls`,
+    fingerprint from the presented client cert for `PeerEntry` resolution.
-    `rustls-pki-types` deps for fingerprint).
+    This path already depends on `alknet-tls` — no new dep edge.
-  - `alknet-call`'s `FingerprintPinVerifier` gains a dep on `alknet-tls`
+  - **Client path** (`alknet-call::FingerprintPinVerifier`): matches the
-    — a new dep edge from a handler crate to a transport-infra crate.
+    server's presented cert against a pinned fingerprint. This path does
-    This may or may not violate ADR-003's "no handler-depends-on-handler"
+    NOT want to depend on `alknet-tls` — it's a client-only deployment
-    rule (alknet-tls is not a handler, but it is transport infra that
+    that needs fingerprint matching, not TLS setup. Moving
-    handler crates didn't previously depend on).
+    `fingerprint.rs` to `alknet-tls` would force `alknet-call` to depend
-  - The dep edge is the main concern: `alknet-call` depending on
+    on `alknet-tls`, pulling `rustls` + `tokio` + (optionally)
-    `alknet-tls` means every call-protocol consumer transitively pulls
+    `quinn`/`tokio-rustls`/`rustls-acme` into every client-only deployment.
-    `rustls` + `tokio` + (optionally) `quinn`/`tokio-rustls`/`rustls-acme`.
+    That's heavy and doesn't serve the use case.
-    That's heavy for a client-only deployment that just needs
-    fingerprint matching, not TLS setup.
 
-  **Likely resolution**: Option A (stay in core). The `rustls` dep in
+  The `rustls` dep in core is narrow: the production code in
-  core is narrow (type usage, not the TLS stack), and moving
+  `fingerprint.rs` uses only `sha2` + `hex` + manual DER parsing. The
-  `fingerprint.rs` to `alknet-tls` creates a heavy dep edge from
+  `rustls::sign::public_key_to_spki` and `rustls::pki_types::alg_id::ED25519`
-  `alknet-call` to `alknet-tls` that doesn't serve the client-only case.
+  usage is in the **test helper only** (`build_ed25519_spki_der`), not
-  The fingerprint functions are used by both the server path (endpoint,
+  production. Core's production dep tree doesn't need `rustls` for
-  which does depend on `alknet-tls`) and the client path (call-client,
+  fingerprint — only the test does. The `rustls` and `rustls-pki-types`
-  which does not want to depend on `alknet-tls`). Keeping them in core
+  deps are listed directly on `alknet-core` for this test helper (and for
-  serves both paths without forcing the client path to pull TLS infra.
+  `Connection`'s quinn/iroh integration types), but the fingerprint
-- **What does NOT block on this**: the `alknet-tls` extraction itself
+  production path is `rustls`-free.
-  (ADR-082). The crate can be created with `fingerprint.rs` staying in
+
-  core, and the question can be resolved later without blocking the
+  Keeping `fingerprint.rs` in core serves both the server path (which
-  extraction.
+  depends on `alknet-tls` anyway) and the client path (which must not
+  depend on `alknet-tls`) without forcing a heavy dep edge on the client.
+  `alknet-tls` re-exports the fingerprint functions for convenience.
+
+  This is a two-way door — moving the module later is a refactor, not a
+  wire-format change. But the rationale is clear: the client path's
+  fingerprint-matching need doesn't justify pulling TLS setup infra.
 - **Cross-references**: ADR-082 (alknet-tls extraction), ADR-003 (crate
   decomposition — handler dep rules), ADR-030 §6 (fingerprint
-  normalization), `crates/alknet-core/src/fingerprint.rs` (the code).
+  normalization), `crates/alknet-core/src/fingerprint.rs` (the code),
+  `crates/alknet-call/src/client/call_client.rs` (`FingerprintPinVerifier`
+  — the client-side consumer)