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
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.