Architecturally, I think the idea of a keyserver per domain seems reasonable, and discovery via DNS is plausible enough. However, I would want to see several changes in this draft:
1. Make it work with KEYTRANS. Key Transparency makes this much more powerful by reducing the required trust in the host. 2. Drop the HTTPS record mode. "HTTPS" records are for improving the bootstrapping of HTTP connections, not for identifying affiliated services that happen to use HTTP. Using a TXT record here may be ugly but at least it matches the common practice in email world (DKIM, SPF, etc.). We can also define a new RR type. 3. Note that DNSSEC is mandatory. This is presumably for discovery of public encryption keys (not signing keys, which can be accompanied by a signature chain), so the required security level is very high. Mandatory DNSSEC is very limiting, so you might want to support " https://example.com/.well-known/domain-key-authority"; as an alternative that will often be easier to deploy. 4. Reduce the emphasis on email. Email encryption has gone out of style, but there are other user@host identity systems where key distribution may be more attractive. --Ben On Fri, May 29, 2026 at 2:44 PM S Kishore <[email protected]> wrote: > All: Greetings. Based on feedback, a new version of "Domain Key > Authorities (DKA): DNS-Designated Public Key Distribution for Email-Address > Identifiers” has been submitted. https: //datatracker. ietf. > org/doc/draft-swaminathan-dka-framework/ > > All: > > Greetings. > > Based on feedback, a new version of "Domain Key Authorities (DKA): > DNS-Designated Public Key Distribution for Email-Address Identifiers” has > been submitted. > > https://datatracker.ietf.org/doc/draft-swaminathan-dka-framework/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-swaminathan-dka-framework/__;!!Bt8RZUm9aw!6E6r7m2UcDjNUlDJn5f-_2YbNY_dnb0DMZYPp7rQQyFjQaOp_ulMOscGaXcvQSDlKeb7ENzrgBtIoDA0fBMD$> > > > Abstract: Email-addresses are widely used beyond email itself, and > the Domain Key Authority (DKA) framework provides a DNS-anchored > mechanism for discovering public keys associated with those identifiers. A > domain uses DNS to designate an authoritative key service for > email-address > identifiers under that domain. Instead of storing per-user public keys in > DNS, > the domain publishes a lightweight DNS record (HTTPS and/or TXT) > identifying the > hostname of its Domain Key Authority (DKA), and clients retrieve > selector-scoped public keys from the DKA over HTTPS. This design > uses DNS for what it does well -- global discovery and delegation -- while > moving per-identifier key storage and retrieval to infrastructure that > scales independently of DNS. The result is a DNS-anchored, application- > agnostic framework for discovering public keys associated with > email-address identifiers. The current draft adds HTTPS DNS record and > retains TXT records for backward compatibility, and provides a > deterministic > DKA discovery and key lookup procedure. > > The concept is not theoretical: an open-source implementation and a demo > site exist at https://keyzero.org > <https://urldefense.com/v3/__https://keyzero.org/__;!!Bt8RZUm9aw!6E6r7m2UcDjNUlDJn5f-_2YbNY_dnb0DMZYPp7rQQyFjQaOp_ulMOscGaXcvQSDlKeb7ENzrgBtIoOEMneTD$> > . > > All comments appreciated. > > Kishore Swaminathan > > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
