[webkit-dev] Interest in supporting cryptographically-generated domain names?
Demi Marie Obenour
demiobenour at gmail.com
Thu May 15 22:54:37 PDT 2025
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 at 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)
More information about the webkit-dev
mailing list