FYI, Namecoin's domain spec (
http://dot-bit.org/Domain_names#TLS_support ) has something about SSL/TLS support.
Additionally, I'm putting some code together to implement the "fingerprint" field at
https://github.com/itsnotlupus/nmcsocksThe general idea is to require .bit domains to use self-signed certs for SSL, and have a local namecoin client act as a man in the middle, verify that the self-signed certs' fingerprint matches the fingerprints found in the namecoin record for the same domain, and rephrase the SSL connection to the browser to appear to use a certificate signed by a "central" namecoin authority (a locally generated CA cert the user has to install in their browser.)
That's not exactly the same implementation as what freeloader247 suggested, but the end result is similar in that you're eliminating yet another central authority when interacting with namecoin domains.
As a bonus, browsers don't need to be tweaked beyond adding a new certificate authority in their browser and using a local namecoin proxy, and certificates can be created/updated/managed at will, as long as their fingerprint is present in the necessary namecoin record.
As an aside, the namecoin fingerprint field could also be used to validate other keys sent by a host to authenticate itself, SSH coming to mind here.
*edit: I just noticed this is almost exactly what da2ce7 proposed in a post from last December:
Since the domains all have fingerprints of their TLS certificates, when one connects to a server defined by a BitDNS record and the server replys with a secure connection, the client can check if the secure connection is valid, not by using a CA, but rather cross-referencing it with the fingerprint included in the block chain. Man-In-The-Middle attacks are very, very, very difficult under this system.
