proposal: distinguish same-origin TLS binding from delegated signing

[igrigorik]

§5.2 ("Binding keys to the directory authority") RECOMMENDS that a directory server include one per-key HTTP Message Signature over @authority;req + content-digest, and says "clients SHOULD ignore keys from a directory response that do not have a corresponding valid signature." PR #98's intent extends this to jwks_uri responses ("we still strongly suggest that jwks_uri response is signed to bind keys to a domain").

This is applied uniformly, but the binding goal is already met by the transport in one common case:

• Same-origin serving. When the directory / jwks_uri is served from the same origin as the @authority the keys speak for, TLS to that origin already binds the keys to that authority. A verifier that fetched https://signer.example/... over TLS and got these keys has the same authority binding the per-key @authority;req signature would provide. The signature is redundant with TLS here.

• Delegated / cross-origin serving. When keys are served from a different origin than the authority (delegation, third-party key hosting, a shared key service), TLS to the key host does not bind the keys to the authority. The per-key @authority;req signature is then the essential — and only — binding. This is exactly where §5.2 earns its keep.

Proposal

Scope §5.2's signing recommendation (and the "ignore unsigned keys" guidance) to the delegated / cross-origin case, or at minimum add a note that a directory/jwks_uri served same-origin with the authority over TLS satisfies the authority-binding goal without per-key signatures. Otherwise a conformant verifier following the blanket SHOULD would ignore unsigned keys that are in fact securely bound to the authority by TLS.

Why it matters

Deployments that reuse a same-origin identity document as the JWKS — e.g., an agent/commerce profile served at the operator's own well-known URL, pointed to by Signature-Agent; type=jwks_uri — would otherwise be forced into dynamic per-key response signing: private keys at the serving layer (or a precompute pipeline), caches keyed on @authority, and re-signing on expires. That is real operational burden with no security gain over TLS in the same-origin case. Distinguishing the two cases keeps the simple same-origin path viable while preserving the signature requirement where it is actually load-bearing (delegation/cross-origin).

[thibmeu]

When the directory / jwks_uri is served from the same origin as the @authority the keys speak for, TLS proves the authority served this public key set.

I don't think that's true. Serving key_example on example.com does not prove that example.com has ownership of the key. Because the keys are public, we could imagine evil.example.com serving the same keys.

Serving a signature over the requested authority helps to bind it. That applies both to the delegated and same-origin.

We can clarify section 5.2 to distinguish transport integrity from key-authority binding, but I would not scope the signing recommendation only to cross-origin/delegated discovery. Would that fit better?

[shivdeep1]

We can clarify section 5.2 to distinguish transport integrity from key-authority binding, but I would not scope the signing recommendation only to cross-origin/delegated discovery. Would that fit better?

Picking this up late because the same scoping question came back on the list this week, and I think the distinction you proposed is the answer to it.

In -02 this text is Appendix B, "Validating the domain binding", and it opens with "It applies to the directory type in Section 5.5."

That's right for the binding. 4.5 rests on the well-known path being reserved, so an arbitrary jwks_uri path can't carry it. But B.1 is a possession proof over @authority and content-digest, and possession isn't type-specific. Two properties sharing one appendix, and the scope sentence reads as covering both.

Practical effect: a jwks_uri or cimd operator can't produce a conformant proof, since 5.5.3 wants "a valid directory response signature as described in Appendix B" and the tag is pinned to http-message-signatures-directory. Which cuts against #98, "We still strongly suggest that jwks_uri response is signed to bound keys to a domain."

Two implementers said on the list this week they only do B.1 on directory responses, because that's what the text licenses.

Suggested edit to the scope paragraph:

The domain binding described in Section 4.5 applies to the directory type
in Section 5.5. The possession proof in Appendix B.1 is not specific to
that type: it covers @authority and content-digest, and applies to any
response serving key material. A server publishing under jwks_uri or cimd
MAY include it, and a verifier MAY consume it under Section 5.5.3.

The tag is the loose end. Simplest is a sentence saying the value names the mechanism rather than the resource, so it's unchanged across types. A second value would be cleaner and more churn. Happy to write either as a PR.