In a TUF-secured package index with thousands of maintainers, when is delegating targets authority worth its cost?

## What delegation is In TUF, the top-level `targets` role does not have to describe every artifact itself. It can **delegate** a set of path patterns to a named role, publishing that role's public keys and threshold inside its own signed metadata. The delegated role then signs its own targets metadata covering only those paths, and may delegate again beneath itself. Delegations are ordered and may be *terminating*, meaning the client stops searching further delegations for a matching path rather than falling through to the next one. A client resolving an artifact walks that tree: top-level targets, then the delegation whose pattern matches, verifying signatures and thresholds at each hop. The effect is that authority over a path is a property of the tree, not of one key. ## The argument for it Consider a language package index with many thousands of independent maintainers. Without delegation, one targets key describes every package in the index. That key becomes the most valuable object in the ecosystem: whoever holds it can publish anything under anyone's name, and it has to be exercised every time any maintainer releases anything — which pushes it towards being online, which is exactly the outcome the role split exists to prevent. With per-namespace delegation, the index's top-level targets role says only "this namespace is described by these keys". The keys that can actually describe a namespace's artifacts belong to that namespace's maintainers and were never on the index's infrastructure. Now compromise of the index's own publishing hosts — the strongest realistic attack on a central service — cannot produce valid targets metadata for any delegated namespace. That is blast-radius scoping, and for a service whose value to downstream consumers is the integrity of other people's source and binaries, it is the main structural defence available. ## The argument against, which is operational Delegation converts a key-management problem you control into a key-management problem thousands of strangers control. Concretely: - **Key loss is routine at scale.** Every lost maintainer key needs a signed change from the delegating role. If that role's key is properly offline, you have just made an offline ceremony part of a daily support queue, and the pressure to bring it online will be constant. - **Delegated metadata expires too.** An abandoned namespace's metadata goes stale and its packages start failing verification for consumers who never did anything wrong. You need a policy for that before you ship, not after. - **Granularity multiplies everything.** Delegating per package rather than per owner produces key sprawl with no additional isolation, because the packages under one owner already fail together. - **Onboarding becomes a security control.** The delegation is only as good as your assurance about who received the keys, which is now a process problem at the scale of your whole maintainer population. ## The honest limit Delegation does not remove the delegating key from the picture. Whoever holds the top-level targets key can revoke a delegation, re-point it at different keys, or add a higher-priority delegation covering the same paths. So the correct claim is narrow and specific: *an attacker who compromises the index's online infrastructure cannot re-sign a delegated namespace*, because the delegating key is offline and out of reach. The claim is **not** that the index operator is technically unable to override a maintainer. Candidates who overstate this are the ones who have read the diagram and not the trust model. Delegation also does not protect against a compromised maintainer within their own namespace. It bounds the damage to that namespace, which is the point, but the maintainer's own account takeover is a threat this control scopes rather than prevents. ## Where the line goes The decision rule that survives contact with reality: delegate where ownership is genuinely independent and where a compromise of one owner should not implicate another. A public index with unrelated maintainers is the clearest yes. An internal repository where one platform team publishes everything is a clear no — you would create key sprawl, a support burden and no isolation, because everything already shares one fate. In between, delegate at the level of the accountable team, keep the delegating key offline and its use rare, decide the expiry and abandonment policy up front, and measure success by whether the delegating key stayed offline a year later. If it did not, the delegation bought you diagrams rather than security.