3 ms·
The OP was originally pointing to ArsTechnica. One of the top comments there suggested that the solution lies in relying on DNS which provides "globally unique
by feelin_googley 9y ago
The OP was originally pointing to ArsTechnica.
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 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.
- Shoothe 9y agoWait, are you suggesting using public key fingerprints instead of easily memorized names? Just like onion addresses?
- feelin_googley 9y agoPlease note the word "plus" in the comment. s/instead of/in addition to/ For example, DNSCurve-enabled nameservers are in the form key.name.tld, cjdns addresses have a key fingerprint embdedded in the users IPv6 address, etc.
- Shoothe 9y agoThat little word changes my option on this proposal. > cjdns addresses have a key fingerprint embdedded in the users IPv6 address, etc. Very cool idea! I'll read more about this...
- feelin_googley 9y agoI highly recommend reading the excellent draft document from Usenet at the URL I posted, particularly the example of the "Western Wisconsin Computer Company". It is much clearer than my comment and my examples of the simple concept explained therein are probably not ideal (maybe even wrong). As for cjdns, https://github.com/cjdelisle/cjdns/blob/master/doc/notes/cryptography.md https://github.com/cjdelisle/cjdns/blob/master/doc/notes/cry... From only a cursory review, I see cjdns as a network where one does not need a third party to: issue a name, issue a key, check a key against a name or a name against a key. Each user creates their own private key, their own public key and finally their own address from their own public key. Unless I am mistaken, users get public keys and addresses from other users, not from a third party.
- feelin_googley 9y agoLooks like sprunge.us is down. Alternate: http://ix.io/D2F http://ix.io/D2F (html)