Key set size is reasonable

What this check verifies

This check counts the keys in the directory and warns if there are more than 100. It is a sanity bound, not a hard limit: a key set within the bound passes, and a larger one warns. It never fails and never makes the directory invalid.

The web-bot-auth spec does not set a maximum key count. The 100-key bound is the checker’s own threshold for “this is more keys than a normal deployment publishes, take a look.”

Why it matters

A real deployment publishes a small number of keys: usually one active key, sometimes a second during rotation. A directory carrying dozens or hundreds of keys is unusual and is more often a mistake than a deliberate choice. It can mean old keys were never pruned during rotation, that a build step appended keys instead of replacing them, or that an unrelated key set was served at the path.

A large key set also enlarges the directory every verifier fetches and gives an attacker more keys to confuse resolution, so trimming it to the keys actually in use is good hygiene. The warning is advisory: if you genuinely need many keys, the directory is still valid and the warning is the checker prompting you to confirm that is intentional.

How to fix it

1. Confirm each published key is one you actually sign with.
2. Remove retired keys once no agent signs with them and no recently issued signature still needs them to verify.
3. If your directory grows on every deploy, check that the build step replaces the key set rather than appending to it.

The usual cause is rotation without cleanup, or an append-only build step. If the size is intentional, no change is needed; the warning simply flags it for review.

References

• RFC 7517 defines the keys array; it sets no maximum count.
• How grading works explains how an advisory warning moves the grade without capping it.