One of the top comments there suggested that the solution lies in relying on DNS which provides "globally unique" names.
But the commercial CA system already relies on domainnames. That is its weakpoint.
The author at ian.sh shows how additional checks by third party CAs, e.g., business registration, do not necessarily solve the problem either.
The best proposals I have seen for solving the problem are ones that have no reliance on third parties, e.g. certificate vendors, domainname vendors, etc. Another way to think of non-reliance on third parties is "middlemen". If they are necessary, then the system is vulnerable.
It is a very old problem that apparently has never been fixed. Today solutions that try to avoid middlemen do exist. But comprehension of why this is necessary is apparently still small-scale because focus remains on the commercial CA business, which seems to be at odds with any system that needs no such middlemen.
This author, who many HN readers know, explains it much better than I can: http://sprunge.us/NHTK
Users or businesses can create and exchange their own public keys directly. (Think of HTTPS like SSH.) They do not have to rely on third parties to assist them.
One does not need a third party CA to perform effective encryption. Have you ever wondered if browser warnings are an insidious way to keep commercial CAs in business?
Public keys are globally unique. Names are not. One could combine them (e.g. key fingerprint plus name) to form an identifier that is better than a name alone.
Recap:
Names alone are not enough to perform effective disambiguation via ICANN DNS or major-browser sponsored CA system. Volunteer-supported Wikipedia actually does a better job of disambiguating names than these commercial services.
Public keys can be generated directly by the named entity they represent instead of by third parties. Middlemen are unnecessary and cause the system to be vulnerable.