Instead of X.509

Just include the site’s public key finger print in its domain name and the problem is solved. With this simple idea the CA’s rôle disappears and they are no longer legitimate stake holders. Here is the minimal necessary software change. A related rôle arises: an ‘introducer’ which is a site that maps between common institutional names and the legitimate URL with said fingerprint. Indeed you might ask about corrupt introducers, but in that case you are vulnerable to only the introducer you choose, not to all the CA’s in the world. If you are dubious you can ask other introducers; I am sure that there would be many.

An introducer likely maps fingerprints to various common names. These ‘common names’ might be in the local language and character set. (I prefer “Baidu” to “百度”.)

All too often today HTTPS is used where there is only one party with the vaguest reason to keep a secret. When a web page uses https to refer to some other site to present an ad to me, and my browser does not trust that 2nd site’s cert, the browser asks me about my expectations about the 2nd site, which I have never heard of. Bizarre! I have no expectations regarding that 2nd site to be in conflict with and the browser knows this! In the case of the URL of the ad: the first web page author knows the legitimate domain name which includes the fingerprint, and that domain name is included in the first page. Problem solved!

I find this idea so obvious that I cannot imagine how it was not adopted over the complex X.509 protocol. I don’t know who first wrote it down.

The original X.509 designers might have thought that the business plan of a particular CA would involve being especially responsible and thus gain a positive reputation and a concomitant business advantage, but deployed browsers interfere with that plan. Under that idea only one of two bad outcomes seem possible to me:

Browser Behavior

The browser would know what part of a domain name was the fingerprint. The browser would use normal insecure DNS to get an IP address, use https to contact that site which would reply with a public key, perhaps embedded in a cert chain. The browser would compute and compare the fingerprint of that key with what was found in the domain name. If they are the same we are back to the conventional TLS situation where the browser has the public key of the intended site. If the domain name with FP was typed in and the fingerprint nearly matches the browser negotiates with the user over the difference; it might have been a simple typo. In any case the user is invoked upon fingerprint mismatch.


The introducer’s job is to provide a two way map between common names and public key fingerprints. Under ‘common name’ I advocate a motley collection such as: These entries are neither complete but merely a list of phrases that an impostor would find it difficult to conform to.

For each of several text lengths and each such named entity, there would be a ‘name’ of that size or smaller so that browsers could reserve visible screen space for that size name when the site is visited. This would burden the introducer to detect and reject such text by an impostor with an otherwise legitimate fingerprint. A favicon like image, in different sizes might be good to.

Of course you have a ‘book mark’ to your introducer which is an URL that includes the introducer’s public key fingerprint.

The bottom line is that when you click on a link in web page X you reliably end up on the page Y as intended by the author of page X, with the browser showing you common name of company responsible for page Y. You are relying only on that introducer that came as a default setting for your browser or that you once nominated.

The above paragraph has a difficulty; the introducer is responsible for avoiding introduction of bogus ‘institutions’ that claim such shortened names as “BοfA” within which the “ο” is from the Greek alphabet. Simple text comparisons fail to detect the effective name collision. At least legitimate introducers have an incentive to avoid such situations, but it may not be easy. More later.

The fundamental difference between CAs and introducers is that the user chooses the introducer and is vulnerable to no one else. An introducer has an incentive to behave and if he behaves, his clients will not visit impostor sites.

QR Codes

A small QR code can easily convey a fingerprint or a slightly larger QR code an URL with embedded fingerprint. Such glyphs can accompany printed ads, even on a bill board or side of a bus or business card.


There are ample fingerprints for individuals. E-mail would be improved if the domain names included fingerprints. Such e-mail addresses would be less frequently typed by hand but business cards with QR codes would serve well. An easy protocol would retrieve the full public key from the pop server indicated by the domain name and then encrypted e-mail could be sent with a symmetric crypto key included encrypted to the public key of the recipient. Facebook would love it and eagerly serve as an individual introducer.

A Problem

I have nearly swept a problem under the rug. These ‘names’ do come tripping off the tongue. Indeed few would ever master even one such name in the sense of being able to type it from memory into the address bar. Today’s ever present smart phones can remember these names and even read QR codes off of buses, business cards, magazines, etc. E-mail includes them naturally where they can be used without careful examination. Cut and paste makes composing such e-mail easy. An introducer serves well to find the ‘real name’ of your local cinema or that Korean car manufacturer.

Other Plans

RFC 4255 is designed to answer similar questions. My top level objection to DNSSEC is that there are several points of subversion among which the attacker can choose and subversion of any of these can selectively mislead some set of DNS queriers about the fingerprint of some domain name. Typically some of these vulnerable DNS systems are under the physical control of neither the browser or the administrator of the intended site.
that is responsible for telling the DNS querier the fingerprint for some specific domain name. Someone who would selective mislead some fraction of the web audience as to the fingerprint of has a choice of sever attack points any of which suffice to mislead the user of DNS or DNSSEC.

Here are differences that I gather from the introduction to that RFC.
RFC 4255this note’s plan
Make a secure connection between a domain name and a fingerprint. Make a secure connection between a fingerprint and a cluster of attributes some of which will probably be rooted in a person’s head. A person may not be sure of the domain name of the drug store a few blocks down.
Rely on the established DNS. Establish a poorly defined user selected sort of authority, the introducer, that maps between human designations, and public key fingerprint.
The domain name must be known before RFC can serve. Clever search engines find people and institutions from scant clues. Tentative identification can be amplified by further subsequent information known to the seeker.
I rely on the one DNS server that officially knows my IP address—a single point of security failure. I rely on the system of my choice—perhaps multiple ones.
As I compose the above table it is clear to me that I am proposing an unregulated, unspecified (in the sense of IETF) service category that is only slightly less general than today’s search engines which are not described by RFC’s. Google does not conform to any “search engine RFC”. A consensus of introducers may help me locate my high school classmate. Most any one of them will identify the Bank of America. There is wide a gamut between.

The only necessary technical consensus is how to include a fingerprint in a domain name. The rest seems to follow.

I need to study the RFC more closely.