PKI deserves to die

[ciphergoth]

In response http://www2.cio.com/research/security/edit/a05232002.html

From: Carl Ellison <cme@acm.org>
Subject: Re: PKI: Only Mostly Dead

Scott,

as far as I'm concerned PKI is not only dying, it deserves to die
much more quickly. That's because when it works, it still doesn't
work.

See the two papers to which I contributed at last month's PKI
Research Workshop http://www.cs.dartmouth.edu/~pki02/

Look especially at what we call the John Wilson problem. In a
nutshell, if you bind a name to a key, even if you do that always
accurately and even if your certificates interoperate with my
software, you have done nothing for me if there are more than about
1000 certified people in the world. That's because there are too
many John Wilsons. I can't tell them apart by name, when you lump
them all together into one big pool (the pool of all people the CA
certifies -- e.g., a big one like VeriSign -- or a little one like
Intel Corporation with only 70,000 and 8 John Wilsons). If I can't
tell them apart (and people can't -- for which we have definite
proof), then I am forced to make a guess as to which one is the right
one -- if the right one is represented at all -- and when I'm handed
a certificate saying that this S/MIME message or HTTPS page came from
John Wilson, I'm not given the list of all John Wilsons, so I don't
even get to compare them to see which one looks like the closest
match.

PKI deserves to die not because of vendor greed, although there is
plenty of that, but because the original idea was wrong. When you
bind a person's name to a public key you have not identified the key
in a way that is useful to me. That's because if I know the name of
the keyholder, I still don't know who the keyholder is.

- Carl

P.S. I strongly recommend your reading those papers in the preprints
available at the PKI Workshop web site.

+------------------------------------------------------------------+
|Carl M. Ellison         cme@acm.org     http://world.std.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

Comments

Covering several points

[giolla.livejournal.com]

For photo's who would count as a trusted third party, and how much do you think
that would cost per key? If you're thinking of a PGP style web of trust then
it'll fall over pretty quickly either by deliberate misuse or just because
people are crap and will say they trust things they shouldn't.

Photo's aren't much use for idenitfying people you've never met, and are of
even less use for identifying machines.

As far as trusting the "key" goes why would I want to? A key that isn't tied
to some other information isn't the slightest bit of good. I need to know that
a given key is associated with the machine I'm connecting to, the e-mail
address I'm communicating with, or the user I'm authenticating. So unless I
associate thet key with some other data it's useless.

If you give me a key and say it's your key, then yes I can trust it directly
and likewise for your server. However I'd want to make a note of that, and
would then might want to pass on that note when someone who asks me for your
key. They'd of course then have to trust me when I say ciphergoth gave me
this key and it's really his. They'd probably make a note of it in fact. Of
course having been given the key by me with or without an attached note, they
should verify the finger print directly with you in the same way they should
now. If I was using the key to exchange e-mails with you I'd probably note
your e-mail address against it and oops back to square one.

To be useful you need a fixed relationship between the key/finger print and
some pointer to a unique idenitifier, and unless I've met you and until image
recognition software is a lot better a photo isn't it.

Also I'd have to refute your statement about the chances of a fingerprint/key
being unique, that is only true for a given implementation of the PK part of
PKI, but if you get the I part right the uniqueness or otherwise of the keys
themselves really doesn't matter as much, as in most infrastructures
the signed data normally contains several bits of unique data.

The problem with PKI isn't the cryptography, it's the infrastructure part.
Maintaining trust, distributing keys, and revoking them if the data they are
associated with changes. Doing this within limited communities, such as
within a company/* or a community small enough that photo's are viable */
is fairly easy, but to date no one has made it scale well. Changing which
bit of data you trust doesn't move you any closer to resolving the problem

Re: Covering several points

[ciphergoth.livejournal.com]

Photos are useful when I want to exchange encrypted email with my friends. If I have your signed key, and you sign a certificate binding a photo to ruis's key, I can have the greatest confidence that the key belongs to the person I want it to. They're not so useful in a commercial setting.

Why does it make more sense to trust a domain or an email address than to trust a key? They are more fickle.

Also I'd have to refute your statement about the chances of a fingerprint/key being unique, that is only true for a given implementation of the PK part of PKI

Er, eh? If the probability that two parties might have the same public key is non-negligible, the crypto is weak. If the probability that two parties with distinct public keys might have the same key fingerprint is non-negligible, the crypto is weak. Only broken systems can have fingerprint collisions. I'm somewhat familiar with all the PK signature algorithms in widespread use, but what I'm saying here is provably true of all PK systems and all hash functions. If you really want to refute this point, please at least provide a counterexample.