[Feature Request] WKD (Web Key Directory) support in CipherMail Gateway Community edition

Gateway
1

Hello CipherMail community, and thanks for maintaining this project :slight_smile:

We’d like to suggest native WKD (Web Key Directory) support in the Community edition.

WKD is a standard OpenPGP building block (RFC 9234) for automatic key discovery, widely adopted by clients (Thunderbird, Proton, OpenKeychain, etc.).
In the open-source spirit and given the “the most configurable encryption gateway” positioning, native WKD support on the gateway should be part of the Community baseline (not a commercial add-on).

Why WKD should be in Community

  • Trust: keys are published under the recipient’s domain via HTTPS → authenticity controlled by the domain owner.
  • Interoperability: modern MUAs query WKD first.
  • User experience: zero configuration to discover public keys.
  • Security: avoids ambiguity/pollution of public HKP keyservers.
  • OpenPGP coherence: WKD is a fundamental component, not an optional extra.

Expected behavior — WKD lookup

  • Global enablement: once WKD is enabled, lookup applies by default to all domains. Admins can then restrict per domain and/or per email address via overrides (disable for a domain, exclude specific addresses, adjust lookup order/TTL).
  • Configurable lookup order (global + per-domain/rule overrides): Local (keystore) → WKD → HKP (or any permutation chosen by the admin).
  • WKD methods: support direct (example.com) and advanced (openpgpkey.example.com).
  • Strict HTTPS (validate with system CAs; no HTTP fallback).
  • Auto-import into the gateway’s OpenPGP keyring with checks: UID equals address; no revocation/expiration; minimum algorithm policy (e.g., RSA ≥ 3072, Ed25519/Curve25519).
  • Cache & refresh: configurable TTL, error backoff (4xx/5xx), reasonable retries.
  • Control lists: denylist for addresses and domains (never query WKD); allowlist per domain if needed.
  • Explicit logging: key source (Local/WKD/HKP), URL queried, fingerprint, import timestamp, decision.

(Optional) — WKD publication helper

Publication is typically served by the domain’s web server. Two lightweight gateway helpers would be very useful:

  1. Export a WKD tree (z-base-32 hu/... hashes + policy) from local public keys, ready to deploy.
    – Supported transports: rsync/SSH, SFTP/FTPS (avoid plain FTP), or HTTP(S) PUT / WebDAV (useful when the site is outside the DMZ at an external host).
  2. Publication exclusions: a denylist to avoid publishing specific addresses (e.g., noreply@, mailing lists).

A simple CLI for export with transport selection, credential handling, and connectivity test is sufficient for Community.

Suggested settings / UI

  • System → OpenPGP → Settings
    • Enable WKD lookup (global) → applies to all domains by default
    • Lookup order: Local, WKD, HKP (drag & drop)
    • Per-domain overrides: enable/disable WKD, exclude specific email addresses, TTL, allow/deny, custom order
    • Minimum key policy (algorithms/key lengths)
    • Logging level (normal/verbose)
  • Test tool: “Test WKD for address” (URLs tried, HTTP code, fingerprint, decision).

Minimal CLI (MVP)

  • ciphermail-wkd --locate user@example.com → WKD test; JSON output (URL, code, fingerprint, decision)
  • ciphermail-wkd --import user@example.com → import if valid
  • ciphermail-wkd --export-wkd /path → build publication tree (optional)

Security & robustness

  • Strict TLS, timeouts/retries, rate limiting.
  • Import without ownertrust (encrypt-only usage).
  • Handle key rotation (prefer the latest non-revoked key per policy).
  • No regression: do not overwrite a newer/valid local key.

Backward compatibility

  • WKD can be disabled: current behavior (Local → HKP) remains unchanged.
  • When enabled: use the preferred key according to policy (freshness/validity).

Acceptance examples

  • With no local key but a valid WKD key, the gateway imports and encrypts; logs show source=WKD.
  • Address/domain on the denylist: no WKD query is performed.
  • Revoked/expired WKD key: import rejected with clear logging.

Roadmap

Is WKD integration in Community planned? If possible, please share a target timeline or public beta.

Thanks for reading — looking forward to your thoughts!

2

Thanks for that AI Slop with absolutely zero value. No links to sources or further documentation.

RFC9234 is “Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages” for BGP.

WKD is still a draft, not finalized. draft-koch-openpgp-webkey-service-20

3

Thanks @Josef-Check for pointing that out — you’re right. WKD isn’t an RFC; it’s the IETF Internet-Draft draft-koch-openpgp-webkey-service.
That said, WKD has been stable in practice and widely implemented for years (e.g., GnuPG, Thunderbird, Proton, OpenKeychain).

Why it matters for CipherMail users

  • Zero-touch, first-contact encryption: the gateway can discover keys via WKD before the very first message, so the first message is already encrypted, with no manual exchange.
  • Domain-controlled HTTPS trust model (less ambiguity than public HKP).
  • Huge ready-made ecosystem: providers/clients already publishing/querying WKD (e.g., Proton’s large user base, Thunderbird) become instantly compatible - no manual key exchange.

It would also position CipherMail as one of the first mainstream gateways to align with WKD-first clients, using domain-controlled HTTPS (less ambiguity than public HKP).

Minimal scope requested: configurable order Local → WKD → HKP, strict HTTPS (no HTTP fallback), per-domain/per-email exclusions, basic auto-import checks (UID=email, not revoked/expired, min algorithms), clear logging, sensible cache/TTL.

References:

An ETA or roadmap would help planning. Thanks for considering.