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

**URL:** <https://community.ciphermail.com/t/feature-request-wkd-web-key-directory-support-in-ciphermail-gateway-community-edition/1010>\
**Category:** Gateway\
**Tags:** pgp\
**Created:** [September 1, 2025, 11:58am UTC](https://community.ciphermail.com/t/feature-request-wkd-web-key-directory-support-in-ciphermail-gateway-community-edition/1010 "2025-09-01T11:58:19Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![opgp-wkd-forum](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/opgp-wkd-forum/32/236_2.png) [@opgp-wkd-forum](https://community.ciphermail.com/u/opgp-wkd-forum)\
**Post date:** [September 1, 2025, 11:58am UTC](https://community.ciphermail.com/t/feature-request-wkd-web-key-directory-support-in-ciphermail-gateway-community-edition/1010/1 "2025-09-01T11:58:19Z")

</div>

**Hello CipherMail community** , and thanks for maintaining this project 🙂

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!**

---

<div class="post-metadata">

**Author:** ![Josef-Check](https://avatars.discourse-cdn.com/v4/letter/j/f04885/32.png) [@Josef-Check](https://community.ciphermail.com/u/Josef-Check)\
**Post date:** [September 2, 2025, 4:30pm UTC](https://community.ciphermail.com/t/feature-request-wkd-web-key-directory-support-in-ciphermail-gateway-community-edition/1010/2 "2025-09-02T16:30:01Z")

</div>

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](https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service)

---

<div class="post-metadata">

**Author:** ![opgp-wkd-forum](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/opgp-wkd-forum/32/236_2.png) [@opgp-wkd-forum](https://community.ciphermail.com/u/opgp-wkd-forum)\
**Post date:** [September 3, 2025, 7:08am UTC](https://community.ciphermail.com/t/feature-request-wkd-web-key-directory-support-in-ciphermail-gateway-community-edition/1010/3 "2025-09-03T07:08:01Z")

</div>

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:**

- IETF draft: [draft-koch-openpgp-webkey-service-20 - OpenPGP Web Key Directory](https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/)
- GnuPG WKD overview: [https://wiki.gnupg.org/WKD](https://wiki.gnupg.org/WKD)

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