Current owner-trust boundary · Owner authorization, SecretStore custody, EstatePublisher, and FountainStore remain separate security authorities.

139 — Owner Trust Root, SecretStore Custody, and Recovery

Fountain Coach separates owner authorization, device enrollment, host credentials, and estate publication. Private keys remain in native SecretStore custody; EstatePublisher carries typed, signed requests; FountainStore is the remote authority. A lost owner root is a bounded recovery condition, not permission to bypass the trust model.

Principal illustration — the deployed authority boundary. It shows custody and evidence flow; it is not a private-key export, a successful trust rotation, or proof that the current owner root is recoverable.

The decision

The security model uses an owner trust root to authorize maintenance operations. The root is a Curve25519 signing key pair. Its public key is configured on the production FountainStore; its private key is held by an owner-controlled SecretStore. The name owner-primary is only a stable key identifier. It does not identify a person, device, or key holder by itself.

EstatePublisher is the native maintenance client. It prepares typed requests, obtains owner authorization from the local SecretStore, and hands approved work to the named FountainStore host adapter. FountainStore remains the remote authority for enrollment, publication, release activation, and trust configuration. The public estate is a projection of Store state, never a security authority.

The custody model

The system separates the owner trust-root private key, device private keys, FountainStore API and host-agent credentials, and TLS private keys. No one of these credentials substitutes for another. Possession of root access to a Linux host does not prove possession of the owner signing key.

The maintenance boundary

owner SecretStore → EstatePublisher → native host adapter → FountainStore
                                           ↘ redacted terminal receipt

EstatePublisher does not accept arbitrary shell commands, caller-supplied credential headers, copied private keys, or generic HTTP deployment instructions. Requests are bound to the exact target, host identity, trust-set digest, current owner identity, approval interval, and idempotency key.

Owner trust-root rotation

Rotation is additive and owner-signed. A valid rotation retains the current trusted owner, adds explicitly named replacement keys, creates a pre-rotation backup, applies the complete trust set atomically, restarts the named service, and verifies HTTPS health. Replay, target mismatch, expired approval, missing credentials, and an invalid current-owner signature are terminal failures.

Recovery is not rotation

If the owner private key is lost, the additive rotation contract cannot be satisfied. A newly generated key is not active merely because it is safely stored, and changing server configuration by root access would bypass the owner authorization invariant.

The deployed system therefore fails closed. It currently has no break-glass owner-recovery operation, recovery token, quorum rule, or independent emergency authority. A future recovery operation must define its authority, replay protection, exact target binding, backup and rollback behavior, service restart, HTTPS health, and redacted terminal receipt.

Rules

1. owner-primary is an identifier, not an identity claim.
2. Private keys remain in native Keychain or SecretStore custody and never enter requests, receipts, MIDI2 messages, browser state, or public estate content.
3. Device enrollment, owner authorization, host credentials, TLS termination, and estate publication remain distinct authorities.
4. Every trust-root rotation is signed by the currently active owner root and bound to one exact target and host.
5. Root access may inspect service state and SecretStore availability, but it does not manufacture an owner signature.
6. A generated replacement key is staged until a typed server receipt proves activation.
7. A lost owner key requires an explicitly governed recovery operation; it never authorizes an undocumented bypass.

Current evidence boundary

Hetzner FountainStore has a configured owner trust root, native encrypted SecretStore, host-agent credential boundary, and typed owner-trust rotation endpoint. The local Mac has a separate owner key and a newly staged replacement key. The Mac key does not match the active Hetzner root, so no rotation or recovery claim may be made from those keys alone.

Related governance boundaries

This is the current security-model synthesis, not a replacement for Chapter 94 (provider-neutral authorization), Chapter 118 (continuity and recovery evidence), Chapter 131 (approval sessions), or Chapter 134 (native publication authority). Chapter 139 binds those contracts to the currently observed owner-root and recovery evidence boundary.

Definition of done

This chapter is complete when the publication pipeline can show key identity by public fingerprint, declared custody boundaries, typed owner-signed requests, terminal rotation evidence, separate enrollment/publication/release proof, and a fail-closed response to lost-root conditions. It does not claim that the missing recovery operation has been implemented.