Key validity window

What this check verifies

A key may carry optional nbf (not before) and exp (expires) members, each a numeric timestamp in seconds since the Unix epoch. These bound the period a key is meant to be used. They are optional; a key with neither is fine.

When they are present, this check confirms they are coherent:

• If exp is in the past, the key is already expired. This fails.
• If both nbf and exp are present and the window between them is longer than about 400 days, the check warns that the validity window is unusually long.
• Otherwise it passes.

{ "kty": "OKP", "crv": "Ed25519", "x": "...", "kid": "...",
  "nbf": 1735689600, "exp": 1767225600 }

Why it matters

An already-expired key should not be signing anything. Publishing one in the active directory is a contradiction: the directory says “use this key” while the key says “I am no longer valid.” A verifier that honors exp will reject signatures made with it, so leaving an expired key in the directory either breaks verification or signals that rotation did not finish. The checker fails this case.

A very long validity window is the opposite problem. Short-lived keys limit the damage if a key is compromised, because the window in which a leaked key is accepted is bounded. A window of years undercuts that benefit. The checker warns rather than fails here, because a long window is a policy weakness, not a broken directory.

The expired case is a real failure; the long-window case is advisory. Neither makes the directory structurally invalid, but an expired key is a genuine fault worth fixing before it breaks verification.

How to fix it

1. Remove or rotate any key whose exp is in the past. A new key should replace the expired one in the directory.
2. If you set a validity window, keep it bounded. A window under roughly a year keeps the key fresh and limits exposure if it leaks; the checker warns past about 400 days.
3. If you do not need to bound a key’s lifetime, you may omit nbf and exp entirely and rotate keys operationally instead.

The usual cause of the failure is a rotation that added a new key but never removed the expired one. The usual cause of the warning is setting exp years out by default. After the fix, no published key should be expired, and any window you set should be reasonably short.

References

• RFC 7517 defines optional validity members on a JSON Web Key.
• The web-bot-auth directory draft (draft-meunier-http-message-signatures-directory) treats per-key nbf and exp as optional.
• How grading works explains how an expired key fails while a long window only warns.