*Ben >> Architecturally, I think the idea of a keyserver per domain seems reasonable, and discovery via DNS is plausible enough. However, I would suggest the following changes and additions to the draft:*
It appears that the DKAs collectively lead to a distributed PKI for email IDs anchored on domains and DNS. Although this is not a PKI in the RFC 5280 sense, mentioning this context would make the specification much more understandable. *Ben>> 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.* I agree. HTTPS is for connection specification, not identification or discovery. TXT always works. New RR type is a deadend. Other suggestions: - Normalization Rules: Before banning dot-removal or plus-tag stripping, I recommend checking the current practices of Gmail and Outlook. This will ensure your specification caters to the majority of email IDs. - Document Weaknesses: (a) Only halfway through the document I realized that the DKAs need not be subdomains and need not even be part of the domain. Here your examples are misleading - at least one example should show the DKA as outside the domain. (b) DKAs need a full mail server for both incoming and outgoing email and all the corresponding DNS setup. This should be mentioned in the Manageability Considerations. (c) Precisely because of (b), DKAs are most likely cloud-sourced. What special privacy or security concerns rise from cloud-sourced DKAs? - Demo: Your demo only shows part of your specification (verification and lookup) but do not show your DNS setup. How are your demo domains and their DKAs setup at the DNS level? Good luck. Bob Traverz On Fri, May 29, 2026 at 3:19 PM Ben Schwartz <bemasc= [email protected]> wrote: > 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] >> > _______________________________________________ > art 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]
