No duplicate key ids

What this check verifies

This check collects the kid value of every key that has one and confirms they are all distinct. If two or more keys carry the same kid, the check fails. Keys without a kid are not counted here.

A key set with two keys should look like this, with a distinct kid on each:

{
  "keys": [
    { "kty": "OKP", "crv": "Ed25519", "x": "...", "kid": "key-2026-a" },
    { "kty": "OKP", "crv": "Ed25519", "x": "...", "kid": "key-2026-b" }
  ]
}

Why it matters

The kid is meant to identify a key. When two keys share a kid, the label no longer points to a single key, so any consumer that looks a key up by kid cannot tell which one is meant. This is mainly a sign of a copy-paste error during key rotation, where a new key was added but its kid was left as a copy of the old one. The same mistake often leaves the public key (x) wrong too, so a duplicate kid is worth investigating beyond the label itself.

Web Bot Auth resolves an incoming signature by thumbprint rather than by directory kid (see the key id and thumbprint check), so a duplicate kid does not by itself break signature resolution. It is still a directory hygiene problem and the checker fails it so you notice the underlying mistake.

How to fix it

1. Give every key a distinct kid.
2. Check that the duplicate is not a sign of a key that was copied wholesale: confirm each key’s x is the correct, distinct public key, not a copy of another.
3. If a key was meant to be removed during rotation, remove it rather than leaving a second copy with the same label.

The usual cause is rotating keys by copying an existing key block and forgetting to update its kid (and often its x). After the fix, each kid in the set should be unique.

References

• RFC 7517 defines kid as a key identifier within a key set.
• How grading works explains how directory checks contribute to the grade.