Trust-anchor policy must hold on long-lived industrial hosts you cannot reliably reach - how do you decide it?

Anchor policy on a reachable fleet is an administration task. On a fleet you cannot reliably reach - long-lived hosts, field equipment, appliances on maintenance windows measured in quarters - it becomes a **commitment problem**, and it should be reasoned about the way other irreversible commitments are. ## The asymmetry that drives everything Adding an anchor to a fleet is a campaign: every list on every host, including the ones inside images and inside runtimes that upgrades will overwrite. **Removing** one is a harder campaign, because removal is only safe once nothing still depends on it, and establishing that requires knowing what each host currently holds. The consequence is a ratchet: estates accumulate anchors, and the accumulated ones are the least reviewed. So the first decision rule is simply: *the cheapest anchor is the one you never install.* ## Whether to run an internal issuing authority at all This is the genuine fork, and it has honest answers on both sides. | | Run an internal authority | Use a public authority for internal names | |---|---|---| | Anchor distribution | you must install and maintain your own anchor on every list on every host | already present in vendor-shipped lists | | Trust breadth for internal traffic | narrow: one authority you operate | broad: whatever the shipped list contains | | Issuance for private or unresolvable names | straightforward | depends on being able to prove control of a public name | | Cost on unreachable hosts | high and recurring | low | | Succession | entirely yours to plan | handled by whoever maintains the shipped list | On a fleet you can reach, the internal authority usually wins on breadth. On a fleet you cannot, the distribution column often decides it, and the honest answer is sometimes "fewer internal authorities than we would like, and pinning where we need real narrowing". ## Lifetime must be chosen against reachability The number that matters is not the anchor's lifetime in isolation; it is the lifetime **relative to the interval at which you can reliably change a host's lists**. If a host is touched once a year and the anchor's succession arrives in three, you have two planned interventions to get right. If the succession arrives sooner than the next touch, you have scheduled an outage. Practical consequences: 1. Plan the **successor anchor before deploying the first one**, and install both while you still have hands on the fleet, so the changeover is a server-side act rather than a fleet-side one. 2. Prefer overlapping anchor lifetimes over just-in-time replacement, because just-in-time assumes a touch you may not get. 3. Treat the anchor's own lifetime as a *reachability* parameter, not a cryptographic one. ## Narrow what you install An anchor entry is authority to vouch for names. Where the validators that matter will honour it, a constrained anchor reduces what a single entry authorises; where they will not, the constraint is a belief rather than a control, and the narrowing has to come from somewhere else - a smaller anchor list on that host, or a pin in a client you build. Verify which case you are in per runtime, not once for the estate. ## Keep an inventory, or you cannot make any of these decisions Every decision above needs to know what is actually installed, and "what we deployed" is not the same as "what is present". A usable anchor inventory records, per host and **per list on that host**: - each entry, identified by its **public key** rather than a friendly name, since two entries with the same name and different keys are two grants; - **who added it and when**, and under what change; - **when the list was last reviewed**, and by whom; - what would break if the entry were removed. An entry nobody can account for is the finding that matters, because an anchor list is the one place where a single unaccounted line grants authority over every name the processes reading that list will ever connect to. Reviewing lists on a schedule is what makes such a line visible at all; without the review, an extra entry is indistinguishable from a legitimate one that predates everybody present. ## How to state the decision A defensible policy on an unreachable fleet reads roughly: *we run this many internal authorities, anchored on these lists, with successors already installed; anchor lifetimes exceed our worst-case touch interval by this margin; each host's lists are inventoried by key and reviewed on this cadence; and where we need narrower trust than an anchor list can express, we pin in clients we ship rather than adding more entries.* Every clause of that is a number or an owner, and the value of writing it down is that it makes the ratchet visible before it closes.