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-discuss@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_Tradi... [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)