Still, I do think it would be possible to do.

My point was that it has already been done, twice: SSH and TLS.

Whether the asymmetric keys are wrapped in OpenPGP certificates, X.509 certificates, or nothing at all doesn't change the fact that we're already using public-key crypto to authenticate network streams (client-to-server and server-to-client). We don't need new network-stream crypto protocols to use public-key crypto for authentication. We need to fix the broken certification systems that help us know who the keys belong to.

BobGregg wrote:

Much like the SSL cert ecosystem today provides a means of merchant identification, without there either being a single point of failure or sinister government control.

Actually, as it's currently implemented, the SSL cert ecosystem today provides many points of failure and sinister government control that compromise the whole system. Count the number of "trusted" root CAs in your web browser -- any one of them can be evil, compromised by crackers, or agree to government intrusion in order to compromise any your web-based communications. Here's a more in-depth analysis of the problem. Even worse, these "trusted" roots can create subordinate CAs, which can in turn compromise all of your X.509-secured communications. You might also be interested in the EFF's SSL Observatory, along with their analysis of the abysmal state of today's X.509 certificate infrastructure.

To solve this properly, we'll probably need to do at least the following:

• enable multiple paths of certification for any certificate -- X.509 only allows one issuer per certificate (OpenPGP allows an arbitrary number).
• provide tools to let users indicate scoped reliance on certifying authorities. For example, you might be fine with using the US Government's certifying authority to identify https://www.irs.gov/ (note: the IRS currently uses akamai's CDN, so TLS is entirely broken for it). But you might not want to accept their certifications for https://slashdot.org/ (note: slashdot doesn't currently use TLS properly site-wide either, even though it should) or any other site that is frequently critical of the US government.

I agree that we need work on distributed trust infrastructure. That's why i contribute to the monkeysphere project -- we're pushing OpenPGP-style multi-party, user-centric certification into SSH, the web, and everywhere else we can.

I'm just not convinced that the US Government is likely do this the right way. It seems probable that they'll be happy with centrally-controlled, single-trust-path certification. Or that they'll botch it in the same way that X.509 is currently botched.

The scheme you're proposing is open to a replay attack by a man-in-the-middle. The MITM simply requests the randomly-generated string from the server, forwards it verbatim to the client, and passes along the client's response as well.

To do this right, you'd need to have the thing being signed/decrypted/passed around (the nonce) embed some unimpeachable detail about the established channel that should be visible to both sides of the transaction without being controllable by either (e.g. start by negotiating an anonymous DH key exchange, then embed the negotiated DH key in the nonce). Then both parties need to:

• generate and sign their own nonce,
• verify the other party's signature over the received nonce
• verify that the key the other party is using does in fact belong to the expected party
• inspect the received nonce to ensure that it is bound to the established channel

This sort of asymmetric-key authentication scheme is already implemented bi-directionally in two different widely-deployed stream-based connections: SSH and TLS. Please don't try to propose a third protocol, it's hard enough to get right in these two already :)

The asymmetric keys in question can be wrapped in whatever sort of packaging you like -- raw pubkey material (commonly used for SSH), X.509 certificates (commonly used for TLS), OpenPGP certificates, or some mixture of the above. See the monkeysphere project if you want to use OpenPGP certification with SSH and TLS connections.

i can't believe this is being moderated as Insightful. What are you mods thinking!?

i'm a huge fan of djb's work, and i use his software (and i use Debian), but quoting his theories about cross-platform compatibility as support for your argument is pretty weak. djb's strong suit is his technical and mathematical rigor, not his infamous interpersonal skills.

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage:

• Just installed package foo, but don't really know quite how you might use it best? debian policy lets you confidently look in /usr/share/doc/foo and know that you'll find *something* that the package maintainer thought would be worth reading, even if it's only the changelog.
• package doesn't have a man page? thanks to policy, that's an actual bug, not just an inconvenience.
• need to understand exactly how service foo starts and stops? you can read /etc/init.d/foo
• where are the config files? you can find them in /etc/foo/
• and so on...

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard (see "Filesystem layout" on this page)! I respect the man for his technical prowess. And i'll grant that his proposed scheme probably makes more technical sense than the FHS, when viewed in isolation.

But you don't achieve cross-platform compatibility through technical rigor. You achieve it through compromise, social and political consensus, transparency, legacy support, and published standards. The FHS currently represents all of those things, as does debian. In fact, that's why debian endorses, attempts to comply with, and contributes back to the FHS, because it is committed to cross-platform compatibility. djb's technical nit-picking, while usually a good thing, does him a disservice in this particular area, and debian gets it right.