Question about PKI-less local https URLs

[Michiel de Jong]

Hi!

In https://wiki.mozilla.org/FlyWeb#Security the following URL scheme is discussed:

Public Keys as Names
One tool the above reference doesn’t discuss is using a public key as a name.  The basic idea is that the device would advertise via Bonjour or the like a name like
<public-key-digest>.printer.<special-TLD>. The browser would handle this specially as follows:

Instead of validating the certificate against the global PKI, it would just check that the public key had the right digest
In the UI, it would just display the right part of the domain name (e.g., printer.<special-TLD>), omitting the public key digest

One advantage of this design is that it leverages the existing browser origin machinery, so it only requires very small modifications to the browser.

My question is, why still include the ".printer." infix? IMHO, displaying a padlock next to "https://printer.<special-TLD>" in the browser's address bar could suggest that this host is in some way the "printer", especially because users are used to trusting the hostname of https://mybank.com/ when they see a padlock, whereas AFAICS this was not checked in any way for the "printer" string.

Wouldn't it be better to use <public-key-digest>.<special-TLD> as the hostname in Bonjour, and then just display something that looks like:

 https://PxwGLFxy1x0hxgIVZ7cKFN0eE9kcFjmxCQ1kftXs6aw.self-signed/login

(greying out the ugly parts, using "self-signed" as the special TLD) in the address bar? The tab head would still display the human-friendly page title anyway, and it would make it easier to cut-and-paste the URL from the addressbar in a reliable way.

Cheers,

Michiel.