spec: the well-known key document is unsigned, so web-host write access equals trust-root compromise

[rrrodzilla]

Summary

The key document published at /.well-known/agent-keys.json carries no
signature. Its authenticity rests entirely on the TLS connection that served
it, which makes write access to the web server equivalent to possession of the
trust root's signing key. Section 8 does not treat the publication channel as
its own threat, and none of §8.2's mitigations apply to it.

What the document is today

KeyDocument (agent-uri-attestation/src/key_document.rs:111) has three
fields and no fourth:

pub struct KeyDocument {
    trust_root: String,
    keys: Vec<PublishedKey>,
    #[serde(default)]
    revoked_keys: Vec<RevokedKey>,
}

That matches §7.2's response format, so this is a specification property rather
than an implementation gap.

Why this is not covered by §8.2

§8.2 covers a compromised signing key thoroughly: revocation on both
granularities, overlap windows, short exp, HSMs. Compromising the
publication host reaches the same outcome — minting attestations that verify
for the whole namespace — but every mitigation §8.2 offers is unavailable:

§8.2 mitigation	Against a compromised publication host
revoked_keys list	The attacker serves the document that carries the list
Key rotation with overlap	The attacker publishes the incoming key
HSM protection	The signing key was never the target
Short exp	Bounds each token, not the attacker's ability to mint more

Revocation is the load-bearing one, and it inverts here: the channel a verifier
consults to learn that a key is bad is the channel the attacker controls.

§8.3 is the nearest coverage, but it addresses a different threat — an
attacker claiming a domain they do not control — and its mitigation ("DNS and
TLS provide domain authentication") is exactly what a host compromise defeats,
because the attacker is serving from the legitimate domain with a legitimate
certificate.

Why the client cannot close it

agent-uri-attestation-wellknown already enforces every check §7.2 asks for:
HTTPS-only, no redirects, caps on declared and actual body length, and the
requirement that a document name the root that served it. Each of those
defends the channel. None of them can distinguish a document the trust root
authored from one an attacker wrote to the same path, because there is nothing
in the document to distinguish them by.

This is also not something a hardened server deployment fixes. A compromised
application server is exactly as fatal as a compromised nginx.

Proposed mitigation

Sign the key document with an offline root key, so the web host never holds
signing material:

• Add a signature field to §7.2's response format covering the document body.
• The signing key stays offline; publication becomes a file copy.
• Verifiers pin the root key out of band, as a deployment decision — §7.2
  already establishes that "which trust roots matter is a deployment decision".

Host compromise then degrades to denial of service and stale-document
replay, rather than namespace takeover.

Open questions

1. Bootstrap. A self-signed document is circular: whoever writes the file
   writes the signature. The root key has to be pinned out of band for this to
   buy anything, which is real deployment cost and worth weighing against the
   threat.
2. Replay of a stale signed document. Signing alone does not stop an
   attacker serving an older validly-signed document that predates a
   revocation. Needs a monotonic version or freshness bound, which is
   additional mechanism.
3. Whether the cost is worth it. For a deployment where the trust root
   already runs its own infrastructure, the added key-management burden may
   exceed the risk. The alternative is to leave the design as it is and state
   the limitation explicitly in §8 so operators can decide.

At minimum, §8 should name this threat and its residual risk, even if the
signed-document mitigation is not adopted.

Scope

Specification change (§7.2 response format, new §8 subsection). Implementation
in agent-uri-attestation and agent-uri-attestation-wellknown follows from
whatever the specification settles on.

[rrrodzilla]

Reviewed this against the spec and both crates. Every factual claim holds: KeyDocument has exactly the three fields shown, matching the §7.2 response format; the §8.2 mitigation table is accurate (all four mitigations target a stolen signing key, none survive a compromised publication host); §8.3's mitigation is literally the thing a host compromise satisfies; and the wellknown client enforces every channel defense listed, none of which can distinguish authorship. The strongest part of the analysis is the inversion: the channel a verifier consults for revocation is the channel the attacker controls.

Five points that sharpen the proposal and the open questions:

1. The proposed mitigation is TUF's root role, and citing TUF answers open question 2. The Update Framework solved this exact shape: an offline root key signs the served document, and replay is handled by a monotonic version plus a short expires inside the signed payload (TUF's snapshot/timestamp roles). That converts "needs additional mechanism" into mechanism with a decade of deployment history. DNSSEC's offline KSK signing an online ZSK is the same pattern.

2. Bootstrap cost (open question 1) is smaller than stated. §7.2 already makes "which trust roots matter" a deployment decision, so every verifier already carries an out-of-band allowlist of root names. Pinning a root key adds one field to a config entry that must exist anyway. The real cost is operational on the trust root's side (offline key ceremony), not verifier-side.

3. Stale-document replay is already partially bounded. §7.2 requirement 5 makes verifiers reject keys outside their validity window at verification time, so a replayed document is only useful until its keys' not_after. The residual exposure is specifically a revoked-but-not-yet-expired key. Worth stating in the issue, because it narrows what a freshness mechanism has to buy.

4. A detection tier belongs in the decision space. Between "document the limitation" and "offline-signed documents" sits transparency: CT-style logging of published documents, or multi-vantage fetching, turns a silent namespace takeover into a detectable event. Given open question 3's doubt about whether prevention justifies the key-management burden, detection-without-prevention is a real middle option.

5. An adjacent bound worth naming in the proposed §8 subsection: revocation freshness is bounded by the discovery cache TTL (one hour by default) regardless of adversary behavior. The wellknown client refuses to serve a cached document past its TTL and fails closed when a refresh fails, so an attacker who can only block the endpoint (not write to it) gains nothing beyond the staleness that exists with no attacker present. The residual inside that window is the revoked-but-not-yet-expired key from point 3. The TTL was sized against token lifetime rather than revocation urgency, and whether one hour is also the right bound for revocation news is worth a sentence in the new section.

Recommendation: adopt the minimum (name the threat and residual risk in §8) regardless of the design decision. For the mitigation, specify the signature as OPTIONAL in §7.2, modeled on TUF (signed payload carries version and expires; verifiers require it by policy against a pinned root key). Open-discovery deployments keep working; high-assurance deployments close the hole.

Edited: point 5 originally attributed an exposure window to the client's retain-on-failure behavior. That was wrong; the retained entry is never served past its TTL, so the bound is the TTL itself, adversary or not.