Idea: Use ENS for OpenPGP Key Publishing (and Auditing)

🌱 ENS Ecosystem
1

Use ENS for OpenPGP Key Publishing (and Auditing)

Category: Standards · Status: Draft / Request for Comment

TL;DR

There is today no standard ENS text-record key for publishing an OpenPGP
public key — ENSIP-5 reserves email, url, avatar, service keys like
com.github / io.keybase, but nothing for PGP. I’d like to propose a small,
spec-compliant convention so a name like alice.eth can advertise “here is my
OpenPGP key, and here is a tamper-evident, on-chain history of every time I
rotated or revoked it.”

DNS already has this (RFC 7929 OPENPGPKEY,
Web Key Directory). ENS can offer the same discovery, plus one thing DNS/WKD
structurally cannot: a publicly auditable, non-equivocable, optionally
multisig-controlled log of key changes.

Concretely: a service key org.openpgp holding the key’s fingerprint
(the compact trust anchor), with an optional org.openpgp.uri pointing to
the full armored key off-chain (HTTPS/WKD/IPFS) — and, as an alternative
substrate, storing the actual OPENPGPKEY DNS record via
ERC-1185 (see Integration below).

Motivation

Publishing a public key is the easy half of PKI. The hard half is binding,
revocation, and auditability. Existing options each miss something:

  • Keyservers (keys.openpgp.org): no strong identity binding; third-party
    signatures dropped, so no web of trust to lean on.
  • WKD / DNS OPENPGPKEY: binds a key
    to a domain via TLS/DNSSEC — good, but the mutation history is invisible (a
    compromised registrar can swap the key and roll it back with no public trace)
    and it can equivocate.
  • Web-of-trust: effectively deprecated in practice.

ENS names are already portable, self-sovereign identities with a text-record
convention for exactly this kind of metadata. Adding OpenPGP means
encrypt-to-alice.eth with a discovery path that is on-chain, auditable, and
controllable by a multisig.

What ENS adds over DNS/WKD

(If ENS only matched DNS there’d be no reason to do it.)

  1. Auditable mutation log for free. Every write is an on-chain event with a
    timestamp — anyone can reconstruct the complete history of a name’s PGP key
    and prove no entry was silently altered. DNS gives you the current value; ENS
    gives you the provable history.
  2. Non-equivocation. A single global ordered state means the resolver can’t
    show a revocation to the public but hide it from a targeted victim — the
    split-view attack that plagues both DNS and transparency-log designs.
  3. Threshold control of the anchor. The name’s controller can be a
    Safe/multisig, so “who may change our disclosure key” is an M-of-N on-chain
    policy instead of one certify-only master key that sinks the identity if
    lost/stolen.

Honest limitations (so we design around them, not oversell)

  • Freshness is still the verifier’s job — a client that caches a key and never
    re-reads the record won’t notice a revocation. Inherent to all key systems, not
    ENS-specific.
  • This is discovery + audit, not a new crypto primitive — reporters still
    encrypt to a normal OpenPGP key with normal tooling.
  • Complements, doesn’t replace, transparency logs (IETF KEYTRANS, Sigstore) —
    this is the ENS-native, no-extra-infrastructure option for names already
    on-chain.

Prior art

  • ENS: ENSIP-5 (EIP-634) text records; ERC-1185 “Storage of DNS Records in
    ENS”    ; io.keybase already binds crypto
    identity to names; forum precedent for adding keys (“audio text record”,
    “enhancements to ENS text records”). No PGP key is currently defined/reserved.
  • DNS/PGP: RFC 7929 OPENPGPKEY, PKA,
    Web Key Directory (WKD) — the analogs this borrows from.
  • Historical web3 attempt: Keybase’s signed sigchain (largely abandoned
    post-acquisition) — a cautionary precedent.

Sketch

Recommended — fingerprint on-chain, key bytes off-chain:

org.openpgp      = <OpenPGP fingerprint, uppercase hex, no spaces>   # trust anchor
org.openpgp.uri  = https://… | ipfs://… | WKD URL                    # optional; verified against the fingerprint

The cheap, security-critical anchor stays on-chain (auditable, non-equivocable);
the bulky, rarely-read key bytes stay off-chain and are verified against it. A
fully-inline armored-key variant could be allowed for names wanting zero
off-chain dependencies (cheap on L2 / CCIP-Read).

Revocation = set org.openpgp to a tombstone (empty or REVOKED) in one
transaction — that tx is the non-equivocable, timestamped revocation event.

Integration consideration: ERC-1185 (DNS records in ENS)

There are two viable substrates in ENS, and they’re complementary:

  • (a) A new org.openpgp text record — simplest, human-readable, works on
    every existing resolver today, easy for wallets to render.
  • (b) ERC-1185 — its
    setDNSRecords() / dnsRecords() resolver profile stores DNS records in wire
    format and supports any RR type, so it can hold the actual
    RFC 7929 OPENPGPKEY record directly.
    Upside: reuses the exact DNS format and existing PGP/DNS tooling, and gives
    a clean migration path for anyone already publishing OPENPGPKEY in DNS.
    Trade-off: ERC-1185 is still in Review and less widely deployed than text
    records, and it’s more complex to author/read.

My leaning: standardize the text-record convention now for adoption, and
recommend ERC-1185 OPENPGPKEY as the tooling-reuse path for names that want
DNS-format parity. A resolver could expose both and treat the on-chain
fingerprint as the canonical anchor. Feedback on whether to bless one or both is
exactly what I’m after.

Open questions

  1. Global key pgp vs service key org.openpgp?
  2. Text record vs ERC-1185 OPENPGPKEY — one, the other, or both?
  3. Fetch URI as a separate record, reuse contenthash, or a small JSON value?
  4. A parallel record for age / non-PGP recipients, or keep this
    OpenPGP-specific?
  5. Which resolvers / wallets / PGP tools (GnuPG, Sequoia, Proton) would need a
    plugin to make encrypt-to-name.eth real?

Next steps

If there’s appetite I’m happy to write a formal ENSIP, ship a reference
encrypt-to-ENS CLI (resolve → fetch → verify → encrypt), and dogfood it in
production: I work on Namefi (on-chain domain tokenization) and run a live
security.txt disclosure program, so I can wire a real security.<name>.eth PGP
record with a Safe-controlled rotation/audit trail and report back on cost + UX.

Disclosure: posting as a Namefi contributor; the proposal is vendor-neutral —
any name holder benefits, nothing Namefi-specific in the standard itself.

Feedback welcome — especially from anyone who’s looked at ENS ↔ PKI, and from the
GnuPG/Sequoia side on what would make tooling adoption realistic.

1 Like
ENS DAO Newsletter #116 — 07/15/2026