Automatically delete expired WKD keys and notify users before expiration

[0x46616c6b]

Currently, the keyExpireTime field on OpenPgpKey is populated during import but never evaluated. Expired keys remain stored and served via WKD indefinitely.

Goals

1. Notify users before their OpenPGP key expires via email, so they can upload a new key in time
2. Automatically delete expired OpenPGP keys to avoid serving outdated keys via WKD

Proposed Implementation

1. New UserNotificationType: OPENPGP_KEY_EXPIRING

• Add a new enum case for upcoming key expiration
• Display a notification banner on the account page with a link to the OpenPGP key management page (similar to password_compromised)

2. Email notification via UserNotificationEvent

• Add a listener for UserNotificationEvent that sends an email to the user
• Use the existing Builder/Sender pattern (new OpenPgpKeyExpiringMessageBuilder + OpenPgpKeyExpiringMessageSender)
• The UserNotificationRateLimiter already prevents duplicate notifications, ensuring the email is only sent once per rate-limit window
• This approach also benefits PASSWORD_COMPROMISED — the same listener could handle email delivery for all notification types in the future

3. New scheduled task: CheckExpiredOpenPgpKeys

• Add a new daily message + handler to MaintenanceSchedule
• The handler should:
  • Notify: Find keys expiring within the next 30 days and create a UserNotification of type OPENPGP_KEY_EXPIRING (using the rate limiter to avoid duplicates), which triggers the email via the event listener
  • Delete: Find keys where keyExpireTime < now and remove them (triggering cache invalidation via the existing InvalidateOpenPgpKeyCacheListener)

4. Notification cleanup

• Remove the OPENPGP_KEY_EXPIRING notification when the user uploads a new key

[y3n4]

Automatically delete expired OpenPGP keys to avoid serving outdated keys via WKD

IMO an expired key is still informative and AFAIK it is common behavior of most keyservers to serve expired PGP keys nonetheless:
After retrieving an expired key I might not be able to send someone an encrypted message, but my mail client (or gpg, or sq etc) will be able to (1) associate the fingerprint with the mail address and (2) to verify signatures created with the key.

[0x46616c6b]

Research: How other WKD implementations and the standard handle expired keys

What the WKD draft says

The current WKD specification (draft-koch-openpgp-webkey-service-21, November 2025, Werner Koch / GnuPG) addresses this explicitly in Section 3.1 (Key Discovery):

"Note that the key may be revoked or expired - it is up to the client to handle such conditions."

Additionally, the spec states:

"To ease distribution of revoked keys, a server may return revoked keys in addition to a new key. The keys are returned by a single request as concatenated key blocks."

This means:

• The standard explicitly permits servers to serve expired and revoked keys
• The standard places the responsibility for handling expiration on the client, not the server
• The standard does not prohibit servers from removing expired keys either — it leaves this to the server operator's discretion

How other implementations handle this

keys.openpgp.org (Hagrid) — the largest public verifying keyserver (source):

• Only publishes keys with explicitly verified email addresses
• Allows only one key per email address — uploading a new key for an address replaces the old one (FAQ: "An email address can only be associated with a single key.")
• Does not automatically remove expired keys — they remain retrievable
• No proactive notification system for key expiration

GnuPG gpg-wks-server — the WKD reference implementation (docs):

• File-based: keys are stored as files in a directory structure
• No automatic expiration management — keys remain until manually removed or replaced via the WKD Update Protocol
• No notification mechanism

Proton Mail:

• Auto-generates PGP keys for all users and publishes them via WKD
• The UI prevents uploading expired keys for encryption (docs: "if you upload an expired key, it is not possible to enable PGP encryption")
• No publicly documented automatic cleanup of expired keys or user notification before expiration

Static WKD setups (community, overview):

• Many operators host WKD as static files generated by gpg-wks-client
• Maintenance is entirely manual — expired keys remain until someone manually removes and re-publishes them
• No standard tooling for automatic cleanup or notification

Arguments for and against removing expired keys

For keeping expired keys (supporting @y3n4's point):

• The WKD draft explicitly states that clients should handle expired keys — serving them is within spec
• An expired key still allows clients to (1) associate a fingerprint with a mail address and (2) verify signatures made with that key — as y3n4 noted
• No major WKD implementation (keys.openpgp.org, GnuPG gpg-wks-server) removes expired keys automatically
• A user may intentionally let a key expire while preparing a replacement and expect the old key to remain briefly discoverable

For removing expired keys:

• Not all clients handle expiration correctly — some may attempt to encrypt to an expired key, leading to messages the recipient cannot decrypt (or confusing error messages)
• As a mail provider with direct access to users, Userli has a stronger relationship than a public keyserver and can proactively manage key hygiene
• Expired keys with lost private keys serve no practical purpose and may cause confusion

Middle ground — notify but don't delete:

• Notify the user (email + UI notification) that their key is about to expire or has expired, giving them the opportunity to upload a new key
• Keep expired keys in WKD, since this is in line with the standard and current keyserver behavior
• Let the user decide whether to delete the expired key themselves

Summary of options

Option	Notify user?	Delete expired keys?	Alignment with standard	Alignment with other implementations
A: Notify + Delete	Yes	Yes	Permitted (not prohibited)	Goes beyond all known implementations
B: Notify only	Yes	No	Fully aligned	Notification is novel; serving expired keys is standard practice
C: Do nothing	No	No	Fully aligned	Matches current behavior of all known implementations