A Robot CA is an automated key signer. Conceived by Phil Zimmermann, the robot's signature indicates only that the user's email address is correct, not that the name on the key correctly identifies the user. Given a key signed by the Robot CA, you can be sure that the email address on it really can read email encrypted with that key. This casual verification can be used as part of a larger scheme to make encryption easier for users who wouldn't otherwise benefit from it.
I'm writing about the Robot CA because I've created one.
The problem with strong verification
Getting a reliably verified signature on a PGP key is difficult, and most people don't do it. Many of the keys I see from people I've "run into" on the net have no signatures on them at all. Since I won't trust such a key, they might as well not have a key. By demanding good trusted signatures, I'm eliminating the possibility of private communication with someone whose identity I can't verify.
If I knew only that the key went with the email address, that would be an improvement. I don't care if the key really belongs to name on it as long as I can communicate privately with the owner of the email address.
A system where weak verification is better than none
Imagine a system where key management is done in the background without user intervention. When you install a mail reader, it generates a key for you with your name and email address on it. It submits this key to a robot CA, and the robot responds with a signature. The mailer takes the signed key and publishes it to a key server for other mailers of its kind to use. The signature on the key means only that the key goes with the email address on it.
When the user tries to send mail to some address, the mailer automatically checks to see if there's a public key for that address. If there is, it checks to see if the key has been verified by a Robot CA. If it has, then it uses the key to encrypt the outgoing email. The users get some benefit of encryption without having to think about it.
Without the robot in this scenario, a malicious user could create a key with the victim's email address on it and send it to the key server. Then users who were auto-encrypting would send the victim messages encrypted for a key the victim doesn't have. With the robot, this simple attack is foiled. The mailer won't use a key that hasn't been verified by a robot. If the attacker submits the fake key for verification, the signed result will go to the victim. The victim's mailer can then ignore it because it knows it doesn't have the private key to go with the attacker's signed public key.
Real verification is still better.
This is no replacement for the traditional web of trust, but it will work nicely with more advanced users who want to use the more traditional methods. If Alice likes trust the way it is, she doesn't have to trust the robot's signatures. She continues to work the way she did before the robot existed. She can still have her key signed by the robot, and she will receive encrypted mail from those who do. Additionally, if Bob has been doing all his crypto in the background without thinking about it, he can still "graduate" to the more advanced methods of key management if he wants to.
Central authority Bad! Decentralization Good!
This minute, there's only one robot CA, so it's a central authority. Ideally there would be many, and no one wold be a central point of failure. ISPs could run them as a service. Given many trusted robots, their public keys could be included on the read-only installation media for mail software and operating systems. This would prevent an attacker from masquerading as an authority.
How it works
The basic design and operation of the Robot CA is simple. It receives a public key block by email (it could use CGI in the future). It looks at the UID(s) on the key, searching for an email address. It aborts if it can't find a valid email address in the UID. Then it signs the key, and emails the signed result to the email address it found. If the mail bounces, it ignores it. If the mail gets through, the user has a copy of their own public key with the robot's signature. The user can then import the new signature and update a keyserver with it.
The one I've written has some limits detailed on the Robot CA's home page. In particular, it can't deal with MIME encoding, and I haven't attempted to support PGP2. Still, I think it's a step in the right direction.
My hope is that this will make encryption more accessible to ordinary users, and ordinary users' email less accessible to snoops.
Votes: 62