On 5/5/25 10:13 AM, 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.
I was aware of Tor onion services, but not of self-authenticating traditional addresses. Thank you. > 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. Could the user experience problem be partially resolved by providing the URL as a QR code on the device itself and prompting the user to provide a human-memorable alias whenever they encounter a new CGDN in the URL bar? That avoids users ever having to interact with the ugly cryptographic hash, at least in common cases. [1] has some interesting ideas, but I'd rather leave them for later to keep the initial implementation simple. I also wonder how many users actually type in domain names they have memorized instead of relying on search. I do, but I would not be surprised if non-technical users often do not. >> 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 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. Yes, I did forget to make that replacement. I sent the same email to chromium-disc...@chromium.org and forgot that I had mentioned Chromium in the body by name. > I also recommend citing RFC 7686 [3] and CAB ballot 201 [4]. > > 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/-- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
