Cap the number of RFC 9421 signatures verified per request

[dahlia]

Background

An RFC 9421 request can carry several signatures in its Signature-Input and Signature fields. verifyRequest() and verifyRequestDetailed() in packages/fedify/src/sig/http.ts try every signature in turn until one verifies, and each attempt may fetch the key its keyid names. Before the fetch, a signature only has to have a created timestamp within the time window and, if it covers content-digest, a matching digest; both are under the sender's control.

There is no limit on the number of signatures, so one unauthenticated request whose signatures name N different key IDs makes Fedify fetch N URLs of the sender's choosing, one after another. Changing the key IDs between requests also bypasses the key cache. Draft-cavage requests carry a single signature, so they are not affected.

Keys whose IDs lead to more than one fetch make this worse; for example, #1132 covers ap: key IDs, each of which may be tried at up to five gateways.

Proposed work

Cap the number of RFC 9421 signatures that are verified per request, e.g., to a small constant such as three or four, and treat the remaining ones as if they were absent. Decide whether the cap should be configurable (e.g., through VerifyRequestOptions and FederationOptions), and in which order signatures are tried when there are more than the cap.

It may also help to skip a signature whose key ID was already tried for the same request.

Scope

This issue is about the number of signatures verified per request. It does not change how a single signature is verified.

Tests

• a request with more signatures than the cap makes no more key fetches than the cap;
• a valid signature within the cap is still accepted;
• a request with the same key ID in several signatures fetches the key once, if deduplication is added.