Use the key cache in `RequestContext.getSignedKey()`

[dahlia]

Background

RequestContext.getSignedKey() calls verifyRequest() without a keyCache, so every call fetches the signer's key, and so does every getSignedKeyOwner() call. Inbox handling passes a KvKeyCache; this path never has.

The access control guide calls getSignedKeyOwner() in authorize predicates, so every signed GET of a protected actor, object, or collection makes Fedify fetch the key again. A bogus key ID also costs one fetch per request, which inboxes avoid through the negative cache.

Proposed work

Give getSignedKey() the same KvKeyCache that inbox handling builds, under kvPrefixes.publicKey with publicKeyTtl. verifyRequest() already refetches a cached key that fails to verify, so key rotation keeps working.

Open questions:

• Should GetSignedKeyOptions let a caller opt out, e.g., for an endpoint that wants a fresh key every time?
• Is caching here a behavior change worth a changelog note for applications that relied on always-fresh lookups?

Tests

• Repeated getSignedKey() calls across requests with the same key ID fetch the key once within its TTL.
• An unreachable key ID is fetched once, and later requests signed with it hit the negative entry.
• A key that no longer verifies is refetched, and the fresh key is cached.

[rewrite0w0]

Hi! I’d like to work on this issue.

I’ll implement the proposed KvKeyCache integration in RequestContext.getSignedKey() and add the tests described above.

[2chanhaeng]

@rewrite0w0 Assigned. Thanks!