Name: DNS-Designated Public Key Discovery for Email-Address Identifiers

Description

The Problem

Email-address identifiers (user@domain) are among the most widely used
identifiers across the Internet. They are used not only for email
communication but also as login identifiers for banking, government
services, e-commerce, social media, healthcare, and enterprise
applications.

Despite this ubiquity, they are not cryptographic identifiers: there is
no standardized, interoperable mechanism for associating a public key
with an email-address identifier and discovering that key in an
application-agnostic way, so that a relying party can encrypt to
alice@example.com, verify a signature associated with
bob@example.net, or authenticate charlie@example.org without shared
secrets.

Existing approaches to public-key distribution for email-address
identifiers are siloed by application or deployment model:

• Email encryption (OpenPGP, S/MIME, WKD): distributes keys for
  encrypted email, but is tied to specific email security ecosystems and
  does not provide a general, application-agnostic framework.
• Authentication (WebAuthn, FIDO2): enables passwordless login, but
  keys are bound to a specific relying party or application context,
  with no general public-key discovery mechanism for an
  email-address identifier.
• Certificate PKI (S/MIME CAs): provides certified key bindings, but
  depends on managed CA infrastructure and is not self-service.
• DNS-based key publication (DANE, OPENPGPKEY): publishes keys via
  DNS, but per-user key storage in DNS creates scaling and operational
  challenges.

Each solves part of the problem. None provides a general,
application-agnostic mechanism for discovering verified public keys
associated with an email-address identifier.

Proposed Solution Framework

The proposed framework allows each domain to designate, via DNS, a key
service responsible for key discovery for email-address identifiers
under that domain.

That service, called a Domain Key Authority (DKA), would:

• verify a registrant’s control of an email-address identifier,
• store selector-scoped public keys for that identifier, and
• return those keys over HTTPS in a structured format.

Architectural Rationale

The DKA framework learns from prior approaches such as OpenPGP,
S/MIME, DANE, and WKD. Specifically, it proposes to separate four
functions that have been conflated or bound to specific applications by
previous approaches:

• Designation of key service: DNS provides the designation
  function at domain granularity, identifying a DKA service
  as authoritative for public keys of email addresses under
  a given domain.
• Storage of key material: the DKA service stores per-identifier key
  records using infrastructure that scales independently of DNS.
• Retrieval of key records: the DKA service is discovered via DNS
  and accessed over HTTPS to retrieve structured key records with
  metadata.
• Identifier-to-key binding: the framework treats an email-address
  identifier as an Internet identifier to which one or more public keys
  may be bound, without limiting use of those keys to email transport.

BOF Goal

One realization of this architecture is specified in
draft-swaminathan-dka-framework-01 (https://datatracker.ietf.org/doc/draft-swaminathan-dka-framework/).

The proposed BOF would assess community interest in standardizing the
DKA framework, discuss the appropriate scope of a potential working
group, and identify related work that should be coordinated.

Required Details

• Status: WG forming
• Responsible AD: TBD (likely ART or SEC area)
• BOF proponents:
  Kishore Swaminathan <k.s.swaminathan@live.com>
  [Additional proponents to be confirmed]
• Number of people expected to attend: 50–80
• Length of session: 2 hours
• Conflicts (whole Areas and/or WGs):
• Chair Conflicts: TBD
• Technology Overlap: LAMPS, KEYTRANS, OpenPGP-related work, DKIM-adjacent work
• Key Participant Conflict: TBD

Information for IAB/IESG

Any protocols or practices that already exist in this space

Yes. Several protocols address parts of this problem:

• OpenPGP (RFC 9580): provides public-key distribution and use for
  encrypted and signed email, but is primarily oriented toward the email
  use case.

• S/MIME (RFC 8551): provides certified key bindings for encrypted
  and signed email, but is likewise specific to the email context and
  commonly relies on certificate infrastructure.

• Web Key Directory (WKD): provides domain-hosted HTTPS retrieval of
  OpenPGP keys associated with mail addresses, but is specific to
  OpenPGP and email encryption.

• DANE (RFC 7671) and OPENPGPKEY (RFC 7929): demonstrated the value
  of DNS-anchored key discovery, but store per-user keying information
  directly in DNS, which creates scaling and operational challenges for
  large numbers of identifiers.

DKA differs from these approaches in that it combines DNS-based service
designation (not per-user DNS records), HTTPS-based key retrieval,
verified mailbox-control binding, selector-scoped keys for application
agnosticism, and a single framework-defined lookup result for a given
(identifier, selector) pair.

Which parsing or serialization formats are involved

• DNS TXT records (tag-value format, ABNF specified)
• JSON (key lookup responses, registration payloads)
• Base64 (public key encoding, algorithm-agnostic)

Which existing or proposed IETF working groups might the work interact with

• LAMPS: potential interaction regarding key formats,
  certificate-related comparisons, and S/MIME interoperability.
• KEYTRANS: transparency mechanisms could complement DKA in future
  work.
• OpenPGP-related work: OpenPGP keys are one possible key type
  distributed through DKA selectors.
• DKIM-adjacent work: DKA uses DKIM validation as one verification
  method and follows existing DNS tag-value conventions.
• SECDISPATCH / DISPATCH: possible venue for initial triage and
  routing guidance.

Drafts that would be in scope for the working group

Initial scope would likely include:

• draft-swaminathan-dka-framework-01: the DKA framework specification
  (DNS designation, key registration, key lookup, selectors, and IANA
  considerations).

Possible future work, but not part of the initial charter, could include:

• application profiles for specific use cases,
• lifecycle management extensions,
• transparency log integration.

What is the intended outcome of the proposed BOF

The intended outcome is to determine whether there is sufficient
community interest and support to charter a working group to
standardize the DKA framework.

Specific questions for the BOF:

1. Is there community consensus that a standardized, DNS-designated,
   application-agnostic public-key discovery mechanism for
   email-address identifiers is needed?

2. Is the architectural approach sound: DNS for service designation,
   HTTPS for key retrieval, and email-based mailbox-control verification
   for registration?

3. Is the scope of the current framework draft appropriate for a
   working-group charter, or should it be narrowed further?

4. Are there existing efforts that should be merged with,
   coordinated with, or clearly distinguished from DKA?

5. Is there sufficient interest and expertise to justify working-group
   formation, or is another path more appropriate?

Proposed charter (if WG forming)

The DKA working group will standardize a DNS-anchored framework for
discovering public keys associated with email-address identifiers. The
framework enables Internet domains to designate, via DNS, a key service
that verifies, stores, and distributes selector-scoped public keys for
identifiers under that domain.

The initial working-group deliverable will be:

1. DKA Framework Specification (Standards Track): DNS-based
   designation of Domain Key Authorities, the key registration
   protocol, the key lookup protocol, selector-scoped key management,
   security/privacy considerations, and IANA registrations.

The working group may later consider additional work, such as
application profiles or lifecycle-related extensions, if the core
framework is successfully adopted and sufficiently stable.

The working group will coordinate as needed with related communities
including LAMPS, KEYTRANS, OpenPGP-related work, and DKIM-adjacent
work.

Milestones

• Month 3: Adopt DKA Framework Specification as WG document
• Month 9: Working Group Last Call for DKA Framework Specification
• Month 12: Submit DKA Framework Specification to IESG

Links to the mailing list, TAO (if applicable), and other relevant information

• Internet-Draft: https://datatracker.ietf.org/doc/draft-swaminathan-dka-framework/
• Reference implementation: [URL TBD]
• Working demonstration: https://keyzero.org