# Railiance Clock attended host delivery — CCR-2026-0028

The operator approved CCR-2026-0028 for both platform and Clock ownership, then
accepted the correction to systemd host delivery. Kubernetes is present on
Railiance01, but this authority runs as a host service and needs no Kubernetes
identity or standing OpenBao read grant.

Ansible's `railiance_clock_prepare_only=true` prepares the nologin system account,
root-owned installation directory, and service-owned mode-0700 state directory.
It does not require a key or activate the authority.

Run the committed `scripts/railiance_clock_custody.py --receipt <new-private-file>`
inside `warden access openbao-platform-admin-login --exec -- python3 ...`.
The helper requires the exact approved CCR, a non-root platform-admin session
from auth/netkingdom, and enabled audit. It generates an ES256 key in memory,
creates the exact KV path with CAS zero, and verifies version 1 before delivery.
No workload policy or role is created. SSH uses strict known-host verification;
the receiver writes a complete mode-0600 file atomically to
`/var/lib/railiance-clock/signing.pem`, owned by `railiance-clock`, and refuses to
overwrite any different existing key. Only public-key metadata enters the receipt.

If custody succeeded and host delivery failed, inspect the receipt stage/version.
Use `--resume-version 1` through a fresh attended envelope to deliver that same
initial version. This never creates or rotates a key. A changed custody version,
existing different host key, or permission drift requires reconciliation.

After successful delivery, Ansible uses `railiance_clock_key_preinstalled=true`,
checks private key metadata, installs the pinned wheel and health probe, and
starts the localhost-only authority. `railiance_clock_private_key_source` is not
needed in this mode. Readiness and independent signature verification are required
before marking the CCR verified. No client trust is inferred from readiness.

Rotation is a separate explicit operation: stop the authority, CAS against the
known current custody version, replace the host key atomically, and distribute
new public key/epoch trust before resuming clients. This initial-admission helper
deliberately does not implement rotation or overwrite keys.

## Accepted production deployment

Version 1 custody and native workstation samples passed on 2026-09-15. See
`docs/evidence/2026-09-15-railiance-clock-host-custody.json` and
`docs/evidence/2026-09-15-railiance-clock-production.json`.
Use the documented private OpenBao endpoint `http://127.0.0.1:18200` for the
attended envelope: the configured public hostname presented an untrusted
certificate during deployment. TLS verification was not disabled.

Authority endpoint on Railiance01: `http://127.0.0.1:8787/v1/time-samples`;
readiness: `http://127.0.0.1:8787/readyz`. Workstations use an authenticated SSH
loopback connection and separately admitted public key/epoch. Trust files last
at most 15 minutes and do not survive a workstation boot. Optional integrations
are not globally enabled by this deployment; operational trust refresh remains
in RCLK-WP-0005-T06 and consumer adoption in RCLK-WP-0004.

The health export sandbox allows read-only adjtimex, which ProtectClock would
block even with modes=0. Empty bounding/ambient capability sets deny clock writes.
The authority keeps ProtectClock enabled.