fix: the address we published was a misdirection, and the channel is unauthenticated

secrets-engine probed the Service DNS name handed over in FLEX-WP-0021-T05
and found it resolves, from the workstation, to an unrelated public host.
Reproduced here: search ad.binect.de answers wildcard, so
flex-auth-secrets-engine.flex-auth.svc.cluster.local and
this-service-does-not-exist.flex-auth.svc.cluster.local both resolve to
80.158.43.29, while the trailing-dot FQDN correctly fails. A bare Service
name in a handover is not merely unreachable from there, it is a live
misdirection, and the handover was ours.

Had a deployment pointed at it, the CheckRequest body would have gone to
that host: subject, tenant, lane and resource ids, stage, field names,
purpose, plus the caller's bearer token.

Trailing-dot FQDN and "in-cluster only" now replace the bare name in the
example README, SCOPE.md, and the T05 note.

Their real question was how the response channel is authenticated, and
they declined to answer it locally because choosing a transport control
for our service is not a consumer's call. Right boundary, so the answer
is recorded here as FLEX-DEC-2026-010: it is not authenticated. Pins
serve plain HTTP, the envelope carries no signature, and a responder that
knows the package id and version can return a well-formed allow that
passes every check a consumer performs.

The part worth stating in the contract is that the digests do not help
and look like they do. Every input to request_digest,
policy_package_digest and registry_snapshot_digest is either sent by the
caller or published in this repo, so a forger reproduces all three
exactly. They establish integrity of the binding, never authenticity of
the source — and publishing more digests makes a forged envelope look
more authenticated, not less.

For secrets-engine specifically: fail-closed protects against a PDP that
is absent, not against one that lies. An unreachable PDP denies; a lying
PDP allows.

Third instance of one seam in three decisions. 008: a tenant carried
into the digest and never compared — visible, not enforced. 009: a caller
authenticated and never recorded — enforced, not visible. 010: a record
verifiable and unauthentic — checkable, but not evidence.

One nuance that changes the operator recommendation: kubectl port-forward
does authenticate the responder, transitively — no DNS name, one named
pod, API-server TLS. That is the exact reverse of the caller direction,
where it bypasses the NetworkPolicy. Independent properties pointing
opposite ways, so neither can be summarised as "the network protects it".

FLEX-WP-0024 carries signing; key custody routes through warden/OpenBao
rather than minting a key here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80

workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md

@@ -250,12 +250,21 @@ reach a pin; nothing about the fallback-free shape of that configuration changed
 Handed back to `secrets-engine` and `glas-harness`:
 
 ```text
-Service:  http://flex-auth-secrets-engine.flex-auth.svc.cluster.local:8080
+Service:  http://flex-auth-secrets-engine.flex-auth.svc.cluster.local.:8080
 Package:  secrets-engine.catalog-lane.lifecycle
 Version:  v2          <- not v1; v1 is deployed and superseded
 callerAuth.mode: warn (not enforced caller authentication)
 ```
 
+**Corrected 2026-09-06: the address originally handed over was a bare Service
+name, which is a live misdirection from a workstation.** `secrets-engine` probed
+it and flex-auth reproduced: `search ad.binect.de` expands any
+`*.svc.cluster.local` name to one unrelated public host, including names for
+services that do not exist. The trailing dot is required and the address is
+in-cluster only. `FLEX-WP-0024` carries the consequence — a published address a
+consumer can be misdirected from, reaching an unsigned decision envelope over
+plain HTTP.
+
 `SCOPE.md` lists secrets-engine among the shipped consumers and
 `examples/secrets-engine/README.md` carries the coordinates at source.
 

workplans/FLEX-WP-0024-decision-envelope-authenticity.md

@@ -0,0 +1,139 @@
+---
+id: FLEX-WP-0024
+type: workplan
+title: "Sign the decision envelope: the response channel is unauthenticated"
+domain: infotech
+repo: flex-auth
+status: ready
+owner: claude
+topic_slug: netkingdom
+planning_priority: P1
+planning_order: 240
+depends_on_workplans:
+  - FLEX-WP-0021
+related_workplans:
+  - FLEX-WP-0019
+  - FLEX-WP-0023
+created: "2026-09-06"
+updated: "2026-09-06"
+---
+
+# FLEX-WP-0024 — Sign the decision envelope: the response channel is unauthenticated
+
+Opened by `FLEX-DEC-2026-010`, from a question `secrets-engine` asked rather
+than answering locally: **how is the response channel authenticated?** They
+declined to choose a transport control for flex-auth's service on the grounds
+that it is not a consumer's call. Correct, and it is why this is a flex-auth
+workplan and not a mitigation in their repo.
+
+The stance today: pins serve plain HTTP, `flex-auth.decision-record.v1` carries
+no signature, and a responder that knows the package id and version — both
+published — can return a well-formed `effect: allow` that passes every check a
+consumer performs.
+
+## The two things not to get backwards
+
+**The digests do not authenticate the responder and cannot.** Every input to
+them is either sent by the caller or published, so a forger reproduces
+`request_digest`, `policy_package_digest`, and `registry_snapshot_digest`
+exactly. Publishing more digests makes a forged envelope look *more*
+authenticated, not less.
+
+**Fail-closed does not cover this.** It protects against a PDP that is absent,
+not against one that lies. An unreachable PDP denies; a lying PDP allows.
+
+## 1. Publish the stance and stop publishing bare Service names
+
+```task
+id: FLEX-WP-0024-T01
+status: done
+priority: high
+```
+
+Owner: `flex-auth`.
+
+**Done 2026-09-06.** `docs/decision-record-contract.md` states that digest
+recomputation is not responder verification, because the contract is the only
+document a consumer is guaranteed to read.
+`docs/operator-caller-access-path.md` carries the reproduced DNS probe and the
+channel analysis. The trailing-dot FQDN replaced the bare Service name in
+`examples/secrets-engine/README.md`, `SCOPE.md`, and the `FLEX-WP-0021-T05`
+handover note — a bare `*.svc.cluster.local` name resolves through
+`search ad.binect.de` to one unrelated public host, and a name for a service
+that does not exist resolves to the same address.
+
+## 2. Choose the signature shape and key custody
+
+```task
+id: FLEX-WP-0024-T02
+status: todo
+priority: high
+```
+
+Owner: `flex-auth`; key custody is **not** ours to invent.
+
+- Detached signature over the canonical envelope, preferred over transport-only
+  mTLS for two reasons: it survives the transport, so a decision audited later
+  is still attributable, where mTLS authenticates a connection that no longer
+  exists; and it composes with `FLEX-DEC-2026-009`, since a record that names
+  its authenticated caller *and* carries flex-auth's signature is an audit
+  artifact where either alone is a claim.
+- Decide the canonical form to sign. The existing canonical-JSON rules from
+  `docs/canonical-request-digest.md` are the obvious basis, but the signed
+  material is the **envelope**, not the request, and it must exclude the
+  signature field itself. Write it down before implementing: an implicit
+  canonicalisation rule is what `FLEX-DEC-2026-007` had to correct.
+- **Do not mint a key in this repo.** Route custody via
+  `warden route find "decision envelope signing key"` and OpenBao, per the
+  estate credential-routing rule. flex-auth decides the shape; it does not own
+  key material.
+- State key rotation and how a consumer discovers the current public key, since
+  a consumer that cannot rotate trust has a pinned key that will one day be
+  wrong.
+
+Gate: the canonical form, the algorithm, and the custody path are written down
+and reviewed before any signing code exists.
+
+## 3. Implement signing and verification
+
+```task
+id: FLEX-WP-0024-T03
+status: wait
+priority: high
+```
+
+Owner: `flex-auth`.
+
+- Add the signature to `schemas/decision_envelope.schema.json` as additive, and
+  state in the contract that `request_digest` is unaffected so no consumer
+  re-pins — the same note that was needed for v2 and for
+  `approval_binding_digest`.
+- Emit unsigned when no key is configured, and say so in the envelope rather
+  than omitting the field silently. Absence stated, not implied — the
+  `pdp_digest` precedent.
+- Ship a verification example and a fixture pair in
+  `examples/secrets-engine/replay/`: a genuine signed envelope and one whose
+  payload was altered after signing, so a consumer's verifier is tested against
+  a real failure rather than only a real success. **A verifier that has never
+  seen an invalid signature is untested**, which is the lesson from every
+  fixture suite in `FLEX-DEC-2026-008`.
+
+Gate: an altered envelope fails verification, an unaltered one passes, and a
+consumer can perform both from the fixtures alone.
+
+## 4. Report the gap to gate-house
+
+```task
+id: FLEX-WP-0024-T04
+status: wait
+priority: medium
+```
+
+Owner: `flex-auth`.
+
+§6.4 obligates the PEP to act on a decision and §9.3 splits degraded mode by
+owner, but **nothing in the standard requires a PDP's response to be
+authenticable**. So a fully conformant PEP can trust a forged allow while
+meeting every published obligation. That is a gap in the standard, not only in
+this implementation, and it belongs in the outstanding v0.8 assent round
+alongside the `FLEX-DEC-2026-009` finding.