On 5/5/25 10:44, Matthew Finkel wrote: > Hi Demi, > > Interesting idea! Comments in-line: > >> On May 4, 2025, at 5:52 PM, Demi Marie Obenour via webkit-dev >> <webkit-dev@lists.webkit.org> wrote: >> >> A major limitation of the Web PKI is that it cannot issue certificates >> for devices that do not own a public domain name or IP address. To >> solve this problem, I have created a proposal for incorporating a public >> key in the domain name itself, allowing a server to be authenticated >> without involving a third party. The proposal can be found at >> <https://demimarie.github.io/cryptographically-generated-domains.html>. > > This idea of using the hash of a public has never gained widespread > excitement, but maybe this time is different! The proposal seems to combine > some previous ideas around self-authenticating addresses [0] and > self-authenticating traditional addresses [1]. I recommend citing the prior > work in the proposal for completeness. The Open Questions section mentions > Tor’s onion services, and indeed a lot can be learned from them with regard > to their addressing scheme. Primarily, cryptographic hashes are not > user-friendly, in fact some would consider them user-hostile because they > lack any inherent meaning and require byte-for-byte comparison that is > tedious. However, the value of 1) uniqueness, 2) self-authentication, and 3) > end-to-end security are important characteristics.
The main difference here is that, at least initially, this is mainly intended for IoT devices, where the link is provided via QR code. This avoids the user ever having to memorize the domain name. The user could be prompted to save the domain name under a human-readable alias for future use. >> Is an implementation of this something that Chromium would be interested >> in? I do plan to propose this to the IETF, but first I want to check if >> there is interest from browser vendors. > > I assume you forgot to replace Chromium with WebKit? :) But, with regard to > Chromium, I believe they were exploring usability improvements in the area of > supporting top-level HTTPS navigations to devices on a local network that > don’t have globally valid TLS certificates. I can’t find the proposal at the > moment, though. > > I also recommend citing RFC 7686 [3] and CAB ballot 201 [4]. I updated the article with RFC 7686. I left out CAB ballot 201 because I didn't see it being relevant. I also added your name in the credits. > I am interested in seeing if there is broader support of this idea, too. > > [0] https://spec.torproject.org/rend-spec/encoding-onion-addresses.html > [1] > https://www.researchgate.net/publication/337510353_Self-Authenticating_Traditional_Domain_Names > [3] https://www.rfc-editor.org/rfc/rfc7686.html > [4] https://cabforum.org/2017/06/08/ballot-201-.onion-revisions/ What would the logical next step be? Should I try to implement this in libsoup (used by WebKitGTK), or should I create an Internet Draft? -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
