Then the gov't can do a handy man-in-the-middle(MITM) attack. They can distribute a different public key for you, and intercept messages, decrypt them, alter them if desired and reencrypt them with your proper public key.

Of course if the whole cyphertext is signed by its sender, then the signature would be invalidated. But the same sort of MITM stuff to the signature.

If you are willing to compromise one key to spy, compromising two is no big step to take.

This problem exists anytime you have one big repository of public keys. The only defense I know of is to have multiple, independent key repositories.

Isn't that problem addressed by you signing the government signed key, after they sign it? If they started floating fake public keys for you, you would be able to detect it, by randomly testing the public keys they send out. I'm sure a watchdog group could/would be setup to randomly test keys and investigate government shenanigans and public complaints.

Also the idea here is ID verification, NOT secure communication. If the government wants to forge the id of it's citizens, there is no stopping them. What's to stop them from issuing false passports and driver's licenses now?

It boils down to someone has to be in a position of trust, and generally we assign that to the government. I trust Driver's licenses now as ID, and would trust them even more, if there was a DriverID Verification website, where I could see a photocopy of the valid license. I would prefer that website be run by the government so that it is under public scrutiny.... instead of fighting the lawyers at privately run sites, who may be corrupt or mob-related.

---

I'm not really a human, but I play one on earth Remember How Lucky You Are

It's been a while since I studied cryptography in any detail, but to test the validity of your signature on the key, I would have to use your public key. In this case I'd be using a compromised key, then of course it would show as OK.

It seems to me the best way to handle PKI is to have several independent (preferably non-profit) corporations that each provide compatible infrastructure operating on different software platforms.

Each body would be responsible for setting their own standards for identification, etc. Also each would have to determine their own policies for handling search warrants, wiretaps etc. These policies should be publicly known.

As a user, I can select one or more key servers to provide key information for me. If I am paranoid, I can sign up for many key servers. Other users can decide which PKI bodies they will accept keys from. Automated systems can be set up to catch discrepancies between different PKI bodies. Software can be configured to automatically check multiple PKI providers.

Natural places to provide identity verification services to a PKI body are Post Offices, banks, DMVs.

Driver's licenses are a reasonable form of ID. Fakes are obtainable. Generally, if the police/state wants evidence to use in court, they have to obtain it through the use of search (wiretap) warrants. Faking DLs and using them to falsely change information in a PKI body would likely make information obtained inadmissable (unless you are an enemy combatant, then they'll just torture you until you confess and then throw away the key). That tends to restrict them to serving warrants to the PKI bodies directly. If I am super paranoid, and I keep 15 PKI server accounts, then John Law must serve 15 warrants to 15 different bodies and then must be executed in a something close to lock step if they are going to pull a switcheroo without me noticing. If even one body refuses to comply then I should start seeing red flags as the PKI bodies start to disagree about my key.

With any number of PKI bodies, I could monitor my keys to make sure that they are correct. Of course an evil the PKI server could be configured to tell people who it thinks are me (by IP address perhaps) that my key is the correct one, while passing the tweaked key to everyone else. Multiple independent servers makes this harder to achieve.

All this sounds great to me, but I am not a cryptographer. Bruce Schneier could probably poke a dozen gross holes in this scheme before his morning coffee. One thing that stuck with me about cryptography, is that protocol design is hard, key exchange is hard and algorithm design is hard--don't build production systems yourself (unless you have spent years gaining mastery of the field), stick to known and publicly evaluated systems. 99% of the time if Eve wants to listen in, she won't crack your cypher, she will find a hole in your protocol and exploit it.


TGI says moo

For email, Thunderbird and mutt support client keys. There's also built-in support for PGP/GPG in mutt to encrypt the email itself. I'm sure there are plugins for Thunderbird to do that if it doesn't already. Many servers can be configured to use TLS-encrypted sessions for MTA to MTA communications when available at the other endpoint.

It's typically considered the MTA's job to deliver the mail first and to concern itself with security second, which is an attitude that needs to change before any of this improves. It does little good to have SSL or TLS sending and receiving if the mail routing in the middle is in plaintext. Encrypting and signing the message at the endpoints with PGP/GPG and sending it through clear channels should offer whole-path protection up to the point where they are easily borken. AFAIK, it still takes quite some time to break a 2048-bit key for GPG.

Here is a nice article on setting up an htaccess based client ssl certificate system. client ssl certs Now I have something to play with this afternoon. :-)

It appears to be in line with your desire for different keys for each site, and is generated by the site and the access key is given to the client. I guess the weakness here is how you get the key to the client? It would have to be delivered personally to them, but in an office setting that would be easy.

My envisioned model is slightly different, with a common public key that you use for all sites, that the server admin would retreive from a public server.

Anyways, this look cool, I hope I can get it working.

---

I'm not really a human, but I play one on earth Remember How Lucky You Are

It is also possible to generate a key pair, store your private key and public key in your browser, and send your public key to the server. The bigger-named browsers mostly allow you to import the keys, but not to generate them. Setting up the system on the server is left as an exercise. ;-)

If you're dealing with shared secret encryption or distributing a private key, the trick to getting the secret key to the intended party is to do so out of band or to transfer it along a channel already secured by some other encryption.